On Wed, Feb 9, 2011 at 6:34 AM, Jed Brown <span dir="ltr"><<a href="mailto:jed@59a2.org">jed@59a2.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div class="im">On Wed, Feb 9, 2011 at 13:17, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>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?</div></blockquote><div><br></div></div><div>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.</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div> 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</div></blockquote><div><br></div></div><div>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</div>


<div>building everything would actually be simpler.</div></blockquote></div></div><div><br></div>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).
</blockquote></div><br>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<div>need #defines for that.</div><div><br></div><div>For other #defines, like those that get memory usage from the operating system, I definitely think code generation would be simpler</div>
<div>than the #if monstrosity that currently exists. It would divide debugging into two parts:</div><div><br></div><div>  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.</div>
<div><br></div><div>  b) Why did we choose to generate that code? This would be entirely contained in a single configure test.</div><div><br></div><div>I do not disagree that for b) we would like a nice way (comment) to indicate which configure test generated that code.</div>
<div><br></div><div>   Matt<br clear="all"><br>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener<br>

</div>