[petsc-dev] configure issues

[Jed Brown]

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?

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