[petsc-dev] configure issues

[Matthew Knepley]

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>