> On Feb 25, 2018, at 12:16 PM, Jed Brown <[email protected]> wrote:
>
> "Smith, Barry F." <[email protected]> writes:
>
>> So fix the damn script instead of just bitching about it! Jeepers, that is
>> what open source is all about.
>
> Yes, my last email was lazy. But your criticism of Lisandro fixing it
> in his packaging script (which he can just do without explaining to
> anyone, and doesn't have to wait for a release) is much the same.
>
>> Or if it is so terrible and unfixable then write a new script. The
>> time wasted on mailing lists and arguing with package manager
>> developers would be better spent fixing installer code.
>
> Agreed. I think this would all be cleaner with a canonical, supported
> way of querying whether a feature is enabled. Right now we have
> RDict.db (from within a Python script, but it takes a lot of work),
> lib/petsc/conf/petscvariables from a makefile, and include/petscconf.h
> from C source, all with different syntax.
Each of these is suppose to serve its own purpose.
The RDict.db is from within configure, the petscvariables is from from
within makefiles, and the petscconf.h is from within source code.
The model used to be ok until the test harness (and maybe the new gnumake
test system) needed information that is not provided in petscvariables.
I think the correct fix is not to get rid of the three data sets but to make
sure that each data set has everything needed for that mode of usage. So
petscvariables should contain everything needed by the makefiles so the
makefiles don't need to try to get information from a different source. In fact
isn't this the only problem? Isn't it relatively easily fixable by putting more
info in the the petscvariables and then any horrible code that tries to get the
information for makefile from petscconf.h can be removed?
What do you propose?
>
> It would be a lot less code to write the install directly in the
> makefile, and would get permissions correct by using the 'install'
> command.
Anyone is free to write the installer in make if they like. It use to be in
make but we found it too hard to maintain so switched to using python a long
time ago. (This was before gnumake).
I find all the gnumake code you have contributed to PETSc completely
incomprehensible and hence impossible to maintain which is why I prefer the
easily understood python installer (that yes it definitely does need work).
Barry
>
> I don't think examples should be installed by default.
