specifying path for license file for commercial compiler?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

specifying path for license file for commercial compiler?

Clune, Thomas L. (GSFC-6101)
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?







--

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
Reply | Threaded
Open this post in threaded view
|

Re: specifying path for license file for commercial compiler?

Marc CHEVRIER
May be using a toolchain file is more appropriate. See 


Le ven. 6 juil. 2018 à 22:59, Clune, Thomas L. (GSFC-6101) <[hidden email]> a écrit :
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?







--

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

--

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
Reply | Threaded
Open this post in threaded view
|

Re: specifying path for license file for commercial compiler?

Stephen McDowell
I agree that a toolchain file is more appropriate, noting that typically modifying the environment variables is much more common for there's compilers (particularly using environment modules).

However, since you've started clearly you would rather not set the environment variables, there may be an easier "hack".

Intel also looks in /opt/intel/licenses for any .lic files. So if you want, you can just create a symbolic link or copy your license file there :)

On Fri, Jul 6, 2018, 10:49 PM Marc CHEVRIER <[hidden email]> wrote:
May be using a toolchain file is more appropriate. See 


Le ven. 6 juil. 2018 à 22:59, Clune, Thomas L. (GSFC-6101) <[hidden email]> a écrit :
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?







--

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
--

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

--

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
Reply | Threaded
Open this post in threaded view
|

Re: specifying path for license file for commercial compiler?

Clune, Thomas L. (GSFC-6101)
In reply to this post by Marc CHEVRIER

Marc,

 

Thank you for the suggestion.  Unfortunately, I’m a bit confused by the documentation and not at all sure how to proceed.   Further help would be appreciated.

 

In particular, I do not see how to capture the existing Fortran, C and CXX toolchains and then provide the minor extension of setting this one environment variable.   In fact, at the moment, I don’t even see a simple way to cut-and-paste the cmake built-in toolchains into a file to use as my baseline for extension.

 

Am I correct in assuming that once the above issues are solved, then a simple line of the form

 

set(ENV(INTEL_LICENSE_FILE) “…”)

 

will then ensure that the compiler “sees” that env variable?   Or do I need to wrap the compiler in a script which just raises many more issues as I need my project to be able to build with many different versions of the  Intel compiler.

 

Thanks in advance,

 

  • Tom

 

 

From: Marc CHEVRIER <[hidden email]>
Date: Saturday, July 7, 2018 at 1:49 AM
To: "Clune, Thomas L. (GSFC-6101)" <[hidden email]>
Cc: CMake MailingList <[hidden email]>
Subject: Re: [CMake] specifying path for license file for commercial compiler?

 

May be using a toolchain file is more appropriate. See 

 

 

Le ven. 6 juil. 2018 à 22:59, Clune, Thomas L. (GSFC-6101) <[hidden email]> a écrit :

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?







--

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


--

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
Reply | Threaded
Open this post in threaded view
|

Re: specifying path for license file for commercial compiler?

Clune, Thomas L. (GSFC-6101)
In reply to this post by Stephen McDowell

Unfortunately, I cannot dictate where the sysadmins are putting the license file.     I can of course put a copy in  /home/<user>/Licenses which is another location that Intel looks by default.   And if there is no better solution, I will provide instructions to all of our developers on making copies themselves on our various development platforms.    Or at that point I’ll just ask them all to set the environment variable in their shell startup files.

 

I’m still a bit astonished that something as simple as this is essentially unsupported.    It is particularly frustrating as try_run() successfully exercises the compiler while the run-of-the-mill compiler invocations under make do not.   Sort of makes sense though.  CMake launches try_run() in a subshell and therefore it sees the env variable I am setting with set(ENV…).   OTOH, the subsequent make commands are not subshells and therefore need a separate mechanism to see that env variable.  

 

 

From: Stephen McDowell <[hidden email]>
Date: Saturday, July 7, 2018 at 2:25 AM
To: Marc CHEVRIER <[hidden email]>
Cc: "Clune, Thomas L. (GSFC-6101)" <[hidden email]>, CMake MailingList <[hidden email]>
Subject: Re: [CMake] specifying path for license file for commercial compiler?

 

I agree that a toolchain file is more appropriate, noting that typically modifying the environment variables is much more common for there's compilers (particularly using environment modules).

 

