[petsc-dev] configure issues

[Jed Brown]

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>