Hmm, I'm not sure I agree that this would make the life of a user any easier. LD_LIBRARY_PATH covers -L, CPATH covers -I and -lhdf5 you would just have to know. I mean it's not like there are different API implementations of HDF5 to choose from so using these new variables just means that their build process becomes non-portable (to a non-eb environment). I see value in the case of toolchains (which is what is already there) since you might want to try different compiler/mpi/math cominations but beyond that I still need some convincing...
On 26 October 2016 at 08:24, Jack Perdue <[email protected]> wrote: > On 10/26/2016 12:48 AM, Jack Perdue wrote: > >> On 10/26/2016 12:37 AM, Alan O'Cais wrote: >> >>> >>> I don't think its so simple, how would you do this for fftw where there >>> are so many different linking options depending on what you want to do? >>> >>> >> For most things (like CFLAGS), I'd at least set a sensible default and >> then let the user >> override in their build environment as needed. e.g. with foss/gompi FFTW: >> >> EB_FFTW_INCLUDEDIRS="-I$EBROOTFFTW/include" >> EB_FFTW_LIBDIRS="-L$EBROOTFFTW/lib" >> EB_FFTW_LIBS="-lfftw3" >> >> isn't a bad start as default linkage. With MKL, it's messier but known >> (by EB). >> >> >> >> For X11 libs in particular, you don't need to handle it, this is why >>> pkg-config exists (and the pkg-config paths are already baked into EB). >>> >> > As to this, yes, perhaps a bad example. But consider, say HDF5. > Why shouldn't I have the following available (changing DIRS to FLAGS > if that makes anyone happier): > > EB HDF5_INCLUDEFLAGS="-I$EBROOTHDF5/include" > EB_HDF5_LIBFLAGS="-L$EBROOTHDF5/lib" > EB_HDF5_LIBS="-lhdf5" > > jack > > > > >>> >>> On 25 Oct 2016 8:23 p.m., "Jack Perdue" <[email protected] <mailto: >>> [email protected]>> wrote: >>> >>> On 10/24/2016 11:42 AM, Kenneth Hoste wrote: >>> >>> >>> >>> 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. ;-) >>> >>> >>> I'd really like to think beyond just toolchains. >>> >>> The new X11 bundle is a good example. >>> >>> We already have EBROOTX11. Can we have >>> EB_X11_INCLUDEDIRS, EB_X11_LIBDIRS and >>> EB_X11_LIBS without stepping on any toes? >>> >>> The INCLUDEDIRS (-I) is usually easy (though not always, >>> e.g. old versions of SparseSuite). >>> >>> The LIBDIRS (-L) is always questionable as to the number and or >>> whether they have '64' in the name. >>> >>> Is there a reason we shouldn't have EB enumerate the 71 libraries >>> in X11/20160819-intel-2016a/lib (with '-l' so I can drop right >>> into a Makefile)? >>> EB_X11_LIBS with that would be wonderful (or so I am imagining). >>> >>> Personally, I'd see all this done via easyconfigs (vs. easyblocks). >>> I don't see a clear way (short of a new "modextravars" mechanism) >>> to enable/disable per-site. But I think keeping the ability to >>> update >>> those things by installers would be better without customizing >>> Python. >>> >>> X11 is just one example... there are a load of others. But providing >>> users an easy way to build programs using EB built modules is a big >>> bonus. >>> >>> >>> jack >>> >>> >>> >>> ------------------------------------------------------------ >>> ------------------------------------ >>> ------------------------------------------------------------ >>> ------------------------------------ >>> 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 >>> ------------------------------------------------------------ >>> ------------------------------------ >>> ------------------------------------------------------------ >>> ------------------------------------ >>> >>> >> > -- Dr. Alan O'Cais E-CAM Software Manager Juelich Supercomputing Centre Forschungszentrum Juelich GmbH 52425 Juelich, Germany Phone: +49 2461 61 5213 Fax: +49 2461 61 6656 E-mail: [email protected] WWW: http://www.fz-juelich.de/ias/jsc/EN
