[petsc-dev] [Mike McQuaid] Re: [Homebrew/homebrew-core] PETSc: import from homebrew-science (#23598)

[Matthew Knepley]

On Sun, Feb 25, 2018 at 1:55 PM, Smith, Barry F. <bsmith at mcs.anl.gov> wrote:

>
>
> > On Feb 25, 2018, at 12:16 PM, Jed Brown <jed at jedbrown.org> wrote:
> >
> > "Smith, Barry F." <bsmith at mcs.anl.gov> 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).
>

I have written a description of Jed's gnumake here

  https://www.cse.buffalo.edu/~knepley/classes/caam519/CSBook.pdf

in Section 1.3.5

  Matt


>    Barry
>
>
> >
> > I don't think examples should be installed by default.
>
>


-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20180225/48635e71/attachment.html>