<div class="gmail_quote">On Wed, Feb 9, 2011 at 14:40, 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 class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><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></blockquote><div><br></div><div>Evidently you did not read what I wrote. All of those require registering an implementation, the macro is used in some XXRegisterAll() to determine whether it can be registered. Yes, this is only two places (only one in C source), but many of them are used in a few more places or in examples.</div>

<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><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><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.</blockquote></div><div><br></div><div>I am one of those sketchy fringe characters who thinks it's easier to debug code in the same language it was written in.</div>