Re: [CMake] Is there a way to obtain the current compiler standard flag?
Ack! Apparently even the hard way won't work, because apparently one
cannot nest $
set(CXX_STD_FLAG "$,\
$>,${CMAKE_CXX11_EXTENSION_COMPILE_OPTION},\
$>,${CMAKE_CXX14_EXTENSION_COMPILE_OPTION},\
$>,${CMAKE_CXX17_EXTENSION_COMPILE_OPTION},\
$>,${CMAKE_CXX20_EXTENSION_COMPILE_OPTION},\
${CMAKE_CXX98_EXTENSION_COMPILE_OPTION}>>>>,\
$>,${CMAKE_CXX11_STANDARD_COMPILE_OPTION},\
$>,${CMAKE_CXX14_STANDARD_COMPILE_OPTION},\
$>,${CMAKE_CXX17_STANDARD_COMPILE_OPTION},\
$>,${CMAKE_CXX20_STANDARD_COMPILE_OPTION},\
${CMAKE_CXX98_STANDARD_COMPILE_OPTION}>>>>>")
begets:
First parameter to $ must resolve to exactly one '0' or '1' value.
I'm all out of ideas. Any new ones would be appreciated.
Thanks,
Chris.
On 6/1/18 3:00 PM, Chris Green wrote:
Hi,
I was hoping this would work:
$,${CMAKE_CXX$_EXTENSION_COMPILE_OPTION},${CMAKE_CXX$_STANDARD_COMPILE_OPTION}>
But apparently it's not legal to calculate a variable name based on a
generator expression. Is there some elegant way to get want I want
here or do I have to check specifically for 98, 11, 14, 17, 20, etc?
Thanks,
Chris.
On 6/1/18 8:27 AM, Chris Green wrote:
Hi,
I'll give this a shot, thank you. Ideally we'd have a generator
expression pick up ${std} from the relevant target property, but I'll
have to play with that since I'm not familiar enough with generator
expressions to know /a priori/ how this will turn out.
Thanks for your help,
Chris.
On 5/30/18 3:12 PM, Chuck Atkins wrote:
Hi Chris.
Try using the the CMAKE_CXX${std}_STANDARD_COMPILE_OPTION variable.
For example, the folowing piece of CMake code:
cmake_minimum_required(VERSION 3.9)
project(foo CXX)
foreach(std IN ITEMS 98 11 14 17)
message("C++${std} std flags:
${CMAKE_CXX${std}_STANDARD_COMPILE_OPTION}")
message("C++${std} ext flags:
${CMAKE_CXX${std}_EXTENSION_COMPILE_OPTION}")
endforeach()
Wll generate for GCC on Linux:
-- The CXX compiler identification is GNU 8.1.1
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
C++98 std flags: -std=c++98
C++98 ext flags: -std=gnu++98
C++11 std flags: -std=c++11
C++11 ext flags: -std=gnu++11
C++14 std flags: -std=c++14
C++14 ext flags: -std=gnu++14
C++17 std flags: -std=c++1z
C++17 ext flags: -std=gnu++1z
-- Configuring done
PGI on Linux:
-- The CXX compiler identification is PGI 18.4.0
-- Check for working CXX compiler: /opt/pgi/linux86-64/18.4/bin/pgc++
-- Check for working CXX compiler:
/opt/pgi/linux86-64/18.4/bin/pgc++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
C++98 std flags: -A
C++98 ext flags: --gnu_extensions
C++11 std flags: --c++11;-A
C++11 ext flags: --c++11;--gnu_extensions
C++14 std flags: --c++14;-A
C++14 ext flags: --c++14;--gnu_extensions
C++17 std flags: --c++17;-A
C++17 ext flags: --c++17;--gnu_extensions
-- Configuring done
And for IBM XL on AIX:
-- The CXX compiler identification is XL 13.1.3
-- Check for working CXX compiler: /usr/bin/xlC
-- Check for working CXX compiler: /usr/bin/xlC -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
C++98 std flags: -qlanglvl=strict98
C++98 ext flags: -qlanglvl=extended
C++11 std flags: -qlanglvl=extended0x
C++11 ext flags: -qlanglvl=extended0x
C++14 std flags:
C++14 ext flags:
C++17 std flags:
C++17 ext flags:
-- Configuring done
-- Generating done
- Chuck
--
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] Is there a way to obtain the current compiler standard flag?
Hi,
I was hoping this would work:
$,${CMAKE_CXX$_EXTENSION_COMPILE_OPTION},${CMAKE_CXX$_STANDARD_COMPILE_OPTION}>
But apparently it's not legal to calculate a variable name based on a
generator expression. Is there some elegant way to get want I want here
or do I have to check specifically for 98, 11, 14, 17, 20, etc?
Thanks,
Chris.
On 6/1/18 8:27 AM, Chris Green wrote:
Hi,
I'll give this a shot, thank you. Ideally we'd have a generator
expression pick up ${std} from the relevant target property, but I'll
have to play with that since I'm not familiar enough with generator
expressions to know /a priori/ how this will turn out.
Thanks for your help,
Chris.
On 5/30/18 3:12 PM, Chuck Atkins wrote:
Hi Chris.
Try using the the CMAKE_CXX${std}_STANDARD_COMPILE_OPTION variable.
For example, the folowing piece of CMake code:
cmake_minimum_required(VERSION 3.9)
project(foo CXX)
foreach(std IN ITEMS 98 11 14 17)
message("C++${std} std flags:
${CMAKE_CXX${std}_STANDARD_COMPILE_OPTION}")
message("C++${std} ext flags:
${CMAKE_CXX${std}_EXTENSION_COMPILE_OPTION}")
endforeach()
Wll generate for GCC on Linux:
-- The CXX compiler identification is GNU 8.1.1
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
C++98 std flags: -std=c++98
C++98 ext flags: -std=gnu++98
C++11 std flags: -std=c++11
C++11 ext flags: -std=gnu++11
C++14 std flags: -std=c++14
C++14 ext flags: -std=gnu++14
C++17 std flags: -std=c++1z
C++17 ext flags: -std=gnu++1z
-- Configuring done
PGI on Linux:
-- The CXX compiler identification is PGI 18.4.0
-- Check for working CXX compiler: /opt/pgi/linux86-64/18.4/bin/pgc++
-- Check for working CXX compiler: /opt/pgi/linux86-64/18.4/bin/pgc++
-- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
C++98 std flags: -A
C++98 ext flags: --gnu_extensions
C++11 std flags: --c++11;-A
C++11 ext flags: --c++11;--gnu_extensions
C++14 std flags: --c++14;-A
C++14 ext flags: --c++14;--gnu_extensions
C++17 std flags: --c++17;-A
C++17 ext flags: --c++17;--gnu_extensions
-- Configuring done
And for IBM XL on AIX:
-- The CXX compiler identification is XL 13.1.3
-- Check for working CXX compiler: /usr/bin/xlC
-- Check for working CXX compiler: /usr/bin/xlC -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
C++98 std flags: -qlanglvl=strict98
C++98 ext flags: -qlanglvl=extended
C++11 std flags: -qlanglvl=extended0x
C++11 ext flags: -qlanglvl=extended0x
C++14 std flags:
C++14 ext flags:
C++17 std flags:
C++17 ext flags:
-- Configuring done
-- Generating done
- Chuck
--
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] Is there a way to obtain the current compiler standard flag?
Hi,
I'll give this a shot, thank you. Ideally we'd have a generator
expression pick up ${std} from the relevant target property, but I'll
have to play with that since I'm not familiar enough with generator
expressions to know /a priori/ how this will turn out.
Thanks for your help,
Chris.
On 5/30/18 3:12 PM, Chuck Atkins wrote:
Hi Chris.
Try using the the CMAKE_CXX${std}_STANDARD_COMPILE_OPTION variable.
For example, the folowing piece of CMake code:
cmake_minimum_required(VERSION 3.9)
project(foo CXX)
foreach(std IN ITEMS 98 11 14 17)
message("C++${std} std flags:
${CMAKE_CXX${std}_STANDARD_COMPILE_OPTION}")
message("C++${std} ext flags:
${CMAKE_CXX${std}_EXTENSION_COMPILE_OPTION}")
endforeach()
Wll generate for GCC on Linux:
-- The CXX compiler identification is GNU 8.1.1
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
C++98 std flags: -std=c++98
C++98 ext flags: -std=gnu++98
C++11 std flags: -std=c++11
C++11 ext flags: -std=gnu++11
C++14 std flags: -std=c++14
C++14 ext flags: -std=gnu++14
C++17 std flags: -std=c++1z
C++17 ext flags: -std=gnu++1z
-- Configuring done
PGI on Linux:
-- The CXX compiler identification is PGI 18.4.0
-- Check for working CXX compiler: /opt/pgi/linux86-64/18.4/bin/pgc++
-- Check for working CXX compiler: /opt/pgi/linux86-64/18.4/bin/pgc++
-- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
C++98 std flags: -A
C++98 ext flags: --gnu_extensions
C++11 std flags: --c++11;-A
C++11 ext flags: --c++11;--gnu_extensions
C++14 std flags: --c++14;-A
C++14 ext flags: --c++14;--gnu_extensions
C++17 std flags: --c++17;-A
C++17 ext flags: --c++17;--gnu_extensions
-- Configuring done
And for IBM XL on AIX:
-- The CXX compiler identification is XL 13.1.3
-- Check for working CXX compiler: /usr/bin/xlC
-- Check for working CXX compiler: /usr/bin/xlC -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
C++98 std flags: -qlanglvl=strict98
C++98 ext flags: -qlanglvl=extended
C++11 std flags: -qlanglvl=extended0x
C++11 ext flags: -qlanglvl=extended0x
C++14 std flags:
C++14 ext flags:
C++17 std flags:
C++17 ext flags:
-- Configuring done
-- Generating done
- Chuck
--
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] Is there a way to obtain the current compiler standard flag?
Hi, We have to use a utility (Root's rootcling/genreflex tool) as part of a custom command to parse some C++ headers. We are in the process of migrating from using raw -std= additions to compilation flags to use of CMAKE_CXX_STANDARD and friends. We need to pass the correct compiler flag to the invocation of rootcling in order to ensure headers are parsed correctly based on the CXX_STANDARD and CXX_EXTENSIONS properties, but we don't appear to be able to discover what it is. We could generate it from scratch like we did before, but it seems like it would be preferable to be able to pass it to the command as already calculated by CMake, perhaps via a generator expression. Is there some way to do this already that I missed, or would this be an enhancement? Thanks, Chris. -- 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] Add CXX dependency generation to custom command for Ninja?
Hi,
We have a custom command for a third-party utility (genreflex, from the
ROOT system) which has a directive:
IMPLICIT_DEPENDS CXX ${CMAKE_CURRENT_SOURCE_DIR}/classes.h
How would I, either as an extra COMMAND or as a separate custom command,
manually invoke the configured CXX compiler with all the
correctly-configured include directories and other pre-processor and
compiler flags with the expected option (-MMD for GCC, I think) on the
above-mentioned classes.h file so that the resulting file can be used in
a DEPFILE directive for the Ninja generator? I would like to model as
closely as possible exactly what CMake would specify to invoke the
compiler to (e.g.) compile an object with only the necessary changes,
but I'm not sure whence to obtain this information. I'm assuming it's
some combination of automatic variables and properties via generator
expressions, but I'm at a loss, I'm afraid. I also don't know whether I
would need to specify the .d file as an OUTPUT or a BYPRODUCTS if I do
this as a COMMAND, or in DEPENDS in addition to DEPFILE if a separate
custom command, and which choice would be better (assuming both of them
work). The resulting CMake code would need to conditionally support both
Makefile and Ninja generators.
Any advice gratefully accepted.
Current custom command definition:
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${dictname}_dict.cpp
${SOURCE_OUTPUT} ${GD_ROOTMAP_OUTPUT} ${PCM_OUTPUT}
COMMAND ${ROOT_GENREFLEX} ${CMAKE_CURRENT_SOURCE_DIR}/classes.h
-s ${CMAKE_CURRENT_SOURCE_DIR}/classes_def.xml
-I${CMAKE_SOURCE_DIR}
${GENREFLEX_INCLUDES} ${GENREFLEX_FLAGS}
-o ${dictname}_dict.cpp
${CLEANUP_COMMAND}
IMPLICIT_DEPENDS CXX ${CMAKE_CURRENT_SOURCE_DIR}/classes.h
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/classes_def.xml
COMMENT "Generating dictionary files for target ${dictname}"
)
Many thanks,
Chris.
--
Chris Green <gre...@fnal.gov>, FNAL CS/SCD/ADSS/SSI/TAC;
'phone (630) 840-2167; Skype: chris.h.green;
IM: gre...@jabber.fnal.gov, chissgreen (AIM),
chris.h.green (Google Talk).
--
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:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] add_test to support generator expressions?
Ah, I see. It appears I was unclear on the difference between target and
test. What I actually want is the *test* property SKIP_RETURN_CODE,
which there does not seem to be any way to access via a generator
expression. Looks like I'm out of look, unless this is an upcoming feature?
Thanks for the clarification,
Chris.
On 10/26/15 3:20 PM, Nils Gladitz wrote:
On 26.10.2015 20:29, Chris Green wrote:
Hi,
I have a function cet_test(), which allows a user to specify the
details of a test which will be executed via a wrapper,
cet_exec_test. It calls the CMake add_test() macro to set this up.
The user may subsequently set the SKIP_RETURN_CODE property on this
test, which must be communicated to cet_exec_test() so that it can
notify CMake if the test requirements are violated. I attempted to do
this with:
add_test(NAME ${target}
...
COMMAND cet_exec_test ... --skip-return-code
$<TARGET_PROPERTY:${target},SKIP_RETURN_CODE>
...)
but this resulted in an error. Am I using generator expressions
wrongly in this case, or does add_test() not support them? Is there
something else I can do?
You did not mention what the error actually is but ...
add_test() does support generator expressions in the command (as long
as you are using the NAME/COMMAND signature; which you are).
Tests are not targets; hence TARGET_PROPERTY does not work here unless
you also happen to have an actual target with the same name as the
test (which is possible but can't be inferred from your snippet) and
you set the property of that target rather than the test.
Nils
--
Chris Green <gre...@fnal.gov>, FNAL CS/SCD/ADSS/SSI/TAC;
'phone (630) 840-2167; Skype: chris.h.green;
IM: gre...@jabber.fnal.gov, chissgreen (AIM),
chris.h.green (Google Talk).
--
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:
http://public.kitware.com/mailman/listinfo/cmake
[CMake] add_test to support generator expressions?
Hi,
I have a function cet_test(), which allows a user to specify the details
of a test which will be executed via a wrapper, cet_exec_test. It calls
the CMake add_test() macro to set this up. The user may subsequently set
the SKIP_RETURN_CODE property on this test, which must be communicated
to cet_exec_test() so that it can notify CMake if the test requirements
are violated. I attempted to do this with:
add_test(NAME ${target}
...
COMMAND cet_exec_test ... --skip-return-code
$<TARGET_PROPERTY:${target},SKIP_RETURN_CODE>
...)
but this resulted in an error. Am I using generator expressions wrongly
in this case, or does add_test() not support them? Is there something
else I can do?
Thanks for any help,
Chris.
--
Chris Green <gre...@fnal.gov>, FNAL CS/SCD/ADSS/SSI/TAC;
--
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:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] add_test to support generator expressions?
Hi,
I should add that I am using CMake 3.3.2.
Sorry for the omission,
Chris.
On 10/26/15 2:29 PM, Chris Green wrote:
Hi,
I have a function cet_test(), which allows a user to specify the
details of a test which will be executed via a wrapper, cet_exec_test.
It calls the CMake add_test() macro to set this up. The user may
subsequently set the SKIP_RETURN_CODE property on this test, which
must be communicated to cet_exec_test() so that it can notify CMake if
the test requirements are violated. I attempted to do this with:
add_test(NAME ${target}
...
COMMAND cet_exec_test ... --skip-return-code
$<TARGET_PROPERTY:${target},SKIP_RETURN_CODE>
...)
but this resulted in an error. Am I using generator expressions
wrongly in this case, or does add_test() not support them? Is there
something else I can do?
Thanks for any help,
Chris.
--
Chris Green <gre...@fnal.gov>, FNAL CS/SCD/ADSS/SSI/TAC;
--
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:
http://public.kitware.com/mailman/listinfo/cmake
[CMake] Utility' targets with ninja generator?
Hi, With UNIX Makefiles I'm used to being able to cd into a subdirectory containing e.g. a C++ source file for which I need to examine the pre-processed source and typing something like, make MyClass.i I can also compile (for fast development cycle and clarity purposes) a single source file and even use tab completion for targets of this nature (with shell completion suitably enabled). This is all great, and improves my productivity measurably. Is there equivalent functionality for the Ninja generator (I'm currently using CMake 3.2.1, but could upgrade to a more recent version easily if appropriate), or can there be (even if only with the new ninja 1.6.0)? My inability to find same is pretty much the only reason I haven't abandoned make in favor of ninja entirely. Thanks for any help, Chris. -- Chris Green gre...@fnal.gov, FNAL CS/SCD/ADSS/SSI/TAC; 'phone (630) 840-2167; Skype: chris.h.green; IM: gre...@jabber.fnal.gov, chissgreen (AIM), chris.h.green (Google Talk). -- 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: http://public.kitware.com/mailman/listinfo/cmake
[CMake] COMMENT ignored for POST_BUILD custom command?
Hi,
With CMake 3.1.2, I don't see my specified COMMENT for a POST_BUILD
command on a library target, viz:
add_custom_command(TARGET ${LIB_TARGET}
POST_BUILD
COMMAND ln -sf $TARGET_LINKER_FILE_NAME:${LIB_TARGET}
${CMAKE_SHARED_LIBRARY_PREFIX}${alias}${CMAKE_SHARED_LIBRARY_SUFFIX}
COMMENT Generate / refresh courtesy link
${CMAKE_SHARED_LIBRARY_PREFIX}${alias}${CMAKE_SHARED_LIBRARY_SUFFIX} -
$TARGET_LINKER_FILE_NAME:${LIB_TARGET}
VERBATIM
WORKING_DIRECTORY ${LIBRARY_OUTPUT_PATH})
The documentation doesn't suggest that this is intended behavior. Is
this a bug, or am I doing something wrong? The desired action does get
carried out during a build as desired, but there is no screen output of
COMMENT to herald the generation of the link.
Thanks,
Chris.
--
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:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] COMMENT ignored for POST_BUILD custom command?
On 3/20/15 12:11 PM, Christopher H Green wrote: Indeed it might, thank you, but I believe I'm seeing the same behavior with ninja also. I can confirm that with CMake 3.2.1, the expected COMMENT is printed with the UNIX Makefile generator, but not for the Ninja generator. Any chance of getting this fixed in an upcoming version? Several of our users are trying out Ninja, and liking what they see so far. Thanks, Chris. Thanks, Chris. Sent from my cell. Original message From: Nils Gladitz Date:2015/03/20 11:57 (GMT-06:00) To: Christopher H Green ,cmake@cmake.org Subject: Re: [CMake] COMMENT ignored for POST_BUILD custom command? On 20.03.2015 16:47, Chris Green wrote: The documentation doesn't suggest that this is intended behavior. Is this a bug, or am I doing something wrong? The desired action does get carried out during a build as desired, but there is no screen output of COMMENT to herald the generation of the link. Assuming you are using one of the Makefile generators this might be fixed by: http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=eeb2831b5f35af1ec8a65be343e754ff1c29550d Which is in 3.2.1. Nils -- Chris Green gre...@fnal.gov, FNAL CS/SCD/ADSS/SSI/TAC; 'phone (630) 840-2167; Skype: chris.h.green; IM: gre...@jabber.fnal.gov, chissgreen (AIM), chris.h.green (Google Talk). -- 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: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] COMMENT ignored for POST_BUILD custom command?
On 3/20/15 2:10 PM, Nils Gladitz wrote: On 20.03.2015 19:41, Chris Green wrote: On 3/20/15 12:11 PM, Christopher H Green wrote: Indeed it might, thank you, but I believe I'm seeing the same behavior with ninja also. I can confirm that with CMake 3.2.1, the expected COMMENT is printed with the UNIX Makefile generator, but not for the Ninja generator. Any chance of getting this fixed in an upcoming version? Several of our users are trying out Ninja, and liking what they see so far. In the Makefile generators this was a regression but with the Ninja generator this seems to have never been implemented. CMake Ninja builds are much less verbose than CMake's Makefiles and I am personally quite fond of that fact. In a diagnostic free build (no warnings or errors) this often means a single line of output for the entire build. You could make this a feature request on the issue tracker though. Hi, Thanks for this. I'm in favor of brief myself, but if I've decided I want a message by using the mechanism provided for same, in general I'd like to see it. I'll put the issue in the tracker. Thanks again, Chris. Nils -- Chris Green gre...@fnal.gov, FNAL CS/SCD/ADSS/SSI/TAC; 'phone (630) 840-2167; Skype: chris.h.green; IM: gre...@jabber.fnal.gov, chissgreen (AIM), chris.h.green (Google Talk). -- 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: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] target_link_libraries replacing fully-qualified library with -lx
On 1/29/15 1:34 PM, Stephen Kelly wrote: Chris Green wrote: this library is found with find_library as part of a config.cmake file invoked as part of find_package() Consider reading http://www.cmake.org/cmake/help/v3.1/manual/cmake-packages.7.html at some point. find_library and config files don't go together. Thanks for the advice; I'll take a look, Chris. Thanks, Steve. -- Chris Green gre...@fnal.gov, FNAL CS/SCD/ADSS/SSI/SSD; 'phone (630) 840-2167; Skype: chris.h.green; IM: gre...@jabber.fnal.gov, chissgreen (AIM, Yahoo), chi...@hotmail.com (MSNM), chris.h.green (Google Talk). -- 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: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] target_link_libraries replacing fully-qualified library with -lx
Hi, On 1/29/15 9:36 AM, Brad King wrote: If you link tothis library using a full path manually, what is recorded in the NEEDED field of the resulting binary? Without SONAME many linkers record the full path. Does INPUT avoid that? With the caveat that a -L is necessary for the linker to find the sonam-ed library based on the linker script (and with uncertainties over whether the same-named library in (e.g.) /usr/lib might jump in, thereby recreating the original problem), the correct NEEDED entry does seem to be made in the linked program: $ objdump -p ../../bin/tbb_init_t-x | grep NEEDED NEEDED libtbb.so.2 NEEDED libstdc++.so.6 NEEDED libm.so.6 NEEDED libgcc_s.so.1 NEEDED libc.so.6 NEEDED librt.so.1 I am extremely uneasy about the possibility of finding the wrong library, though. Thanks, Chris. -- Chris Green gre...@fnal.gov, FNAL CS/SCD/ADSS/SSI/SSD; 'phone (630) 840-2167; Skype: chris.h.green; IM: gre...@jabber.fnal.gov, chissgreen (AIM, Yahoo), chi...@hotmail.com (MSNM), chris.h.green (Google Talk). -- 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: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] target_link_libraries replacing fully-qualified library with -lx
Hi, On 1/29/15 11:11 AM, Alexander Neundorf wrote: just to make sure: you did check that the library directory is not part of LIBRARY_PATH ? Alex I have verified that the presence or absence of LIBRARY_PATH (or LD_LIBRARY_PATH) is irrelevant in the presence of a linker script. Best, Chris. -- Chris Green gre...@fnal.gov, FNAL CS/SCD/ADSS/SSI/SSD; 'phone (630) 840-2167; Skype: chris.h.green; IM: gre...@jabber.fnal.gov, chissgreen (AIM, Yahoo), chi...@hotmail.com (MSNM), chris.h.green (Google Talk). -- 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: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] target_link_libraries replacing fully-qualified library with -lx
Hi,
On 1/29/15 9:06 AM, Brad King wrote:
then I'm guessing there's no SONAME:
It can only be this if something tells CMake that it has no SONAME.
That can only happen when it is an imported target with an appropriate
property set. CMake doesn't try to read the binary IIRC.
I can confirm that replacing the text libtbb.so file containing the
INPUT instruction with a link to the library with the SONAME is
sufficient to solve the problem, at least as a short term workaround.
There is no importing of targets: this library is found with
find_library as part of a config.cmake file invoked as part of
find_package(). I don't know whether CMake is using readelf, objdump or
readlink, but it appears that something of that nature is being tried (a
quick search with ack revealed cmELF.{h,cxx}). If interpreting the INPUT
directive were to be added to that procedure, I think we would be very
happy. Should I put an entry in Mantis?
Thanks,
Chris.
--
Chris Green gre...@fnal.gov, FNAL CS/SCD/ADSS/SSI/SSD;
'phone (630) 840-2167; Skype: chris.h.green;
IM: gre...@jabber.fnal.gov, chissgreen (AIM, Yahoo),
chi...@hotmail.com (MSNM), chris.h.green (Google Talk).
--
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:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] target_link_libraries replacing fully-qualified library with -lx
On 1/29/15 7:41 AM, Brad King wrote: On 01/28/2015 03:12 PM, Chris Green wrote: target_link_libraries(target /X/Y/libtbb.so) results in link.txt files containing -ltbb. This happens when the library is in an implicit link directory, or possibly when the library does not have an SONAME field set. Thanks for this, Brad. Assuming that the list of implicit link directories is internal to CMake and nobody has added to it by mistake, then I'm guessing there's no SONAME: *$ ls -l $TBB_LIB** *total 3144 -rw-r--r--. 1 greenc g163 20 Aug 19 07:15 libtbb.so -rwxr-xr-x. 1 greenc g163 2493406 Aug 19 07:15 libtbb.so.2 -rw-r--r--. 1 greenc g163 26 Aug 19 07:15 libtbbmalloc.so -rwxr-xr-x. 1 greenc g163 675732 Aug 19 07:15 libtbbmalloc.so.2 -rw-r--r--. 1 greenc g163 32 Aug 19 07:15 libtbbmalloc_proxy.so -rwxr-xr-x. 1 greenc g163 28976 Aug 19 07:15 libtbbmalloc_proxy.so.2 drwxr-xr-x. 3 greenc g1634096 Jul 23 2013 tbb *$ cat $TBB_LIB/libtbb.so** *INPUT (libtbb.so.2) *$ objdump -p $TBB_LIB/libtbb.so | grep SONAME** *objdump: /home/greenc/work/cet-is/products/tbb/v4_2_5/Linux64bit+2.6-2.12-e6-prof/lib/libtbb.so: File format not recognized *$ objdump -p $TBB_LIB/libtbb.so.2 | grep SONAME** * SONAME libtbb.so.2 I would hazard a guess that the linker instruction in libtbb.so is not sufficient currently for CMake to deduce the SONAME as libtbb.so.2. I can test a workaround when I get to work of replacing the libtbb.so and friends with the more usual symbolic link, but it would be nice if a future version of CMake were able to understand this particular system. Is this analysis correct and reasonable, or is there something I'm missing? Thanks, Chris. For the former case, use an imported target: http://www.cmake.org/cmake/help/v3.1/command/add_library.html#imported-libraries http://www.cmake.org/cmake/help/v3.1/manual/cmake-buildsystem.7.html#imported-targets -Brad -- Chris Green gre...@fnal.gov, FNAL CS/SCD/ADSS/SSI/SSD; 'phone (630) 840-2167; Skype: chris.h.green; IM: gre...@jabber.fnal.gov, chissgreen (AIM, Yahoo), chi...@hotmail.com (MSNM), chris.h.green (Google Talk). -- 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: http://public.kitware.com/mailman/listinfo/cmake
[CMake] target_link_libraries replacing fully-qualified library with -lx
Hi, I've been trying to run down a problem with our cmake-based build system that appears to be a result of a target_link_libraries(...) invocation taking a fully qualified shared library location and replacing it with -llib. Since we're trying very hard to avoid picking up unwanted, older copies of this library from system areas, this is causing us quite some angst. The command: target_link_libraries(target /X/Y/libtbb.so) results in link.txt files containing -ltbb. I wasn't able to find anywhere in documentation that mentioned this was a possible behavior of target_link_libraries, which is why it took us so long to trace it down to this in particular. So, my questions: 1. Is this a bug? 2. If not a bug, what is the rationale for this behavior, and under what circumstances does this behavior get triggered? 3. Is it possible to deactivate this behavior? 4. If not, can it be made possible to deactivate this behavior? Thanks for your help, Chris. -- Chris Green gre...@fnal.gov, FNAL CS/SCD/ADSS/SSI/SSD; 'phone (630) 840-2167; Skype: chris.h.green; IM: gre...@jabber.fnal.gov, chissgreen (AIM, Yahoo), chi...@hotmail.com (MSNM), chris.h.green (Google Talk). -- 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: http://public.kitware.com/mailman/listinfo/cmake
[CMake] Need WILL_FAIL_ASSERTION or equivalent.
Hi, I find myself needing to count a test that I expect to fail an assertion (I'm using CMake 2.8.4). My first attempt, using the test property WILL_FAIL, erm, failed because apparently an abort is trapped as an exception rather than a failing execution. I have worked around this for now by writing a wrapper script, but can I suggest two enhancements (assuming this behavior isn't implemented somewhere I haven't found)? 1. WILL_FAIL be enhanced to take a number as well as true (if this is possible) such that if a number is passed then that is the error code expected and anything else is a failure. 2. A new property WILL_FAIL_ASSERTION which can be either true or a regular expression specifying the particular assertion to be expected, with anything else (even another assertion) being a test failure. Of course, anything that provides the desired behavior (preferably by specifying a test property) would be perfectly fine: the above are merely suggestions. Thanks, Chris. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Stop substitution in passthrough list arguments?
Hi,
I have a macro which takes a variety of arguments and does all the
things necessary for making a test: compiling the exec (or copying the
script), putting input files in the right place and setting desired
properties on the test. I use the ParseArguments
http://www.cmake.org/Wiki/CMakeMacroParseArguments macro found on the
Wiki to handle all the switches and optional list arguments and at some
point I ended up using this system to pass a PASS_REGULAR_EXPRESSION
property through my macro and the argument parser. Unfortunately, by the
time it was processed by the embedded SET_TESTS_PROPERTIES command, what
would have been a simple:
SET_TESTS_PROPERTIES (Unscheduled_03_t PROPERTIES PASS_REGULAR_EXPRESSION
Assertion `handle.isValid\\(\\) == require_presence_' failed.
)
command became:
cet_test(Unscheduled_03_t HANDBUILT
TEST_EXEC test_must_abort
TEST_ARGS art -c Unscheduled_03_t.fcl
TEST_PROPERTIES PASS_REGULAR_EXPRESSION
Assertion `handle.isValid() == require_presence_' failed.
DATAFILES
fcl/Unscheduled_03_t.fcl
fcl/messageDefaults.fcl
)
Note that the parentheses required no less than eight backslash escapes
each in order to be interpreted correctly by the time they were seen by
the SET_TESTS_PROPERTIES command.
Is there any way at all to pass this (or any other) argument through the
cet_test macro's argument parser and embedded SET_TESTS_PROPERTIES
command without getting all those backslashes swallowed? If not, can
there be?
For illustration purposes, the relevant lines from cet_macro are:
MACRO(cet_test CET_TARGET)
#snip
CET_PARSE_ARGS(CET
DATAFILES;DEPENDENCIES;LIBRARIES;SOURCES;TEST_ARGS;TEST_EXEC;TEST_PROPERTIES
HANDBUILT;PREBUILT;NO_AUTO;USE_BOOST_UNIT;INSTALL_EXAMPLE;INSTALL_SOURCE
${ARGN}
)
#snip
IF(CET_TEST_PROPERTIES)
SET_TESTS_PROPERTIES(${CET_TARGET} PROPERTIES ${CET_TEST_PROPERTIES})
ENDIF()
#snip
Thanks for your help,
Chris.
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] make test to run tests in parallel in CMake 2.8?
Hi, I would have expected this naively to be a FAQ already, but the almighty Ge wasn't particularly helpful. If I *have* missed the answer somehow, please accept my apologies and I'd appreciate a brief pointer to the right place to find it: I'm investigating upgrading our build system from CMake 2.6.4 to 2.8.4 for (among other things) its touted ability to run tests in parallel. Indeed, ctest -j12 on an 8-way machine works just fine. However, I seem to be unable to find a way to invoke this behavior from make: make -j12 test is apparently just, make test with more typing. Is there some CMAKE variable I should have provided to enable this behavior, something else I should have done? Or is parallel test behavior just not available without invoking ctest explicitly? If this is the case, is something planned for future releases? Thanks for your help and time, Chris Green. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] make test to run tests in parallel in CMake 2.8?
On 2/28/11 8:13 AM, Michael Wild wrote: On 02/28/2011 03:03 PM, Chris Green wrote: snip Try this: make test ARGS=-j12 Bingo! Thank you, Chris. -- Chris Green gre...@fnal.gov, FNAL CD/ADSS/CET; 'phone (630) 840-2167. IRC: gre...@jabber.fnal.gov, chrisgr...@jabber.dsd.lbl.gov; chissgreen (AIM, Yahoo); chi...@hotmail.com (MSNM); chris.h.green (Google Talk). ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
