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