However, since you've started clearly you would rather not set the environment variables, there may be an easier "hack".

 

Intel also looks in /opt/intel/licenses for any .lic files. So if you want, you can just create a symbolic link or copy your license file there :)

 

On Fri, Jul 6, 2018, 10:49 PM Marc CHEVRIER <[hidden email]> wrote:

May be using a toolchain file is more appropriate. See 

 

 

Le ven. 6 juil. 2018 à 22:59, Clune, Thomas L. (GSFC-6101) <[hidden email]> a écrit :

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?







--

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

--

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


--

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
Reply | Threaded
Open this post in threaded view
|

Re: specifying path for license file for commercial compiler?

Juan E. Sanchez
Hi,

Could you create a simple compiler wrapper script, and point the
CMAKE_*_COMPILER variables there:

#!/bin/bash
export INTEL_LICENSE_FILE=/usr/local/intel/license
/path/to/ifort "$@"

Regards,

Juan


On 7/8/18 8:41 PM, Clune, Thomas L. (GSFC-6101) wrote:

> Unfortunately, I cannot dictate where the sysadmins are putting the
> license file.     I can of course put a copy in  /home/<user>/Licenses
> which is another location that Intel looks by default.   And if there is
> no better solution, I will provide instructions to all of our developers
> on making copies themselves on our various development platforms.    Or
> at that point I’ll just ask them all to set the environment variable in
> their shell startup files.
>
> I’m still a bit astonished that something as simple as this is
> essentially unsupported.    It is particularly frustrating as try_run()
> successfully exercises the compiler while the run-of-the-mill compiler
> invocations under make do not. Sort of makes sense though.  CMake
> launches try_run() in a subshell and therefore it sees the env variable
> I am setting with set(ENV…).   OTOH, the subsequent make commands are
> not subshells and therefore need a separate mechanism to see that env
> variable.
>
> *From: *Stephen McDowell <[hidden email]>
> *Date: *Saturday, July 7, 2018 at 2:25 AM
> *To: *Marc CHEVRIER <[hidden email]>
> *Cc: *"Clune, Thomas L. (GSFC-6101)" <[hidden email]>, CMake
> MailingList <[hidden email]>
> *Subject: *Re: [CMake] specifying path for license file for commercial
> compiler?
>
> I agree that a toolchain file is more appropriate, noting that typically
> modifying the environment variables is much more common for there's
> compilers (particularly using environment modules).
>
> However, since you've started clearly you would rather not set the
> environment variables, there may be an easier "hack".
>
> Intel also looks in /opt/intel/licenses for any .lic files. So if you
> want, you can just create a symbolic link or copy your license file there :)
>
> On Fri, Jul 6, 2018, 10:49 PM Marc CHEVRIER <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     May be using a toolchain file is more appropriate. See
>
>     https://cmake.org/cmake/help/v3.12/manual/cmake-toolchains.7.html
>
>     Le ven. 6 juil. 2018 à 22:59, Clune, Thomas L. (GSFC-6101)
>     <[hidden email] <mailto:[hidden email]>> a écrit :
>
>         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?
>
>
>
>
>
>
>
>         --
>
>         Powered by www.kitware.com <http://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
>
>     --
>
>     Powered by www.kitware.com <http://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
>
>
>

--

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
Reply | Threaded
Open this post in threaded view
|

Re: specifying path for license file for commercial compiler?

Hendrik Sattler
In reply to this post by Clune, Thomas L. (GSFC-6101)
You  could user "cmake -E env ...." in combination with https://cmake.org/cmake/help/v3.12/prop_gbl/RULE_LAUNCH_COMPILE.html and maybe https://cmake.org/cmake/help/v3.12/prop_gbl/RULE_LAUNCH_LINK.html if needed.


Am 6. Juli 2018 22:34:04 MESZ schrieb "Clune, Thomas L. (GSFC-6101)" <[hidden email]>:

>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?
>
>
>
>
>
>
>
>--
>
>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
--

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
Reply | Threaded
Open this post in threaded view
|

Re: specifying path for license file for commercial compiler?

Alan W. Irwin-2
In reply to this post by Clune, Thomas L. (GSFC-6101)
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
Reply | Threaded
Open this post in threaded view
|

Re: specifying path for license file for commercial compiler?

