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

[Smith, Barry F.]

  I think RDict.db is valuable, but saving it every five seconds while configure is running is not valuable and should be changed to just save it at the end of the run.

   Barry


> On Mar 16, 2018, at 8:14 PM, Matthew Knepley <knepley at gmail.com> wrote:
> 
> 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.
>  
>   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.
>  
> 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.
> 
>   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/