[petsc-dev] configure issues

[Barry Smith]

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.