PETSC_DIR as a symlink

[Satish Balay]

On Thu, 26 Nov 2009, Jed Brown wrote:

> On Thu, 26 Nov 2009 09:26:41 -0600 (CST), Satish Balay <balay at mcs.anl.gov> wrote:
> > BTW: What exact error message do you get?
> 
> It was this one, but it's working correctly now.
> 
>   The environmental variable PETSC_DIR /home/jedbrow/petsc-dev is not a directory
> 
> This system is actively hostile in the sense that there are different
> incompatible core tools scattered everywhere, the error came before I
> fixed up LD_LIBRARY_PATH and such to get consistent libs.  The error
> was probably caused by that nonsense, sorry for the noise.

ok.

> 
> > > peraps this is one case where --prefix install is useful?
> 
> I'm not sure, I want the source to stick around for debugging purposes
> and to make rebuilding easier.  I think --prefix is good for everything
> that you only want one version of, or that you don't expect any useful
> debugging information from.  It is pretty much the only sensible thing
> for desktop and core libs, the alternative is that you're constantly
> monkeying with LD_LIBRARY_PATH, or building with RPATH in which case a
> libc upgrade means rebuilding/downloading all of userland.  This is the
> reason for the Debian/GNU guidelines.
> 
> A lot of clusters manage multiple MPI implementations built with
> multiple ABI-incompatible compilers plus (if you're lucky) some debug
> builds for a core set of libraries.  This works, but administering all
> of these builds and building new software becomes a lot more work.  When
> a library is near the top of the stack and the value of having multiple
> versions present is greater than the effort of managing them, PETSc's
> no-prefix system works well (but any system that cleanly handles
> out-of-source builds would be fine too).

agree..

> 
> There are applications for which PETSc is just another library and users
> want to 'aptitude install petsc' and have it Just Work.  We might argue
> that they just don't know what they want, but it can be a hard sell.
> Some of these build systems are only designed for a single in-source
> build which is an insult to any precocious users who thinks they might
> want more than one version of PETSc.  This is where the --prefix install
> comes in (and a pkg-config file would be nice too).

most of the other packages support multiple install modes. [for ex:
mpich supports VPATH configure - which is equivalent to PETSC_ARCH].
I think there is an issue with users having to remember/learn many
types of installation methods for each package] - that pushes the idea
that 'a single build model should work for all packages'..

satish

> 
> Jed
>