error in handling download external packages

[Barry Smith]

On Oct 22, 2008, at 10:55 AM, Satish Balay wrote:

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

    We should only doing the cp/mv for packages that do not have their
own proper make install. (I don't know if we use it when we should not
anywhere). We should try to improve this and eliminate at least some
of the private include files from getting over.
>
>
> The current model is to have the same 'prefix' provided to PETSc be
> the prefix for all external packages.

   We should probably have support for using a different prefix for all
of the externals, this wouldn't be hard to do. (but use the same by  
default).
Of course, this doesn't really solve the problem anyways since we would
still have to point to this other directory when compiling user code  
because
of the mpi.h as you point out.

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

   This is true.

    I wasn't saying we had to solve this problem, but I do think it
is a problem.  A users code could easily pick up the wrong include
for something since we now have hundreds in our arch/include location.

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