On Wed, Nov 16, 2011 at 8:11 AM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_quote"><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">On Wed, Nov 16, 2011 at 07:46, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com" target="_blank">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>1) Nope, we have some package structs in our public interface.</div></div></blockquote><div><br></div></div><div>So those use</div><div><br></div><div>#ifdef PETSC_HAVE_HDF5</div><div>#include <hdf5.h> /*R INCLUDES=PETSC_HDF5_INCLUDES R*/</div>

<div>#endif</div><div><br></div><div>which, since it's in a public header, the build system would recognize means that those include flags need to go in PETSC_INCLUDES.</div></div></blockquote><div><br></div><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> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote">
<div>With shared libs </div><div class="im">
<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></div><div>2) Of course they can dig in and pull something out, but the reason we have "make getincludedirs" is that this is beyond most users</div>

</div></blockquote><div><br></div></div><div>Yeah, I want something like</div><div><br></div><div>CFLAGS = -DMY_THING `/path/to/petsc-tool cflags --required-packages=hdf5:parmetis --optional-packages=mumps --arch=mpich-clang-opt`</div>

<div><br></div><div>this would check that the required packages are available with this PETSC_ARCH and set up CFLAGS to include them directly (and error if the packages are not available). If available, the flags for the optional packages would also be added to CFLAGS. As always, the PETSC_HAVE_* macros from petscconf.h would be visible so the user could check whatever they wanted.</div>

<div><br></div><div>Note that if the user was not calling these packages directly, they would not need to write anything for required/optional packages. Maybe there is a better way to specify this.</div></div></blockquote>
<div><br></div><div>This would not be hard to code up.</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"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="gmail_quote"><div></div><div>3) We have been a package manager since Barry convinced us to download and install packages</div></div></blockquote><div><br></div></div><div>I'm only distinguishing between intent. Installing a package for someone else to use directly should be independent from making that package available through our common interface (which does not need to expose it to the user).</div>
<div class="im">
<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><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>If shared libraries are being used, we _should_ be linking libpetsc.so such that -lpetsc is enough. Overlinking is bad because it makes the ABI more fragile.</div></div></blockquote><div><br>


</div></div><div>Nice if we can make it work.</div></div></blockquote><div><br></div></div><div>That is how shared libs are intended to be used. Some of the Linux distros are getting quite strict about enforcing this proper usage.</div>
</div></blockquote><div><br></div><div>If we only support some Linux distros, things would be easy.</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"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">How do you distinguish these cases by looking at the source?</blockquote></div></div><br><div>The non-portable system include is wrapped in an #ifdef, perhaps with an #else, and usually does not need special paths. The other has the "require package" annotation that activates a suitable build environment and disables building the file if the environment is not available.</div>

</blockquote></div><br>I hate annotations. There has to be a better way to do this. How many times are the bfort annotations screwed up?<div><br></div><div>   Matt<br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener<br>
</div>