error in handling download external packages

[Satish Balay]

For one - I think each external package should have its own 'make
install' - this should copy its public include files to the prefix
location. [currently we do 'cp' for some packages - and this might
copy both internal and public include files to the install location].

The current model is to have the same 'prefix' provided to PETSc be
the prefix for all external packages. Placing package includes in a
separate location breaks this mode. [and then we have to figure out
which packages user will include via petsc include - like mpi.h etc,
and ones that are not directly included - perhaps like mumps.h]

So I don't see the benefit [except for reduced number of files in
prefix/include] by hiding the includes in a different location - and
complicating the install model.

The current model benifits users in the sense that - if they were to
have some usercode that uses externalpackages directly aswell - then
they can rely on PETSc install of these packages..

Satish

Satish On Wed, 22 Oct 2008, Barry Smith wrote:

> 
>   After we have compiled the external package libraries we copy them over to
> the install site, ok.
> But we also blindly copy over ALL of its include files over to the install
> site so that the PETSc interface
> for that package can be built. But then we leave all those includes there even
> though they are not
> needed by the user of the installed PETSc.
> 
>  Possible correction: put those includes in another directory that is used for
> building PETSc but not used
> when compiling user code. Somehow need to pass the appropriate -I only when
> building PETSc
> and not for user code.
> 
>  Barry
> 
> Even when we do not install the package, that is we use one someone already
> installed, we point
> to its include files in our makefile system and continue to point to them
> (with -I stuff) when users
> build code.
>