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 ... 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. 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. * 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.... :-) 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