At first I like #2 over #1, like Mike. But then that ties all supported compilers to one LAM package, which means each time a new compiler version is supported, a whole new LAM package must be released. So I now like #1 better. That scheme fits into OPD-land nicely. It's also the way the paths end up being. In future releases (not in CVS yet), you'll be seeing mpich-p4-gcc being a path name, because mpich can be built w/ different devices and compilers... ending up in quite a matrix. We'll be seeing mpich-gm-gcc, mpich-vmi-gcc, etc. We already use this scheme on our own systems- so we had to answer this question for ourselves quite a while ago.
I think we have to forget about auto-detection of compilers, as I might be planning to install Intel compilers, and I'll want to get LAM-Intel installed regardless of the compiler's presence. At most, auto-detection might be able to make the selection default status, but shouldn't be making the decision of course. We don't have any Intel compilers OSCAR'ized yet after all. Come to think of it, why not? Would OPD support having a repository behind a password? That's a separate topic tho.
Jeremy
At 09:30 AM 3/12/2003 -0500, Michael Chase-Salerno wrote:
I would prefer to see #2 over #1. When deciding which packages to use a user shouldn't have to deselect/select something multiple times or figure out which is the right one. The package should be LAM. If there are multiple rpms that are needed to support that, it should be a package specific config option, perhaps automatically determined/defaulted by the package code, if possible.
Mike
On Wed, 2003-03-12 at 09:20, Jeff Squyres wrote: > 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? -- Michael Chase-Salerno [EMAIL PROTECTED] IBM Linux Systems Technology Poughkeepsie, NY System Installation Suite www.sisuite.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
-------------------------------------------------------
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
