Re: [CMake] ENOEXEC exit code from ctest on FreeBSD

[Eric Noulard]

Le lun. 9 juil. 2018 à 07:14, Anoop C S  a écrit :

> Hi all,
>
> While running tests from a wip branch[1] for socket_wrapper project I
> noticed the following output
> on FreeBSD:
>
>
Your issue seems more related with the "socker wrapper" project than with
CMake/CTest but...


> Following that I ran one among the failed tests from the above list using
> `ctest`:
>
> # ctest -R test_thread_echo_tcp_connect
> Test project /root/build
> Start 21: test_thread_echo_tcp_connect
> 1/1 Test #21: test_thread_echo_tcp_connect .***Failed0.07 sec
>
> 0% tests passed, 1 tests failed out of 1
>
> Total Test time (real) =   0.07 sec
>
> The following tests FAILED:
>  21 - test_thread_echo_tcp_connect (Failed)
> Errors while running CTest
>

If you want to have more verbose output from ctest you an run:

ctest -R test_thread_echo_tcp_connect -VV

and ctest will spit out whatever output "test_thread_echo_tcp_connect" is
giving.
otherwise did you try to run the test "manually" without ctest:

from
https://git.cryptomilk.org/users/asn/socket_wrapper.git/tree/tests/CMakeLists.txt?h=master-fix
it looks like the test executable is:

test_thread_echo_tcp_connect

so try running:

./test_thread_echo_tcp_connect

and whether it fails or not.



> # uname -a
> FreeBSD bazinga.localdomain 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321309:
> Fri Jul 21 02:08:28 UTC
> 2017 r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
>
>
You seem to be compiling and running your tests as 'root' user. This is
usually not a good idea
(even if it may not have anything to do with your failure).


> I couldn't see any genuine errors from the test logs as such. Am I missing
> something? Since I am a
> newbie to FreeBSD(and also to cmake) I would require some help to debug
> the reason for ENOEXEC exit
> code.
>

Try running in verbose mode, you may even debug into the test if you run
the test without ctest.


>
> Note:- The failed test cases uses threads.
> [1]
> https://git.cryptomilk.org/users/asn/socket_wrapper.git/log/?h=master-fix
>
>
Then I suggest you ask on the project mailing list what may make this test
fail.

-- 
Eric
-- 

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

[CMake] ENOEXEC exit code from ctest on FreeBSD

[Anoop C S]

Hi all,

While running tests from a wip branch[1] for socket_wrapper project I noticed 
the following output
on FreeBSD:

# make test
Running tests...
Test project /root/build
  Start  1: test_ioctl
 1/25 Test  #1: test_ioctl .   Passed0.03 sec
  Start  2: test_tcp_listen
 2/25 Test  #2: test_tcp_listen    Passed0.03 sec
  Start  3: test_tcp_dup2
 3/25 Test  #3: test_tcp_dup2 ..   Passed0.03 sec
  Start  4: test_fcntl
 4/25 Test  #4: test_fcntl .   Passed0.03 sec
  Start  5: test_echo_tcp_connect
 5/25 Test  #5: test_echo_tcp_connect ..   Passed0.07 sec
  Start  6: test_echo_tcp_bind
 6/25 Test  #6: test_echo_tcp_bind .   Passed0.34 sec
  Start  7: test_echo_tcp_socket_options
 7/25 Test  #7: test_echo_tcp_socket_options ...   Passed0.23 sec
  Start  8: test_echo_tcp_sendmsg_recvmsg
 8/25 Test  #8: test_echo_tcp_sendmsg_recvmsg ..   Passed0.19 sec
  Start  9: test_echo_tcp_write_read
 9/25 Test  #9: test_echo_tcp_write_read ...   Passed0.13 sec
  Start 10: test_echo_tcp_writev_readv
10/25 Test #10: test_echo_tcp_writev_readv .   Passed0.16 sec
  Start 11: test_echo_tcp_get_peer_sock_name
11/25 Test #11: test_echo_tcp_get_peer_sock_name ...   Passed0.28 sec
  Start 12: test_echo_udp_sendto_recvfrom
12/25 Test #12: test_echo_udp_sendto_recvfrom ..   Passed0.23 sec
  Start 13: test_echo_udp_send_recv
