<div class="gmail_quote">On Wed, Feb 9, 2011 at 12:33, 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;">
If you refer to the first part of your comment above, it suggested generating the correct code,</blockquote><div><br></div><div>So every function in PETSc that currently does</div><div><br></div><div>#if something</div><div>
...</div><div>#else</div><div>...</div><div>#endif</div><div><br></div><div>would be replaced by generated headers and source files that have only the chosen path. I think this will make it far more confusing to find out what paths are possible, to make edits safely, and to locate definitions. I do not know of any successful project that generates code for something like this.</div>
<div><br></div><div>Barry was not suggesting any new use of the preprocessor, just renaming existing macros to make navigation easier. I think it's fine to keep the existing names and instead write a snippet of elisp to make navigation easier. Your response that all use of the preprocessor should be replaced by generated code (or something) does not address the problem at all, and, if anything, makes it worse because configure would become more complicated.</div>
<div><br></div><div>For what it's worth, despite Python being "better" in all the ways you mention, I don't know anybody who finds it easier/safer/faster to edit BuildSystem code than to edit PETSc C source. This is less a statement about the language and more a statement about organization, but I would be very cautious about moving large amounts of complexity from src/*.c to config/*.py.</div>
</div>