[petsc-dev] configure issues

[Matthew Knepley]

On Wed, Feb 9, 2011 at 6:34 AM, Jed Brown <jed at 59a2.org> wrote:

> On Wed, Feb 9, 2011 at 13:17, Matthew Knepley <knepley at gmail.com> wrote:
>
>> What does this sentence mean? If petscconf.h has no logic, then isn't all
>> the logic on the Python side? Isn't all that logic used from C?
>>
>
> The result of tests go into petscconf.h. For the example I brought up,
> different macro values imply that different code must be executed. To remove
> the #if completely, you would have to generate different imperative code.
>
>
>>
>>
>>>  bodies are currently generated by Python. It sounds like you want to
>>> generated imperative code in Python and call that from C. I think that would
>>> add
>>>
>>
>> We can currently control the build to do selective builds, just as we do
>> with #defines right now. I think that removing that code from the tree and
>> building everything would actually be simpler.
>>
>
> I agree that when possible, configuration choices should be available at
> runtime instead of compile time. However, "everything" cannot be compiled
> because some are mutually exclusive: scalar precision, real/complex, int
> size, C++ mangling, and architecture specific things. Consider the code that
> sets up floating point trapping. Only one path can be compiled on any
> specific architecture. Either you generate the fp.c source file differently
> for each architecture, you have a different source file for each
> architecture and have the build system use the correct one, or you keep them
> all in the same file and use the preprocessor to decide which one to compile
> (this is currently done).


I did not mean at runtime. I meant that a great portion of our defines now
just remove an entire file from the build. We do not
need #defines for that.

For other #defines, like those that get memory usage from the operating
system, I definitely think code generation would be simpler
than the #if monstrosity that currently exists. It would divide debugging
into two parts:

  a) Why doesn't the generated code work? We have made mistakes in just the
code I mentioned because we could not follow the inclusions correctly.

  b) Why did we choose to generate that code? This would be entirely
contained in a single configure test.

I do not disagree that for b) we would like a nice way (comment) to indicate
which configure test generated that code.

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