13/25 Test #13: test_echo_udp_send_recv    Passed0.12 sec
  Start 14: test_echo_udp_sendmsg_recvmsg
14/25 Test #14: test_echo_udp_sendmsg_recvmsg ..   Passed0.28 sec
  Start 15: test_swrap_unit
15/25 Test #15: test_swrap_unit    Passed0.00 sec
  Start 16: test_max_sockets
16/25 Test #16: test_max_sockets ...   Passed0.01 sec
  Start 17: test_close_failure
17/25 Test #17: test_close_failure .   Passed0.03 sec
  Start 18: test_fork_thread_deadlock
18/25 Test #18: test_fork_thread_deadlock ..   Passed0.00 sec
  Start 19: test_tcp_socket_overwrite
19/25 Test #19: test_tcp_socket_overwrite ..   Passed0.03 sec
  Start 20: test_thread_sockets
20/25 Test #20: test_thread_sockets    Passed0.02 sec
  Start 21: test_thread_echo_tcp_connect
21/25 Test #21: test_thread_echo_tcp_connect ...***Failed0.07 sec
  Start 22: test_thread_echo_tcp_write_read
22/25 Test #22: test_thread_echo_tcp_write_read ***Failed0.07 sec
  Start 23: test_thread_echo_tcp_sendmsg_recvmsg
23/25 Test #23: test_thread_echo_tcp_sendmsg_recvmsg ...***Failed0.07 sec
  Start 24: test_thread_echo_udp_send_recv
24/25 Test #24: test_thread_echo_udp_send_recv .   Passed0.08 sec
  Start 25: test_sendmsg_recvmsg_fd
25/25 Test #25: test_sendmsg_recvmsg_fd    Passed0.00 sec

88% tests passed, 3 tests failed out of 25

Total Test time (real) =   2.54 sec

The following tests FAILED:
 21 - test_thread_echo_tcp_connect (Failed)
 22 - test_thread_echo_tcp_write_read (Failed)
 23 - test_thread_echo_tcp_sendmsg_recvmsg (Failed)
Errors while running CTest
*** Error code 8

Stop.
make: stopped in /root/build

Following that I ran one among the failed tests from the above list using 
`ctest`:

# ctest -R test_thread_echo_tcp_connect
Test project /root/build
Start 21: test_thread_echo_tcp_connect
1/1 Test #21: test_thread_echo_tcp_connect .***Failed0.07 sec

0% tests passed, 1 tests failed out of 1

Total Test time (real) =   0.07 sec

The following tests FAILED:
 21 - test_thread_echo_tcp_connect (Failed)
Errors while running CTest

# echo $?
8

# uname -a
FreeBSD bazinga.localdomain 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321309: Fri 
Jul 21 02:08:28 UTC
2017 r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

# cmake --version
cmake version 3.10.2

CMake suite maintained and supported by Kitware (kitware.com/cmake).

I couldn't see any genuine errors from the test logs as such. Am I missing 
something? Since I am a
newbie to FreeBSD(and also to cmake) I would require some help to debug the 
reason for ENOEXEC exit
code.

Note:- The failed test cases uses threads.

[1] https://git.cryptomilk.org/users/asn/socket_wrapper.git/log/?h=master-fix


Thanks,
Anoop C S.
-- 

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/

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

[Alan W. Irwin]

On 2018-07-06 20:34- 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 

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

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

[Hendrik Sattler]

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)" 
:
>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 
>
>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

Re: [CMake] 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//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 
*Date: *Saturday, July 7, 2018 at 2:25 AM
*To: *Marc CHEVRIER 
*Cc: *"Clune, Thomas L. (GSFC-6101)" , CMake 
MailingList 
*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 > 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)
mailto:thomas.l.cl...@nasa.gov>> 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 

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
CM

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

[Clune, Thomas L. (GSFC-6101)]

Unfortunately, I cannot dictate where the sysadmins are putting the license 
file. I can of course put a copy in  /home//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 
Date: Saturday, July 7, 2018 at 2:25 AM
To: Marc CHEVRIER 
Cc: "Clune, Thomas L. (GSFC-6101)" , CMake MailingList 

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 
mailto:marc.chevr...@gmail.com>> 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) 
mailto:thomas.l.cl...@nasa.gov>> 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 

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

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

