[petsc-dev] What is this for?

[Matthew Knepley]

On Wed, Nov 16, 2011 at 8:11 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

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

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
would have to distinguish #ifdefs which test features from those that
indicate packages.


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

This would not be hard to code up.


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

If we only support some Linux distros, things would be easy.


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

I hate annotations. There has to be a better way to do this. How many times
are the bfort annotations screwed up?

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