[petsc-dev] configure issues

[Jed Brown]

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().


> 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 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/*.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110209/b46c2eae/attachment.html>