error in handling download external packages
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.
error in handling download external packages
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 [This would be the primary reason for picking up the wrong include]. In that sense include/packagename/pkginc.h might be a valid thing. But the package has to support this internally [as in 'make install' provides include/pkgname/pkginclude'. And the recommended usage from user code would be: #inlcude package/pkginc.h [this model is not in sync with curent PETSc model of supporing both install in PETSC_DIR-src and 'make install with prefix']. It might be better to identify the namespace conflicts and ask the packages to fix the names.. The other kind of conflict is: user installs superlu separately - and then tries to use PETSc installed with --download-superlu. These 2 versions of superlu will conflict with each other.. The fix in this case is to not use the duplicate install of superlu anyway... Satish
error in handling download external packages
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 motivation for hiding the includes? Thanks, Matt On Wed, Oct 22, 2008 at 11:18 AM, Satish Balay balay at mcs.anl.gov wrote: 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 [This would be the primary reason for picking up the wrong include]. In that sense include/packagename/pkginc.h might be a valid thing. But the package has to support this internally [as in 'make install' provides include/pkgname/pkginclude'. And the recommended usage from user code would be: #inlcude package/pkginc.h [this model is not in sync with curent PETSc model of supporing both install in PETSC_DIR-src and 'make install with prefix']. It might be better to identify the namespace conflicts and ask the packages to fix the names.. The other kind of conflict is: user installs superlu separately - and then tries to use PETSc installed with --download-superlu. These 2 versions of superlu will conflict with each other.. The fix in this case is to not use the duplicate install of superlu anyway... Satish -- 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
error in handling download external packages
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 numerous times. I think most users think this way as well. What is the motivation for hiding the includes? Per our previous decisions, not hiding the includes, but having an option of putting all their includes in a different place then the PETSc include directory. Now if they have PETSc install ParMetis the includes are ALWAYS put in the same place as the PETSc ones. Barry So someone use the ParMetis, but not using PETSc needs to have a -I/somewhere/petsc-install-location/include instead of a -I/somehere/parmetis-install-location/include Thanks, Matt On Wed, Oct 22, 2008 at 11:18 AM, Satish Balay balay at mcs.anl.gov wrote: 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 [This would be the primary reason for picking up the wrong include]. In that sense include/packagename/pkginc.h might be a valid thing. But the package has to support this internally [as in 'make install' provides include/pkgname/pkginclude'. And the recommended usage from user code would be: #inlcude package/pkginc.h [this model is not in sync with curent PETSc model of supporing both install in PETSC_DIR-src and 'make install with prefix']. It might be better to identify the namespace conflicts and ask the packages to fix the names.. The other kind of conflict is: user installs superlu separately - and then tries to use PETSc installed with --download-superlu. These 2 versions of superlu will conflict with each other.. The fix in this case is to not use the duplicate install of superlu anyway... Satish -- 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
