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

[Matthew Knepley]

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.


> >>   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. 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/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20180317/2a35d224/attachment.html>