So the question came up on the call this week about supporting libraries
compiled with something other than gcc 2.x. This would include LAM,
MPICH, HDF5, PVM, and probably others.
Although this is obviously a Good Thing, what's the best way to do
this? For example, I can see some obvious compiler targets:
- gcc 2.9x
- gcc 3.x
- icc
- ...?
Some questions (taking LAM as the example, although the issue is the
same for all library packages):
1. Should there be multiple LAM packages, one for each compiler?
PRO: easy modularity; each package is identical in terms of
structure and content; only difference is which compiler was
used to make the RPMs
CON: lots of packages; could be confusing to user ("Do I want
lam-6.5.9-gcc-2.9x-x86 or lam-6.5.9-gcc-3.2-x86 or
lam-6.5.9-icc-x86 or...?")
2. Or should the LAM package simply have multiple RPMs?
PRO: only one package to maintain; no duplicated code in multiple
packages
PRO: choice of which default version to use becomes a configurator
issue
CON: ...?
3. What versions of gcc 3.x do we support? Since, in particular, the
C++ ABI changes so much from version to version, I would think that
we'd only want to support the latest and greatest -- MDK 9.0 ships
gcc 3.2, which, IIRC, was supposed to be the "good" one...?
Regardless of the answers between these, the package(s) may have to
get a little smarter to know which RPMs they can install (e.g., can't
install an icc-based RPM if icc is not installed).
Comments?
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Oscar-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/oscar-devel
