On Wed, Feb 9, 2011 at 7:32 AM, Jed Brown <jed at 59a2.org> wrote: > On Wed, Feb 9, 2011 at 13:42, Matthew Knepley <knepley at gmail.com> wrote: > >> 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 >> need #defines for that. >> > > 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. > >> 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. Matt -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110209/0014e159/attachment.html>
