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 >
