Pablo, I wanted to share some insight on some differences between intel’s easybuild file and what you get by using compilervar.sh to get the environment. The values CC, CXX are not defined by intel maybe for some good reason, not sure why. As for CFLAGS I don’t think that should be defined because different programs need to compile with different flags and defining CFLAGS can cause some issues. CC, CXX could be done according to Lmod’s use of pushenv see https://www.tacc.utexas.edu/research-development/tacc-projects/lmod/advanced-user-guide/more-about-writing-module-files
I found documentation on intel 2015 Parallel Studio Page 20 tells you do use compilervar.sh http://www.ritme.com/uploads/assets/FAQ/Intel/Release_Notes_C_2015_L_EN_initial_product.pdf I have seen this documentation for Intel 2016, and I presume it is same for 2017. I have attached a copy of modulefile from easybuild and compilervars.sh, there are lots of differences that need to be accounted. This link https://software.intel.com/en-us/articles/using-environment-modules-with-the-intel-development-tools tells you how to create modulefile from shell script using env2 utility. This is how I got my modulefile for intel-17-compilervar. I am using this in my easybuild, unfortunately when I run easybuild it generates the default intel modulefile so I have to overwrite with mine. Intel does not make use of CC CFLAGS variable. It seems like Makefile variables defined inside the file override ones in the environment. I tried a simple example of Makefile to see what happens. [hpcswadm@hpcv18 ~]$ make gcc a.c; [hpcswadm@hpcv18 ~]$ echo $CC pgcc [hpcswadm@hpcv18 ~]$ cat Makefile CC=gcc all: $(CC) a.c; clean: rm a.out [hpcswadm@hpcv18 ~]$ ml Currently Loaded Modules: 1) pgi/16.4 [hpcswadm@hpcv18 ~]$ ml show pgi ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- /nfs/grid/software/RHEL7/pfizer-modules/all/pgi/16.4.lua: ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- pushenv("CC","pgcc") pushenv("FC","pgfortran") pushenv("CXX","pgcxx") pushenv("F77","pgf77") From this experiment, I can conclude if your intent is to use $CC $CXX for building software then, I would be careful with hardcoded Makefile that have CC defined. Whereas configure script accurately pick up $CC if defined. I think for this reason, $CC is not defined by most compilers for instance gcc and intel don’t redefine $CC to gcc or icc. That being said, you can potentially intermix compilers if some Makefile have $CC defined in file while configure might define CC from environment. It would depend on each site if your intent is to use $CC for users to compile code then it might be okay, however if they are using to build software with complicated Makefile structure and they redefine $CC inside then it should not be used. From: [email protected] [mailto:[email protected]] On Behalf Of Kenneth Hoste Sent: Monday, October 24, 2016 12:42 PM To: [email protected] Subject: Re: [easybuild] easybuild -devel files for users? On 23/10/16 11:59, Pablo Escobar Lopez wrote: wouldn't make sense if compiler modules provide $CC $CXX and Co. by default? It would make sense in certain cases, but not in others... This should really be up to the site to decide on this. Question is what EasyBuild v3.0 should do by default: should the toolchain module define $CC, $CFLAGS & co or not? Oh yes, and someone should modify the Toolchain easyblock to include this information in the generated module file. ;-) K. 2016-10-22 23:59 GMT+02:00 Alan O'Cais <[email protected]<mailto:[email protected]>>: Maybe I'm misunderstanding but that is pretty much exactly why I 'created' the trivial buildenv easyblock. The users just load the module that gets created and they can simply use $CC and friends in their build processes, making switching toolchains very straightforward. On 22 Oct 2016 4:09 p.m., "Vanzo, Davide" <[email protected]<mailto:[email protected]>> wrote: From a user perspective it would be more interesting to have this option under Lmod than EB. The end user is most likely to interact only with the environment modules manager than EB directly. The idea would be that the user loads all the modules he/she needs according to a specific toolchain and can get all the linking flags by calling something like: $module -L In this way the user can use command substitution directly into Makefiles. More importantly, this should also take into account ordering the lib flags accordingly since sometimes order is essential for successful linking. That is something that we discussed internally since this functionality is provided by our current modules manager (although in a very primitive way) and would be lost when transitioning to Lmod. -- Davide Vanzo, PhD Application Developer Adjunct Assistant Professor of Chemical and Biomolecular Engineering Advanced Computing Center for Research and Education (ACCRE) Vanderbilt University - Hill Center 201 (615)-875-9137<tel:%28615%29-875-9137> www.accre.vanderbilt.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.accre.vanderbilt.edu&d=DQMDaQ&c=UE1eNsedaKncO0Yl_u8bfw&r=RMJdCm7m5fiPWhajwKUnEW5yn4eK2YdUWW-MLVShghg&m=XIzkmzDF00WsTllPE8K-UQ1aE0HodmAbbD66y2rVPys&s=F9PctC0VtCxzmOvKUceGuwYTfqZUYFI0FsBRGqR8e6Y&e=> On Oct 22 2016, at 8:12 am, Jack Perdue <[email protected]<mailto:[email protected]>> wrote: On 10/22/2016 02:47 AM, Kenneth Hoste wrote: > Hi Jack, > > On 21/10/16 02:46, Jack Perdue wrote: >> Howdy EB gods (Ken and crew), >> >> So EB, puts some useful environment settings in >> <app>/<version>/easybuild/<app>*-devel >> >> Is there a way to utilize those variables when not >> using EB? >> >> For example, I assume that if a user loads icc that they >> more than likely would like CC=icc (CFLAGS is a different >> matter). >> >> But EB doesn't do that now (probably for good reason). > > It doesn't right now, no, but would it be interesting to add an option > to include statements to define the build environment as used by > EasyBuild in the toolchain module? > > You can argue for it both ways, it's just a matter of what EasyBuild > should do by default (and we currently have a window of opportunity to > change the default behavior with EasyBuild 3.0 being the next release). I'd definitely like to see it as an option. For testing, --dump-env-script on ImageMagick-7.0.3-2-intel-2016b.eb would be a good start. I'd like to see _everything_ set in that .env instead set in the modules first... as just a start. Beyond that, I'd also like to see a line with -lX11 -lXabc -lX123 so I don't need to remember the name of all the X11 libs. But it should be a site (or user) selectable option (I could see some people not wanting such things). jack (who won't be making it to Utah but does have new cluster coming online and has the ability to provide beer through his agents) ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ -- Pablo Escobar López HPC systems engineer sciCORE, University of Basel SIB Swiss Institute of Bioinformatics http://scicore.unibas.ch<https://urldefense.proofpoint.com/v2/url?u=http-3A__scicore.unibas.ch&d=DQMDaQ&c=UE1eNsedaKncO0Yl_u8bfw&r=RMJdCm7m5fiPWhajwKUnEW5yn4eK2YdUWW-MLVShghg&m=XIzkmzDF00WsTllPE8K-UQ1aE0HodmAbbD66y2rVPys&s=zy8LWDZGdKzeSxPzuxj6kfpfTyfRFnyED2Hwjvqc_oY&e=>
intel-17-compilervar
Description: intel-17-compilervar
intel-easybuild-2017
Description: intel-easybuild-2017
