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>
