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

[Jed Brown]

Matthew Knepley <knepley at gmail.com> writes:

> On Fri, Mar 16, 2018 at 11:50 PM, Jed Brown <jed at jedbrown.org> wrote:
>
>> 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.
>
>
> Okay, JSON is fine. I am opposed to YAP.

Well, parsing makefile variable statements into a dict is in the
standard library.

>> >>   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.
>>
>
> I think there is a conceptual difference here. "Caching" is the retention of
> test results to be used in a _subsequent_ run of configure. This is wholly
> wrong, and we do not do it, as you note. We persist the configure
> information
> directly as Python modules in order that a later consumer can get at it.
> This is safer, since there is no translation between the code that ran in
> configure and what you output. 

pickle can serialize code.  So when you load from a file, you could end
up running arbitrary code.  Restricting the serialization to
human-readable data eliminates a lot of complications when reasoning
about its behavior.  Duplication of that data is a separate matter.

> I think it is easier to debug, because you do not have to debug
> serialization at the same time. I would also argue its easier to
> transform because it is already code, but I could see the other side
> on that.
>
>   Matt
>
> -- 
> 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/>