[petsc-dev] What is this for?

[Jed Brown]

On Wed, Nov 16, 2011 at 07:19, Matthew Knepley <knepley at gmail.com> 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.)

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.


> 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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111116/c8c94a5a/attachment.html>