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 >
