[petsc-dev] configure issues

[Dmitry Karpeev]

This is all very confusing to me, but here is my simple question:
if cpp directives were to be abandoned in favor of code generation,
what would I do instead of
#if defined (PETSC_USE_DEBUG)
     <stuff>
#endif
?

On Wed, Feb 9, 2011 at 7:40 AM, Matthew Knepley <knepley at gmail.com> wrote:

> 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/76e8cc68/attachment.html>