[petsc-dev] What is this for?

[Jed Brown]

On Wed, Nov 16, 2011 at 07:46, Matthew Knepley <knepley at gmail.com> wrote:

> 1) Nope, we have some package structs in our public interface.
>

So those use

#ifdef PETSC_HAVE_HDF5
#include <hdf5.h> /*R INCLUDES=PETSC_HDF5_INCLUDES R*/
#endif

which, since it's in a public header, the build system would recognize
means that those include flags need to go in PETSC_INCLUDES.

With shared libs


> 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
>

Yeah, I want something like

CFLAGS = -DMY_THING `/path/to/petsc-tool cflags
--required-packages=hdf5:parmetis --optional-packages=mumps
--arch=mpich-clang-opt`

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.

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.


> 3) We have been a package manager since Barry convinced us to download and
> install packages
>

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).


>
>
>> 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.
>

That is how shared libs are intended to be used. Some of the Linux distros
are getting quite strict about enforcing this proper usage.

How do you distinguish these cases by looking at the source?


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