I have no objection to someone setting up a branch to test allowing versioning (and PETSC_ARCH) with the —prefix option.
Barry On Jan 22, 2014, at 1:43 PM, Jed Brown <[email protected]> wrote: > Barry Smith <[email protected]> writes: > >> On Jan 22, 2014, at 1:24 PM, Jed Brown <[email protected]> wrote: >> >>> Barry Smith <[email protected]> writes: >>> >>>> When we first tried to follow “community standards” with —prefix I >>>> was told that “community standards” did not recognize the need for >>>> multiple installs and that community standards did not allow for >>>> putting archs onto names to allow multiple installs. We >>>> specifically removed the concept of PETSC_ARCH for installs for this >>>> reason. Have community standards changed? >>> >>> There is a big difference between having the install variant in the path >> >> I have no idea what the sentence fragment above is suppose to mean. > > /opt/petsc/arch-dbg/ > > User has to manually set flags to find that path. If we didn't set > RPATH, they'd also need LD_LIBRARY_PATH. (Not setting RPATH is nice for > testing new system configurations, among other things.) > >>> (user has to manage paths themselves) and versioning libraries installed >>> to the same path. We can continue with using the prefix for everything >>> (which some distros will work around to avoid offloading path management >>> to the user) or we can allow multiple installs to a standard path (users >>> don't have to deal with paths, instead run petsc-3.5.0-dbg-config). >> >> I am not fundamentally objecting to name spacing the things >> installed but I previously understood that this was considered a >> big no-no. > > Installing to funky paths is discouraged, but versioning libraries is > encouraged. If there is only one variant, that versioning is usually > libfoo.so.1.2.3. Then you can have several versions installed and > precompiled binaries can keep using the old versions. > > When there are multiple variants (e.g, python2 and python3), the > libraries usually absorb the variant name.
