I wrote an eselect module to choose between different Intel C/C++ Compiler (icc). It is based on empi[1], an eselect module to switch between different mpi implementations. It might be conflicting with the actual dev-lang/icc official ebuild: the official ebuild installs the file "/etc/profile.d/05icfc" to manage the paths, while the goal of the eselect module is to change the static configuration to a more dynamic one. My developpement is available on github[2]. I also bumped the icc ebuild[3] to latest version (2011.0.084) based on the official portage one. I removed the /etc/profile.d/05icfc file from it. The eselect module needs testing. I did try it with two icc versions (2011.0.084 and a previous 11.1). It's my first try with an eselect module so I'm looking for inputs. [1] http://dev.gentoo.org/~jsbronder/empi.xml [2] https://github.com/nbigaouette/ebuilds under app-admin/eselect-icc [2] https://github.com/nbigaouette/ebuilds under dev-lang/icc Reproducible: Always
So, as icc/ifc are not slotted, between what do you want to select?
Hi Nicolas, Thanks for your work! I am in the middle of re-writing the whole suite of intel packages [1] and I will definitely take a closer look of your eselect modules. I was actually planning in doing similar stuff. [1] http://git.overlays.gentoo.org/gitweb/?p=dev/bicatali.git;a=summary
@Justin AFAIK, slotting is the only way to have multiple versions of a package installed in gentoo, right? So icc would need to be slotted for this to work. I need it to be that way so I've set up my machine for this and I though I would share the work I've done. Note that I don't use icc for compiling gentoo packages, but for scientific calculations where speed is crucial. @Sébastien Your re-write is good news! The old ebuild is kind of scary and is way too big. There is also different rpms in the tar package from intel; splitting them into different ebuild is nice, but without an eclass it's a nightmare. My modifications are mostly making sure <INSTALLDIR> was sed'ed in every file and commented the "05ifc" installation part to let the eselect module manage this. What I like about this module is that while adding/removing a profile is done by root, switching between them is not. Each user can change as they want between one (or none). That way I can deploy an updated compiler without breaking everything, test it, and tell user about it when it's done. The actual way of a installing a single package and upgrading it is too dangerous in our production run. A single regression in the (proprietary...) compiler can means a lot of wasted time to everyone (and to the cluster too!). I'd like to add that empi is more complicated then this module. empi will copy the mpi's ebuild to a new location with an updated name, call emerge to install it, etc. None of these tricks are done in this module. I've also added many checks so it's more rebust (check if run as root, if command failed, etc.) A lot more could be added though.
Hi Sébastien, I see that you integrated some work into gentoo science. Icc is now slotted. That means that the eselect module should now work with science overlay, am I right? I just tried it and installed 12.0.4.191 from science overlay. I was then able to add an icc profile using eselect-icc and switch between it and the older 11.1.056 already installed on the current box. What would be needed to have eselect-icc included in the science overlay?
Hi Nicolas, I was thinking of eselecting the icc/ifort using your initial work, but you are welcome to do so! One thing I would like to do is not populating the env variables in the ebuilds but linking the proper files in /etc/profile.d/ as upstream does. Let us know if you have any changes/proposal to do, and whether you would like a commit access in the sci overlay. Thanks,
Hi Sébastien, The eselect module is done and working. I've been using it for some time now without any modifications. I don't know of anything else that could be implemented for it: it is feature complete as far as I'm concerned... I'm not sure I understand when you say you don't want to put environment variables in the ebuilds. But I can say that the eselect module does not need any modifications to the icc ebuild (I just tried it and it works with 12.0.4.191). The only modification required was the slotting, which has been implemented in the science overlay. This eselect module package only contains the files /etc/profile.d/icfc.{c,}sh and /usr/share/eselect/modules/icc.eselect. The content of the profile.p just points to the user home directory. That way, every use can use a different version. I forgot to document the addition of a new profile, so here it is: # eselect icc add icfc-2011.4.191 /opt/intel/composerxe-2011.4.191/bin/iccvars.sh intel64 The number in the string "icfc-2011.4.191" can be anything, as long as the string starts with "icfc-". It will be the string shown with "eselect icc list". The path is the path to the file setting the PATH and others. Finally, the "intel64" is just the architecture. Choosing a profile using eselect will edit the file $HOME/.env.d/icfc.sh to source the right file. For example: $ cat ${HOME}/.env.d/icfc.sh source /opt/intel/composerxe-2011.4.191/bin/iccvars.sh intel64 export ESELECT_ICFC="icfc-2011.4.191" It's as simple as that. So as long as you don't have any issue with that or any suggestions, I think you can simply import the ebuild folder from github. I wouldn't mind pushing that myself. I've also found a bug in =dev-lang/icc-12.0.4.191. The file /opt/intel/composerxe-2011.4.191/bin/compilervars.sh contains "pkg_bin" instead of "bin" for the paths so the different path variable never get updated... Thanks
