> On Jul 9, 2018, at 1:04 AM, Alan W. Irwin <[email protected]> wrote: > > On 2018-07-06 20:34-0000 Clune, Thomas L. (GSFC-6101) wrote: > >> To use the Intel compiler, one must use an environment variable that >> specifies the path to the license file. E.g., >> >> export INTEL_LICENSE_FILE=/usr/local/intel/license >> >> Other commercial compilers use a very similar mechanism. I had hoped to >> capture such information in a cache file so that I could avoid polluting the >> shell where I am invoking cmake: >> >> % cmake -C my-cache <src-dir> >> >> Such a cache file could look like: >> >> set(CMAKE_Fortran_COMPILER >> "/usr/local/intel/2018/compilers_and_libraries_2018.3.222/linux/bin/intel64/ifort" >> CACHE path "Fortran compiler") >> set(ENV{INTEL_LICENSE_FILE} "/usr/local/intel/license" CACHE path "Intel >> license") >> >> >> Unfortunately, the compiler is not “seeing” the env variable and complains >> that there is no license. Is there a solution to this, or am I forced to >> set the env variable each time I try to build? > > Hi Thomas: > > I only skimmed responses so someone else may have said this as well, > but you will need a valid license both at cmake time (since cmake > typically tests the compiler to see if it works) and also at build > time when you obviously also have to use the compiler. In both cases > to answer your concern about polluting your normal environment > variable setup, I would advocate simply setting the environment > variable *just* for the command, e.g., > > env INTEL_LICENSE_FILE=/usr/local/intel/license cmake .... > env INTEL_LICENSE_FILE=/usr/local/intel/license make …
I agree that this will work, but I’m trying to make things as easy as possible on our “developers”. (Our developers are largely scientists with little interest learning any new details about our build system, and I’m the one forcing them towards cmake.) Currently _every_ other setting in the configuration is captured in the generated make system and their remains a danger that someone will login the next morning and forget to make the extra step. It really is not that big of a deal, but the difference is glaring given nothing else needs this. > > rather than doing anything more complex. > > I also have to ask is ifort really a necessity for you? There are > two reasons I have asked this question. > > * Licensing infrastructure you need with proprietary compilers was > just plain annoying to me in the past. In the old days in a shared > environment I often had to wait to get work done until a compiler > license became available from someone else who was using it. So our > institution kept buying more licenses, but it was never enough. Our computing centers have what is in essence an unlimited license, so this is not an issue for us. (Helps when you buy thousands of cores each year.) There are several issues here. We try to keep our model as portable as possible. In practice this means gfortran, ifort, and PGI, with plans for others. Intel remains the workhorse for the scientists because it generates faster code (10%-25% depending on the configuration.) Any given version of the model is intended therefore to default to a specific version of the Intel compiler. The core team needs the ability to explore variant versions of the compiler as we introduce new features that break older compilers. In theory, and aside from this license file issue, all of the pertinent information can be set on the command line for cmake and then subsequent make commands are very simple ‘make install’. I’ve not yet exposed the scientists to the cmake build system, and they are still using a well-designed but idiosyncratic set of GNUmake + env setup scripts. I would like to capture the details for the variant builds so that the typical scientist can simply type: % cmake <src-dir> % make -j 10 install while the core team can do variants with % cmake <some-flags-to-point-to-gfortran-8.3> <src-dir> or % cmake <some-flags-to-point-to ifort-version++> <src-dir> Currently I am using environment modules (mod and lmod) to load the path for the compiler and license files. This is workable, but I thought I could go one step further and eliminate the need for setting up an environment for the ‘make’ step. > And > also in the old days when Sourceforge had a compile farm including > licensed compilers from Sun, that licensing software was semi-broken > and would often make it impossible to use the Sun part of the compile > farm. Maybe licensing infrastructure is much better implemented now, > but those bad old days completely radicalized me about licensing > infrastructure annoyances, and as a result I have been content for > years to compile fortran code with gfortran which has no licensing > infrastructure annoyances and virtually always produces reliable > results for me. While we technically do not have a mandate to support our compiler for external developers, we do maintain gfortran capabilities for various reasons including the ones you mention above. > > * ifort reliability was not impressive the one time I had some > (indirect) experience with it. For that case, I had a colleague who > wasted a month of both his time and my time trying to use ifort to > compile lapack as well as one of my software projects that required > lapack to solve some linear equations. ifort didn't complain at all, > but simply produced bad results at run time (i.e., the linear > equations were not being solved correctly.) After a lot of hair > pulling we discovered that this guy's habit (he was a strict fortran > traditionalist who would have no truck with new-fangled ideas such as > cmake!) of concatanating all fortran code into one giant file before > compiling it was the cause of the issue; ifort quietly produced bad > code whenever it had to process too many source lines! I hope ifort > is much more reliable now, but it sure gave me a bad first impression > in that regard. > > Hope you don't mind these old war stories.... :-) Based upon conversations with colleagues in other institutions, the most frustrating compiler is always the one you don’t do your development with. Because of my clients, I mostly start with Intel and then get frustrated when a design discovers defects in gfortran. But others that primarily work with gfortran say the same about Intel. My conclusion as that we subconsciously develop a coding style this is (mostly) robust within our native environment. When the situation permits, I mostly develop with the NAG fortran compiler. The generated code is not particularly fast, but the compiler is very strict and very robust. Cheers, - Tom > > Alan > __________________________ > Alan W. Irwin > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
