This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
On Wed, 29 Jul 2009, Jeff Squyres wrote:
> On Jul 28, 2009, at 1:56 PM, Ralf Wildenhues wrote:
>>> - support files are not versioned (e.g., show_help text files)
>>> - include files are not versioned (e.g., mpi.h)
>>> - OMPI's DSOs actually are versioned, but more work would be needed
>>> in this area to make that versioning scheme work in real world
>>> - ...and probably some other things that I'm not thinking of...
>> You can probably solve most of these issues by just versioning the
>> directory names where you put the files; and with some luck, some
>> downstream distribution can achieve this by merely passing a bunch of
>> --foodir=... options to configure.
> This is probably true -- we do obey all the Autoconf-specified directories,
> so overriding --foodir= should work. It may break things like mpirun
> --prefix behavior, though. But I think that the executables would be
> problematic -- you'd only have 1 mpirun, orted, etc. OMPI does *not*
> currently handle the Autoconf --program-* configure options properly. I
> confess to not recalling the specific issues, but I recall we had long
> discussions about them -- the issues are quite tangled and complicated. And
> I remember coming to the conclusion "not worth supporting those."
> FWIW, Chris is probably right that it's far easier to simply install
> different OMPI versions into different $prefix trees (IMHO).
Agreeed. I was looking at the versioning of shared libraries not as a way
to allow multiple installs in the same prefix, but to allow users to know
when it was time to recompile their application.