[CMake] specifying path for license file for commercial compiler?

[Alan W. Irwin]

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
__________________________