This is all very confusing to me, but here is my simple question:<div>if cpp directives were to be abandoned in favor of code generation,</div><div>what would I do instead of </div><div>#if defined (PETSC_USE_DEBUG)</div><div>
<stuff></div><div>#endif</div><div>?<br><br><div class="gmail_quote">On Wed, Feb 9, 2011 at 7:40 AM, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com">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 class="im">On Wed, Feb 9, 2011 at 7:32 AM, Jed Brown <span dir="ltr"><<a href="mailto:jed@59a2.org" target="_blank">jed@59a2.org</a>></span> wrote:<br>
</div><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div>On Wed, Feb 9, 2011 at 13:42, 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>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></blockquote><div><br></div></div><div>Name one that _only_ involves dropping files from the build. Hint: don't forget about XXRegisterAll().</div>
</div></blockquote><div><br></div></div><div>Anything that uses #requirespackage. There are at least 50. I went through all of them today since I was refactoring builder.py.</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 class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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.</div></div></blockquote><div><br></div></div><div>That is basically just one function, the fp_trap stuff is more complex, but entirely maintainable in my opinion. I think PetscMemoryGetCurrentUsage is a confusing function only because there was some attempt to only write "PetscFunctionBegin" once instead of just making 5 short-but-complete snippets for each alternative (i.e. duplicate the mundane stuff into all 5 bodies instead of duplicating the conditionals to avoid duplicating the mundane stuff).</div>
<div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div> 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></blockquote><div><br></div></div><div>Recall that BuildSystem _still_ does not have a way to write a code snippet once and have it run immediately or in batch (there is currently potential for inconsistency even if I just want to do one test). Occasionally there is a combinatorial number of paths through the code (because features are, at least in principle, independent). If you generate it, you have to manage the results of multiple orthogonal tests (where should the logic to handle this go), and be confident that all code paths are correct. Sometimes the result of a test is used in many places, answering the question "where is this snippet of code used and why does it look this way" becomes difficult if there are a dozen snippets for a given test. Generating the snippets is a bit like writing a function FrobnicateTheVariablesInScopeOnLine192(); the snippet may not make sense in it's own right, just in the context where it is needed. This is an unconventional way to organize code and not going to reduce complexity (especially to someone new to the project).</div>
</div></blockquote><div><br></div></div><div>I really cannot understand what you are worried about here. We do this all the time.</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 class="gmail_quote"><div>I would rather write structured code that uses the results of these tests (i.e. in a C file where it is now) than to generate said code somewhere in config/*.</div></div>
</blockquote></div></div><br>I would not agree.<div><div></div><div class="h5"><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>
</div></div></blockquote></div><br></div>