Re: [CMake] issue with target_link_libraries and MSVC

I'm not sure, but I think, you should consider 'set_target_properties' (https://cmake.org/cmake/help/v3.0/command/set_target_properties.html). E.g. target_link_libraries(my_target source1.cpp source2.cpp) set_target_properties(my_target PROPERTIES LINK_FLAGS "\openmp") 2016-04-12 17:29

Re: [CMake] [cmake-developers] Changing FOLDER property of ALL_BUILD and RUN_TESTS targets in VS

On 04/12/2016 02:54 PM, Robert Dailey wrote: > set_target_properties( ALL_BUILD PROPERTIES FOLDER ${predefined_folder} ) > > if( BUILD_TESTING ) > set_target_properties( RUN_TESTS PROPERTIES FOLDER "Testing" ) > endif() > > However this fails stating those targets do not exist. They don't

[CMake] Automoc for a part of target sources

Hi all, Is it somehow possible to apply automoc-like processing to the list of files, not whole target? My use case: in QtWebKit most of sources composing core targets are not related to Qt at all, but there are specific sources specific to Qt port. Currently I'm using automoc, but I suspect

[CMake] ASAN error

Hello, I am running on Ubuntu 15.10, with g++ 5.2.1 I have built my cmake project with ASAN and UBSAN. When I run the ctest nightly memory check, all of my tests fail with the error Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING Has

[CMake] Changing FOLDER property of ALL_BUILD and RUN_TESTS targets in VS

I have the following CMake code: get_property( predefined_folder GLOBAL PROPERTY PREDEFINED_TARGETS_FOLDER ) set_target_properties( ALL_BUILD PROPERTIES FOLDER ${predefined_folder} ) if( BUILD_TESTING ) set_target_properties( RUN_TESTS PROPERTIES FOLDER "Testing" ) endif() However this

Re: [CMake] Setting properties from within a function

I don't get how come the macro works because `target_compile_definitions` needs at least 3 parameters. The second one must be PRIVATE|PUBLIC|INTERFACE. Tamas On Tue, Apr 12, 2016 at 7:43 AM, Michael Surette wrote: > I would like to use set target properties from within a

Re: [CMake] Setting properties from within a function

On 2016-04-12 06:57 PM, Tamás Kenéz wrote: I don't get how come the macro works because `target_compile_definitions` needs at least 3 parameters. The second one must be PRIVATE|PUBLIC|INTERFACE. Tamas On Tue, Apr 12, 2016 at 7:43 AM, Michael Surette

[CMake] find_package: request/proposal for better version matching support

I've run into a bit of an issue with the find_package interface. Let's say I want to use a library libsemver: find_package(semver REQUIRED) Now, I want my code to work even when libsemver releases new versions with breaking API changes, and I happen to know they follow the semantic versioning

Re: [CMake] issue with target_link_libraries and MSVC

Hi Benjamin, MSVC flags start with “forward” slashes: / (However, MSVC also accepts hyphens (-) in my experience.) Documentation for /openmp flag: https://msdn.microsoft.com/library/fw509c3b.aspx Best regards, Miroslav From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Benjamin Ballet

Re: [CMake] Documenting CMakeLists.txt and custom or local .cmake files

I was hoping to get a little guidance on my question of how to document my CMakeLists.txt and other .cmake files. Any suggestions of how, as a cmake user, one may take advantage of the sphinx documentation scheme that cmake uses for its documentation? -Original Message- From: CMake

[CMake] FindBoost does not detect absence of header file

FindBoost does not detect absence of header files. To be specific: Run the following under cmake version 3.5.1: set(Boost_NO_BOOST_CMAKE ON) # prevent shortcut set(Boost_USE_STATIC_LIBS OFF) set(Boost_USE_MULTITHREADED ON) set(Boost_USE_STATIC_RUNTIME OFF) add_definitions(-DBOOST_ALL_DYN_LINK)

[CMake] issue with target_link_libraries and MSVC

I'm trying to add the openmp flag to a target with target_link_libraries. \openmp is interpreted as a file name and visual try to link to \openmp.obj The documentation state that target_link_libraries see an item as a flag if it start with - but MSVC flags start with \ Is there a way to add a

Re: [cmake-developers] CMake API for warnings

Hi Ruslo, Sorry for taking so long to respond here. I've been hoping to find time to think through the design deeply but I don't know when that may happen. Here is some more feedback. I invite others to jump in here. Without more interest I'm hesitant to proceed. On 04/05/2016 02:03 PM,

