[petsc-dev] configure issues

[Jed Brown]

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