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

[Jed Brown]

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.

>>   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/>