[petsc-dev] DESTDIR

Dmitry Karpeev karpeev at mcs.anl.gov
Fri Apr 23 09:40:16 CDT 2010


I would just add that petsc-config should, in my opinion, define
compile and link commands (i.e., including the compiler and the linker),
not merely the relevant flags (some of those are compiler-dependent).
Having these is very important, it seems to me.
There was a related discussion on moab-dev about whether the
compiler/linker information should be exported in addition to
the include and lib paths.

Dmitry.

On Fri, Apr 23, 2010 at 3:46 AM, Jed Brown <jed at 59a2.org> wrote:
> On Thu, 22 Apr 2010 16:44:07 -0500 (CDT), Satish Balay <balay at mcs.anl.gov> wrote:
>> On Thu, 22 Apr 2010, Sean Farley wrote:
>>
>> > >
>> > > I guess DESTDIR is useful for packaging PETSc? [perhaps rpm or
>> > > equivalent?] Is that what you are trying to do?
>> >
>> >
>> > Yes, this is a pet project of mine for os x and, potentially, rpms or
>> > something similar, though I haven't looked into other packaging systems.
>>
>> Ok - I'll look at it. Perhaps its a simple change.
>
> Distros heavily discourage RPATH installs.  This makes sense when
> installing to /usr or /usr/local (which they usually mandate), but not
> at all when installing to a non-standard path.  Supporting both RPATH
> and non-RPATH installs adds some build system complication.
>
> This relates to something that has been on my mind for a while: in the
> interest of making PETSc more accessible from external packages that do
> not want to use PETSc's makefiles, I suggest having a petsc-config that
> offers compilation and linking flags, including shared libs (no
> recursive dependencies), static libs, and RPATH/non-RPATH linking.  I
> would use pkgconfig for this except that pkgconfig is bad at handling
> multiple installs, so a stand-alone petsc-config written in Python seems
> like the natural candidate.
>
> Jed
>



More information about the petsc-dev mailing list