[petsc-dev] configure issues

Matthew Knepley knepley at gmail.com
Wed Feb 9 06:42:40 CST 2011

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.


What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110209/93b18ad6/attachment.html>

More information about the petsc-dev mailing list