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

[Jed Brown]

Matthew Knepley <knepley at gmail.com> writes:

> On Fri, Mar 16, 2018 at 9:33 PM, Jed Brown <jed at jedbrown.org> wrote:
>
>> Matthew Knepley <knepley at gmail.com> writes:
>>
>> >> 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.
>>
>> I just don't see the value of RDict.  It's read interface right now is
>> grotesque (requires a lot of code and knowing a lot of almost magic
>> names, thus it gets copy-pasted).
>
>
> Criticism of the interface is fine. Rewrite it. No one will stop you.

You were suggesting stripping out tons of needless complexity.  I wanted
to understand why it even needs to be persistent, especially in this
non-human-readable form.  If the complexity is gutted so it becomes just
a dict with attributes, then it could be persisted as JSON which would
be more stable and human readable.

>>   I'd mainly prefer a nicer read
>> interface, but if we redo the read interface, I'd rather it come from a
>> human readable source.  And less duplication is better.
>>
>
> This is the truly strange thing. You are advocating communicating between
> programs by text files. This is a bizarre, and I thought dead, opinion. I
> would much rather have structured data, than unstructured text that we
> parse each time we want to do something.

Text is easier to debug and transform, and not a security hazard.

Our configure doesn't cache anything because it's really hard to
determine what might have become stale.  (CMake does a lot of caching
and makes a mess of cache invalidation.)  I really don't know what all
is in RDict.db so I can't assess when it might be stale.  It apparently
contains the build directory which Debian does not want referenced in
anything it installs.