<div class="gmail_quote">On Wed, Nov 16, 2011 at 07:19, 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 id=":3p3">There is a big difference between<div><br></div><div>  1) Using only the necessary include directories for a given compile, which might work</div><div><br></div><div> and</div><div><br></div><div>  2) Removing includes we "don't need", which I do not think will work</div>

<div><br></div><div>Starting with 1). This will break things like "make getincludedirs", unless you want to maintain one</div><div>thing with the kitchen sink for users, and one tailored thing for PETSc. I think this will generate weird</div>

<div>errors where the full line breaks something, but we never see it because we use the custom build.</div><div>I could still support this if we tested the antique version along with the custom one.</div></div></blockquote>
<div><br></div><div>Since our public headers don't need to include those implementation headers, the user does not have access to them unless they personally include them. In that case, they should pull the variable out of the makefile/cmake/python configuration. We just want to make it completely consistent how the necessary variable is named. (Note that this is using PETSc as a package manager, not just a library.)</div>
<div><br></div><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><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":3p3"><div><br></div><div>
However with 2), how would we distinguish includes we only want if the package is found from those</div><div>that just do not work because of a configuration/build bug? If its annonation, as Jed suggests, how is</div><div>

that a step up from #ifdef?</div></div></blockquote></div><br><div>So there are two cases</div><div><br></div><div>2a. Include a system header if it exists. It is expected to provide a typedef or function that is needed in the public interface (either directly by the user or in an inline function). Configure would have checked what is available and we have fallback logic if it is not provided. I don't think #ifdefs are wrong here.</div>
<div><br></div><div>2b. Compile an optional implementation which requires some headers. If the package is not available, this implementation file is not even compiled. This is where that annotation could be useful, so that the build environment can stay in the source file instead of being written into the makefile or some other independent file. This also reduces the granularity with which we can specify compiler flags (it's currently directory-level).</div>