Marc CHEVRIER
In reply to this post by Clune, Thomas L. (GSFC-6101)
You have just to put set command (not cache) for your compiler (CMAKE_Fortran_COMPILER) and environment variable in a file and specify this file on cmake command line with option -DCMAKE_TOOLCHAIN_FILE=your-file.

Le lun. 9 juil. 2018 à 03:32, Clune, Thomas L. (GSFC-6101) <[hidden email]> a écrit :

Marc,

 

Thank you for the suggestion.  Unfortunately, I’m a bit confused by the documentation and not at all sure how to proceed.   Further help would be appreciated.

 

In particular, I do not see how to capture the existing Fortran, C and CXX toolchains and then provide the minor extension of setting this one environment variable.   In fact, at the moment, I don’t even see a simple way to cut-and-paste the cmake built-in toolchains into a file to use as my baseline for extension.

 

Am I correct in assuming that once the above issues are solved, then a simple line of the form

 

set(ENV(INTEL_LICENSE_FILE) “…”)

 

will then ensure that the compiler “sees” that env variable?   Or do I need to wrap the compiler in a script which just raises many more issues as I need my project to be able to build with many different versions of the  Intel compiler.

 

Thanks in advance,

 

  • Tom

 

 

From: Marc CHEVRIER <[hidden email]>
Date: Saturday, July 7, 2018 at 1:49 AM
To: "Clune, Thomas L. (GSFC-6101)" <[hidden email]>
Cc: CMake MailingList <[hidden email]>
Subject: Re: [CMake] specifying path for license file for commercial compiler?

 

May be using a toolchain file is more appropriate. See 

 

 

Le ven. 6 juil. 2018 à 22:59, Clune, Thomas L. (GSFC-6101) <[hidden email]> a écrit :

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?







--

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


--

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
Reply | Threaded
Open this post in threaded view
|

Re: specifying path for license file for commercial compiler?

Clune, Thomas L. (GSFC-6101)
In reply to this post by Alan W. Irwin-2


> On Jul 9, 2018, at 1:04 AM, Alan W. Irwin <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: specifying path for license file for commercial compiler?

Clune, Thomas L. (GSFC-6101)
In reply to this post by Marc CHEVRIER
Mark and Juan,

Thanks!   Between your two suggestions I was able to make something work.    My first attempt at using -DCMAKE_TOOLCHAIN_FILE resulted in some error messages that I completely misinterpreted as needing to “re-teach”  CMAKE about the Intel compiler.    A simple wrapper for the compiler does exactly what was desired.





> On Jul 9, 2018, at 4:40 AM, Marc CHEVRIER <[hidden email]> wrote:
>
> You have just to put set command (not cache) for your compiler (CMAKE_Fortran_COMPILER) and environment variable in a file and specify this file on cmake command line with option -DCMAKE_TOOLCHAIN_FILE=your-file.



> On Jul 8, 2018, at 10:32 PM, Juan E. Sanchez <[hidden email]> wrote:
>
> Hi,
>
> Could you create a simple compiler wrapper script, and point the CMAKE_*_COMPILER variables there:
>
> #!/bin/bash
> export INTEL_LICENSE_FILE=/usr/local/intel/license
> /path/to/ifort "$@"
>
> Regards,
>
> Juan
>

--

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
Reply | Threaded
Open this post in threaded view
|

Re: specifying path for license file for commercial compiler?

Alan W. Irwin-2
In reply to this post by Clune, Thomas L. (GSFC-6101)
On 2018-07-09 12:48-0000 Clune, Thomas L. (GSFC-6101) wrote:

[...]
> 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.

I agree with your overall conclusion (and many other interesting
points you made which I didn't quote).

> 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.

I have no experience with that compiler myself, but a colleague has
taken advantage of its well-known strictness to make sure the Fortran
binding of the PLplot C library (which is implemented using the
iso_c_binding module) is fully compliant with the Fortran 2003
standard with run-time results that pass our Fortran tests (which
demand that our standard set of 33 plot examples written in Fortran
2003 give identical results to the corresponding C examples).  He has
also achieved similar testing success with ifort, and I have done the
same with gfortran.  So with PLplot, those three Fortran compilers
give perfect test results and although we haven't yet had the time to
look at other Fortran compilers presumably most of them will also
produce perfect test results (since most Fortran vendors report they
have correctly implemented all parts of the iso_c_binding module).

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