<div class="gmail_quote">On Wed, Nov 16, 2011 at 09:07, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div>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</div>
<div>would have to distinguish #ifdefs which test features from those that indicate packages.</div></div></blockquote><div><br></div><div>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</div>
<div><br></div><div>#include <blocks.h></div><div><br></div><div>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.</div>
<div>  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im"><div></div></div><div>If we only support some Linux distros, things would be easy.</div>
</div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I hate annotations. There has to be a better way to do this. How many times are the bfort annotations screwed up?</blockquote>
</div><br><div>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.)</div>