On Wed, Feb 9, 2011 at 14:40, Matthew Knepley <knepley at gmail.com> wrote:
> Name one that _only_ involves dropping files from the build. Hint: don't >> forget about XXRegisterAll(). >> > > Anything that uses #requirespackage. There are at least 50. I went through > all of them today since I was refactoring builder.py. > 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. > > >> >>> 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. >>> >> >> 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). >> >> >>> 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. >>> >> >> 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). >> > > I really cannot understand what you are worried about here. We do this all > the time. > > >> 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/*. >> > > I would not agree. I am one of those sketchy fringe characters who thinks it's easier to debug code in the same language it was written in. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110209/771131cf/attachment.html>
