[petsc-dev] configure issues

[Matthew Knepley]

I can't believe you guys want further screwing around with the C
preprocessor. I want all that crap completely
out of the system. We are very close to that.

  Matt

On Sun, Feb 6, 2011 at 1:00 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
> On Feb 6, 2011, at 12:16 AM, Jed Brown wrote:
>
> > Isn't this just making up for the editor (and perhaps static analysis
> challenges with Python)? As long as the definition is explicit, grep -r
> HAVE_FOO config/ should locate the definition. For the other direction, you
> can grep the source tree (fast if it's in memory or indexed). So how about a
> couple Emacs functions for this instead of writing fragile file system paths
> into the configuration macros?
>
>    Getting them into etags would be good.
> >
> >
> >> On Feb 4, 2011 1:03 AM, "Barry Smith" <bsmith at mcs.anl.gov> wrote:
> >>
> >>
> >> On Feb 3, 2011, at 1:35 PM, Jed Brown wrote:
> >>
> >> > On Thu, Feb 3, 2011 at 16:27, Barry Smith <bsmith at mcs.anl.gov> wrote:
> >> >
> >> >
> >> >>  Then you are not going to like my next idea. I think that
> "configure"
> >> >> tests should be imbedded directly into the source code and evaluated
> at
> >> >> compile time to determine what gets built etc. In other words no
> distinction
> >> >> between configure and build time :-).
> >> >>
> >> >
> >> > How to handle tests that need to actually be executed, in a batch
> >> > environment?
> >> >
> >> >
> >> >> This also eliminates the possibility of "incorrect semantic
> information in
> >> >> comments" since the comments won't be "requires X Y and Z" but
> instead the
> >> >> actual tests. Having the test code for a functionality being in a
> different
> >> >> place than the use of a functionality is not a good model (the
> obvious
> >> >> problem with what I say is that the use might be in 50 places so
> should I
> >> >> have the same test in 50 places?)
> >> >>
> >> >
> >> > And should the test be executed in all 50 places, or should the result
> be
> >> > cached? Since C code is context dependent, it would be hard to prove
> that it
> >> > was actually the same test in all 50 places, even if it resided in a
> common
> >> > header.
> >> >
> >>
> >>   Yes directly imbedding the tests is probably not practical but how
> about a naming convention that points directly to the test from the source.
> Now sometimes one has to hunt around to find the test associated with a
> particular #if since they could be in some many locations. For example
> instead of
> >>
> >> #if defined(PETSC_HAVE_FOO)     where is the test of foo
> >>
> >> have
> >>
> >> #if
> defined(PETSC_HAVE_FOO_BUILDSYSTEM_CONFIG_MATTSCRAZYFILE_MATTSCRAZYMETHODINTHATFILE)
> >>
> >>  now I can always go directly to the test.  Ideally the links would be
> bi-directional but that is hard.
> >>
> >>  Barry
> >>
> >>
> >>
> >> > On Thu, Feb 3, 2011 at 16:27, Barry Smith <bsmith at mcs.anl.gov> wrote:
> >> > Configure is only slow because it has grown into this monster over
> time; a complete refactoring should bring it down to barely a minute or so.
> >> >
> >> > Even a minute is a long time compared to 3 seconds which is what an
> incremental build with a couple new/modified implementation files should
> take.
> >> >
> >> > But configure needs to run a lot of tests which involves invoking the
> compiler a lot of times (it needs to run the compiler on tiny test programs
> to generate understandable errors as soon as possible, squashing it together
> into a big compilation later is bad because errors become confusing). I'm
> not sure that <1 minute is achievable, but I hope it is.
> >> >
> >> >   Then you are not going to like my next idea. I think that
> "configure" tests should be imbedded directly into the source code and
> evaluated at compile time to determine what gets built etc. In other words
> no distinction between configure and build time :-).
> >> >
> >> > How to handle tests that need to actually be executed, in a batch
> environment?
> >> >
> >> > This also eliminates the possibility of "incorrect semantic
> information in comments" since the comments won't be "requires X Y and Z"
> but instead the actual tests. Having the test code for a functionality being
> in a different place than the use of a functionality is not a good model
> (the obvious problem with what I say is that the use might be in 50 places
> so should I have the same test in 50 places?)
> >> >
> >> > And should the test be executed in all 50 places, or should the result
> be cached? Since C code is context dependent, it would be hard to prove that
> it was actually the same test in all 50 places, even if it resided in a
> common header.
> >>
> >
>
>


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