Re: [cmake-developers] Changing FOLDER property of ALL_BUILD and RUN_TESTS targets in VS

On 04/12/2016 02:54 PM, Robert Dailey wrote: > set_target_properties( ALL_BUILD PROPERTIES FOLDER ${predefined_folder} ) > > if( BUILD_TESTING ) > set_target_properties( RUN_TESTS PROPERTIES FOLDER "Testing" ) > endif() > > However this fails stating those targets do not exist. They don't

Re: [cmake-developers] Automoc same source - More thoughts

Am 12.04.2016 um 17:40 schrieb Sebastian Holtermann: Am 12.04.2016 um 13:43 schrieb Sebastian Holtermann: Sorry for the noise. I've stumbled over bug https://cmake.org/Bug/view.php?id=12873 a few times now since I like to use same named data/view classes. I've prepared a fix that generates

Re: [cmake-developers] Automoc same source - More thoughts

On 04/12/2016 03:12 PM, Sebastian Holtermann wrote: > Here it is. Please review/commit. > > To test it insert #include "moc_item.cpp" in any or many > of the item.cpp files of the attached test project. Thanks for working on this! As requested in the issue tracker entry you linked, in this

[cmake-developers] Changing FOLDER property of ALL_BUILD and RUN_TESTS targets in VS

I have the following CMake code: get_property( predefined_folder GLOBAL PROPERTY PREDEFINED_TARGETS_FOLDER ) set_target_properties( ALL_BUILD PROPERTIES FOLDER ${predefined_folder} ) if( BUILD_TESTING ) set_target_properties( RUN_TESTS PROPERTIES FOLDER "Testing" ) endif() However this

[Cmake-commits] CMake branch, next, updated. v3.5.1-915-geaadfd3

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, next has been updated via eaadfd357c9a6a438f642dd892b8bea771279a90 (commit) via

[cmake-developers] [CMake 0016060]: Chrome warns cmake installer is harmful program

The following issue has been SUBMITTED. == https://public.kitware.com/Bug/view.php?id=16060 == Reported By:raysatiro Assigned To:

[Cmake-commits] CMake branch, next, updated. v3.5.1-913-ge985c24

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, next has been updated via e985c24c197f416fdf1a85a3a833e82609357841 (commit) via

Re: [cmake-developers] CMake API for warnings

On 13-Apr-16 01:00, Brad King wrote: Hi Ruslo, Sorry for taking so long to respond here. I've been hoping to find time to think through the design deeply but I don't know when that may happen. Here is some more feedback. I invite others to jump in here. Without more interest I'm hesitant to

[Cmake-commits] CMake branch, master, updated. v3.5.1-439-gd0b2ec3

_VERSION_MINOR 5) -set(CMake_VERSION_PATCH 20160412) +set(CMake_VERSION_PATCH 20160413) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/

Re: [cmake-developers] Automoc same source name fix (proposal)

Am 12.04.2016 um 11:57 schrieb Sebastian Holtermann: Oops, moc_item.cpp it is. For the attached test case you end up with foo_automoc.cpp -- As before but includes sources below foo_automoc.dir/data/moc_item.cpp foo_automoc.dir/view/moc_item.cpp foo_automoc.dir/moc_item.cpp -- Powered by

[cmake-developers] Automoc same source name fix (proposal)

Hi, I've stumbled over bug https://cmake.org/Bug/view.php?id=12873 a few times now since I like to use same named data/view classes. I've prepared a fix that generates all moc_xxx.cpp files in the foo_automoc.dir subdirectory. For the attached test case you end up with foo_automoc.cpp -- As

[Cmake-commits] CMake branch, next, updated. v3.5.1-909-g6278587

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, next has been updated via 6278587aaa4c450405bbb05c921c2df831540c8d (commit) via

Re: [cmake-developers] Automoc same source - More thoughts

Am 12.04.2016 um 13:43 schrieb Sebastian Holtermann: Sorry for the noise. I've stumbled over bug https://cmake.org/Bug/view.php?id=12873 a few times now since I like to use same named data/view classes. I've prepared a fix that generates all moc_xxx.cpp files in the foo_automoc.dir

[cmake-developers] [CMake 0016059]: It is not possible to specify a linker different from the compiler to link a shared library

The following issue has been SUBMITTED. == https://cmake.org/Bug/view.php?id=16059 == Reported By:Antonio Assigned To: