[petsc-dev] What is this for?

[Jed Brown]

On Wed, Nov 16, 2011 at 09:07, Matthew Knepley <knepley at gmail.com> wrote:

> I hate extra step annotations, which can be screwed up. I think we could
> do a rule based on the #ifdef. This could possibly work, but we
> would have to distinguish #ifdefs which test features from those that
> indicate packages.
>

Trouble is that it has to be obvious to the user how to get a suitable
build environment. How are you going to tell which package

#include <blocks.h>

comes from? And how should you error if SPAI is not available? I'm all for
eliminating redundancy, but I think it is better for users to have
(checked) redundancy than magic.


> If we only support some Linux distros, things would be easy.
>

My point was that they are requiring all packages to do this anyway, so we
have to support the strict model if we want PETSc to be packaged for those
distros. Falling back to something more verbose on systems with broken
shared libraries is understandable, static linking needs everything all the
time.


> I hate annotations. There has to be a better way to do this. How many
> times are the bfort annotations screwed up?


Those are a problem because they are too slow to always be updated. A while
back, I put in a hack to avoid touching bfort output that did not need to
be updated. Then Barry made bfort support more local scoping (so that we
could, in principle make it an automatic part of the build sytem), but my
hack got lost in that change, so all the ftn-auto are regenerated when you
rebuild the stubs. We can set up CMake (or a different system) to track
proper dependencies for the generated files, at which point those bugs
should go away because the generated files will always be updated. (Note
that we want to make sure the time stamp doesn't change if the contents of
the generated file doesn't change.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111116/435cf249/attachment.html>