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

[Jed Brown]

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 and some people edit
petscvariables and/or petscconf.h to work around weird issues.  We can't
practically get rid of petscvariables without abandoning make.

It's also frustrating to debug because the names used in Python may not
match the names used in human-readable output, and that also prevents
grepping to find unused variables.