[petsc-dev] Is ./configure --help broken?

[Matthew Knepley]

On Fri, Mar 16, 2018 at 9:23 PM, Jed Brown <jed at jedbrown.org> wrote:

> Matthew Knepley <knepley at gmail.com> writes:
>
> > On Fri, Mar 16, 2018 at 6:25 PM, Jed Brown <jed at jedbrown.org> wrote:
> >
> >> Matthew Knepley <knepley at gmail.com> writes:
> >>
> >> > On Fri, Mar 16, 2018 at 2:20 PM, Jed Brown <jed at jedbrown.org> wrote:
> >> >
> >> >> Matthew Knepley <knepley at gmail.com> writes:
> >> >>
> >> >> > On Fri, Mar 16, 2018 at 1:27 PM, Jed Brown <jed at jedbrown.org>
> wrote:
> >> >> >
> >> >> >> Matthew Knepley <knepley at gmail.com> writes:
> >> >> >>
> >> >> >> > On Fri, Mar 16, 2018 at 1:17 PM, Jed Brown <jed at jedbrown.org>
> >> wrote:
> >> >> >> >
> >> >> >> >> Matthew Knepley <knepley at gmail.com> writes:
> >> >> >> >>
> >> >> >> >> > I agree. We should remove all code (about 2/3 of it) which
> does
> >> a
> >> >> >> >> > hierarchy of communicating dicts (the original design). That
> >> would
> >> >> >> >> > make everything simple.  No threads, no parents, etc. We
> leave
> >> in
> >> >> the
> >> >> >> >> > help the way we want it, types for args, etc. One thing its
> >> notably
> >> >> >> >> > missing, and that PETSc Options are missing, is listing the
> >> thing
> >> >> that
> >> >> >> >> > set the option (default, command line, code, env).
> >> >> >> >>
> >> >> >> >> Does RDict even need to be persistent?  Who all reads it?  I
> >> wonder
> >> >> if
> >> >> >> >> an existing human-readable file would be sufficient instead?
> >> >> >> >>
> >> >> >> >
> >> >> >> > I think we should persist the entire set of options used to
> >> configure
> >> >> for
> >> >> >> > later
> >> >> >> > interrogation, however we have not done that much so far.
> >> >> >>
> >> >> >> CONFIGURE_OPTIONS is written to petscvariables and printed by make
> >> info.
> >> >> >> I think fewer duplications is desirable.
> >> >> >>
> >> >> >
> >> >> > This gets into a separate discussion. I think Python info is more
> >> useful
> >> >> > since its
> >> >> > directly visible to scripts we might write.
> >> >>
> >> >> Just call your Python parsing function.
> >> >
> >> >
> >> > Parse a makefile to get info? This is too convoluted for my first
> choice.
> >> >
> >> >
> >> >> But this gets back to my earlier question: who needs to read RDict.db
> >> and
> >> >> for what purpose?
> >> >>
> >> >
> >> > 1) We read this to get the configure modules during install and other
> >> post
> >> > configure operations.
> >> >
> >> > 2) I would like us to read RDict.db to get the original configure
> >> > environment
> >>
> >> The problem is that RDict.db is opaque
> >
> >
> > This seems to be a normative characterization. I think the make variables
> > are
> > "dead" because its hard to make use of them in scripting.
> >
> >
> >> and some people edit
> >> petscvariables and/or petscconf.h to work around weird issues.
> >
> >
> > Awful. We should not encourage this. It should flow from the top.
>
> Cray and others have admitted to doing this for as long as I've used
> PETSc.  It's possible to discourage it without setting land mines.


I guess my attitude is that most people using PETSc attempt to work within
the
structures setup to use it. Cray people seem not to give a fuck and just
change
stuff willy nilly until it works for them. Thats fine. We can't stop them,
but I am
not motivated to enable them either.

  Matt


>
> >>   We can't
> >> practically get rid of petscvariables without abandoning make.
> >>
> >
> > The aim should not be to get rid of them, but rather to have them be read
> > only.
>
> Good luck with that.
>
> >> It's also frustrating to debug because the names used in Python may not
> >> match the names used in human-readable output,
> >
> >
> > Changing this is trivial.
>
> Hooray!
>
> >   Matt
> >
> >
> >> and that also prevents
> >> grepping to find unused variables.
> >>
> >
> >
> >
> > --
> > 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/>
>



-- 
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/20180316/8145a6a2/attachment.html>