Re: [CMake] Dependencies of an external project
ExternalProject does its work at build time, so too late for find_package which
is executed at config time.
Have a look at module FetchContent which does its work before config time.
Le 19 nov. 2019 à 16:13 +0100, hex , a écrit :
> I have an external CMake project that gets exported on install. The root
> project uses it as a package. The external project must be installed prior
> being used as a package.
> I can solve this problem by using `ExternalProject` for both projects and
> declare their dependency. My setup is different, though, as the root project
> depends on an external project. Since I am including the external project
> without it having installed on system I am not sure if it is correct to use
> the package as downstream or whether upstream should be applied instead.
>
> Consider the following project structure:
>
> my_test
> ├── cmake
> ├── extern
> │ └── mylibrary
> │ ├── cmake
> │ ├── include
> │ │ └── my_library
> │ └── src
> ├── include
> │ └── my_test
> └── src
>
> `mylibrary` is a standalone project with `export` on install to use its
> library as package.
>
> `my_test` (root) is another project that depends on `mylibrary`.
>
> CMakeLists.txt:
> ```
> # add dependencies
> add_subdirectory( extern )
> add_subdirectory( src )
> ```
>
> extern/CMakeLists.txt:
> ```
> ExternalProject_Add(mylibrary
> CMAKE_ARGS
> -D CMAKE_INSTALL_PREFIX=${CMAKE_BINARY_DIR}
> SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/mylibrary"
> )
> ```
>
> src/CMakeLists.txt:
> ```c
> list( APPEND CMAKE_PREFIX_PATH "${CMAKE_BINARY_DIR}" )
>
> find_package( my_library REQUIRED )
>
> #=
> # Define targets
> #=
> add_executable( MyTestProject test.cpp )
> add_dependencies(MyTestProject my_library-exportname)
> target_link_libraries( MyTestProject PUBLIC my_library-exportname)
> ```
>
> I added `add_dependencies` to have `my_library` be installed prior to
> building `my_test`. However, build fails even before that since I have
> `find_package()` in the same CMake txt file.
>
> How can I setup my install as dependency for a package?
> --
>
> Powered by kitware.com/cmake
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit https://cmake.org/services
>
> Visit other Kitware open-source projects at https://www.kitware.com/platforms
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
> This mailing list is deprecated in favor of https://discourse.cmake.org
--
Powered by kitware.com/cmake
Kitware offers various services to support the CMake community. For more
information on each offering, please visit https://cmake.org/services
Visit other Kitware open-source projects at https://www.kitware.com/platforms
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
This mailing list is deprecated in favor of https://discourse.cmake.org
Re: [CMake] CHECK_CXX_COMPILER_FLAG doesn't give correct result for -fsanitize=address
This is the expected behaviour.
As you already discovered, it is possible to control the compilation and link
steps with variables as described in
https://cmake.org/cmake/help/latest/module/CheckCXXSourceCompiles.html#module:CheckCXXSourceCompiles.
To specify, in a more clean way, link options, use preferably the variable
CMAKE_REQUIRED_LINK_OPTIONS.
Le 24 oct. 2019 à 22:42 +0200, Michael Ellery , a écrit :
> I’ve dealt with that using something like this:
>
> set (_saved_CRL ${CMAKE_REQUIRED_LIBRARIES})
> set (CMAKE_REQUIRED_LIBRARIES “-fsanitize=address;asan")
> check_cxx_compiler_flag (-fsanitize=address COMPILER_SUPPORTS_SAN)
> set (CMAKE_REQUIRED_LIBRARIES ${_saved_CRL})
>
> the second item in CMAKE_REQUIRED_LIBRARIES is only needed when using gcc
> which also requires a -lasan when linking (clang does not need this)
>
> > On Oct 24, 2019, at 12:47 PM, Turner, Adrian Keith via CMake
> > wrote:
> >
> > Hi CMake Mailing List,
> >
> > I am using the CHECK_CXX_COMPILER_FLAG directive in a CMake file to detect
> > whether the compiler uses the "-fsanitize=address" compiler flag. I'm using
> > the g++ 7.3.0 compiler which supports this flag but the
> > CHECK_CXX_COMPILER_FLAG directive incorrectly determines that this flag is
> > not supported.
> >
> > To test this I tried compiling the following program:
> > int main() {};
> >
> > This compiled with the following commands:
> > > g++ -fsanitize=address -c test.cpp
> > > g++ -fsanitize=address test.o -o test.exe
> >
> > And fails with the same error message as CHECK_CXX_COMPILER_FLAG when I
> > compile with:
> > > g++ -fsanitize=address -c test.cpp
> > > g++ test.o -o test.exe
> >
> > producing the following message:
> > Undefined symbols for architecture x86_64:
> > "___asan_init", referenced from:
> > __GLOBAL__sub_I_00099_0_test.cpp in test.o
> > "___asan_version_mismatch_check_v8", referenced from:
> > __GLOBAL__sub_I_00099_0_test.cpp in test.o
> > ld: symbol(s) not found for architecture x86_64
> > collect2: error: ld returned 1 exit status
> >
> > It seems that CHECK_CXX_COMPILER_FLAG doesn't add the flag to the linking
> > command when it tests compilation. Is this a bug with
> > CHECK_CXX_COMPILER_FLAG or is there something I'm missing?
> >
> > Many thanks
> > Adrian Turner
> >
> >
> > --
> >
> > 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] Separating spaces are escaped by JOIN generator expression
This is the way to proceed...
Le 6 août 2019 à 17:23 +0200, Unknown Unknown , a écrit :
> I am getting a further by combining your idea with a "add_custom_command" and
> using the "COMMAND_EXPAND_LISTS" trick I have just discovered. Essentially I
> have something like the following to get the desired results:
>
> list(APPEND DICTIONARY_INCLUDES
> "-I$,$-I>")
>
> add_custom_command(
> OUTPUT ${DICTIONARY_SOURCE}
> COMMAND rootcling -f ${DICTIONARY_SOURCE}
> -rml lib${PROJECT_NAME}.so
> -rmf lib${PROJECT_NAME}.rootmap
> -s lib${PROJECT_NAME}.so
> -inlineInputHeader
> "${DICTIONARY_INCLUDES}"
> -I${CMAKE_CURRENT_SOURCE_DIR} ${DICTIONARY_HEADERS}
> ${CMAKE_CURRENT_SOURCE_DIR}/${DICTIONARY_LINKDEF}
> DEPENDS MyLibrary ${DICTIONARY_HEADERS} ${DICTIONARY_LINKDEF}
> COMMAND_EXPAND_LISTS
> )
>
> > Le mar. 6 août 2019 à 02:56, Marc CHEVRIER a
> > écrit :
> > > Oops, I mean: $ To generate a semi-colon character (I.e. ‘;’)
> > > Le 6 août 2019 à 00:08 +0200, Unknown Unknown , a
> > > écrit :
> > > > Bonjour Marc,
> > > >
> > > > Thanks for the reply! Now I get:
> > > > (add_custom_command):
> > > > Error evaluating generator expression:
> > > >
> > > > $
> > > >
> > > > Expression did not evaluate to a known generator expression
> > > >
> > > > I am really just trying to join the INTERFACE_INCLUDE_DIRECTORIES of my
> > > > target with the "- I" compiler include flags... I have since noticed
> > > > that I don't get a list indeed, and that:
> > > > set(DICTIONARY_INCLUDES "
> > > > -I$,
> > > > -I>")
> > > > does the exact same thing, i.e. the Make/Ninja command is almost
> > > > perfect if it were not for those backslashes coming out of nowhere at
> > > > the end of each include path!
> > > >
> > > > > Le lun. 5 août 2019 à 17:26, Marc CHEVRIER
> > > > > a écrit :
> > > > > > If you want to define a list, try to use $ rather than a
> > > > > > space to separate the items. This way, you will get a CMake list
> > > > > > rather than a string: list(APPEND DICTIONARY_INCLUDES
> > > > > > "-I$,$-I>")
> > > > > > Le 5 août 2019 à 22:56 +0200, Dakeryas , a
> > > > > > écrit :
> > > > > > > I am facing the exact same issue when when joining libraries from
> > > > > > > a target for some CMake function defined by the Cern ROOT library
> > > > > > > (ROOT_GENERATE_DICTIONARY in that case). I am defining a list:
> > > > > > > list(APPEND DICTIONARY_INCLUDES "
> > > > > > > -I$,
> > > > > > > -I>") which is then passed to the ROOT function. I can see from
> > > > > > > the build error that all the includes have a backslash appended,
> > > > > > > i.e.: ... -I/home/user/lib1/include/\ -I/home/user/lib2/include/\
> > > > > > > -I... The BUILD_INTERFACE vs INSTALL_INTERFACE is respected,
> > > > > > > everything seems to work aside from these nasty backlashes... If
> > > > > > > I save the command manually after seeing the error and perform a
> > > > > > > string replacement to remove the backlashes, I get the desired
> > > > > > > result. Is there any fix five years later?
> > > > > > > Sent from the CMake mailing list archive at Nabble.com.
> > > > > > > --
> > > > > > >
> > > > > > > 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] Separating spaces are escaped by JOIN generator expression
If you want to define a list, try to use $ rather than a space to separate the items. This way, you will get a CMake list rather than a string: list(APPEND DICTIONARY_INCLUDES "-I$,$-I>") Le 5 août 2019 à 22:56 +0200, Dakeryas , a écrit : > I am facing the exact same issue when when joining libraries from a target > for some CMake function defined by the Cern ROOT library > (ROOT_GENERATE_DICTIONARY in that case). I am defining a list: list(APPEND > DICTIONARY_INCLUDES " > -I$, -I>") > which is then passed to the ROOT function. I can see from the build error > that all the includes have a backslash appended, i.e.: ... > -I/home/user/lib1/include/\ -I/home/user/lib2/include/\ -I... The > BUILD_INTERFACE vs INSTALL_INTERFACE is respected, everything seems to work > aside from these nasty backlashes... If I save the command manually after > seeing the error and perform a string replacement to remove the backlashes, I > get the desired result. Is there any fix five years later? > Sent from the CMake mailing list archive at Nabble.com. > -- > > 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] FindPython3 Python_FIND_VIRTUALENV seems to be ignored
This is a bug already identified (see https://gitlab.kitware.com/cmake/cmake/issues/19525). I am currently working on a fix. Le 1 août 2019 à 11:33 +0200, sebastian.muell...@zf.com, a écrit : > Hi all, > > I’ve been trying to convince Cmake 15.1 to use the python installation in my > virtual anaconda environment rather than the anaconda base installation. > I’m using this to find python: > > set(Python3_FIND_VIRTUALENV "FIRST") > find_package(Python3 3.6.8 EXACT COMPONENTS Development NumPy) > > First, I’m using Anaconda Prompt to execute the commands. I `activate > testenv`, to activate my environment. > When I then run `cmake .. -G "Visual Studio 14 2015 Win64"`, I get this > output: > > -- Selecting Windows SDK version to target Windows 10.0.16299. > -- The C compiler identification is MSVC 19.0.24215.1 > -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual > Studio 14.0/VC/bin/x86_amd64/cl.exe > -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual > Studio 14.0/VC/bin/x86_amd64/cl.exe – works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info – done > -- Detecting C compile features > -- Detecting C compile features - done > -- Found Git: C:/app/tools/Git/cmd/git.exe (found version "2.17.1.windows.2") > -- Could NOT find Python3: Found unsuitable version "3.6.4", but required is > exact version "3.6.8" (found C:/app/anaconda3/libs/python36.lib) > -- Configuring done > -- Generating done > -- Build files have been written to: D:/src/project/vsbuild > > I would expect cmake rather to find the python in > C:/app/anaconda3/envs/testenv/… since this is the active environment and > according to the > HINT I set it to be favored over other python installations (as documented in > https://cmake.org/cmake/help/v3.15/module/FindPython3.html). > > Additional info: > $ which python > C:/app/anaconda3/envs/testenv/python.exe > $ python –version > Python 3.6.8 :: Anaconda, Inc. > > I’m working on Windows 10. Any ideas what is going wrong? > > Kind regards/Viele Grüße > Sebastian Müller > > -- > > 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] Getting library name from library target to pass to legacy Makefile
An alternate solution is to use generator expression TARGET_LINKER_FILE_NAME because the linker is also able to use full path names rather than radical names as library input. Le 22 juil. 2019 à 17:55 +0200, Dustyn Blasig , a écrit : > Thanks, Marc. That is exactly what I need, but I'm stuck with 3.12.4 for the > foreseeable future. Is there a way to get the equivalent behavior in older > versions? > > > On Mon, Jul 22, 2019 at 1:04 AM Marc CHEVRIER > > wrote: > > > You can use generator expression TARGET_FILE_BASE_NAME, available with > > > version 3.15. > > > Le 22 juil. 2019 à 05:24 +0200, Dustyn Blasig , a écrit > > > : > > > > Hi All, > > > > > > > > I am integrating a legacy Makefile with our CMake flow, and need to > > > > pass the name of a CMake library target to the Makefile via > > > > add_custom_command(). The library uses the OUTPUT_NAME property to > > > > override the default. > > > > > > > > add_library(foo_lib SHARED ...) > > > > set_target_properties(foo_lib PROPERTIES OUTPUT_NAME foo) # Generates > > > > libfoo.so > > > > add_custom_command(... COMMAND make ... FOO_LIB_LINKER_NAME= ...) > > > > > > > > I need to be the value passed to -l of g++, namely -lfoo or > > > > -lfood for debug builds. I can't seem to find an expression/property > > > > that gives this shortened name. The generator expressions like > > > > TARGET_LINKER_FILE_NAME give libfoo.so. > > > > > > > > What is the appropriate way to get just the stem of the library with > > > > the configuration-specific suffix if needed? > > > > > > > > Thanks! > > > > -- > > > > > > > > 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] Getting library name from library target to pass to legacy Makefile
You can use generator expression TARGET_FILE_BASE_NAME, available with version 3.15. Le 22 juil. 2019 à 05:24 +0200, Dustyn Blasig , a écrit : > Hi All, > > I am integrating a legacy Makefile with our CMake flow, and need to pass the > name of a CMake library target to the Makefile via add_custom_command(). The > library uses the OUTPUT_NAME property to override the default. > > add_library(foo_lib SHARED ...) > set_target_properties(foo_lib PROPERTIES OUTPUT_NAME foo) # Generates > libfoo.so > add_custom_command(... COMMAND make ... FOO_LIB_LINKER_NAME= ...) > > I need to be the value passed to -l of g++, namely -lfoo or -lfood for > debug builds. I can't seem to find an expression/property that gives this > shortened name. The generator expressions like TARGET_LINKER_FILE_NAME give > libfoo.so. > > What is the appropriate way to get just the stem of the library with the > configuration-specific suffix if needed? > > Thanks! > -- > > 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] Moving build artifacts to custom directory
Have a look at variables ‘CMAKE_*_OUTPUT_DIRECTORY’ (Like CMAKE_ARCHIVE_OUTPUT_DIRECTORY. See https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html) and target properties ‘*_OUTPUT_DIRECTORY’ (Like ARCHIVE_OUTPUT_DIRECTORY. See https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html). Le 3 juil. 2019 à 08:19 +0200, vinay kumar Kotegowder , a écrit : > Hi Everyone, > > How do I move the build artifacts(ELFs, Static libraries, custom > intermediate files) to custom folder at the build of "cmake --build ." > ? > > Also does "cmake --build . -- clean" takes care of cleaning these > build artifacts from the directory to which they previously moved? > > Regards, > Vinay > -- > > 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] CMake is Converting lists to strings
You are wrongly using the STRING(REPLACE …) command.
The right way to use it to avoid list conversion is to expand the list inside
quotes (to preserve list items separators):
STRING (REPLACE "../" "" SIMPLE_LIST "${SIMPLE_LIST}")
Without the quotes, all list elements are concatenated in the result string
(see documentation).
Another possibility is using LIST(TRANSFORM …):
LIST(TRANSFORM SIMPLE_LIST REPLACE « ^\\.\\./" "")
Le 12 juin 2019 à 12:22 +0200, J Decker , a écrit :
> I know... just need to rebuild a new list... something like
>
> set( _ALL_INCLUDES )
> foreach( INC ${ALL_INCLUDES})
> string(REPLACE "../" "" INC ${INC})
> LIST( APPEND _ALL_INCLUDES ${INC} )
> endforeach( INC )
> set( ALL_INCLUDES ${_ALL_INCLUDES})
>
> > On Wed, Jun 12, 2019 at 3:10 AM J Decker wrote:
> > > I'm collecting sources and includes into a parent scope variable, and
> > > then attempting to use that variable to reference the right sources.
> > > Sources get added to the list as ../(theirpath)/(source) so in the parent
> > > level I can simply replace "../" with "" and then they are relative in
> > > the right place.
> > > This works; as far as, the includes, sources and defines get all
> > > collected into the top level, but when i try to remove the ../ the list
> > > gets converted into a string.
> > >
> > > # Create a list of things
> > > set( SIMPLE_LIST -I../lib1/include -I../lib2/include -I../lib3/include )
> > > # set a variable using that list...
> > > set( AMALG_COMMAND echo ${SIMPLE_LIST} )
> > > # this outputs
> > > COMMAND:echo;-I../lib1/include;-I../lib2/include;-I../lib3/include
> > > message( "COMMAND:${AMALG_COMMAND}")
> > >
> > > # replace ../ with nothing
> > > STRING( REPLACE "../" "" SIMPLE_LIST ${SIMPLE_LIST} )
> > > # re-set a variable with the eventual command to run
> > > set( AMALG_COMMAND echo ${SIMPLE_LIST} )
> > > # this outputs COMMAND:echo;-Ilib1/include -Ilib2/include -Ilib3/include
> > > message( "COMMAND:${AMALG_COMMAND}")
> > >
> > > When that final command actually gets run in a
> > > add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/out.c COMMAND
> > > ${AMALG_COMMAND} )
> > >
> > > Then the command is 'echo "-Ilib1/include -Ilib2/include -Ilib3/include"'
> > > which is incorrect.
> > >
> > >
> > > I tried first LIST(JOIN) but that defiantly makes a string and doesn't
> > > help.
> > > string(REPLACE " " ";" SIMPLE_LIST ${SIMPLE_LIST}) to try and reverse it
> > > back to a list doesn't seem to help...
> --
>
> 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] How to use Ninja on Windows with MSVC?
The easiest way is to launch a CMD with the correct development environment (see for example https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-prompt-for-vs). Le 22 mai 2019 à 15:58 +0200, Robert Dailey , a écrit : > From the command line, I want to generate Ninja build scripts that > utilize a specific version of MSVC compiler. Basically I'd like the > combination of `-G"Visual Studio 15 2017"` with regards to its ability > to find the C and C++ compiler on the system via registry/environment > variables, and `-G"Ninja"` with regards to it being the build driver > for that compiler. > > Is this even possible? > -- > > 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] How to pass linker options with whitespace?
You have to use SHELL token (see documentation of add_link_options)
add_link_options ("SHELL:-s USE_WEBGL2=1" "SHELL:-s FULL_ES2=1")
Le 12 mai 2019 à 21:14 +0200, Fredrik Orderud , a écrit :
> I'm struggling to figure out how to pass "-s USE_WEBGL2=1 -s
> FULL_ES2=1" (without the quotes) as linker options to _all_ CMake
> targets when using Emscripten targeting WebAssembly.
>
> I've already tried add_link_options(-s USE_WEBGL2=1 -s FULL_ES2=1),
> but that caused the second "-s" to disappear before reaching the
> linker. Also, calling add_link_options("-s USE_WEBGL2=1 -s
> FULL_ES2=1") causes quotes to be added to the linker call.
>
> I'm currently using set_target_properties(target PROPERTIES LINK_FLAGS
> "-s USE_WEBGL2=1 -s FULL_ES2=1") as temporary solution. This works
> fine, but am not satisfied with having to apply this manually to all
> targets.
>
> Any suggestions?
> --
>
> 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] PIE-pie_off and CMP0083-cmp0083_new fail for openSuse Leap 15.0
clearly, from what shown on http://paste.opensuse.org/14067189, c++ compiler from OpenSuse Leap is buggy. Expected output from readelf for executable tests_1 is « Elf file type is EXEC (Executable file) » which is not the case. Option -no-pie is not taken into account. This explains the failures for some PIE tests. Le 20 mars 2019 à 11:44 +0100, Christoph Grüninger , a écrit : > Hi Alan, > thanks for you answer. Do you know how the open build service works? It > sets up a fresh installation for each (openSuse) platform. Then CMake's > sources are deflated, configure is called and the package is build, > installed, tested and then packaged. So no other CMake version is > involved beside CMake 3.14. So both good and bad platforms are from the > same CMake source. They only differ in the versions of GCC, make, and so on. > > In the meantime I got some input from the openSuse community, indicating > that Leap 15.0's GCC discrespects the pie/no-pie switch, cf. > http://paste.opensuse.org/14067189 > If an openSuse bug is confirmen, I let you know. > > Bye > Christoph > > > Am 20.03.19 um 02:21 schrieb Alan W. Irwin: > > > > Hi Christoph: > > > > Just in case the trouble is simply due to a real CMake bug for some > > old version of CMake, what exact versions of CMake are you testing on > > each of your various "good" platforms compared to your "bad" platform, > > openSuse Leap 15.0? > > > > Alan > > __ > > Alan W. Irwin > > -- > Unfortunately, plots are notoriously hard to get right. Partly, the > default settings of programs like gnuplot or Excel are to blame for > this since these programs make it very convenient to create bad plots. > -- Till Tantau, "The TikZ and PGF Packages" > -- > > 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] Remove a custom command added with add_custom_command( POST_BUILD ...)
In the meantime if this POST_BUILD command calls a specific tool you can create a no-op shell script with the same name and put its location in the PATH variable. Le 6 mars 2019 à 07:41 +0100, Olivier Gomez , a écrit : > Thank you for your suggestions. > I think the best option is a patch but it will take some time ... I guess I > will have to find a workaround in the meantime ! > > Anyway, thanks again ! > Olivier > > > Le mar. 5 mars 2019 à 18:58, Kyle Edwards a > > écrit : > > > On Tue, 2019-03-05 at 10:01 -0700, Olivier Gomez wrote: > > > > Hello, > > > > > > > > I have been searching for a way to remove a custom command > > > > (POST_BUILD > > > > event) from a target in CMake but, so far, I've found nothing. > > > > > > > > I tried to add another custom command to override the first one but > > > > it seems > > > > to append a second command. > > > > I tough that could work because of the first signature of > > > > add_custom_command() that can take an optional argument named APPEND. > > > > https://cmake.org/cmake/help/v3.4/command/add_custom_command.html#gen > > > > erating-files > > > > Then, I looked for a target property that contains the POST_BUILD > > > > custom > > > > command (to erase it) but, again, I found nothing related (I listed > > > > every > > > > property using the "cmake --help-property-list" command). > > > > > > > > > > > > The context is that I configure a project using a "CMake SDK" from a > > > > third > > > > party library (custom functions that create and configure a shared > > > > library > > > > target basically). > > > > Until recently, I used to create those target by myself using > > > > standard CMake > > > > command. > > > > But now I switched to the "SDK" because it does a lot of specific > > > > thing > > > > depending on the platform (and between the current version of the SDK > > > > and > > > > all the legacy version) and I don't want to rewrite everything. > > > > > > > > Specifically, this SDK add a custom command as a POST_BUILD event to > > > > run a > > > > tool that perform a signature on the produced library. As it is a > > > > proprietary tool that requires a valid licence to work, I want to > > > > remove > > > > that command in order to have a successful build even if i don't > > > > currently > > > > have a licence on my machine. > > > > > > > > So ... is there some way to remove a custom command in CMake ? (or > > > > ignore > > > > failed command maybe) > > > > > > CMake doesn't have a way to remove a custom command from a target. Your > > > best bet would be to either: > > > > > > 1) Fork the SDK for your project to remove the proprietary tool, or > > > 2) Submit a patch upstream to add an option to disable the proprietary > > > tool. > > > > > > Kyle > -- > > 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-developers] Mandatory export of a static library dependency
As I said, You don’t have all symbols in fooshared when PUBLIC is used but, because barstatic is PUBLIC, it is included in link commands where fooshared is specified. For example, specifying command 'target_link_libraries (any PRIVATE fooshared)’ is equivalent to 'target_link_libraries (any PRIVATE fooshared barstatic)’ because barstatic is specified as PUBLIC dependency of fooshared. Le 28 févr. 2019 à 11:14 +0100, Lassi Niemistö , a écrit : > Hello, > > I understand it is a bit awkward scenario to need to have all symbols from > barstatic available in fooshared and yes I can work around it by the OBJECT > library method. > > However, I see it contradictory to > Get all symbols from barstatic included into fooshared when linking it in > PUBLIC mode > Still need to export also barstatic even when this is not necessary due to 1. > > Clarification: the executable is spit out from the same build/cmake than > fooshared. It uses only barstatic and not fooshared at all. The executable is > not the problem, problem is the exporting of fooshared to external builds. > > This goes towards generic discussion on what is the preferred way of creating > both .so and .a versions of a library, check e.g. > https://stackoverflow.com/questions/2152077/is-it-possible-to-get-cmake-to-build-both-a-static-and-shared-version-of-the-sam. > Although the OBJECT library method works, it is clumsy due to needing to > define target_include_directories, compiler flags etc multiple times and > having yet another named target to maintain. It is more beautiful to just > create the static lib as your base and then link the shared version to it, > although it works only when the shared lib has at least one extra source file > compared to the static version. Or, worked until the export stage. > > -Lassi > > From: Marc CHEVRIER > Sent: torstai 28. helmikuuta 2019 11.37 > To: cmake-developers@cmake.org; Lassi Niemistö > Subject: Re: [cmake-developers] Mandatory export of a static library > dependency > > Hi, > > It is perfectly normal that CMake requires static library to be exported when > command ’target_link_libraries(fooshared barstatic)’ is specified because > this is equivalent to command 'target_link_libraries(fooshared PUBLIC > barstatic)’. > > As you have already discovered, using command > 'target_link_libraries(fooshared PRIVATE barstatic)’ avoids exporting of > barstatic library. > Now, I think you did a wrong diagnostic regarding your link problems with > this signature. Symbols visibility is not changed by specifying ‘PRIVATE’ but > link commands are changed. With ‘PRIVATE’, the link command for your > executable do not contains anymore a reference to barstatic library. And the > ‘fooshared’ library will contains only objects from ‘barstatic’ needed to > solved unreferenced symbols (so may be not all objects from ‘barstatic’). > > So to solve your problem you have two possibilities: > > > 1. Specify ‘barstatic’ library as dependency of your executable, i.e. > 'target_link_libraries(exec PRIVATE fooshared barstatic)’. > 2. Ensure that all objects of `barstatic` are included in your ‘fooshared’ > library. For that purpose, you can create `barstatic` as OBJECT library and > include all objects in your ‘fooshared’ library using pattern > ‘add_library(fooshared SHARED .. $ …)’. But the > most simple is, may be, to put directly all your sources in ‘fooshared’ > library. > > > Le 28 févr. 2019 à 08:25 +0100, Lassi Niemistö , a > écrit : > > > Hello, > > > > The cmake "users" list did not wake any replies, so posting here as a > > possible bug: > > > > I use CMake 3.13RC1. My project produces, installs and exports a shared > > library target "fooshared". Some logical parts of "fooshared" are reused in > > an executable, so I have placed those sources into an internal static > > library target "barstatic". I have used target_link_libraries(fooshared > > barstatic) to make this work. > > > > Problem: when I try to: > > install(TARGETS fooshared DESTINATION EXPORT myexport) > > install(EXPORT myexport DESTINATION ) > > ..I get a whine about dependency to "barstatic" which is not in the export > > group "myexport". > > > > I wouldn't like to export "barstatic" at all, it should remain under the > > hood. I tried to use target_link_libraries(fooshared PRIVATE barstatic) > > which cut the export chaining, but then symbols from "barstatic" were not > > available for users of "fooshared" anymore. So I worked around this by > > converting "barstatic" into an object libra
Re: [cmake-developers] Mandatory export of a static library dependency
Hi, It is perfectly normal that CMake requires static library to be exported when command ’target_link_libraries(fooshared barstatic)’ is specified because this is equivalent to command 'target_link_libraries(fooshared PUBLIC barstatic)’. As you have already discovered, using command 'target_link_libraries(fooshared PRIVATE barstatic)’ avoids exporting of barstatic library. Now, I think you did a wrong diagnostic regarding your link problems with this signature. Symbols visibility is not changed by specifying ‘PRIVATE’ but link commands are changed. With ‘PRIVATE’, the link command for your executable do not contains anymore a reference to barstatic library. And the ‘fooshared’ library will contains only objects from ‘barstatic’ needed to solved unreferenced symbols (so may be not all objects from ‘barstatic’). So to solve your problem you have two possibilities: 1. Specify ‘barstatic’ library as dependency of your executable, i.e. 'target_link_libraries(exec PRIVATE fooshared barstatic)’. 2. Ensure that all objects of `barstatic` are included in your ‘fooshared’ library. For that purpose, you can create `barstatic` as OBJECT library and include all objects in your ‘fooshared’ library using pattern ‘add_library(fooshared SHARED .. $ …)’. But the most simple is, may be, to put directly all your sources in ‘fooshared’ library. Le 28 févr. 2019 à 08:25 +0100, Lassi Niemistö , a écrit : > Hello, > > The cmake "users" list did not wake any replies, so posting here as a > possible bug: > > I use CMake 3.13RC1. My project produces, installs and exports a shared > library target "fooshared". Some logical parts of "fooshared" are reused in > an executable, so I have placed those sources into an internal static library > target "barstatic". I have used target_link_libraries(fooshared barstatic) to > make this work. > > Problem: when I try to: > install(TARGETS fooshared DESTINATION EXPORT myexport) > install(EXPORT myexport DESTINATION ) > ..I get a whine about dependency to "barstatic" which is not in the export > group "myexport". > > I wouldn't like to export "barstatic" at all, it should remain under the > hood. I tried to use target_link_libraries(fooshared PRIVATE barstatic) which > cut the export chaining, but then symbols from "barstatic" were not available > for users of "fooshared" anymore. So I worked around this by converting > "barstatic" into an object library, but it feels ugly. > > Why would CMake require exporting statically linked dependency targets among > the targets that use them? Feels like a bug to me. > > Regards, > -Lassi Niemistö > -- > > 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-developers -- 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-developers
Re: [CMake] Static Libraries and target_link_libraries
It is quite inexact because a target can store many information like include directories or preprocessor definitions for example (through properties like INCLUDE_DIRECTORIES or COMPILE_DEFINITIONS). So it make sense to enable to specify link libraries to a static library using PRIVATE or PUBLIC to ensure various settings are propagated to the static library compilation step. Le 25 janv. 2019 à 15:46 +0100, Andrew Bell , a écrit : > > When creating a static library, you can still use the function > "target_link_libraries" even though the static library is never linked, as > such. What you're doing is creating a dependency record for cmake so that > target_link_libraries of a static library are included in a link of some > other target which depends on the static library. What seems confusing is > that target_link_libraries accepts the keywords PUBLIC and PRIVATE as well as > INTERFACE when used with a static library, since only INTERFACE really makes > sense in this context. > > Would it be beneficial to issue a warning when someone uses PUBLIC or PRIVATE > with target_link_libraries on a static library to make it clear that they may > not be understanding what's going on? > > -- > Andrew Bell > andrew.bell...@gmail.com > -- > > 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-developers] real functions (was: $LIST_LENGTH{} syntax)
I am not convince that the proposed syntax is a good idea because it introduce
a new syntax just to solve one action on a list.
What about introducing a syntax similar to the version comparison:
• LENGTH_EQUAL
• LENGTH_GREATER
• LENGTH_LOWER
• etc…
To use it:
if (my_list LENGTH_EQUAL 1)
# do my stuff
endif()
Or introduce a more general syntax for list management as part of an expression:
$LIST{,[,,…]}
Where , and use same semantic as list command.
To use it:
of ($LIST{LENGTH,my_list} EQUAL 1)
# do my stuff
endif()
The advantage of this syntax is extensibility: More can be added and more
commands can be introduced (for example $STRING{…}).
Le 22 janv. 2019 à 16:37 +0100, Brad King via cmake-developers
, a écrit :
> On 1/22/19 10:28 AM, tors...@robitzki.de wrote:
> > With `$CACHE{VAR}` and `$ENV{VAR}` we already have the syntax for calling a
> > „function“.
>
> No, there is no obvious way to pass arguments, handle nested quoting, etc.
> The language was not designed for that. That is a big can of worms I'd rather
> not open just to solve the list length problem which is already only 2 lines.
>
> > Once we have this, it would be possible to define $LIST_LENGTH in the CMake
> > language
>
> Not as efficiently as a dedicated syntax for the only language construct
> we have that resembles a data structure.
>
> -Brad
> --
>
> 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-developers
--
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-developers
Re: [CMake] set_property imported_location_release
Yes, the most efficient way is using conditional setting. For example:
if (CMAKE_SIZEOF_VOID_P EQUAL 4)
set(import_path /to/lib32)
else()
set(import_path /to/lib64)
endif()
set_property(TARGET foo PROPERTY IMPORT_LOCATION "${import_path}/lib.so")
Le 21 déc. 2018 à 15:14 +0100, Lars , a écrit :
> Marc,
>
> Appreciate the quick and helpful response.
>
> In a config file that supports multiple platforms, do I need to create
> import_location_path variable and populate it depending on platform and 32/64
> etc? Any other options?
>
> Thanks.
>
> Kind regards, Lars
>
> Fra: Marc CHEVRIER
> Sendt: fredag 21. desember 2018 13.41
> Til: cmake@cmake.org; Lars
> Emne: Re: [CMake] set_property imported_location_release
>
> Properties IMPORTED_LOCATION* do not support generator expressions.
>
> Generally speaking, if a property supports generator expression, it is
> explicitly specified in documentation.
> Le 21 déc. 2018 à 13:07 +0100, Lars , a écrit :
> > Hello,
> >
> > Trying to import an external library but having some issue with setting
> > imported_location_release property.
> >
> > Basically I have config file which does this;
> > add_library(foo STATIC IMPORTED)
> > set_property(target foo APPEND PROPERTY
> > interface_include_directories
> > "$"
> > "$")
> >
> > set_property(TARGET foo APPEND PROPERTY
> > IMPORTED_LOCATION_RELEASE
> > $<$:${foo_root}/lib/release/foo.a>)
> >
> > The imported target is used in a target_link_libraries method;
> > target_link_libraries(an_application foo)
> >
> > Running CMake 3.6.1 does not produce any warnings. Running make I get a
> > "target pattern contains no '%'" error message with a reference to a
> > Build.make file.
> >
> > The Build.make contains the string "
> > $<$:/tmp/prototype/foo/lib/release/foo.a". We did not
> > expect to see the generator expression in the Build.make file.
> >
> > Does set_property support generator expression in this context? What are we
> > doing wrong?
> >
> > Appreciate any help :-)
> >
> > king regards, Lars
> >
> > --
> >
> > 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] set_property imported_location_release
Properties IMPORTED_LOCATION* do not support generator expressions.
Generally speaking, if a property supports generator expression, it is
explicitly specified in documentation.
Le 21 déc. 2018 à 13:07 +0100, Lars , a écrit :
> Hello,
>
> Trying to import an external library but having some issue with setting
> imported_location_release property.
>
> Basically I have config file which does this;
> add_library(foo STATIC IMPORTED)
> set_property(target foo APPEND PROPERTY
> interface_include_directories
> "$"
> "$")
>
> set_property(TARGET foo APPEND PROPERTY
> IMPORTED_LOCATION_RELEASE
> $<$:${foo_root}/lib/release/foo.a>)
>
> The imported target is used in a target_link_libraries method;
> target_link_libraries(an_application foo)
>
> Running CMake 3.6.1 does not produce any warnings. Running make I get a
> "target pattern contains no '%'" error message with a reference to a
> Build.make file.
>
> The Build.make contains the string "
> $<$:/tmp/prototype/foo/lib/release/foo.a". We did not
> expect to see the generator expression in the Build.make file.
>
> Does set_property support generator expression in this context? What are we
> doing wrong?
>
> Appreciate any help :-)
>
> king regards, Lars
>
> --
>
> 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] target_link_libraries not populating INCLUDE_DIRECTORIES?
Command target_link_libraries do not populate directly the properties of the
target due to many constraints regarding the values given to the command
(generator expressions, other targets, etc…).
The full contents is taken into account at generation time not at the
configuration time. This is why you cannot get full information using command
get_target_property which is evaluated at configuration time.
Le 21 déc. 2018 à 09:30 +0100, Ciccio Pasticcio ,
a écrit :
> Hi all,
>
> considering the following CMakeLists.txt:
>
> PROJECT(lib_foo)
> ADD_LIBRARY(lib_foo SHARED )
> TARGET_INCLUDE_DIRECTORIES(PRIVATE private/ PUBLIC inc/)
> FIND_PACKAGE(Boost 1.55 REQUIRED COMPONENTS chrono system)
> TARGET_LINK_LIBRARIES(lib_foo PRIVATE Boost::chrono Boost::system)
> GET_TARGET_PROPERTIES(tinc lib_foo INCLUDE_DIRECTORIES)
> MESSAGE(STATUS "Include dirs: ${tinc}")
>
> I would expect a message with my private/ and inc/ paths, plus the one that
> comes with the Boost libraries, instead I only get the directories specified
> in TARGET_INCLUDE_DIRECTORIES. The manpage of TARGET_LINK_LIBRARIES says:
> PRIVATE and PUBLIC items will populate the INCLUDE_DIRECTORIES property of
> .
>
> If I print Boost_INCLUDE_DIR I found the inclusion path.
>
> Am I missing something?
>
> Thanks,
> Gabriele
> --
>
> 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] [MSVC] Setting warning level on target feels like long-time bug
I think the discussion is shifting from the initial problem which was unwanted warning « Command line warning D9025: overriding '/W3' with '/W4' ». Changing defaults is not a good idea from my point of view because relying on defaults can be problematic if Microsoft decide to change the default behaviour. Moreover, removing ‘/W3’ from defaults will remove the warning for this flag but the problem remains for all other flags possibly overloaded. The real question is how to manage cleanly target specific flags overriding global or directory defaults? And the frustrating thing is that cl.exe do not allow to disable D9025 warning! :( Le 9 déc. 2018 à 13:32 +0100, Mateusz Loskot , a écrit : > On Sun, 9 Dec 2018 at 12:14, Craig Scott wrote: > > > > From what I understand from a very limited quick search just now, > > it seems that /W3 is the default warning level for Visual Studio > > Yes, it is the default level indeed. > > > but CMake explicitly adds it as a default compiler flag in > > CMAKE__FLAGS_INIT. > > This makes me wonder if it has always been the default, otherwise it isn't > > clear why it was deemed necessary to add it. > > Yes, I'd suspect it was added as 'just in case' too eagerly. > > > More to the point, unless there's a reason not to, perhaps we could > > consider removing it from the default flags CMake sets. > > I think this would largely address the situation you're describing and > > shouldn't actually change the behavior of existing projects. > > Yes, it should be removed. > Unless I'm missing an important reason behind the explicit -W3. > > No, "This has been the default since CMake began" [1], is not enough > rationale to keep it. > > In the old times of manual editing of CMAKE_CXX_FLAGS, it was not a huge deal > - in fact, fiddling with CMAKE_CXX_FLAGS was quite canonical way of > doing things.. > But with the advent of target_compile_options, the string call > requirement is just unacceptable. > > [1] https://gitlab.kitware.com/cmake/cmake/issues/18317 > > > I've CC'ed the developer's list and suggest that follow-up discussion > > should occur there. > > FYI, I've just subscribed to the developer's list. > > Best regards, > -- > Mateusz Loskot, http://mateusz.loskot.net > -- > > 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] How force cmake debug/release
Have a look at the documentation :
https://cmake.org/cmake/help/v3.13/
Le 6 déc. 2018 à 09:51 +0100, Andy , a écrit :
> In cmake I have:
> if (${CMAKE_BUILD_TYPE} STREQUAL Release)
> message(WARNING "Release")
> endif()
>
> if (${CMAKE_BUILD_TYPE} STREQUAL Debug)
> message(WARNING "Debug")
> endif()
>
> (how write something like elseif?)
>
> If I call "cmake ." it write: "Warning:Debug"
> Debug is default and I must call "cmake . -DCMAKE_BUILD_TYPE=Release"
> for release?
> --
>
> 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] cmake 3.12 - python libs / 32 / 64 bits
FYI, I just deliver a MR (
https://gitlab.kitware.com/cmake/cmake/merge_requests/2624) which fix the
problem of the selection of the library with the wrong architecture.
Le jeu. 15 nov. 2018 à 10:00, Eric Noulard a
écrit :
> Le jeu. 15 nov. 2018 à 09:47, Stéphane Ancelot
> a écrit :
>
>> I agree. That was a debug snippet...but is wrong ... I setted up again
>> the toolchain, but does not help.
>>
>
> If you are using a proper toolchain for 32bit compilation.
> It looks like a bug in the find_package for Python in the cross-compiling
> case.
> Do you have a stripped down example which exhibit the issue?
> Which version of CMake are you using?
>
>
>> So, I know where are include_dirs and libs for 32 bits cross compiling,
>> I have to hardcode it like this ?
>>
>> add_library(python SHARED IMPORTED)
>> set_target_properties( python PROPERTIES IMPORTED_LOCATION /usr/lib32/
>> libpython2.6.so )
>> target_include_directories(python SYSTEM ...
>>
>
> I think you can do that but it replaces the use of find_package(Python2
> COMPONENTS Development)
> may be fixing this would be a better long-term solution ?
>
>
>
>>
>>
>> Le 14/11/2018 à 17:53, Marc CHEVRIER a écrit :
>>
>> The way you proceed is wrong.
>> The system configuration is determined during the 'project' function
>> call. Setting information after this call is useless. So, in your example,
>> on a 64bit system, the compilation configuration will be 64bit (variable
>> CMAKE_SIZEOF_VOID_P has value 8).
>> This explain why 'FIND_LIBRARY_USE_LIB32_PATHS' has no effect. This
>> property is taken in consideration only on 32bit systems.
>>
>> Moreover, I am not sure that modifying variable 'CMAKE_SYSTEM_PROCESSOR'
>> is a valid action.
>>
>> To configure a 32bit compilation environment, two possibilities:
>> * using environment variables: env CFLAGS=-m32 CXXFLAGS=-m32 cmake ...
>> * using a toolchain file: see
>> https://cmake.org/cmake/help/v3.13/manual/cmake-toolchains.7.html
>>
>>
>> Le mer. 14 nov. 2018 à 14:06, Stéphane Ancelot
>> a écrit :
>>
>>> Hi,
>>>
>>> My system is 64 bits but I can cross compile python c modules for 32
>>> bits .
>>>
>>> Unfortunately I don't manage to retrieve python 32 libs , always the 64
>>> bits version is found.
>>>
>>>
>>> here is what I tried :
>>>
>>> cmake_minimum_required(VERSION 3.10)
>>> project(py_autom)
>>>
>>>
>>> set(CMAKE_SYSTEM_PROCESSOR "i686")
>>>
>>> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -m32" CACHE STRING "c++ flags")
>>> set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -m32" CACHE STRING "c flags")
>>>
>>> set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB32_PATHS TRUE)
>>> set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS FALSE)
>>>
>>> include_directories(python2.6)
>>> find_package(Python2 COMPONENTS Development)
>>>
>>>
>>>
>>> message(STATUS "python ${PYTHON_INCLUDE_DIRS} ${Python2_LIBRARIES_DIR}
>>> ${Python2_FOUND}")
>>>
>>> Regards
>>>
>>> Steph
>>> --
>>>
>>> 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
>>
>
>
> --
> 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
Re: [CMake] cmake 3.12 - python libs / 32 / 64 bits
The way you proceed is wrong.
The system configuration is determined during the 'project' function call.
Setting information after this call is useless. So, in your example, on a
64bit system, the compilation configuration will be 64bit (variable
CMAKE_SIZEOF_VOID_P has value 8).
This explain why 'FIND_LIBRARY_USE_LIB32_PATHS' has no effect. This
property is taken in consideration only on 32bit systems.
Moreover, I am not sure that modifying variable 'CMAKE_SYSTEM_PROCESSOR' is
a valid action.
To configure a 32bit compilation environment, two possibilities:
* using environment variables: env CFLAGS=-m32 CXXFLAGS=-m32 cmake ...
* using a toolchain file: see
https://cmake.org/cmake/help/v3.13/manual/cmake-toolchains.7.html
Le mer. 14 nov. 2018 à 14:06, Stéphane Ancelot a
écrit :
> Hi,
>
> My system is 64 bits but I can cross compile python c modules for 32 bits .
>
> Unfortunately I don't manage to retrieve python 32 libs , always the 64
> bits version is found.
>
>
> here is what I tried :
>
> cmake_minimum_required(VERSION 3.10)
> project(py_autom)
>
>
> set(CMAKE_SYSTEM_PROCESSOR "i686")
>
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -m32" CACHE STRING "c++ flags")
> set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -m32" CACHE STRING "c flags")
>
> set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB32_PATHS TRUE)
> set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS FALSE)
>
> include_directories(python2.6)
> find_package(Python2 COMPONENTS Development)
>
>
>
> message(STATUS "python ${PYTHON_INCLUDE_DIRS} ${Python2_LIBRARIES_DIR}
> ${Python2_FOUND}")
>
> Regards
>
> Steph
> --
>
> 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] java_home usage
Variable must be specified using upper case. So 'set (JAVA_HOME ...)' should be OK (or environment variable JAVA_HOME is OK as well). javac is expected to be in $JAVA_HOME/bin. Le lun. 22 oct. 2018 à 10:16, Stéphane Ancelot a écrit : > Hi, > > If I set java_home in cmake 3.12 , Java_JAVAC_EXECUTABLE is not using my > java_home env but /usr/bin/javac > > > what is wrong ? > > Regards, > > S.Ancelot > > -- > > 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] Howot add jar files in final jar file
Option INCLUDE_JARS is used to specify classpath javac option for java sources compilation. Currently, there is no possibility to add jars using add_jar command. You have to use a custom command for that purpose. Le lun. 22 oct. 2018 à 11:05, Stéphane Ancelot a écrit : > Hi, > > I have to package some jar files in the final jar. > > I can compile it with add_jar specifying INCLUDE_JARS but unfortunately, > they are not added to the final target jarfile > > Regards > > S.Ancelot > -- > > 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] target_compile_flags and PUBLIC
Have a look at '$' and '$'
generator expressions.
Le mar. 9 oct. 2018 à 09:48, Biddiscombe, John A. a
écrit :
> I have a problem with exported flags from a project.
>
> If I use `target_compile_options(hpx PUBLIC ${flags})` hpx is compiled
> with the flags, and all 500+ tests within the project that depend on hpx
> inherit the flags too, so they get built correctly. However, the
> `HPXTargets.cmake` file that is generated with the exported targets, also
> inherits these flags and lists them in INTERFACE_COMPILE_OPTIONS, so now
> users are complaining that flags used to compile hpx are being passed onto
> their project and some of the stuff we use like `-Werror=sign-compare`
> causes a build fail in their project. If I use `target_compile_options(hpx
> PRIVATE ${flags})` then the flags are not passed on to the user projects,
> but also not passed on to the tests either. Is there an easy way of saying,
> pass these flags to all my projects within this 'PROJECT' but don't export
> them via the PUBLIC/INTERFACE to 3rd party users?
>
> Thanks
>
> JB
> --
>
> 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] Trouble with conditional generator expression inside target_link_libraries
For now, clearly it is not supported. Introducing a generator expression
breaks the parsing of arguments of command target_link_libraries.
@Björn I suggest to you to log an issue (see
https://gitlab.kitware.com/cmake/cmake/issues) about that (don't forget to
put a short example demonstrating the problem) to enable discussion about
this and to identify a solution.
Le jeu. 4 oct. 2018 à 19:09, Björn Blissing a
écrit :
> Hi Marc,
>
>
>
> If that is the case that mixing of “optimized” and “debug” keywords with
> generator expressions is impossible, I think this should be mentioned in
> the official documentation. It took us the better part of an afternoon to
> track down why we suddenly had a dependency to a library called “
> optimized.lib”.
>
>
>
> Other people seem to struggle with similar issues as well:
> https://www.google.com/search?q=optimized.lib+cmake
>
>
>
> Regards,
>
> Björn
>
>
>
>
>
> *From:* Marc CHEVRIER
> *Sent:* Thursday, October 4, 2018 6:59 PM
> *To:* Björn Blissing
> *Cc:* Andrew Fuller ; Eric Noulard <
> eric.noul...@gmail.com>; CMake Mailinglist
>
>
> *Subject:* Re: [CMake] Trouble with conditional generator expression
> inside target_link_libraries
>
>
>
> I am afraid that you cannot mix "optimized" or "debug" keywords with
> "generator expressions" because keywords handling is done during evaluation
> of command "target_link_libraries" and "generator expressions" are
> evaluated during generation.
>
>
>
> And target_link_libraries expect following pattern: []
> [ ...], so specifying a generator expression wrapping this breaks
> the parsing of the arguments: keyword is no longer at the beginning of the
> sequence so it is no longer recognized as is...
>
>
>
> So, The most efficient way to work-around this problem is to transform
> your list of libraries in valid generator expressions:
>
>- INITIAL: optimized foo debug food_d
>- RESULT: $<$:foo> $<$:foo_d>
>
> For that purpose, an helper function can do the trick...
>
>
>
> Le jeu. 4 oct. 2018 à 18:34, Björn Blissing a
> écrit :
>
> Hi Andrew,
>
>
>
> That works, but as previously said. The third party find module I am using
> do not differentiate between debug and release libraries. To make matters
> even worse the keywords “optimized” and “debug” is already in the variable
> list, trying to split them will be painful.
>
>
>
> The workaround I am using right now is to have an IF-statement for the
> list option:
>
> if(${USE_FOOLIB})
>
> target_link_libraries(my_exe
>
> PUBLIC
>
> ${FOO_LIBRARIES}
>
> )
>
> endif()
>
>
>
>
>
> target_link_libraries(my_exe
>
> PUBLIC
>
> $<$:bar>
>
> )
>
>
>
> But that breaks the pattern with using generator expressions, as I do for
> the rest of my options.
>
>
>
> I don’t know if this should be considered a bug, but it seems really
> strange that generator expressions should break down for only this special
> case, i.e. the combination using lists with the conditional operator BOOL
> and using it inside target_link_libraries.
>
>
>
> I don’t know if other CMake functions will react similarly bad to the
> list/bool operator combo.
>
>
>
> Regards,
>
> Björn
>
>
>
>
>
> *From:* Andrew Fuller
> *Sent:* Thursday, October 4, 2018 6:16 PM
>
>
> *To:* Björn Blissing ; Eric Noulard <
> eric.noul...@gmail.com>
> *Cc:* CMake Mailinglist
> *Subject:* Re: [CMake] Trouble with conditional generator expression
> inside target_link_libraries
>
>
>
> What about this:
>
>
>
>
> list(APPEND FOO_LIBRARIES_OPT foo)
> list(APPEND FOO_LIBRARIES_DBG foo_d)
>
> target_link_libraries(my_exe
>PUBLIC
> debug "$<$:${FOO_LIBRARIES_DBG}>"
> optimized "$<$:${FOO_LIBRARIES_OPT}>"
> "$<$:bar>"
> )
>
> A little more verbose.
> --
>
> *From:* Björn Blissing
> *Sent:* October 4, 2018 9:00:28 AM
> *To:* Andrew Fuller; Eric Noulard
> *Cc:* CMake Mailinglist
> *Subject:* RE: [CMake] Trouble with conditional generator expression
> inside target_link_libraries
>
>
>
> Hi Andrew,
>
>
>
> When I put the genex inside double quotes I get:
>
> optimized.lib;foo.lib;debug.lib;foo_d.lib;bar.lib; --- for both debug and
> release builds
>
> Regards,
>
> Björn
>
>
>
>
>
> *From:* Andrew Fuller
> *Sent:* Thursday, October 4, 2018 5:54 PM
> *To:* Björn Blissin
Re: [CMake] Trouble with conditional generator expression inside target_link_libraries
I am afraid that you cannot mix "optimized" or "debug" keywords with
"generator expressions" because keywords handling is done during evaluation
of command "target_link_libraries" and "generator expressions" are
evaluated during generation.
And target_link_libraries expect following pattern: []
[ ...], so specifying a generator expression wrapping this breaks
the parsing of the arguments: keyword is no longer at the beginning of the
sequence so it is no longer recognized as is...
So, The most efficient way to work-around this problem is to transform your
list of libraries in valid generator expressions:
- INITIAL: optimized foo debug food_d
- RESULT: $<$:foo> $<$:foo_d>
For that purpose, an helper function can do the trick...
Le jeu. 4 oct. 2018 à 18:34, Björn Blissing a
écrit :
> Hi Andrew,
>
>
>
> That works, but as previously said. The third party find module I am using
> do not differentiate between debug and release libraries. To make matters
> even worse the keywords “optimized” and “debug” is already in the variable
> list, trying to split them will be painful.
>
>
>
> The workaround I am using right now is to have an IF-statement for the
> list option:
>
> if(${USE_FOOLIB})
>
> target_link_libraries(my_exe
>
> PUBLIC
>
> ${FOO_LIBRARIES}
>
> )
>
> endif()
>
>
>
>
>
> target_link_libraries(my_exe
>
> PUBLIC
>
> $<$:bar>
>
> )
>
>
>
> But that breaks the pattern with using generator expressions, as I do for
> the rest of my options.
>
>
>
> I don’t know if this should be considered a bug, but it seems really
> strange that generator expressions should break down for only this special
> case, i.e. the combination using lists with the conditional operator BOOL
> and using it inside target_link_libraries.
>
>
>
> I don’t know if other CMake functions will react similarly bad to the
> list/bool operator combo.
>
>
>
> Regards,
>
> Björn
>
>
>
>
>
> *From:* Andrew Fuller
> *Sent:* Thursday, October 4, 2018 6:16 PM
>
>
> *To:* Björn Blissing ; Eric Noulard <
> eric.noul...@gmail.com>
> *Cc:* CMake Mailinglist
> *Subject:* Re: [CMake] Trouble with conditional generator expression
> inside target_link_libraries
>
>
>
> What about this:
>
>
>
>
> list(APPEND FOO_LIBRARIES_OPT foo)
> list(APPEND FOO_LIBRARIES_DBG foo_d)
>
> target_link_libraries(my_exe
>PUBLIC
> debug "$<$:${FOO_LIBRARIES_DBG}>"
> optimized "$<$:${FOO_LIBRARIES_OPT}>"
> "$<$:bar>"
> )
>
> A little more verbose.
> --
>
> *From:* Björn Blissing
> *Sent:* October 4, 2018 9:00:28 AM
> *To:* Andrew Fuller; Eric Noulard
> *Cc:* CMake Mailinglist
> *Subject:* RE: [CMake] Trouble with conditional generator expression
> inside target_link_libraries
>
>
>
> Hi Andrew,
>
>
>
> When I put the genex inside double quotes I get:
>
> optimized.lib;foo.lib;debug.lib;foo_d.lib;bar.lib; --- for both debug and
> release builds
>
> Regards,
>
> Björn
>
>
>
>
>
> *From:* Andrew Fuller
> *Sent:* Thursday, October 4, 2018 5:54 PM
> *To:* Björn Blissing ; Eric Noulard <
> eric.noul...@gmail.com>
> *Cc:* CMake Mailinglist
> *Subject:* Re: [CMake] Trouble with conditional generator expression
> inside target_link_libraries
>
>
>
> What happens if you put the genex inside double quotes?
>
>
>
> target_link_libraries(my_exe
>
> PUBLIC
>
> "$<$:${FOO_LIBRARIES}>"
>
> "$<$:bar>"
>
> )
>
>
> --
>
> *From:* CMake on behalf of Björn Blissing <
> bjorn.bliss...@vti.se>
> *Sent:* October 4, 2018 8:49:19 AM
> *To:* Eric Noulard
> *Cc:* CMake Mailinglist
> *Subject:* Re: [CMake] Trouble with conditional generator expression
> inside target_link_libraries
>
>
>
> Hi Eric,
>
>
>
> I tried to do a self contained minimal example:
>
>
>
> cmake_minimum_required(VERSION 3.12)
>
> project(expension_error LANGUAGES CXX)
>
>
>
> add_executable(my_exe main.cpp)
>
>
>
> option(USE_FOOLIB "Use foo.lib" ON)
>
> option(USE_BARLIB "Use bar.lib" ON)
>
>
>
> list(APPEND FOO_LIBRARIES optimized foo)
>
> list(APPEND FOO_LIBRARIES debug foo_d)
>
>
>
>
>
> target_link_libraries(my_exe
>
> PUBLIC
>
> $<$:${FOO_LIBRARIES}>
>
> $<$:bar>
>
> )
>
>
>
> But when I run this script using CMake 3.12.2, it expands to something
> even worse:
>
>
>
> $<1:optimized;foo.lib;foo_d>.lib;bar.lib --- for debug builds
>
> $<1:optimized;foo.lib;>.lib;bar.lib-- for release builds
>
>
>
> So something goes really wrong when I try to use a list inside a
> conditional generator expression inside target_link_libraries().
>
>
>
> Regards,
>
> Björn
>
>
>
>
>
>
>
> *From:* Eric Noulard
> *Sent:* Thursday, October 4, 2018 5:10 PM
> *To:* Björn Blissing
> *Cc:* CMake Mailinglist
> *Subject:* Re: [CMake] Trouble with conditional generator expression
> inside target_link_libraries
>
>
>
>
>
> Le jeu. 4 oct. 2018 à 16:53, Björn Blissing a
> écrit :
>
> Hello Eric,
>
>
>
> The minimal example was just to display the expansion error. In real life
>
Re: [CMake] How to append a string on list inside a function
Using a cache variable seems not required. A function creates a new scope
and inherit a copy of all variables defined in the upper scope.
So, by adding a set command using PARENT_SCOPE in your function you can
update the variable in the parent scope:
function(addTest targetName)
# create the executable with all the souces
add_executable(${targetName} ${ARGN})
list(APPEND allTestsList ${targetName})
*set (allTestsList ${allTestsList} PARENT_SCOPE) *
message("inside addTestFunction. allTestsList: "
${allTestsList})
endfunction()
Le jeu. 27 sept. 2018 à 12:43, Romain LEGUAY a
écrit :
> Hello everyone,
>
> I try to append a string (target name) on a list inside a function called
> in other CMakeLists.
>
> I have the following project’s tree:
>
> ├── CMakeLists.txt
> ├── test
> ├── CMakeLists.txt
> └── app
> ├── CMakeLists.txt
> ├── appA
> │ ├── CMakeLists.txt
> │ └── main.cpp
> └── appB
> ├── CMakeLists.txt
> └── main.cpp
>
> Inside the test/CMakeLists.txt, I defined an internal variable like this:
> set(allTestsList "" CACHE INTERNAL "All executable tests.'')
> And my function:
> function(addTest targetName)
> # create the executable with all the souces
> add_executable(${targetName} ${ARGN})
> list(APPEND allTestsList ${targetName})
> message("inside addTestFunction. allTestsList: "
> ${allTestsList})
> endfunction()
>
> I call this function inside the test/app/appA and test/app/appB
> CMakeLists.txt like this:
> addTest(appA main.cpp)
> addTest(appB main.cpp)
>
> I expected to have as final result:
> inside addTestFunction. allTestsList: appA;appB
>
> But I only have:
> inside addTestFunction. allTestsList: appB
>
> I suspect that a new variable is created at each call of the function.
>
> Is it possible to use a global variable? (I tried to use PARENT_SCOPE with
> no success).
>
> Thank you,
>
> Romain
>
>
> --
>
> 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] LOCATION target property, generator expressions
LINK_FLAGS does not support expressions. However, property LINK_OPTIONS (and INTERFACE counterpart) support generator expressions. These properties are new for version 3.13 which will be available soon (probably next month). Le mer. 26 sept. 2018 à 05:21, Hendrik Greving < hendrik.greving@gmail.com> a écrit : > Hello, > > our cmake setup is using LOCATION property for two targets to compute a > relative path from these two, and adds this to LINK_FLAGS (for rpath, but > irrelevant in this context). In order to update our cmake w.r.t. CMP0026, I > don't know how to get LINK_FLAGS consume a generator expression. In other > cases file(GENERATE.. writing a set(var TARGET_FILE..) into a file, and > reading the file to obtain 'var' worked. Thanks in advance! > -- > > 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] Labels on tests defined on another subdirectory
Using command 'get_directory_property(var DIRECTORY ${my_dir} TESTS)' is OK
to retrieve tests defined in some sub directory.
But, it is useless because command 'set_test_properties()' must be called
from the directory where the tests are defined.
but you can do:
set (MY_LABELS LABEL1)
add_subdirectory("my_dir")
and in "my_dir":
add_test(TEST1 ...)
set_property(TEST TEST1 APPEND PROPERTY LABELS ${MY_LABELS})
Le mer. 19 sept. 2018 à 19:45, Raffi Enficiaud <
raffi.enfici...@mines-paris.org> a écrit :
> On 19.09.18 08:25, Marc CHEVRIER wrote:
> > directory property 'TESTS' returns the tests created in the
> > *current* directory only.
> > The main reason to this limitation is the fact that tests created in
> > different directories can have same name.
>
> The get_directory_property call is made from the directory that is
> calling add_subdirectory, so I am guessing that the property is
> available everywhere?
>
> I would like to modify the labels of some specific tests. Is there a
> non-intrusive way to do that? Can I set a variable to inherit this LABEL
> before the call to add_subdirectory?
>
> Thanks!
> Raffi
>
> >
> >
> > Le mer. 19 sept. 2018 à 02:22, Raffi Enficiaud
> > > <mailto:raffi.enfici...@mines-paris.org>> a écrit :
> >
> > Hi,
> >
> > I just wanted to know if it is possible from a directory to add
> labels
> > on tests defined on a sub-directory (via add_subdirectory).
> >
> > When I do a set_tests_properties on the tests that were retrieved
> with
> > get_directory_property, cmake says that the test is not found.
> >
> > Maybe I am missing some syntax there? The following does not work:
> >
> > get_directory_property(CURRENT_DIRECTORY_TESTS
> >DIRECTORY ${my_dir}
> >TESTS)
> >
> > if(NOT "${CURRENT_DIRECTORY_TESTS}" STREQUAL "")
> > set_tests_properties(${CURRENT_DIRECTORY_TESTS} PROPERTIES
> LABELS
> > "some-labels")
> > endif()
> >
> >
> > Thanks!
> > Raffi
> >
> > --
> >
> > 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
>
--
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] Labels on tests defined on another subdirectory
directory property 'TESTS' returns the tests created in the *current* directory
only.
The main reason to this limitation is the fact that tests created in
different directories can have same name.
Le mer. 19 sept. 2018 à 02:22, Raffi Enficiaud <
raffi.enfici...@mines-paris.org> a écrit :
> Hi,
>
> I just wanted to know if it is possible from a directory to add labels
> on tests defined on a sub-directory (via add_subdirectory).
>
> When I do a set_tests_properties on the tests that were retrieved with
> get_directory_property, cmake says that the test is not found.
>
> Maybe I am missing some syntax there? The following does not work:
>
> get_directory_property(CURRENT_DIRECTORY_TESTS
> DIRECTORY ${my_dir}
> TESTS)
>
> if(NOT "${CURRENT_DIRECTORY_TESTS}" STREQUAL "")
> set_tests_properties(${CURRENT_DIRECTORY_TESTS} PROPERTIES LABELS
> "some-labels")
> endif()
>
>
> Thanks!
> Raffi
>
> --
>
> 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] Appending to CMAKE_CXX_FLAGS
If you set directory property at the top level CMakeList.txt, before any
target definition, all targets will inherit this value.
And, because property 'COMPILE_OPTIONS' supports generator expressions (see
https://cmake.org/cmake/help/v3.12/manual/cmake-generator-expressions.7.html),
you can specify:
add_compile_options("$<$:/MP>")
Le mar. 11 sept. 2018 à 19:19, Michael Jackson
a écrit :
> Hmm. The idea for the “/MP” flags for those that don’t use Visual Studio
> is that it will inform the compiler to use all the cores on the system to
> compile. Much like Ninja does automatically and “make -jN” does for
> makefiles.
>
> Essentially I want to automatically add the “/MP” flag anytime that I
> configure using Visual Studio (2015/2017) as the generator. I guess I could
> put the append string fairly high up in the CMake hierarchy. I am not
> seeing a property (from the first link you sent) that would allow me to do
> that.
>
>
>
> --
>
> Michael Jackson | Owner, President
>
> BlueQuartz Software
>
> [e] mike.jack...@bluequartz.net
>
> [w] www.bluequartz.net
>
>
>
> *From: *Marc CHEVRIER
> *Date: *Tuesday, September 11, 2018 at 1:04 PM
> *To: *Michael Jackson
> *Cc: *CMake
> *Subject: *Re: [CMake] Appending to CMAKE_CXX_FLAGS
>
>
>
> The best approach is to use properties (see
> https://cmake.org/cmake/help/git-master/manual/cmake-properties.7.html).
>
>
>
> At directory level and target level you can use property
> 'COMPILE_OPTIONS'. These properties can be updated using, respectively
> 'add_compile_options' and 'target_compile_options'.
>
>
>
> Be aware that variable 'CMAKE_CXX_FLAGS' is a string so to extend it you
> have to use:
>
> string(APPEND CMAKE_CXX_FLAGS "flag1 flag2")
>
>
>
>
>
> Le mar. 11 sept. 2018 à 17:58, Michael Jackson <
> mike.jack...@bluequartz.net> a écrit :
>
> What is the “modern” way to append to CMAKE_CXX_FLAGS? This is the logic
> that I would like:
>
>
>
> If (MSVC)
>
> Set(CMAKE_CXX_FLAGS ${ CMAKE_CXX_FLAGS} “/MP”)
>
> Endif()
>
>
>
> I have always heard that appending to the compile flags in this way is
> “bad”. What is the best practice for doing this?
>
>
>
> Thanks
>
> --
>
> Michael Jackson | Owner, President
>
> BlueQuartz Software
>
> [e] mike.jack...@bluequartz.net
>
> [w] www.bluequartz.net
>
> --
>
> 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] Appending to CMAKE_CXX_FLAGS
The best approach is to use properties (see
https://cmake.org/cmake/help/git-master/manual/cmake-properties.7.html).
At directory level and target level you can use property
'COMPILE_OPTIONS'. These properties can be updated using, respectively
'add_compile_options' and 'target_compile_options'.
Be aware that variable 'CMAKE_CXX_FLAGS' is a string so to extend it you
have to use:
string(APPEND CMAKE_CXX_FLAGS "flag1 flag2")
Le mar. 11 sept. 2018 à 17:58, Michael Jackson
a écrit :
> What is the “modern” way to append to CMAKE_CXX_FLAGS? This is the logic
> that I would like:
>
>
>
> If (MSVC)
>
> Set(CMAKE_CXX_FLAGS ${ CMAKE_CXX_FLAGS} “/MP”)
>
> Endif()
>
>
>
> I have always heard that appending to the compile flags in this way is
> “bad”. What is the best practice for doing this?
>
>
>
> Thanks
>
> --
>
> Michael Jackson | Owner, President
>
> BlueQuartz Software
>
> [e] mike.jack...@bluequartz.net
>
> [w] www.bluequartz.net
> --
>
> 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] [CMAKE] cmake_device_link.o: nvcc fatal: Unknown option 'Wl, -start-group'
Hi,
To avoid this, put link flags in ‘LINK_FLAGS’ target properly.
´target_link_libraries’ is populating ´LINK_LIBRARIES’ target property.
Le sam. 8 sept. 2018 à 01:40, Alvin Chu a écrit :
> Hi cmake team,
> I'm using cmake 3.12.1, and building a project which has cuda codes, the
> cmake file looks like,
> list(APPEND ALL_OBJECTS $)
> list(APPEND ALL_OBJECTS $)
> add_library(lib1 SHARED ${ALL_OBJECTS})
> list(APPEND ALL_LIBRARIES -Wl,-start-group)
> list(APPEND ALL_LIBRARIES ${SOME_LIBS})
> list(APPEND ALL_LIBRARIES -Wl,-end-group)
> target_link_libraries(lib1 ${ALL_LIBRARIES})
>
> Now for this project, cmake will generate a cmake_device_link.o, using
> the link flags in lib1, then I got error
> nvcc fatal : Unknown option 'Wl,-start-group'
>
> I checked cmake source code, and seems cmake doesn't check if the link
> flags in lib1 is supported by nvcc or not, and it directly passed all the
> flag to nvcc which caused the problem. Maybe this is one way to fix this
> issue.
>
> I also noticed cmMakefileLibraryTargetGenerator::WriteStaticLibraryRules
> will check CUDA_RESOLVE_DEVICE_SYMBOLS to decide if need generate
> cmake_device_link.o or not,
> but cmMakefileLibraryTargetGenerator::WriteSharedLibraryRules don't, I
> tried add this check in
> cmMakefileLibraryTargetGenerator::WriteSharedLibraryRules,
> and my build can success w/o cmake_device_link.o, so maybe this is also a
> way to fix the issue.
>
> I'm new to cmake, so if there's any better way to solve my problem, please
> let me know.
>
> Thanks.
> Alvin
> --
>
> 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] Export a custom property of a target
'define_property' is nearly useless except for documentation. Export of custom properties is managed through target property 'EXPORT_PROPERTIES'. Le mer. 22 août 2018 à 15:58, Raphael Grimm a écrit : > Hi, > > I added a custom target property via 'define_property' > (https://cmake.org/cmake/help/latest/command/define_property.html). > > When using this target in a different cmake project the property is not > found by cmake and the meta information stored in the target property is > lost. > > Is there a way to also export custom target properties? > > Regards > > Raphael > > > -- > > 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?
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) <
thomas.l.cl...@nasa.gov> 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
> *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) <
> 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
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) <
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
Re: [CMake] How to specify library dir for imported interface?
Next version of CMake (3.13) will supports properties LINK_OPTIONS as well as INTERFACE_LINK_OPTIONS. Le mer. 4 juil. 2018 à 16:02, Francis Giraldeau a écrit : > > However, it seems no property exists to actually specify the library dir > > of imported target, nor the linker flags to pass when using the > > imported target. > > > > What would be the best way to specify the library dir for an imported > > library? > > My workarround at the moment is to add a global link_directories(). It is > not clean, as it lacks the transitivity for library users, but at least it > works. > > Cheers, > > Francis > -- > Francis Giraldeau > -- > > 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] Adding a target to 'all' that was previously excluded
You can use a new target, built by all, depending on your initial target: add_custom_target(build_blah_X ALL) add_dependencies(build_blah_X blah_X) Le mer. 4 juil. 2018 à 03:33, Andrew White a écrit : > How do I add an excluded (executable) target to the build. I know that if > I add a library EXCLUDE_FROM_ALL and then create a dependency on that > library then that the library will be built anyway. How do I trigger > similar behaviour from an executable target? > > Example: > > Directory A contains a CMakeLists.txt that builds half a dozen utilities. > As part of my project, I want to add a single target from that list. > > I can include the build info without auto-adding all targets by going: > > Add_subdirectory(blah EXCLUDE_FROM_ALL) > > How do I then add target blah_X to my 'all' build? Or is there another > way to approach this? > > Thanks > > -- > Andrew > > -- > > 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] Changing link flags for one target
LINK_FLAGS property do not support generator expressions. In CMake 3.13, directory and target properties LINK_OPTIONS, supporting generator expressions, managed by commands add_link_options and target_link_options are introduced, . For earlier versions you can use global variables to set flags for all targets (CMAKE_*_LINKER_FLAGS) and use target property LINK_FLAGS to override default settings (options specified by LINK_FLAGS are defined *after* those coming from global variable). Le mer. 4 juil. 2018 à 05:06, Hendrik Sattler a écrit : > You could try a generator expression with a custom target property. > > Am 4. Juli 2018 04:27:58 MESZ schrieb Andrew White < > andrew.wh...@audinate.com>: > >In my cross-compile environment for an embedded platform, I need to set > >the stack size for each executable. The linker flag to set the stack > >size is (for example) "-Wl,-elf2flt='-s 2'". > > > >Is there an easy way to set this flag for every executable except one, > >for which I set "-Wl,-elf2flt='-s 4'"? Obviously I can call > > Set_target_properties( PROPERTIES LINK_FLAGS > "-Wl,-elf2flt='-s > >2'") > >on each target, but is there a mechanism to make this the default and > >then set a different value on a single target? > > > >If necessary, I suspect "-Wl,-elf2flt='-s 2' -Wl,-elf2flt='-s > >4'" will produce the correct result. > >* can I avoid doing it like this? > >* how can I be sure that the more specific option will follow the > >general one? > > > >(Assume all the targets are added via add_subdirectory commands that > >are common across multiple platforms, and that I'm adding > >platform-specific build rules in the project CMakeLists.txt) > > > >Thanks > > > >-- > >Andrew > -- > > 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] Different INSTALL target settings per project
FYI, next release (3.13) will relaxing this contraint so you will be able to apply this strategy. Le mar. 3 juil. 2018 à 08:05, Andrew White a écrit : > We have a number of projects that include other projects. Some of the > parent projects are cross-compile projects with various odd settings. > > Example project: > > add_subdirectory(a) > add_subdirectory(b) > > I want to go: > Install(TARGETS target_a program_b > RUNTIME DESTINATION other-bin > ) > > If I put it in the root CMakeLists.txt, CMake complains that the targets > are not defined in this context. But if I put an install() command in > subdirs A and B, then the 'other-bin' output path will apply to all > projects, not just this one. > > Is there an easy way to specify custom install paths for targets in > subdirectories without directly hacking the environment variables? > > Thanks > > -- > Andrew > > -- > > 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] how to deprecate a target?
FYI: Starting with CMake 3.11, it is now possible to define an alias of an imported target. Le lun. 2 juil. 2018 à 09:27, Petr Kmoch a écrit : > Hi Bram. > > Wild idea: could you also define a non-namespaced target `foo` and craft > it such that linking against it generates a linker warning? Something like > "Warning: symbol `Using_just_foo_is_deprecated_use_Foo_foo_instead` defined > twice, ignoring weak definition." > > Petr > > On 2 July 2018 at 00:11, Bram de Greve wrote: > >> That is unfortunate ... do you know any not-so-nice ways? >> >> So, what would you recommend here? >> >> I'm deprecating the old ways to use the Foo package (using Foo_LIBRARIES >> and Foo_INCLUDE_DIRS. You know, the cmake 2.x way of things). I can do that >> nicely with variable watches. >> >> But what about the target names? If I want to guarantee a seamless >> transition period, I should opt to keep using the "foo" target names. But >> then there's no way to "upgrade" to "Foo::foo" targets without breakage, >> since there's no deprecation strategy. And I can't use target aliases, >> since that is not allowed on imported targets. >> >> To answer my own question, I think the best thing is to move to the >> "Foo::foo" targets right now. There's at least one downstream package that >> will be hurt by this, but the damage is less than waiting for everyone to >> have moved to the "foo" target first. >> >> Best, >> >> Bram. >> >> >> >> On 6/29/2018 20:22, Robert Maynard wrote: >> >>> I am not aware of a nice way to setup CMake to error out if a user >>> links to `foo` instead of `Foo::foo`. >>> On Fri, Jun 29, 2018 at 2:05 AM Bram de Greve >>> wrote: >>> Hi all, Consider this situation. I'm building a Foo packaged, to be used by a Bar project. Foo used to export its target as simply foo. Now it exports its target as Foo::foo. Bar contains this: add_library(bar ...) target_link_libraries(bar foo) This of course must now be: add_library(bar ...) target_link_libraries(bar Foo::foo) But if bar still links to the foo instead of Foo::foo, then CMake doesn't really complain. foo doesn't exist, but configures and generates just fine. Of course, you'll face strange build errors, from which it isn't immediately apparent what's causing this ... How can I make sure CMake will complain loudly when bar still links to foo? Thanks, Bram. -- 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 > -- 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
Re: [CMake] Interface source paths evaluated relative to dependent library
Fine. I am surprised because both commands expects the same thing: a CMake list. The only touchy point is to ensure that the list separator is correctly passed to the command without early evaluation. For that purpose ensure that the generator expression is passed to the command inside quotes: target_include_directories(target INTERFACE "$") Le lun. 25 juin 2018 à 17:41, Rich T a écrit : > Ah, brilliant - I thought I'd tried that, but just gave it another go > following your advice and it worked a charm. > Incidentally, do you know what the rules are around the > BUILD_INTERFACE generator expression and line breaks / list items? > It seems to work fine in target_sources when enclosing multiple > lines/files, but in target_include_directories I need one > BUILD_INTERFACE expression per directory or I get an error. > > Thanks again, > > Rich > > On Mon, Jun 25, 2018 at 3:28 PM, Marc CHEVRIER > wrote: > > You can manage different paths (one for build export and one for install > > export) by using '$' and '$'. > > '$' accepts absolute paths and > > '$ expects paths relative to the install prefix > > (CMAKE_INSTALL_PREFIX variable). > > . > > > > > > Le lun. 25 juin 2018 à 16:23, Rich T a > écrit : > >> > >> Hi everyone, I've a question about interface sources. > >> > >> If you create an interface target A, add some sources via > >> > >> add_library(A INTERFACE) > >> target_sources(A INTERFACE some/relative/path) > >> > >> then link to another library B: > >> > >> add_library(B) > >> target_link_libraries(B PRIVATE A) > >> > >> B will search for those sources relative to its own source directory, > not > >> the directory where A is defined. This means B fails to configure with a > >> missing sources error if the targets are in different directories. > >> > >> If I specify the paths absolutely, B successfully finds the sources. > >> However, A can no longer be exported and neither can the static variant > of B > >> by association. > >> > >> I tried using $ in front of the relative > >> path, however it turns out SOURCE_DIR isn't a whitelisted property for > >> INTERFACE libraries. > >> > >> Is this behavior intentional, and if so, is there any workaround? (other > >> than defining all targets with interface sources in the same directory > as > >> the targets that use them) > >> -- > >> > >> 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] Interface source paths evaluated relative to dependent library
You can manage different paths (one for build export and one for install export) by using '$' and '$'. '$' accepts absolute paths and '$ expects paths relative to the install prefix (CMAKE_INSTALL_PREFIX variable). . Le lun. 25 juin 2018 à 16:23, Rich T a écrit : > Hi everyone, I've a question about interface sources. > > If you create an interface target A, add some sources via > > add_library(A INTERFACE) > target_sources(A INTERFACE some/relative/path) > > then link to another library B: > > add_library(B) > target_link_libraries(B PRIVATE A) > > B will search for those sources relative to its own source directory, not > the directory where A is defined. This means B fails to configure with a > missing sources error if the targets are in different directories. > > If I specify the paths absolutely, B successfully finds the sources. > However, A can no longer be exported and neither can the static variant of > B by association. > > I tried using $ in front of the relative > path, however it turns out SOURCE_DIR isn't a whitelisted property for > INTERFACE libraries. > > Is this behavior intentional, and if so, is there any workaround? (other > than defining all targets with interface sources in the same directory as > the targets that use them) > -- > > 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] FindPythonLibs on macOS
There is no specific reason. But, starting with CMake 3.12, a new approach to manage python is available (modules FindPython2, FindPython3 and FindPython) which take care of consistency between interpreter and libraries and rely, when possible, on python-config tool. Le ven. 22 juin 2018 à 11:04, Jonas Devlieghere a écrit : > Hi everyone, > > I'm having trouble with FindPythonLibs on macOS when having a version of > Python installed from either via python.org or Homebrew (in addition to > the system one). > > The issue is that I end up with an inconsistency between the library and > the interpreter, which causes issues at runtime. > > -- Found PythonLibs: /usr/lib/libpython2.7.dylib (found version "2.7.10") <- > System Python > -- Found PythonInterp: /usr/local/bin/python2.7 (found version "2.7.15") > <- Homebrew Python > > I was wondering if there's a particular reason that FindPythonLibs doesn't > use the python-config binary to find both the python libraries and > interpreter. > > Cheers, > Jonas > -- > > 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] Null alias targets?
Starting with CMake v3.11, it is now possible to aliasing an imported
target. So you can have something like that:
if (BUILD_MY_LIB)
add_library(my_lib SHARED )
add_library(MY_NAMESPACE::mylib ALIAS my_lib)
else()
add_library(system_lib SHARED IMPORTED GLOBAL)
set_property(TARGET system_lib PROPERTY IMPORTED_LOCATION
/path/to/system/lib)
add_library(MY_NAMESPACE::mylib ALIAS system_lib)
endif()
And, after you can use target MY_NAMESPACE::mylib transparently...
Le jeu. 14 juin 2018 à 06:53, Andrew White a
écrit :
> I have a library that needs to be built on some platforms but on others is
> part of the OS. I'd like to avoid putting "if platform" conditional code
> in the places it is used, but instead hide it away in my platform-specific
> code.
>
> One way to do this is define a variable mylib_targetname in each platform
> and add ${mylib_targetname} as a dependency. It can be defined on some
> platforms and undefined on others.
>
> It feels cleaner if I could create an alias target MY_NAMESPACE::mylib and
> refer to that. This lets me define the dependency without making sure an
> environment variable is set, which feels more natural. But in order to
> make this work I need a way to express that MY_NAMESPACE::mylib might be
> (legitimately) null on some platforms, and I can't figure out how to do
> this.
>
> Any ideas?
>
> --
> Andrew
>
> --
>
> 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] losing CMakeCache.txt after changing the compiler...
By using multiple build environments, I mean multiple build directories as well as controlled environment for each of them. If you have multiple compilers or even multiple versions of a compiler, by managing carefully environment variables (i.e. PATH variable for example) by using some bash functions, you can easily ensure to use always the correct compiler for each build environment. Le mer. 6 juin 2018 à 16:50, René J. V. Bertin a écrit : > Marc CHEVRIER wrote: > > > You can easily avoid this bad experience by using different builds > > environments : one per compiler ! > > > You mean one build directory per compiler? That can be very > disk-expensive, and > it doesn't solve the issue (e.g. you clone an environment and then change > the > compiler - why would that cause certain cached variables to be reset that > don't > need to be reset). > > Qt projects using CMake (e.g. KDE) are in a class of their own; Qt's auto- > generation applications use a mix of hardcoded absolute and relative paths > that > can easily go wrong when you update something that invalidates certain > paths. > > Or when you access your build directory in different ways. This is a bit > of a > different issue, but suppose you have directories: > > /a/b/c/d/e/f/projectA/work/source > /a/b/c/d/e/f/projectA/work/build > > and a symlink $HOME/projects/projectA -> /a/b/c/d/e/f/projectA > > Depending on shell and OS you may get surprises when you do things like > > %> cd $HOME/projects/ > %> (cd projectA/work/build ; cmake ../source) > %> (cd /a/b/c/d/e/f/projectA/work/build ; make) > > Qt's auto-generated relative paths (in step 2) will be invalid in step 3 > if no > path normalisation occurs, because of the different number of levels > between the > 2 access paths to the same working directory. Linux suffers from this, not > the > Mac OS. > > This is a cmake issue only insofar as cmake could prevent it by > normalising the > working dir always (make should probably do the same). > > R. > > -- > > 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] Spaces in conditional output of generator expressions
Using "SHELL:": add_compile_options("$<$:SHELL:-assume realloc_lhs>")
By using "SHELL:", you ensure that the two parts of the option will be
remain together.
Documentation is here:
https://cmake.org/cmake/help/git-master/command/target_compile_options.html
Le dim. 3 juin 2018 à 18:40, Hendrik Sattler a
écrit :
>
>
> Am 3. Juni 2018 16:33:12 MESZ schrieb Marc CHEVRIER <
> marc.chevr...@gmail.com>:
> >In fact, the right way to manage « composite » options is to use «
> >SHELL: »
> >prefix (introduced in up-coming version 3.12).
>
> Can you modify the example to show its use?
> Why is it called shell? IMHO a build to its not required to use any kind
> of shell.
>
> >Le dim. 3 juin 2018 à 16:11, Neil Carlson a
> >écrit :
> >
> >> Something not immediately obvious to me, and perhaps not to others
> >that
> >> might come across this thread, is that all spaces in the option
> >string need
> >> to be replaced with a semicolon, and not just those that separate
> >options
> >> (with Linux/make at least). For example an option that takes an
> >argument
> >> '-assume realloc_lhs'. If you do this:
> >>
> >> BAD: add_compile_options("$<$:-assume
> >> realloc_lhs>")
> >>
> >> you get a single quoted token "-assume realloc_lhs" on the compile
> >line
> >> which the compiler doesn't understand. The correct thing is
> >>
> >>
> >> GOOD:
> >add_compile_options("$<$:-assume;realloc_lhs>")
> >>
> >>
> >> On Sun, Jun 3, 2018 at 7:33 AM Neil Carlson
> >
> >> wrote:
> >>
> >>>
> >>> On Sun, Jun 3, 2018 at 7:08 AM Marc CHEVRIER
> >
> >>> wrote:
> >>>
> >>>> [...]
> >>>> GOOD: target_compile_options(someTarget PRIVATE
> >>>> "$<$:-Wall;-Wextra>")
> >>>>
> >>>
> >>> Ah, that's it. Never occurred to me to quote the whole thing,
> >thinking
> >>> that would turn the generator expression into a literal string and
> >not be
> >>> interpreted. Thanks!
> >>>
> >>>
> >>>
> >> --
> >>
> >> 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] Spaces in conditional output of generator expressions
In fact, the right way to manage « composite » options is to use « SHELL: »
prefix (introduced in up-coming version 3.12).
Le dim. 3 juin 2018 à 16:11, Neil Carlson a
écrit :
> Something not immediately obvious to me, and perhaps not to others that
> might come across this thread, is that all spaces in the option string need
> to be replaced with a semicolon, and not just those that separate options
> (with Linux/make at least). For example an option that takes an argument
> '-assume realloc_lhs'. If you do this:
>
> BAD: add_compile_options("$<$:-assume
> realloc_lhs>")
>
> you get a single quoted token "-assume realloc_lhs" on the compile line
> which the compiler doesn't understand. The correct thing is
>
>
> GOOD:
> add_compile_options("$<$:-assume;realloc_lhs>")
>
>
> On Sun, Jun 3, 2018 at 7:33 AM Neil Carlson
> wrote:
>
>>
>> On Sun, Jun 3, 2018 at 7:08 AM Marc CHEVRIER
>> wrote:
>>
>>> [...]
>>> GOOD: target_compile_options(someTarget PRIVATE
>>> "$<$:-Wall;-Wextra>")
>>>
>>
>> Ah, that's it. Never occurred to me to quote the whole thing, thinking
>> that would turn the generator expression into a literal string and not be
>> interpreted. Thanks!
>>
>>
>>
> --
>
> 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] Spaces in conditional output of generator expressions
When you use bare semicolon, it is required to encapsulate the whole generator expression in quotes to avoid list evaluation during command call; i.e: WRONG: target_compile_options(someTarget PRIVATE $<$:- Wall;-Wextra>) GOOD: target_compile_options(someTarget PRIVATE "$<$:- Wall;-Wextra>") Le dim. 3 juin 2018 à 15:03, Neil Carlson a écrit : > Sorry, the missing colon was a typo in my email, not actually missing. > Strangely, the bare semicolon doesn't work for me (Linux/make). However > $ does work! That prompted me to try escaping the semicolon > (\;) and that worked too. Thanks all! > > On Sun, Jun 3, 2018 at 12:18 AM Marc CHEVRIER > wrote: > >> Did you try with $ rather than the ; character? >> >> Le dim. 3 juin 2018 à 06:24, Craig Scott a >> écrit : >> >>> On Sun, Jun 3, 2018 at 12:34 PM, Neil Carlson >>> wrote: >>> >>>> On Sat, Jun 2, 2018 at 4:53 PM Stephen McDowell >>>> wrote: >>>> >>>>> It should be a CMake list, which is delineated by semicolons. >>>>> >>>>> add_compile_options($<$-Wall;-Wextra>) >>>>> >>>>> I am writing this from a phone so untested, but that has worked for me >>>>> in the past. >>>>> >>>> >>>> Right about the list, and is one of the things I tried, but didn't >>>> work. This one >>>> seems to break the generator expression. >>>> >>> >>> I think you are missing a colon after the first ">". I just tried a >>> command like the following and it produces the right compiler command line >>> options for me (on macOS using CMake 3.11.0 with either Ninja or Xcode): >>> >>> target_compile_options(someTarget PRIVATE >>> $<$:-Wall;-Wextra> >>> ) >>> >>> I also works for me even without the semi-colon (i.e. using a space >>> instead), which was kinda surprising given that I didn't quote the whole >>> generator expression. Not sure about other platforms or generators. >>> >>> >>> >>> -- >>> Craig Scott >>> Melbourne, Australia >>> https://crascit.com >>> -- >>> >>> 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] Spaces in conditional output of generator expressions
Did you try with $ rather than the ; character? Le dim. 3 juin 2018 à 06:24, Craig Scott a écrit : > On Sun, Jun 3, 2018 at 12:34 PM, Neil Carlson > wrote: > >> On Sat, Jun 2, 2018 at 4:53 PM Stephen McDowell >> wrote: >> >>> It should be a CMake list, which is delineated by semicolons. >>> >>> add_compile_options($<$-Wall;-Wextra>) >>> >>> I am writing this from a phone so untested, but that has worked for me >>> in the past. >>> >> >> Right about the list, and is one of the things I tried, but didn't work. >> This one >> seems to break the generator expression. >> > > I think you are missing a colon after the first ">". I just tried a > command like the following and it produces the right compiler command line > options for me (on macOS using CMake 3.11.0 with either Ninja or Xcode): > > target_compile_options(someTarget PRIVATE > $<$:-Wall;-Wextra> > ) > > I also works for me even without the semi-colon (i.e. using a space > instead), which was kinda surprising given that I didn't quote the whole > generator expression. Not sure about other platforms or generators. > > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > -- > > 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] losing CMakeCache.txt after changing the compiler...
You can easily avoid this bad experience by using different builds environments : one per compiler ! Le sam. 2 juin 2018 à 11:43, René J.V. Bertin a écrit : > Hi, > > This happened once too often for me: I apply successive tweaks to a > CMakeCache file, reinvoke make (or ninja) and then at some point lose > everything because I forgot that changing the compiler is a "lethal" > operation. > > Why does cmake have to throw away the entire cache file when something > changes in the compiler path? That seems like a cheap way to implement a > "let's keep track of which cached settings depend on the choice of > compiler". At the least it wouldn't be much less cheap to rename > CMakeCache.txt to CMakeCache.bak instead of deleting it. > > And FWIW, this is also a situation in which storing the exact CMake > invocation in a comment at the top of the cache file could be useful... > > R. > -- > > 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
