On Wed, Nov 16, 2011 at 7:37 AM, Jed Brown <[email protected]> wrote:
On Wed, Nov 16, 2011 at 07:19, Matthew Knepley <[email protected]> wrote:
There is a big difference between
1) Using only the necessary include directories for a given compile, which might work
and
2) Removing includes we "don't need", which I do not think will work
Starting with 1). This will break things like "make getincludedirs", unless you want to maintain one thing with the kitchen sink for users, and one tailored thing for PETSc. I think this will generate weird errors where the full line breaks something, but we never see it because we use the custom build. I could still support this if we tested the antique version along with the custom one.
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.)
1) Nope, we have some package structs in our public interface. 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 3) We have been a package manager since Barry convinced us to download and install packages
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.
Nice if we can make it work.
However with 2), how would we distinguish includes we only want if the package is found from those that just do not work because of a configuration/build bug? If its annonation, as Jed suggests, how is that a step up from #ifdef?
So there are two cases
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.
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).
How do you distinguish these cases by looking at the source? Matt -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener