error in handling download external packages

Barry Smith bsmith at mcs.anl.gov
Wed Oct 22 13:08:36 CDT 2008


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
>




More information about the petsc-dev mailing list