[Clune, Thomas L. (GSFC-6101)]

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

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) 
mailto:thomas.l.cl...@nasa.gov>> 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 

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

[CMake] find_package: keyword REQUIRED ignored

[Quaquaraquà]

Hi there,

I'm using a custom script [1] to look for the library sqlite3. However, 
the keyword "REQUIRED" (as quietly) is ignored by find_package. That is 
even if the library is not found, the script continues is processing:


// CMakeLists.txt

cmake_minimum_required(VERSION 3.10)project(hello_world)list(APPEND CMAKE_MODULE_PATH 
"${CMAKE_SOURCE_DIR}/build-aux/")
find_package(SQLite3 REQUIRED)

// output:

cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_COMPILER=clang 
-DCMAKE_CXX_COMPILER=clang++ -G "CodeBlocks - Unix Makefiles" ../

-- Could NOT find SQLITE3 (missing: SQLITE3_LIBRARY)
-- Configuring done
-- Generating done
-- Build files have been written to: ...


Any idea what is wrong here?


[1] 
https://github.com/LuaDist/libsqlite3/blob/master/cmake/FindSQLite3.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

Re: [CMake] Eclipse CDT4 - Unix Makefiles / Ninja Generator

[Alexander Neundorf]

On 2018 M07 7, Sat 19:09:18 CEST Martin Weber wrote:
> Hi all,
> 
> FYI, according to this [1], those generators do no longer work with the new
> core build introduced in CDT 9.5.
> 
> Martin
> 
> [1] http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg33066.html

do you know whether the new build system of CDT is documented somewhere ?
I found this, but this is far from enough.
http://www.eclipse.org/org/langsymp/CDT%20Managed%20Build%20System.pdf

Alex

-- 

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

[CMake] groups of ascii nul ('\0) characters inserted into make output but this just occurs for parallel builds

[Alan W. Irwin]

My parallel builds on my Linux OS (currently Debian Buster, but this
also happened for Debian Jessie so this is a long-standing problem)
have ascii null ('\0) characters inserted in the output while the
corresponding non-parallel build does not have those extra characters.
For example, for the PLplot case and proceeding from a clean start
by configuring PLplot in an initially empty build tree:

software@merlin> make -j16 test_noninteractive >& test_noninteractive.out
software@merlin> od -c test_noninteractive.out |grep '\\0'
0713660   g   r   a   d   i   e   n   t   .  \n  \n  \0  \0  \0  \0  \0
0713700  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0717000  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0717540  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0   O   u   t
0722160   1   4   f   .   f   9   0   .   o  \n  \0  \0  \0  \0  \0  \0
0722200  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0722740  \0  \0  \0  \0  \0  \0  \0   O   u   t   p   u   t   f   i

Note the test_noninteractive target has been configured by the PLplot
build system to build all non-interactive test command prerequisties
and then runs those test commands.  (Note, these test commands are
just executables that I build and are not formal CMake test commands
that, for example, are run by ctest.)  Also note those '\0' characters
occur in groups, and there are three such groups in the output, but
because parallel builds mix target outputs together it is impossible
to tell which target is generating the '\0' characters.  And if I drop
the parallel build (-j16) option, the issue goes away.

Note, there is a chance this is an operating system problem rather
than a CMake problem.  For example, my shell (bash) might not properly
handle the case where many different applications are simultaneously
outputting to stdout.  But if so, it is a difficult issue to
replicate.  For example, I implemented a simple Makefile where the all
target had 10 different prerequisites, and each of those prerequisites
used the the cat command to output the UTF-8 contents of the same file
where the file was long enough (in this case ~1 characters) so the
different outputs were mixed together for the parallel build case.
But that test failed to replicate the issue because the parallel and
non-parallel builds produced output with the same number of characters
(which was 10 times the number of characters in the file), and further
evaluation using "od -c" showed no instances of "\0" in either the
parallel or non-parallel output.

So two questions for those who are lurking here:

1. Have you ever experienced this problem when building a target with
large numbers of prerequisites in parallel with CMake, and if so, what
was the fix?

2. It is possible (although I cannot imagine how the symptoms would
just be limited to emission of extra '\0' characters) this issue could
be the symptom of a parallel build race condition for the PLplot build
system.  To help eliminate or confirm this possibility what is the most
fool-proof method to diagnose whether such a race exists?

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