On Oct 22, 2008, at 12:16 PM, Matthew Knepley wrote:
> I have a problem with hiding the package includes. If I tell PETSc
> to install
> ParMetis, I think I should be able to use ParMetis however I want. I
> do not
> just want to use it through the PETSc interface. I have done this
> numero
I have a problem with hiding the package includes. If I tell PETSc to install
ParMetis, I think I should be able to use ParMetis however I want. I do not
just want to use it through the PETSc interface. I have done this numerous
times. I think most users think this way as well. What is the motivati
On Wed, 22 Oct 2008, Barry Smith wrote:
> 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.
I guess part of the problem is namespace issue
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 f
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
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 thou
