From mail at danijar.com Sat Aug 1 11:54:58 2015 From: mail at danijar.com (Danijar Hafner) Date: Sat, 1 Aug 2015 11:54:58 -0400 Subject: [CMake] How to use subdirectories that need to be installed first? Message-ID: After some hours of research and getting no help on Stackoverflow, I decided to ask here on the mailing list. I have a problem with my CMake build system. There are CMakeLists.txt files defining runtimes or libraries or using ExternalProjects_Add() to download and build external code. Because of dependencies, those projects have to find each other. Now I want to have a CMakeLists.txt at the top level that builds all those at once. In order to find a project, is must be installed. But finding projects is already done at configuration time in CMake. Those are two approaches I already tried: 1. Run a CMake process for every project: Using execute_process(${CMAKE_COMMAND} ...), I can configure and build each project after another at configure time. However, this means I always have to run CMake after editing the code and cannot compile from within the IDE I generated project files for. 2. Linking to CMake targets: Running a CMake process for all external libraries is okay since I don't work on them. My own libraries could be used by calling target_link_libraries() with their target names. However, linking isn't enough. My libraries include directories of external libraries. Those must be made available to the using project, as well. How can I use libraries within my CMake project that need to be installed first? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkadlubo at gmail.com Mon Aug 3 06:38:31 2015 From: tkadlubo at gmail.com (=?UTF-8?Q?Tadeusz_Andrzej_Kad=C5=82ubowski?=) Date: Mon, 3 Aug 2015 12:38:31 +0200 Subject: [CMake] ZERO_CHECK hangs for a MS Visual Studio 2010 project on Windows7 Message-ID: Hello, I have a piece of C++ and Fortran software that I'm porting to the CMake build system. On my TeamCity continuous integration server I observe a weird behaviour: whenever I modify a CMakeLists.txt in a way that might mean ZERO_CHECK has something to update, building the ZERO_CHECK hangs until it gets killed off by the CI server job scheduler some 6 hours later. The project in question is definitely not big enough to make 6h of ZERO_CHECK sound reasonable. Besides, when I restart the build job after it gets killed, the second build works ok: it completes ZERO_CHECK promptly, and carries on with its regular job of compiling, linking etc.etc. Log sample: [13:23:52][Step 4/4] [13:23:52][Step 4/4] Microsoft (R) Visual Studio Version 10.0.40219.1. [13:23:52][Step 4/4] Copyright (C) Microsoft Corp. All rights reserved. [13:23:52][Step 4/4] 1>------ Build started: Project: ZERO_CHECK, Configuration: RelWithDebInfo x64 ------ [13:23:56][Step 4/4] 1>Build started 31.07.2015 13:23:54. (it looks the same way even when I enable detailed logging in MSBuild) This behavior seems to be 100% reproducible, and doing any trivial `echo "#FOO!" >> CMakeLists.txt` dummy commit is enough to trigger it. The same behavior seems to happen both when I run the build directly from devenv.com and via IncrediBuild distributed build thingy. Has any of you seen a ZERO_CHECK build that hangs in VisualStudio 2010? Any ideas about how and why it might happen? Is there any way to see some verbose logs of what was it that the ZERO_CHECK build wanted to accomplish when it hanged? I tried looking around with procmon, but I'm not very proficient with this tool, and didn't see anything obvious. Hoping to hear from you soon, -- Tadeusz Andrzej Kad?ubowski -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Mon Aug 3 11:30:20 2015 From: DLRdave at aol.com (David Cole) Date: Mon, 3 Aug 2015 11:30:20 -0400 Subject: [CMake] CDash problems In-Reply-To: References: Message-ID: OK, I finally have a build of boost I can rely on which enables me to try this out for you again. Using the following source tree, I am able to get a successful build & test of Safe Numerics, other than a couple of warnings, and it actually submits to the CDash dashboard, no problem. Source tree: davidcole at TRIVET /c/dev/repos/safe_numerics (master) $ git log -1 commit 569dc083c96845f06c5bf7a9d9d6756fd45d43bd Author: Robert Ramey Date: Sun Feb 1 21:14:12 2015 -0800 updated html documentation Script used to build and submit dashboard (w/ CMake 3.3.0, ninja, MS compiler from Visual Studio 2013, and a boost install with "system" layout): @rem Windows cmd script "build-SafeNumerics.cmd" setlocal set build_dir=%~n0 rmdir /q /s "%build_dir%" mkdir "%build_dir%" pushd "%build_dir%" cmake ^ -DBOOST_ROOT=C:\dev\NSB\x86\Release\boost ^ -DCMAKE_BUILD_TYPE=Release ^ -G Ninja C:\dev\repos\safe_numerics\CMake ninja Experimental popd endlocal Results: http://my.cdash.org/buildSummary.php?buildid=803237 When I update to most recent master (source at commit 78111d12), it still submits, but there are build errors in it: http://my.cdash.org/buildSummary.php?buildid=803238 The CMake/CDash stuff looks reasonable from my perspective. I haven't dug into all the details or anything, but it basically works, provided you have a boost install to point it to. I have no problems at all submitting dashboards for this project. If you want, I actually have a machine at work that is already submitting some open source dashboards -- if you'd like, I can add a Nightly run for Safe Numerics in this Windows/VS2013 environment since it is small and quick to run. HTH, David C. On Thu, Jun 25, 2015 at 12:16 PM, David Cole wrote: > I cloned your project [Safe > Numerics](https://github.com/robertramey/safe_numerics) to try to help > you out by attempting to reproduce this problem. > > I see the most recent activity is in the "policies" branch, but I > don't see anything in the whole repo, in either 'master' or 'policies' > branches that refer to how to build it via CMake, or how to attempt to > submit a CDash build... > > I browsed through the html docs and did a 'git grep -i experimental' > to no avail. > > Do you have build instructions? Should I just configure using the > "CMake/CMakeLists.txt" file and then try to build the Experimental > target? Will it build ok on Windows with VS 2013, or Ninja plus that > compiler? > > > Thx, > David C. > > > On Thu, Jun 25, 2015 at 10:44 AM, Robert Ramey wrote: >> I set up a project on the cdash.org website. >> >> When I invoke the "experimental" target it runs the tests and uploads the >> results to cdash.org. So far so good. In my github project and >> documentation I've encouraged uses of this project to use CMake to build it >> and test it and run the "experimental" target so that their test results >> will also appear on the cdash dashboard. But when someone other than myself >> tries to do this, I get an emal from admin at cdhash.org which says: >> >> Object: Cannot create handler based on XML content >> An XML submission from 42.156.137.83 to the project Safe Numerics cannot be >> parsed. The content of the file is as follow: >> >> -CDash on my.cdash.org >> >> What do I have to do to find out the problem and fix this? >> >> The project is "Safe Numerics" >> >> http://my.cdash.org/index.php?project=Safe+Numerics >> >> >> Robert Ramey >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake From ggarra13 at gmail.com Mon Aug 3 13:22:57 2015 From: ggarra13 at gmail.com (=?ISO-8859-1?Q?Gonzalo_Garramu=F1o?=) Date: Mon, 03 Aug 2015 14:22:57 -0300 Subject: [CMake] ninja under windows Message-ID: <55BFA371.2080607@gmail.com> I compiled Ninja on cygwin from git. That now works fine it seems. I am trying to compile for msvc. However, when cmake runs, I get: [1/123] Building CXX object 'libACESclip\CMakeFiles\ACESclip.dir\src\ACESclipWriter.cpp.obj'ninja: fatal: unknown deps type 'msvc' $ ninja --version 1.6.0.git Is compiling under the microsoft compiler not an option for ninja files ( I can compile with NMake Makefiles just fine in the same project ). From paul at mad-scientist.net Mon Aug 3 17:25:31 2015 From: paul at mad-scientist.net (Paul Smith) Date: Mon, 03 Aug 2015 17:25:31 -0400 Subject: [CMake] ARGVx "inherited" by sub-functions? Message-ID: <1438637131.2516.10.camel@mad-scientist.net> Is this a known thing, or a bug (I'm using cmake 3.1.0): I create this CMakeLists.txt: cmake_minimum_required(VERSION 3.1.0) project(ArgTest) function(FOO one two) message(STATUS "extra args are ${ARGN}") message(STATUS "third arg is ${ARGV2}") endfunction() function(BAR one) FOO(${one} TWO) message(STATUS "do something with ${ARGN}") endfunction() BAR(ONE N1 N2 N3 N4) Note how I invoke BAR() with 5 arguments, but BAR invokes FOO with only two arguments. I would expect that the third argument ${ARGV3} would be empty in function FOO. However, when I run cmake on this file it shows: -- extra args are -- third arg is N2 -- do something with N1;N2;N3;N4 So the ARGN for function FOO is correct (nothing there) but FOO has "inherited" the extra ARGVx arguments beyond the first two, that I passed to function BAR! That's rather unexpected. Bug or feature? From DLRdave at aol.com Mon Aug 3 21:49:06 2015 From: DLRdave at aol.com (David Cole) Date: Mon, 3 Aug 2015 21:49:06 -0400 Subject: [CMake] ARGVx "inherited" by sub-functions? In-Reply-To: <1438637131.2516.10.camel@mad-scientist.net> References: <1438637131.2516.10.camel@mad-scientist.net> Message-ID: You could argue bug or feature depending on your point of view. (I'd lean toward bug, as it is rather unexpected...) However, it has been that way for quite some time, (ever since function was added?), so it may require a new policy to fix, since some function calls from inside functions may be accidentally depending on the current behavior. D On Monday, August 3, 2015, Paul Smith wrote: > Is this a known thing, or a bug (I'm using cmake 3.1.0): > > I create this CMakeLists.txt: > > cmake_minimum_required(VERSION 3.1.0) > project(ArgTest) > > function(FOO one two) > message(STATUS "extra args are ${ARGN}") > message(STATUS "third arg is ${ARGV2}") > endfunction() > > function(BAR one) > FOO(${one} TWO) > message(STATUS "do something with ${ARGN}") > endfunction() > > BAR(ONE N1 N2 N3 N4) > > Note how I invoke BAR() with 5 arguments, but BAR invokes FOO with only > two arguments. I would expect that the third argument ${ARGV3} would be > empty in function FOO. > > However, when I run cmake on this file it shows: > > -- extra args are > -- third arg is N2 > -- do something with N1;N2;N3;N4 > > So the ARGN for function FOO is correct (nothing there) but FOO has > "inherited" the extra ARGVx arguments beyond the first two, that I > passed to function BAR! > > That's rather unexpected. Bug or feature? > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From frankmiller at cfrankmiller.com Mon Aug 3 23:04:41 2015 From: frankmiller at cfrankmiller.com (Miller, Frank) Date: Mon, 03 Aug 2015 22:04:41 -0500 Subject: [CMake] ninja under windows In-Reply-To: <55BFA371.2080607@gmail.com> References: <55BFA371.2080607@gmail.com> Message-ID: <55C02BC9.4070307@cfrankmiller.com> I suspect that ninja thinks its on a posix system because you compiled it in cygwin. Try building it in a windows "terminal". I routinely use cmake and ninja on windows with the msvc toolchain and it works great but I use msys instead of cygwin. Hopefully that helps you. Frank On 8/3/2015 12:22 PM, Gonzalo Garramu?o wrote: > I compiled Ninja on cygwin from git. That now works fine it seems. > I am trying to compile for msvc. However, when cmake runs, I get: > > [1/123] Building CXX object > 'libACESclip\CMakeFiles\ACESclip.dir\src\ACESclipWriter.cpp.obj'ninja: > fatal: unknown deps type 'msvc' > > $ ninja --version > 1.6.0.git > > Is compiling under the microsoft compiler not an option for ninja > files ( I can compile with NMake Makefiles just fine in the same > project ). From dseaward925 at gmail.com Tue Aug 4 03:56:56 2015 From: dseaward925 at gmail.com (David Seaward) Date: Tue, 4 Aug 2015 09:56:56 +0200 Subject: [CMake] Why would CMake add dependencies to libgomp? In-Reply-To: <55B34419.3000102@gmail.com> References: <55B34419.3000102@gmail.com> Message-ID: That was very helpful, thanks Nils. I'll be modifying the CMake file to include gomp only when (gcc & !mingw) On Sat, Jul 25, 2015 at 10:08 AM, Nils Gladitz wrote: > On 25.07.2015 09:52, David Seaward wrote: >> >> Hi, >> >> I am generating Code::Blocks project files using CMake GUI. When I do >> this dependencies to GOMP/libgomp are added to the project makefiles. >> If I remove them manually, then make the project, they are added again >> (and the build fails because they are there and I don't have libgomp). >> > > From the looks of it libpointmatcher links to the libraries in > ${libnabo_LIBRARIES}: > https://github.com/ethz-asl/libpointmatcher/blob/master/CMakeLists.txt#L137 > > And libnabo_LIBRARIES contains "gomp" when using gcc: > https://github.com/ethz-asl/libnabo/blob/master/libnaboConfig.cmake.in#L11 > > Nils From gurenchan at gmail.com Tue Aug 4 05:42:51 2015 From: gurenchan at gmail.com (Owen Alanzo Hogarth) Date: Tue, 4 Aug 2015 17:42:51 +0800 Subject: [CMake] cmake output files and different platforms. Message-ID: I am having a bit of trouble getting this sorted out. I set set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin) in one of my cmakelists.txt file and it works almost as expected. If I use the terminal to build everything goes where it needs to and then I can reference the relative location of my files and folders from my c code BUT if I use xcode to build the same program, xcode seems to append a Debug or Release to the end of my path breaking all my c code. sample output below // terminal // /Users/user/FOLDER/project/build/bin/ // /Users/user/FOLDER/project/build/bin/resources/ // xcode // /Users/user/FOLDER/project/build/bin/Debug/ // /Users/user/FOLDER/project/build/bin/Debug/resources/ // clion // /ad053ed7/ad053ed7/Debug/bin/ // /ad053ed7/ad053ed7/Debug/bin/resources/ As you can see I am getting three different outputs based on the same cmake file using 3 ways of building. is there a way to make these filenames consistent so that I when I try to load some resources my code doesn't break? -------------- next part -------------- An HTML attachment was scrubbed... URL: From slither.jz at gmail.com Tue Aug 4 15:07:30 2015 From: slither.jz at gmail.com (Jakub Zakrzewski) Date: Tue, 4 Aug 2015 21:07:30 +0200 Subject: [CMake] cmake output files and different platforms. In-Reply-To: References: Message-ID: Hi, your problem has two natures. From the terminal you're most probably using the "Unix Makefiles" generator. For xcode it's a multi-configuration generator that adds the build configuration to the path. Now, about CLion... it seems to run CMake by itself in a directory of it's choice. You'll have a hard time with it. > is there a way to make these filenames consistent so that I when I try to load some resources my code doesn't break? Easily - use relative paths in your code and make sure you set the right working directory when running. On 4 August 2015 at 11:42, Owen Alanzo Hogarth wrote: > I am having a bit of trouble getting this sorted out. > > I set > set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin) > > in one of my cmakelists.txt file and it works almost as expected. If I use > the terminal to build everything goes where it needs to and then I can > reference the relative location of my files and folders from my c code BUT > > if I use xcode to build the same program, xcode seems to append a Debug or > Release to the end of my path breaking all my c code. > > sample output below > // terminal > // /Users/user/FOLDER/project/build/bin/ > // /Users/user/FOLDER/project/build/bin/resources/ > > // xcode > // /Users/user/FOLDER/project/build/bin/Debug/ > // /Users/user/FOLDER/project/build/bin/Debug/resources/ > > // clion > // /ad053ed7/ad053ed7/Debug/bin/ > // /ad053ed7/ad053ed7/Debug/bin/resources/ > > As you can see I am getting three different outputs based on the same > cmake file using 3 ways of building. > > is there a way to make these filenames consistent so that I when I try to > load some resources my code doesn't break? > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Pozdrowienia Jakub Zakrzewski -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan at su-root.co.uk Tue Aug 4 16:46:53 2015 From: dan at su-root.co.uk (Dan Liew) Date: Tue, 4 Aug 2015 13:46:53 -0700 Subject: [CMake] [BUG] add_custom_command(TARGET ...) can't see in scope target Message-ID: Hi, I'm almost certain this is a bug but I thought I'd ask the mailing lists first. I'm observing a problem with CMake's add_custom_command() when using the TARGET version of the signature. Code demonstrating the issue can be found at [1] In ``test/CMakeLists.txt`` [2] I try using add_custom_command() to build and run an executable every time the ``foolib`` library is rebuilt. The motivation behind doing this is to have some very quick and simple library tests run every time the library is built. This use of add_custom_command() does not seem to work at all. Using CMake 2.8.12.2 the requested command is not invoked when running ``make foolib``. I am aware that the custom command won't run if ``foolib`` has already been made but even if I do a clean build the custom command specified does not run. When using CMake 3.2.3 I get a warning about CMP0040 which complains that the target passed to the TARGET argument in ``add_custom_command()`` doesn't exist. ``` Policy CMP0040 is not set: The target in the TARGET signature of add_custom_command() must exist. Run "cmake --help-policy CMP0040" for policy details. Use the cmake_policy command to set the policy and suppress this warning. The target name "foolib" is unknown in this context. This warning is for project developers. Use -Wno-dev to suppress it ``` This doesn't make sense the target **clearly exists and is in scope** because the ``simple_test`` executable links against it and also it is possible to read properties of the target. Seems like there's some sort of weird scope issue going on here. Thoughts? [1] https://github.com/delcypher/cmake_add_custom_command_bug [2] https://github.com/delcypher/cmake_add_custom_command_bug/blob/master/test/CMakeLists.txt Thanks, Dan Liew From nilsgladitz at gmail.com Tue Aug 4 17:07:28 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 04 Aug 2015 23:07:28 +0200 Subject: [CMake] [BUG] add_custom_command(TARGET ...) can't see in scope target In-Reply-To: References: Message-ID: <55C12990.8010201@gmail.com> On 04.08.2015 22:46, Dan Liew wrote: > > The target name "foolib" is unknown in this context. > This warning is for project developers. Use -Wno-dev to suppress it > ``` > > > This doesn't make sense the target **clearly exists and is in scope** > because the ``simple_test`` executable links against it and also it is > possible to read properties of the target. > > Seems like there's some sort of weird scope issue going on here. > > foolib is defined in this CMakeLists.txt: https://github.com/delcypher/cmake_add_custom_command_bug/blob/master/lib/CMakeLists.txt That is the (only) context in which you can extend the definition of the target with custom commands. Nils From tamas.kenez at gmail.com Tue Aug 4 17:10:54 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Tue, 4 Aug 2015 23:10:54 +0200 Subject: [CMake] on cmake supporting one arch per project (from CMake IR) Message-ID: On 2015-07-30 11:51:54 GMT, Nagy-Egri M?t? Ferenc via CMake wrote: > how on Earth am I going to build x86/x64/ARM targets from one VS solution? > [...] > the way how CMake has been designed immediately rules it out from ~75% of application development going on in the world in the future (mobile app devel) Well, we are building Android and iOS projects with CMake and we simply configure separate build dirs for each architecture. We even need to configure seperate dirs for Debug and Release builds for the makefile generators. It doesn't feel like a problem for us. We simply adapt our workflows to it. Is there anything wrong with this approach we don't recognize? Tamas Kenez -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan at su-root.co.uk Tue Aug 4 17:15:46 2015 From: dan at su-root.co.uk (Dan Liew) Date: Tue, 4 Aug 2015 14:15:46 -0700 Subject: [CMake] [BUG] add_custom_command(TARGET ...) can't see in scope target In-Reply-To: <55C12990.8010201@gmail.com> References: <55C12990.8010201@gmail.com> Message-ID: > foolib is defined in this CMakeLists.txt: > https://github.com/delcypher/cmake_add_custom_command_bug/blob/master/lib/CMakeLists.txt > > That is the (only) context in which you can extend the definition of the > target with custom commands. Since when? I haven't seen that documented anywhere. IMHO this behavior is counter-intuitive, in general I expect the scope of a target to not depend on the cmake command I am trying to use. Seeing as targets seem to be visible globally to all the commands (that I've used so far) it seems to reasonable to me to expect add_custom_command() to be able to see these targets too. From dan at su-root.co.uk Tue Aug 4 17:19:09 2015 From: dan at su-root.co.uk (Dan Liew) Date: Tue, 4 Aug 2015 14:19:09 -0700 Subject: [CMake] [BUG] add_custom_command(TARGET ...) can't see in scope target In-Reply-To: References: <55C12990.8010201@gmail.com> Message-ID: For reference I've opened up a bug report http://www.cmake.org/Bug/view.php?id=15681 From iosif.neitzke+cmake at gmail.com Tue Aug 4 17:20:12 2015 From: iosif.neitzke+cmake at gmail.com (Iosif Neitzke) Date: Tue, 4 Aug 2015 16:20:12 -0500 Subject: [CMake] [BUG] add_custom_command(TARGET ...) can't see in scope target In-Reply-To: References: <55C12990.8010201@gmail.com> Message-ID: "Dependencies listed with the DEPENDS argument may reference files and outputs of custom commands created with add_custom_command() in the same directory (CMakeLists.txt file)." http://www.cmake.org/cmake/help/v2.8.8/cmake.html#command:add_custom_target On Tue, Aug 4, 2015 at 4:15 PM, Dan Liew wrote: >> foolib is defined in this CMakeLists.txt: >> https://github.com/delcypher/cmake_add_custom_command_bug/blob/master/lib/CMakeLists.txt >> >> That is the (only) context in which you can extend the definition of the >> target with custom commands. > > Since when? I haven't seen that documented anywhere. IMHO this > behavior is counter-intuitive, in general I expect the scope of a > target to not depend on the cmake command I am trying to use. Seeing > as targets seem to be visible globally to all the commands (that I've > used so far) it seems to reasonable to me to expect > add_custom_command() to be able to see these targets too. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From nilsgladitz at gmail.com Tue Aug 4 17:24:32 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 04 Aug 2015 23:24:32 +0200 Subject: [CMake] [BUG] add_custom_command(TARGET ...) can't see in scope target In-Reply-To: References: <55C12990.8010201@gmail.com> Message-ID: <55C12D90.8000704@gmail.com> On 04.08.2015 23:15, Dan Liew wrote: >> foolib is defined in this CMakeLists.txt: >> https://github.com/delcypher/cmake_add_custom_command_bug/blob/master/lib/CMakeLists.txt >> >> That is the (only) context in which you can extend the definition of the >> target with custom commands. > Since when? As far as I know it has always been this way. > I haven't seen that documented anywhere. IMHO this > behavior is counter-intuitive, in general I expect the scope of a > target to not depend on the cmake command I am trying to use. I think it is sensible that the definition of a target is scoped to one single directory. Where the definition of a target consists of e.g. sources, properties, dependencies and custom commands related to the target. You can reference/query global targets in other directories but you can not change them. Nils From iosif.neitzke+cmake at gmail.com Tue Aug 4 17:32:21 2015 From: iosif.neitzke+cmake at gmail.com (Iosif Neitzke) Date: Tue, 4 Aug 2015 16:32:21 -0500 Subject: [CMake] [BUG] add_custom_command(TARGET ...) can't see in scope target In-Reply-To: <55C12D90.8000704@gmail.com> References: <55C12990.8010201@gmail.com> <55C12D90.8000704@gmail.com> Message-ID: And: "A target created in the same directory (CMakeLists.txt file) that specifies any output of the custom command as a source file is given a rule to generate the file using the command at build time." http://www.cmake.org/cmake/help/v3.3/command/add_custom_command.html But it's not super clear in the documentation. On Tue, Aug 4, 2015 at 4:24 PM, Nils Gladitz wrote: > On 04.08.2015 23:15, Dan Liew wrote: >>> >>> foolib is defined in this CMakeLists.txt: >>> >>> https://github.com/delcypher/cmake_add_custom_command_bug/blob/master/lib/CMakeLists.txt >>> >>> That is the (only) context in which you can extend the definition of the >>> target with custom commands. >> >> Since when? > > > As far as I know it has always been this way. > >> I haven't seen that documented anywhere. IMHO this >> behavior is counter-intuitive, in general I expect the scope of a >> target to not depend on the cmake command I am trying to use. > > > I think it is sensible that the definition of a target is scoped to one > single directory. > Where the definition of a target consists of e.g. sources, properties, > dependencies and custom commands related to the target. > > You can reference/query global targets in other directories but you can not > change them. > > Nils > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From DLRdave at aol.com Tue Aug 4 18:10:49 2015 From: DLRdave at aol.com (David Cole) Date: Tue, 4 Aug 2015 18:10:49 -0400 Subject: [CMake] on cmake supporting one arch per project (from CMake IR) In-Reply-To: References: Message-ID: There's nothing wrong with that approach, per se, it simply "doesn't feel natural" to Xcode and Visual Studio users. Xcode and Visual Studio users building modern apps for multiple targeted platforms (phone, tablet, simulated phone/tablet, desktop, other) are used to switching the target platform in the IDE somewhere **within a single project file** for non-CMake-generated project files. Forcing them to have multiple Xcode or VS project files, one each for each of their platforms (and configs) feels like a lot of work somehow. The only thing "wrong" with your approach is you have to spend a lot of time convincing people that CMake is worth it, when all they want to do is open a project file and build. They don't want to have to manage a slew of build trees and project files, when it seems like it ought to be "done already" with what's readily available in the UI... I totally understand this, and get it. And I still love CMake despite this particular shortcoming. ;-) David C. On Tue, Aug 4, 2015 at 5:10 PM, Tam?s Ken?z wrote: > On 2015-07-30 11:51:54 GMT, Nagy-Egri M?t? Ferenc via CMake wrote: > >> how on Earth am I going to build x86/x64/ARM targets from one VS solution? >> [...] >> the way how CMake has been designed immediately rules it out from ~75% of >> application development going on in the world in the future (mobile app >> devel) > > Well, we are building Android and iOS projects with CMake and we simply > configure separate build dirs for each architecture. We even need to > configure seperate dirs for Debug and Release builds for the makefile > generators. > > It doesn't feel like a problem for us. We simply adapt our workflows to it. > Is there anything wrong with this approach we don't recognize? > > Tamas Kenez > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From scott at towel42.com Tue Aug 4 19:10:21 2015 From: scott at towel42.com (Scott Aron Bloom) Date: Tue, 4 Aug 2015 23:10:21 +0000 Subject: [CMake] on cmake supporting one arch per project (from CMake IR) In-Reply-To: References: Message-ID: -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of David Cole via CMake Sent: Tuesday, August 4, 2015 3:11 PM To: Tam?s Ken?z Cc: cmake at cmake.org Subject: Re: [CMake] on cmake supporting one arch per project (from CMake IR) There's nothing wrong with that approach, per se, it simply "doesn't feel natural" to Xcode and Visual Studio users. Xcode and Visual Studio users building modern apps for multiple targeted platforms (phone, tablet, simulated phone/tablet, desktop, other) are used to switching the target platform in the IDE somewhere **within a single project file** for non-CMake-generated project files. Forcing them to have multiple Xcode or VS project files, one each for each of their platforms (and configs) feels like a lot of work somehow. The only thing "wrong" with your approach is you have to spend a lot of time convincing people that CMake is worth it, when all they want to do is open a project file and build. They don't want to have to manage a slew of build trees and project files, when it seems like it ought to be "done already" with what's readily available in the UI... I totally understand this, and get it. And I still love CMake despite this particular shortcoming. ;-) David C. =================== IMO, this is one of the biggest shortcomings of CMake. I understand the heritage of the CMake world being "make file" based.. I really do.. And I love having a true "out of source" make file generator for when I am doing my Linux based development. And I don?t mind having a src tree, a build, a build.rel, build.32 and a build.rel.32 etc etc for every possible configuration I need. However, when on windows, in VS, having at a minimum of two build directories (64 vs 32) is a major downside of CMake. I understand if its not in the 3.X timeframe, as I would expect it to be a major change.. But IMO, being able to have architecture as well as build types in one VS project (as well as xcode) would be a major improvement for the community. Scott From rwan.work at gmail.com Tue Aug 4 20:14:14 2015 From: rwan.work at gmail.com (Raymond Wan) Date: Wed, 5 Aug 2015 08:14:14 +0800 Subject: [CMake] on cmake supporting one arch per project (from CMake IR) In-Reply-To: References: Message-ID: On Wed, Aug 5, 2015 at 7:10 AM, Scott Aron Bloom wrote: > =================== > IMO, this is one of the biggest shortcomings of CMake. I understand the heritage of the CMake world being "make file" based.. I really do.. And I love having a true "out of source" make file generator for when I am doing my Linux based development. And I don?t mind having a src tree, a build, a build.rel, build.32 and a build.rel.32 etc etc for every possible configuration I need. > > However, when on windows, in VS, having at a minimum of two build directories (64 vs 32) is a major downside of CMake. > > I understand if its not in the 3.X timeframe, as I would expect it to be a major change.. But IMO, being able to have architecture as well as build types in one VS project (as well as xcode) would be a major improvement for the community. > Scott I don't do any Windows development, so I didn't realize this. But to change CMake (even 4.x) to accommodate this seems strange to me. I mean, for the Linux/Unix developers out there, it "works". While there was an earlier argument that the vast majority of users are Windows-based, if we consider just developers, then I don't think the difference is that large. In any case, as alluded to in the other thread, why not develop a Windows-way of creating CMakeLists.txt -- i.e., create another project (WMake or WCMake :-P ) that generates partially compatible CMakeLists.txt ... Or maybe VS should be including this as a feature in their IDE, instead? Alternatively, perhaps we should just admit that Windows and Linux-based development are different. And CMake supports "cross-platform development (including Windows) for Linux-based developers". Not suggesting it should turn away Windows-based developers, but just admit that it was created with a Linux/Unix mindset (for better or worse) and can't satisfy all development paradigms... Ray From scott at towel42.com Tue Aug 4 20:23:12 2015 From: scott at towel42.com (Scott Aron Bloom) Date: Wed, 5 Aug 2015 00:23:12 +0000 Subject: [CMake] on cmake supporting one arch per project (from CMake IR) In-Reply-To: References: Message-ID: -----Original Message----- From: Raymond Wan [mailto:rwan.work at gmail.com] Sent: Tuesday, August 4, 2015 5:14 PM To: Scott Aron Bloom Cc: cmake at cmake.org Subject: Re: [CMake] on cmake supporting one arch per project (from CMake IR) On Wed, Aug 5, 2015 at 7:10 AM, Scott Aron Bloom wrote: > =================== > IMO, this is one of the biggest shortcomings of CMake. I understand the heritage of the CMake world being "make file" based.. I really do.. And I love having a true "out of source" make file generator for when I am doing my Linux based development. And I don?t mind having a src tree, a build, a build.rel, build.32 and a build.rel.32 etc etc for every possible configuration I need. > > However, when on windows, in VS, having at a minimum of two build directories (64 vs 32) is a major downside of CMake. > > I understand if its not in the 3.X timeframe, as I would expect it to be a major change.. But IMO, being able to have architecture as well as build types in one VS project (as well as xcode) would be a major improvement for the community. > Scott I don't do any Windows development, so I didn't realize this. But to change CMake (even 4.x) to accommodate this seems strange to me. I mean, for the Linux/Unix developers out there, it "works". While there was an earlier argument that the vast majority of users are Windows-based, if we consider just developers, then I don't think the difference is that large. In any case, as alluded to in the other thread, why not develop a Windows-way of creating CMakeLists.txt -- i.e., create another project (WMake or WCMake :-P ) that generates partially compatible CMakeLists.txt ... Or maybe VS should be including this as a feature in their IDE, instead? Alternatively, perhaps we should just admit that Windows and Linux-based development are different. And CMake supports "cross-platform development (including Windows) for Linux-based developers". Not suggesting it should turn away Windows-based developers, but just admit that it was created with a Linux/Unix mindset (for better or worse) and can't satisfy all development paradigms... Ray ================= I understand.. However, my point are these. First, its no longer just windows, its windows and mac using XCode. Second, VS and XCode ALREADY support this feature in their IDE. In NON CMake created project systems, I can have in 1 project, Arm, Android, Windows Phone, x86 and x64. Where some applications in the project get built, others don?t, and every library can get built with different options. This isn?t a CMakeLists.txt issue, it?s a Solution "output" from Cmake issue. Third, its on linux as well, more and more IDEs support multiple targets and platforms for a given project. Eclipse, and I believe Qt Creator (though I could be wrong) to name two popular ones. Fourth, just because it "was this way" doesn?t mean "it should always be this way", that?s a pretty depressing point of view to take on. And last, CMake already does it "kinda" for configurations. For VS and for XCode, it will generate 4 different configurations (or as many are as available in CMAKE_CONFIGURATION_TYPES), however, it only does it for one platform, Win32 or Win64 depending on the generator selected. All we are asking for (and we do realize its not trivial to implement) is to generate both multiple configuration and targets. Scott From rwan.work at gmail.com Tue Aug 4 21:53:03 2015 From: rwan.work at gmail.com (Raymond Wan) Date: Wed, 5 Aug 2015 09:53:03 +0800 Subject: [CMake] on cmake supporting one arch per project (from CMake IR) In-Reply-To: References: Message-ID: On Wed, Aug 5, 2015 at 8:23 AM, Scott Aron Bloom wrote: > I understand.. However, my point are these. > > First, its no longer just windows, its windows and mac using XCode. > Second, VS and XCode ALREADY support this feature in their IDE. In NON CMake created project systems, I can have in 1 project, Arm, Android, Windows Phone, x86 and x64. Where some applications in the project get built, others don?t, and every library can get built with different options. This isn?t a CMakeLists.txt issue, it?s a Solution "output" from Cmake issue. > Third, its on linux as well, more and more IDEs support multiple targets and platforms for a given project. Eclipse, and I believe Qt Creator (though I could be wrong) to name two popular ones. Hmmmm, well, this last point raises the question of whether the support you're asking is best served by the IDE developers by "wrapping around" CMake (or some other build tool). > Fourth, just because it "was this way" doesn?t mean "it should always be this way", that?s a pretty depressing point of view to take on. ... > All we are asking for (and we do realize its not trivial to implement) is to generate both multiple configuration and targets. It is a depressing view and not quite what I was suggesting. It's more like "was this way" is working for some people already. The new feature that you and some others are asking for seems to be a lot of work (NB: I'm not a CMake developer). And it *feels* like that this is something that either the build tool could support or maybe even the IDE. As the IDE here is closed source and doesn't permit changes, then changing the more open build tool is the next logical step. But if effort is put into making some CMake 4.0 and suddenly VS's IDE puts what you desire out within the IDE, then there will be no users. Or, not enough to justify the effort... Again, I'm not a Windows developer, but would this statement be correct? Does VS or Xcode permit "plugins" to be created by the community so that maybe one could be made to "wrap around" CMake? Ray From scott at towel42.com Tue Aug 4 22:04:04 2015 From: scott at towel42.com (Scott Aron Bloom) Date: Wed, 5 Aug 2015 02:04:04 +0000 Subject: [CMake] on cmake supporting one arch per project (from CMake IR) In-Reply-To: References: Message-ID: -----Original Message----- From: Raymond Wan [mailto:rwan.work at gmail.com] Sent: Tuesday, August 4, 2015 6:53 PM To: Scott Aron Bloom Cc: cmake at cmake.org Subject: Re: [CMake] on cmake supporting one arch per project (from CMake IR) On Wed, Aug 5, 2015 at 8:23 AM, Scott Aron Bloom wrote: > I understand.. However, my point are these. > > First, its no longer just windows, its windows and mac using XCode. > Second, VS and XCode ALREADY support this feature in their IDE. In NON CMake created project systems, I can have in 1 project, Arm, Android, Windows Phone, x86 and x64. Where some applications in the project get built, others don?t, and every library can get built with different options. This isn?t a CMakeLists.txt issue, it?s a Solution "output" from Cmake issue. > Third, its on linux as well, more and more IDEs support multiple targets and platforms for a given project. Eclipse, and I believe Qt Creator (though I could be wrong) to name two popular ones. Hmmmm, well, this last point raises the question of whether the support you're asking is best served by the IDE developers by "wrapping around" CMake (or some other build tool). > Fourth, just because it "was this way" doesn?t mean "it should always be this way", that?s a pretty depressing point of view to take on. ... > All we are asking for (and we do realize its not trivial to implement) is to generate both multiple configuration and targets. It is a depressing view and not quite what I was suggesting. It's more like "was this way" is working for some people already. The new feature that you and some others are asking for seems to be a lot of work (NB: I'm not a CMake developer). And it *feels* like that this is something that either the build tool could support or maybe even the IDE. As the IDE here is closed source and doesn't permit changes, then changing the more open build tool is the next logical step. But if effort is put into making some CMake 4.0 and suddenly VS's IDE puts what you desire out within the IDE, then there will be no users. Or, not enough to justify the effort... Again, I'm not a Windows developer, but would this statement be correct? Does VS or Xcode permit "plugins" to be created by the community so that maybe one could be made to "wrap around" CMake? Ray ===== I know VS absolutely allows for plugins, but I do not believe it would be appropriate, to be honest, I don?t think you fully understand the problem being put forth. For VS, the project it loads, has no idea it came from CMake, or from any other build system (qmake etc). For VS at the top level it?s a sln (solution) file, and each library or executable is a project file (vcproj or vcxproj for newer versions). CMake generates these files, and the IDE loads the SLN file in first, which points to which project files to load. For every file, its possible (not typical) to have different options for both configuration (debug, release, relwithdebug etc) as well as target technology (win32, win64 etc). Typically files, get their options from the project settings, and each project has settings for config and target. However, they are in the same file per project. It really wouldn?t make sense to have the IDE generating its own project files from CMakeList.txt files, though it is theoretically possible. And in reality, I have been a VS (as well as makefile developer) for over 25 years, since before it was Visual Studio, their typical flow, is to use the IDE to create the SLN and Project files using their methods, again it could be a plugin, however, to do so, you would have to write a CMake plugin, which could parse a CMake input file set, and create a complete solution. To me it seems like overkill, since the pluging would have to be in a VS plugin compatible language (at least at the interface). Again possible, but its never going to come from MS (or apple for XCode) I do understand the current cmake works for many users, however, right now for XCode and VS, its missing a major aspect of the development process. And for both of them, PART of the need is already serviced. I can tell you, I would never have pushed my company (and it was my decision) to use CMake, if it ONLY supported 1 configuration per solution file (debug vs release). That would have been a major step back from QMake. Scott From greg.marr at autodesk.com Tue Aug 4 22:06:27 2015 From: greg.marr at autodesk.com (Greg Marr) Date: Wed, 5 Aug 2015 02:06:27 +0000 Subject: [CMake] on cmake supporting one arch per project (from CMake IR) In-Reply-To: References: Message-ID: > Hmmmm, well, this last point raises the question of whether the > support you're asking is best served by the IDE developers by > "wrapping around" CMake (or some other build tool). Since CMake is the one generating the project files, it is obvious that it should be the one that is updated to add this support. The current lack of support is not due to any kind of limitation in any of the IDEs, it is purely a limitation of the tool that is generating the project files that already contain all the necessary support for the requested features, and have done so for many years now, since before the last time that the Visual Studio generators had to be rewritten to move from vcproj to vcxproj. The generated project files can already contain multiple configurations (release vs debug), but not multiple platforms. From dan at su-root.co.uk Tue Aug 4 22:41:25 2015 From: dan at su-root.co.uk (Dan Liew) Date: Tue, 4 Aug 2015 19:41:25 -0700 Subject: [CMake] [BUG] add_custom_command(TARGET ...) can't see in scope target In-Reply-To: References: <55C12990.8010201@gmail.com> Message-ID: On 4 August 2015 at 14:20, Iosif Neitzke wrote: > "Dependencies listed with the DEPENDS argument may reference files and > outputs of custom commands created with add_custom_command() in the > same directory (CMakeLists.txt file)." > > http://www.cmake.org/cmake/help/v2.8.8/cmake.html#command:add_custom_target That doesn't really seem to have anything to do with the issue I'm using. That's the documentation for the DEPENDS argument to add_custom_target() which I'm not using here. I'm using add_custom_command() From dan at su-root.co.uk Tue Aug 4 22:46:01 2015 From: dan at su-root.co.uk (Dan Liew) Date: Tue, 4 Aug 2015 19:46:01 -0700 Subject: [CMake] [BUG] add_custom_command(TARGET ...) can't see in scope target In-Reply-To: References: <55C12990.8010201@gmail.com> <55C12D90.8000704@gmail.com> Message-ID: On 4 August 2015 at 14:32, Iosif Neitzke wrote: > And: > > "A target created in the same directory (CMakeLists.txt file) that > specifies any output of the custom command as a source file is given a > rule to generate the file using the command at build time." > > http://www.cmake.org/cmake/help/v3.3/command/add_custom_command.html That documentation is for the first signature of ``add_custom_command()`` (Generating Files section in the docs) which I'm not using here. I'm using the other signature (Build Events in the docs) which mentions nothing about add_custom_command(TARGET ...) working only on targets created in the same directory. CMakes behaviour could be clearer here, it should probably raise an error rather than pretending that the target doesn't exist which is clearly does. > But it's not super clear in the documentation. Agreed! From dan at su-root.co.uk Tue Aug 4 22:49:17 2015 From: dan at su-root.co.uk (Dan Liew) Date: Tue, 4 Aug 2015 19:49:17 -0700 Subject: [CMake] [BUG] add_custom_command(TARGET ...) can't see in scope target In-Reply-To: <55C12D90.8000704@gmail.com> References: <55C12990.8010201@gmail.com> <55C12D90.8000704@gmail.com> Message-ID: >> I haven't seen that documented anywhere. IMHO this >> behavior is counter-intuitive, in general I expect the scope of a >> target to not depend on the cmake command I am trying to use. > > > I think it is sensible that the definition of a target is scoped to one > single directory. > Where the definition of a target consists of e.g. sources, properties, > dependencies and custom commands related to the target. > > You can reference/query global targets in other directories but you can not > change them. It seems sensible from a safety standpoint (preventing targets from accidentally being modified from other directories) but it also limiting in that it prevents certain directory layouts (like the one I tried in my example). From m.brehler at dkfz-heidelberg.de Wed Aug 5 11:03:53 2015 From: m.brehler at dkfz-heidelberg.de (Brehler, Michael) Date: Wed, 5 Aug 2015 17:03:53 +0200 Subject: [CMake] NSIS Installer: Changing shortcuts 'Start in' Message-ID: <57EE86D11538B44096C712532DBB6C5A0131C25E11EF@DKFZEX01.ad.dkfz-heidelberg.de> Hi community, we are using NSIS (CPack) for our Windows installers. Our current setup looks like this: ;Create shortcuts CreateDirectory "$SMPROGRAMS\$STARTMENU_FOLDER" @CPACK_NSIS_CREATE_ICONS@ @CPACK_NSIS_CREATE_ICONS_EXTRA@ CreateShortCut "$SMPROGRAMS\$STARTMENU_FOLDER\Uninstall.lnk" "$INSTDIR\Uninstall.exe" With the $INSTDIR set to top level directory (not the bin with the executables). The problem is that we need to set the 'Start in' path for the created shortcut to the bin directory. Using this code: SetOutPath "$INSTDIR\bin" CreateShortcut "$SMPROGRAMS\$STARTMENU_FOLDER\ TEST.lnk" "$INSTDIR\bin\Test.exe" SetOutPath "$INSTDIR" we have a workaround but we would prefer to change the 'Start in' path for the @CPACK_NSIS_CREATE_ICONS@ command without manually adding shortcuts. Thanks Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.marr at autodesk.com Wed Aug 5 14:42:25 2015 From: greg.marr at autodesk.com (Greg Marr) Date: Wed, 5 Aug 2015 18:42:25 +0000 Subject: [CMake] on cmake supporting one arch per project (from CMake IR) References: Message-ID: "Since CMake is the one generating the project files, it is obvious that it should be the one that is updated to add this support. The current lack of support is not due to any kind of limitation in any of the IDEs, it is purely a limitation of the tool that is generating the project files that already contain all the necessary support for the requested features, and have done so for many years now, since before the last time that the Visual Studio generators had to be rewritten to move from vcproj to vcxproj. The generated project files can already contain multiple configurations (release vs debug), but not multiple platforms." Gilles Khouzam from Microsoft has created an experimental fork, current as of 3.2.1, that adds this support. https://github.com/Microsoft/CMake/tree/feature/MSMultiPlatform Adding experimental MultiPlatform support to CMake for Windows and VS 2012 and above. By setting the CMAKE_VS_EFFECTIVE_PLATFORMS variable, the user is able to specify that multiple platforms should be produced for the same project. The supported platforms are Win32, ARM and x64 (not applicable to Windows Phone) and should be specified as a delimited string Win32;ARM;x64 for example. From rcdailey.lists at gmail.com Wed Aug 5 15:02:20 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Wed, 5 Aug 2015 14:02:20 -0500 Subject: [CMake] Managed C++ / C# Projects: Location of assembly DLL Message-ID: I am including external MS projects via CMake for my C# projects. The Managed C++ projects I generate via CMake directly. However, sharing assembly references between the two is difficult. Sometimes I need my imported C# projects to know where to find the managed C++ DLL assembly it built. This is in the CMake binary directory, which might be different on each machine, so I can't exactly setup a relative path to this file in the C# project references section. Likewise with dependencies on C# output from Managed C++. It's a little easier to tell CMake where to find the output DLL file for a C# project (since the output location is relative inside the source dir). How do you guys recommend solving these dependency issues? Is there a way I can add an assembly reference to a Managed C++ project via path through CMake? From scott at towel42.com Wed Aug 5 15:17:28 2015 From: scott at towel42.com (Scott Aron Bloom) Date: Wed, 5 Aug 2015 19:17:28 +0000 Subject: [CMake] on cmake supporting one arch per project (from CMake IR) In-Reply-To: References: Message-ID: When I had tried it previously, It was too out of date, I will take a look. Im still hoping CMake integrates it in. Scott -----Original Message----- From: Greg Marr [mailto:greg.marr at autodesk.com] Sent: Wednesday, August 5, 2015 11:42 AM To: Raymond Wan; Scott Aron Bloom Cc: cmake at cmake.org Subject: RE: [CMake] on cmake supporting one arch per project (from CMake IR) "Since CMake is the one generating the project files, it is obvious that it should be the one that is updated to add this support. The current lack of support is not due to any kind of limitation in any of the IDEs, it is purely a limitation of the tool that is generating the project files that already contain all the necessary support for the requested features, and have done so for many years now, since before the last time that the Visual Studio generators had to be rewritten to move from vcproj to vcxproj. The generated project files can already contain multiple configurations (release vs debug), but not multiple platforms." Gilles Khouzam from Microsoft has created an experimental fork, current as of 3.2.1, that adds this support. https://github.com/Microsoft/CMake/tree/feature/MSMultiPlatform Adding experimental MultiPlatform support to CMake for Windows and VS 2012 and above. By setting the CMAKE_VS_EFFECTIVE_PLATFORMS variable, the user is able to specify that multiple platforms should be produced for the same project. The supported platforms are Win32, ARM and x64 (not applicable to Windows Phone) and should be specified as a delimited string Win32;ARM;x64 for example. From gurenchan at gmail.com Wed Aug 5 16:17:34 2015 From: gurenchan at gmail.com (Owen Alanzo Hogarth) Date: Thu, 6 Aug 2015 04:17:34 +0800 Subject: [CMake] passing a list of files from c source code to cmake Message-ID: I know it's possible to send variables into your c source code from the cmake tutorials where you set the version. let's say in your c source code you access some resource files that are located in your source tree under a resources folder. I can put those in some type of array in my c source code. Now is it possible to send that list back to cmake at build time so that it can copy those files to the binary tree on each build? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dank at kegel.com Wed Aug 5 17:08:36 2015 From: dank at kegel.com (Dan Kegel) Date: Wed, 5 Aug 2015 16:08:36 -0500 Subject: [CMake] passing a list of files from c source code to cmake In-Reply-To: References: Message-ID: On Wed, Aug 5, 2015 at 3:17 PM, Owen Alanzo Hogarth wrote: > I can put those in some type of array in my c source code. Now is it > possible to send that list back to cmake at build time so that it can copy > those files to the binary tree on each build? You can write a script that parses the C source file (should be easy if you put the array body in a .h file with no decoration) and pulls it into a CMake list. From dank at kegel.com Wed Aug 5 17:57:42 2015 From: dank at kegel.com (Dan Kegel) Date: Wed, 5 Aug 2015 16:57:42 -0500 Subject: [CMake] passing a list of files from c source code to cmake In-Reply-To: References: Message-ID: I don't think it needs to be a custom command, you just do it inline. See e.g. FILE(STRINGS, ...) http://www.cmake.org/cmake/help/v3.0/command/file.html or FILE(READ, ...) http://www.cmake.org/pipermail/cmake/2007-May/014222.html There are several gotchas related to quoting. Ping the list if you run into trouble. - Dan On Wed, Aug 5, 2015 at 4:27 PM, Owen Alanzo Hogarth wrote: > do you have any example of that? > > Would it be a custom command? I haven't seen anything like this being done > before? > > On Thu, Aug 6, 2015 at 5:08 AM, Dan Kegel wrote: >> >> On Wed, Aug 5, 2015 at 3:17 PM, Owen Alanzo Hogarth >> wrote: >> > I can put those in some type of array in my c source code. Now is it >> > possible to send that list back to cmake at build time so that it can >> > copy >> > those files to the binary tree on each build? >> >> You can write a script that parses the C source file (should be easy if >> you put the array body in a .h file with no decoration) and pulls >> it into a CMake list. > > From d3ck0r at gmail.com Wed Aug 5 19:18:43 2015 From: d3ck0r at gmail.com (J Decker) Date: Wed, 5 Aug 2015 16:18:43 -0700 Subject: [CMake] passing a list of files from c source code to cmake In-Reply-To: References: Message-ID: a combination of the above.. ---- somefile.h "file1", "file2", "file3" ---- somefile.c ... const char *files[] = { #include "somefile.h" }; would be easiest for cmake to parse the .h... I would think... otherwise no; might be easier to maintain the list in the cmake and stuff it into the C using configure_file() On Wed, Aug 5, 2015 at 2:57 PM, Dan Kegel wrote: > I don't think it needs to be a custom command, you just do it inline. > See e.g. > FILE(STRINGS, ...) > http://www.cmake.org/cmake/help/v3.0/command/file.html > or FILE(READ, ...) > http://www.cmake.org/pipermail/cmake/2007-May/014222.html > > There are several gotchas related to quoting. Ping the list if you > run into trouble. > - Dan > > > On Wed, Aug 5, 2015 at 4:27 PM, Owen Alanzo Hogarth > wrote: > > do you have any example of that? > > > > Would it be a custom command? I haven't seen anything like this being > done > > before? > > > > On Thu, Aug 6, 2015 at 5:08 AM, Dan Kegel wrote: > >> > >> On Wed, Aug 5, 2015 at 3:17 PM, Owen Alanzo Hogarth < > gurenchan at gmail.com> > >> wrote: > >> > I can put those in some type of array in my c source code. Now is it > >> > possible to send that list back to cmake at build time so that it can > >> > copy > >> > those files to the binary tree on each build? > >> > >> You can write a script that parses the C source file (should be easy if > >> you put the array body in a .h file with no decoration) and pulls > >> it into a CMake list. > > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From boitoletre at gmail.com Thu Aug 6 04:41:05 2015 From: boitoletre at gmail.com (A D) Date: Thu, 6 Aug 2015 10:41:05 +0200 Subject: [CMake] target_include_directories(): SYSTEM option does not seem to work on recent versions of CMake, when targeting Xcode. Message-ID: Hi, We are moving our codebase from native project file to CMake based management. The process is going well, but we need the Boost dependency to be configured as a system library (to avoid spamming the build log with Boost related warnings). It is our understanding that giving a SYSTEM argument to target_include_directories function should do just that. Yet it does not seem to work as expected. We created a minimal example that reproduces the problem: cmake_minimum_required(VERSION 3.0) find_package(Boost 1.49 COMPONENTS) project(system_dependencies) add_executable(${PROJECT_NAME} main.cpp) target_include_directories(${PROJECT_NAME} SYSTEM PUBLIC ${Boost_INCLUDE_DIRS}) The compiler invocation issued by Xcode contains this Boost header search path: *-I/Users/.../SDK/boost/include* It is not using "-isystem" flag, whereas it is available. Did we misuse the command ? Or should we report this as a bug ? Thank you for reading, ---- The environment: CMake v3.3.0 (previously tested with v3.0.0 for the same results) OS X 10.9.5 Xcode 5.1.1 There is a Stack overflow question opened for this problem: http://stackoverflow.com/q/31722426/1027706 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Thu Aug 6 04:57:27 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 06 Aug 2015 10:57:27 +0200 Subject: [CMake] target_include_directories(): SYSTEM option does not seem to work on recent versions of CMake, when targeting Xcode. In-Reply-To: References: Message-ID: <55C32177.2020100@gmail.com> On 08/06/2015 10:41 AM, A D wrote: > It is not using "-isystem" flag, whereas it is available. > > Did we misuse the command ? Or should we report this as a bug ? > > Thank you for reading, I am not too familiar with XCode myself but Modules/Platform/Darwin.cmake contains # Xcode does not support -isystem yet. if(XCODE) set(CMAKE_INCLUDE_SYSTEM_FLAG_C) set(CMAKE_INCLUDE_SYSTEM_FLAG_CXX) endif() suggesting that even though the compiler might support -isystem, Xcode itself does (or did) not. I can't tell if that is something that may or may not have changed with current Xcode releases. If you have reason to believe it is supported now (e.g. because you are able to create and Xcode project without cmake that has explicit system includes) you may want to open an issue. Nils From yess at hell.org.pl Thu Aug 6 08:13:07 2015 From: yess at hell.org.pl (Tadeusz Andrzej Kadlubowski) Date: Thu, 6 Aug 2015 14:13:07 +0200 Subject: [CMake] ZERO_CHECK hangs for a MS Visual Studio 2010 project on Windows7 Message-ID: <20150806121306.GA12957@hell.org.pl> Hello, I have a piece of C++ and Fortran software that I'm porting to the CMake build system. On my TeamCity continuous integration server I observe a weird behaviour: whenever I modify a CMakeLists.txt in a way that might mean ZERO_CHECK has something to update, building the ZERO_CHECK hangs until it gets killed off by the CI server job scheduler some 6 hours later. The project in question is definitely not big enough to make 6h of ZERO_CHECK sound reasonable. Besides, when I restart the build job after it gets killed, the second build works ok: it completes ZERO_CHECK promptly, and carries on with its regular job of compiling, linking etc.etc. Log sample: [13:23:52][Step 4/4] [13:23:52][Step 4/4] Microsoft (R) Visual Studio Version 10.0.40219.1. [13:23:52][Step 4/4] Copyright (C) Microsoft Corp. All rights reserved. [13:23:52][Step 4/4] 1>------ Build started: Project: ZERO_CHECK, Configuration: RelWithDebInfo x64 ------ [13:23:56][Step 4/4] 1>Build started 31.07.2015 13:23:54. (it looks the same way even when I enable detailed logging in MSBuild) This behavior seems to be 100% reproducible, and doing any trivial `echo "#FOO!" >> CMakeLists.txt` dummy commit is enough to trigger it. The same behavior seems to happen both when I run the build directly from devenv.com and via IncrediBuild distributed build thingy. Has any of you seen a ZERO_CHECK build that hangs in VisualStudio 2010? Any ideas about how and why it might happen? Is there any way to see some verbose logs of what was it that the ZERO_CHECK build wanted to accomplish when it hanged? I tried looking around with procmon, but I'm not very proficient with this tool, and didn't see anything obvious. Hoping to hear from you soon, -- Tadeusz Andrzej Kadlubowski From JamesJ at motionview3d.com Thu Aug 6 12:12:38 2015 From: JamesJ at motionview3d.com (James Johnston) Date: Thu, 6 Aug 2015 16:12:38 -0000 Subject: [CMake] ninja under windows In-Reply-To: <55BFA371.2080607@gmail.com> References: <55BFA371.2080607@gmail.com> Message-ID: <0b8d01d0d062$b7326510$25972f30$@motionview3d.com> > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Gonzalo > Garramu?o > Sent: Monday, August 03, 2015 17:23 > To: cmake at cmake.org > Subject: [CMake] ninja under windows > > I compiled Ninja on cygwin from git. That now works fine it seems. > I am trying to compile for msvc. However, when cmake runs, I get: > I wouldn't even go there... I would recommend: * Do not build anything requiring native Windows build tools from Cygwin - for example, don't call Visual C++ compiler from Cygwin. * Consider not build anything requiring native Windows build tools from MSYS/MSYS2, like Visual C++ compiler, since MSYS/MSYS2 is a fork of Cygwin. (Unless MSYS/MSYS2 maintainers patch Cygwin to resolve the problems, which you'd better research before going there.) It sounds drastic but I can tell you from experience that eventually you'll run into problems and you may be on your own. The big reason I have run into is that Cygwin's handling of stdin/out/err pipes differs from how most Windows programs (i.e. programs based on Visual C++ runtime, or based on .NET Framework) handle the pipes. They do this for POSIX compatibility reasons, I'd guess. And the Cygwin maintainers in the past have shown limited interest in being compatible with non-Cygwin programs. The end result is you end up with things like a basic/simple .NET Framework 4.0 program not working right if called from Cygwin, for example. If you want to forge ahead, I can offer two suggestions that seem to mitigate the problems - today anyway: * Set CYGWIN environment variable to contain pipe_byte. This is very important but I forget the specifics why, other than non-Cygwin programs break if this isn't set. (Search the Cygwin mailing lists for my posts on the issue). * Make a custom build of Cygwin and then set CYGWIN environment variable to contain pipe_nooverlap (a flag I added). This is also very important because if you don't, .NET Framework 4.0 apps and potentially other programs called from Cygwin will break. I submitted a patch to Cygwin maintainers but they rejected it, so you'll have to build Cygwin yourself (and rebuild it every time the maintainers release new Cygwin version). The link to the patch is here: https://cygwin.com/ml/cygwin-patches/2013-q4/msg00020/pipepatch Setting these flags maybe breaks some POSIX compatibility but in practice, I have had zero problems with common Cygwin programs (bash, coreutils). Since proper interaction with non-Cygwin programs now requires you to make a custom build of Cygwin - a big hassle - I suggest don't even go there, and keep Cygwin (and its MSYS/MSYS2) derivatives out of your build system if you require calling native Windows apps (e.g. Visual C++). There are other unrelated considerations if you want a 100% solid build environment, like you should research the (non-)reliability of forking under Cygwin/MSYS/MSYS2. I have to commend the Cygwin developers for making it work in the first place, since Windows provides no forking API. But in the end, to get POSIX working on the Win32 API, I think they are relying on a lot of undocumented Win32 stuff that works in practice but subject to breakage when new versions of Windows come out, etc. > > Is compiling under the microsoft compiler not an option for ninja files ( I can > compile with NMake Makefiles just fine in the same project ). It is and we do it, here is how: 1. Don't build Ninja under Cygwin. IIRC the procedure would be (a) install Python for Windows, (b) go to a Visual C++ command prompt to set up VC++ environment, (c) call Ninja bootstrapper script. 2. Run CMake from a Visual C++ command prompt when you want to use the Ninja generator because Ninja generator will just look for whatever "cl.exe" is in the PATH. At no point does Cygwin enter into the equation. Best regards, James Johnston From JamesJ at motionview3d.com Thu Aug 6 12:58:58 2015 From: JamesJ at motionview3d.com (James Johnston) Date: Thu, 6 Aug 2015 16:58:58 -0000 Subject: [CMake] on cmake supporting one arch per project (from CMake IR) In-Reply-To: References: Message-ID: <0b9a01d0d069$3030ea80$9092bf80$@motionview3d.com> > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Greg Marr > Sent: Wednesday, August 05, 2015 18:42 > To: Raymond Wan; Scott Aron Bloom > Cc: cmake at cmake.org > Subject: Re: [CMake] on cmake supporting one arch per project (from > CMake IR) > > > Gilles Khouzam from Microsoft has created an experimental fork, current as > of 3.2.1, that adds this support. > https://github.com/Microsoft/CMake/tree/feature/MSMultiPlatform > > Adding experimental MultiPlatform support to CMake for Windows and VS > 2012 and above. > > By setting the CMAKE_VS_EFFECTIVE_PLATFORMS variable, the user is able > to specify that multiple platforms should be produced for the same project. > > The supported platforms are Win32, ARM and x64 (not applicable to > Windows Phone) and should be specified as a delimited string > Win32;ARM;x64 for example. I read this and also glanced through the patch (look for commit ID 065bdceb0fbe5253b229faa843fce6b1c271f047 in his repo). It feels a little goofy and too VS-centric to me. How should existing end-user code like this be handled? if(MSVC90 AND NOT CMAKE_CL_64) # set 32-bit VC2008 flags set(CMAKE_CXX_FLAGS ) # snip elseif(MSVC90 AND CMAKE_CL_64) # set some 64-bit VC2008 flags set(CMAKE_CXX_FLAGS ) # snip endif() Well, it seems like you would need platform-specific CXX_FLAGS variables, in addition to the configuration-specific CXX_FLAGS variables already offered. So you'd need a lot new CMake variables for the compiler, linker, etc. Ideally you'd want to figure out how to do this without completely breaking every piece of user code that previously ever touched those variables. While you're at it, you'd want platform-specific variables containing platform-specific paths to each compiler. (e.g. path to 32-bit cl.exe, path to 64-bit cl.exe.) Of course, that opens the door to mixing VC++ and non-VC++ compilers in the same CMake project... Also, the meaning of variables like "MSVC90" or even "CMAKE_CL_64" change: previously CMAKE_CL_64 meant "building for 64-bit" whereas maybe now it means "you may or may not be building for 64-bit" ??? What is CMAKE_CL_64 supposed to do if CMAKE_VS_EFFECTIVE_PLATFORMS is set to Win32;x64? Also, you're still limited to VS generator in his patch, as evidenced by "VS" in "CMAKE_VS_EFFECTIVE_PLATFORMS". I guess that's all fine & well as far as Microsoft's concerned. What if I want to build multi-platforms with the Ninja generator? GNU Make generator? Multi-platforms on Linux? Mac? (Personally I dislike the VS generator / MSBuild on Windows for big builds because the parallelization in MSBuild and cl.exe isn't coordinated, leading to significant over/under-subscription problems that can be avoided with any other generator on Windows.) I'm not making this up, if CMake supported multi-platform building, I would be needing/wanting to specify multiple platforms for the project I'm working on right now: (1) VC++ 32-bit, (2) VC++ 64-bit, (3) GCC cross-compiler, (4) C++ Builder. Some targets would be built for multiple platforms; others would be built for only one of those four platforms. I have annoying requirements that multi-platform could help with like: the cross-compiler requires a custom build step/tool that is built using Visual Studio. Very flexible multi-platform can/should be "easy" for the makefile generators to handle. And the VS generator can handle #1 and #2 fine enough but what if I want it to generate a CMake project containing the GCC/BCC32 targets, for example? How the heck does that work? And what if I want multiple VC++ versions in my platform list - say, VC2008 and VS2013? (After all, I could point to differing versions of cl.exe with my platform-specific COMPILER variables). Again that's something that multi-platform makefile generators can/should handle "easily" but what if the VS generator is asked to generate for VC2008 and VC2013 platforms? Right now the VS generators have it easy - they only have one cl.exe version to contend with (and it's guaranteed to be a cl.exe to begin with). I guess you could have the Ninja/makefile generators happily generate true multi-platform stuff while have the VS generator just croak, but then what if I want to use the VS IDE for my VC++ targets? It would be awesome if CMake could support multi-platform - it could really simplify things for me (as now I am working on a superbuild that iterates through all the above platforms) - but I'd rather see it in a form that is baked into the core of CMake, rather than something VS-specific hacked onto the VS generator that I feel won't interact well with anything non-VS. Best regards, James Johnston From JamesJ at motionview3d.com Thu Aug 6 13:26:07 2015 From: JamesJ at motionview3d.com (James Johnston) Date: Thu, 6 Aug 2015 17:26:07 -0000 Subject: [CMake] Managed C++ / C# Projects: Location of assembly DLL In-Reply-To: References: Message-ID: <0b9b01d0d06c$fb5a2a20$f20e7e60$@motionview3d.com> > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Robert > Dailey > Sent: Wednesday, August 05, 2015 19:02 > To: CMake > Subject: [CMake] Managed C++ / C# Projects: Location of assembly DLL > > I am including external MS projects via CMake for my C# projects. The > Managed C++ projects I generate via CMake directly. However, sharing > assembly references between the two is difficult. > > Sometimes I need my imported C# projects to know where to find the > managed C++ DLL assembly it built. This is in the CMake binary directory, > which might be different on each machine, so I can't exactly setup a relative > path to this file in the C# project references section. > > Likewise with dependencies on C# output from Managed C++. It's a little > easier to tell CMake where to find the output DLL file for a C# project (since > the output location is relative inside the source dir). > > How do you guys recommend solving these dependency issues? Is there a > way I can add an assembly reference to a Managed C++ project via path > through CMake? I also need to use C#. Until CMake has first-class C# support, I hacked together a primitive "csproj" file generator in about a day and a half (excluding the wrong approach I initially took). I also had problems with "how do you deal with references" and "how do you get the C# project to do an out-of-source build?" (I don't want the C# projects touching my source tree, it's not the CMake way.) So initially I investigated calling csc.exe directly as a custom build step but that approach will have two problems: * No IntelliSense support for C# in the IDE because a C++ project is emitted. * More importantly, system references are difficult to resolve. To see what I mean, built a Hello World C# app in Visual Studio and look at the MSBuild invocation to csc.exe. Note they don't specify "/reference:System.Core.dll" on the command line. Instead we end up with a full path to something like "/reference:C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll" - which is a different path from what is used at runtime (GAC path "C:\WINDOWS\assembly\GAC..."). If you Google there are good reasons to link with the reference assembly and not the one installed on your system. Well it turns out that MSBuild has a complicated set of rules for resolving references, they are not well documented, and they are found in your Microsoft.Common.targets file (search for AssemblySearchPaths to see the list of 9 locations it checks). These rules are different and lengthier than the ones used by csc.exe if an absolute path is not provided. So here's my suggestion: 1. Generate a csproj file on-the-fly from a template and put it into your binary dir, given a list of source files, target name, references, etc. That solves the out-of-source build problem. Make a reusable CMake function(s) for adding C# targets which handles the steps here. 2. Use either include_external_msproject if using a VS generator, or create a custom command/target to directly invoke MSBuild if using a non-VS generator. 3. For references, if you will be using include_external_msproject (as opposed to custom target), and the reference is not an imported target, you will want to generate a project reference. Else, generate a regular reference directly to the file for the configuration. 4. You can use file(GENERATE) to make configuration-specific files that list the references for each configuration. These can then be 'ed into the main csproj file. This lets you use generator expressions if you need to when determining the path for your reference. 5. If generating a project reference to a C++ project, you can use $/../ref.vc(x)proj to get to the project file. If the project reference is to another C# project you can use the undocumented EXTERNAL_MSPROJECT target property. If it's a non-project reference then you have to provide a which can be done with $ for C++ references and a custom property you'll have to maintain for C# project references. 6. Don't forget to call CMake add_dependencies() as well. Best regards, James Johnston From lectem at gmail.com Thu Aug 6 16:54:47 2015 From: lectem at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Gregoire?=) Date: Thu, 6 Aug 2015 22:54:47 +0200 Subject: [CMake] Modules FindXXX.cmake for toolchains under windows Message-ID: Hi, I have some experience with cmake toolchain files, and wanted to try it under windows. Everything works fine (find_library, path etc) except find_package. I added a custom FindCTRULIB.cmake file in my folder D:/devkitPro/devkitArm and this folder is listed in my CMAKE_FIND_ROOT_PATH, printing its value gives this : d:/devkitPro/devkitARM;d:/devkitPro I also tried to put it in D:/devkitPro/devkitArm/cmake and D:/devkitPro/devkitArm/share/cmake but it doesn't work. Did I misunderstand the find_package documentation ? I know that I could use CMAKE_MODULE_PATH, but I think this one should only be used by the projects, not for scripts that are shipped with other libraries. Thanks, Lectem -------------- next part -------------- An HTML attachment was scrubbed... URL: From dank at kegel.com Thu Aug 6 17:48:46 2015 From: dank at kegel.com (Dan Kegel) Date: Thu, 6 Aug 2015 16:48:46 -0500 Subject: [CMake] ninja under windows In-Reply-To: <0b8d01d0d062$b7326510$25972f30$@motionview3d.com> References: <55BFA371.2080607@gmail.com> <0b8d01d0d062$b7326510$25972f30$@motionview3d.com> Message-ID: I've been using cygwin buildbot for some time, doing pure windows builds. The trick is to have the cygwin buildslave unset a few environment variables (like cygwin's PATH and TEMP and temp), then run a windows batch file to do everything involving compilers, e.g. running windows cmake. There is a tiny bit of magic involved in cleansing the environment enough for the windows tools to be happy, but not much. But I agree: for cmake and things like ninja that run compilers, use pure windows versions, even if you kick them off originally from a cygwin shell script. - Dan From boitoletre at gmail.com Fri Aug 7 04:14:37 2015 From: boitoletre at gmail.com (A D) Date: Fri, 7 Aug 2015 10:14:37 +0200 Subject: [CMake] target_include_directories(): SYSTEM option does not seem to work on recent versions of CMake, when targeting Xcode. In-Reply-To: References: <55C32177.2020100@gmail.com> <55C45ECD.7060203@gmail.com> Message-ID: Opened issue 15687 for this problem: http://www.cmake.org/Bug/view.php?id=15687 Thank again for your help Nils. (ps: sorry, just realize now that I forgot to forward other answers to the list... Pasting the content below) 2015-08-07 9:27 GMT+02:00 A D : > 2015-08-06 10:57 GMT+02:00 Nils Gladitz : > >> suggesting that even though the compiler might support -isystem, Xcode >> itself does (or did) not. I can't tell if that is something that may or may >> not have changed with current Xcode releases. >> > > Xcode has been calling Clang behind the scene (I think it was a custom > Apple GCC before). There is an Xcode setting for "header search path", > which is a list of 'non-system' headers. Even if there is not a separate > Xcode settings for "system headers", there is a setting for the cpp flags > that are directly forwarded to the compiler: in practice, this allows to > achieve everything that would be possible by invoking Clang directly. In > particular, if I take the path from "header search path" setting, and put > it as "-isystem ${path_value}" in the "Other C++ flags" setting, I obtain > the expected result. > > If you have reason to believe it is supported now (e.g. because you are >> able to create and Xcode project without cmake that has explicit system >> includes) you may want to open an issue. >> > > Thank you for this suggestion, I will report the issue referring to this > exchange. > > Best regards, > 2015-08-07 9:55 GMT+02:00 A D : > > 2015-08-07 9:31 GMT+02:00 Nils Gladitz : > >> One issue you might want to look for when passing the flag directly to >> the compiler without allowing IDE interpretation might be that the internal >> code model used by Xcode for e.g. auto-completion might then not know about >> it. > > > That is a good point indeed. So I just tried, and both the linter and > auto-completion seem to make no difference with regard to how the header > path is provided to the project (they kept working in the same way): > * The linter stopped 'underlining' the boost include as soon as I gave the > '-isystem ' to the C++ flags > * Adding a new library to this '-isystem' flag, auto-completion was aware > of its symbols as soon as I included its headers in a compilation units. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From josch at debian.org Fri Aug 7 05:08:08 2015 From: josch at debian.org (Johannes Schauer) Date: Fri, 07 Aug 2015 11:08:08 +0200 Subject: [CMake] emulating cmake-gui behaviour with cmake commandline on windows Message-ID: <20150807090808.16465.89378@localhost> Hi, I am trying to build the CMake project 3dtk with the following CMakeLists.txt: https://sourceforge.net/p/slam6d/code/HEAD/tree/trunk/CMakeLists.txt This works well on linux with ccmake and also on windows with cmake-gui. Now I'm trying to let it work on windows with the cmake command line program to automate the configuration. Unfortunately I'm running into a problem with cmake on windows that I did not encounter with cmake-gui. The CMakeLists.txt file at several occasions uses the add_subdirectory directive but always without the second argument (the build_dir). This seems to work fine for cmake-gui on windows and ccmake on linux. But with cmake on windows I now get the following message for every add_subdirectory directive: CMake Error at Z:/CMakeLists.txt:471 (add_subdirectory): add_subdirectory not given a binary directory but the given source directory "Z:/src/slam6d" is not a subdirectory of "Z:/". When specifying an out-of-tree source a binary directory must be explicitly specified. This error message is also strange because clearly, "Z:/src/slam6d" is a subdirectory of "Z:/". I would like to know the command line option that I have to supply to cmake on windows to get the same behaviour as with cmake-gui on windows. In my case, the source is in Z:/ and in cmake-gui I specify "Z:/lib64-msvc-12.0" as the value of "Where to build the binaries" and as explained above this works completely well. But after successfully configuring and generating the project in "Z:/lib64-msvc-12.0" using the cmake-gui method, when I cd into "Z:/lib64-msvc-12.0" and just run "cmake .." I get the error messages above. Same happens when I create a new directory "Z:/cmaketest", cd into it and then run "cmake ..", I again get the errors above. So in summary, with or without an existing CMakeCache.txt, I'm running into the error messages above on windows when using cmake (and not cmake-gui). So I suspect that I'm missing an option to cmake to make it behave like cmake-gui. I don't think my CMakeLists.txt is the culprit because that one works totally fine on linux and also works well with cmake-gui. What could the problem be? Thanks! cheers, josch -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: signature URL: From DLRdave at aol.com Fri Aug 7 12:27:40 2015 From: DLRdave at aol.com (David Cole) Date: Fri, 7 Aug 2015 12:27:40 -0400 Subject: [CMake] emulating cmake-gui behaviour with cmake commandline on windows In-Reply-To: <20150807090808.16465.89378@localhost> References: <20150807090808.16465.89378@localhost> Message-ID: Put your source in a sub-directory. CMake simply does not work at the root of a drive letter on Windows. CMakeLists.txt MUST be in at least one sub-directory underneath a root drive letter path. HTH, David C. On Fri, Aug 7, 2015 at 5:08 AM, Johannes Schauer wrote: > Hi, > > I am trying to build the CMake project 3dtk with the following CMakeLists.txt: > https://sourceforge.net/p/slam6d/code/HEAD/tree/trunk/CMakeLists.txt > > This works well on linux with ccmake and also on windows with cmake-gui. > > Now I'm trying to let it work on windows with the cmake command line program to > automate the configuration. Unfortunately I'm running into a problem with cmake > on windows that I did not encounter with cmake-gui. > > The CMakeLists.txt file at several occasions uses the add_subdirectory > directive but always without the second argument (the build_dir). This seems to > work fine for cmake-gui on windows and ccmake on linux. But with cmake on > windows I now get the following message for every add_subdirectory directive: > > CMake Error at Z:/CMakeLists.txt:471 (add_subdirectory): > add_subdirectory not given a binary directory but the given source > directory "Z:/src/slam6d" is not a subdirectory of "Z:/". When specifying > an out-of-tree source a binary directory must be explicitly specified. > > This error message is also strange because clearly, "Z:/src/slam6d" is a > subdirectory of "Z:/". > > I would like to know the command line option that I have to supply to cmake on > windows to get the same behaviour as with cmake-gui on windows. > > In my case, the source is in Z:/ and in cmake-gui I specify > "Z:/lib64-msvc-12.0" as the value of "Where to build the binaries" and as > explained above this works completely well. > > But after successfully configuring and generating the project in > "Z:/lib64-msvc-12.0" using the cmake-gui method, when I cd into > "Z:/lib64-msvc-12.0" and just run "cmake .." I get the error messages above. > > Same happens when I create a new directory "Z:/cmaketest", cd into it and then > run "cmake ..", I again get the errors above. > > So in summary, with or without an existing CMakeCache.txt, I'm running into the > error messages above on windows when using cmake (and not cmake-gui). So I > suspect that I'm missing an option to cmake to make it behave like cmake-gui. > > I don't think my CMakeLists.txt is the culprit because that one works totally > fine on linux and also works well with cmake-gui. > > What could the problem be? > > Thanks! > > cheers, josch > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From josch at debian.org Fri Aug 7 12:37:40 2015 From: josch at debian.org (Johannes Schauer) Date: Fri, 07 Aug 2015 18:37:40 +0200 Subject: [CMake] emulating cmake-gui behaviour with cmake commandline on windows In-Reply-To: References: <20150807090808.16465.89378@localhost> Message-ID: <20150807163740.16465.23278@localhost> Hi, Quoting David Cole (2015-08-07 18:27:40) > Put your source in a sub-directory. CMake simply does not work at the > root of a drive letter on Windows. CMakeLists.txt MUST be in at least > one sub-directory underneath a root drive letter path. oh wow that was a simple fix. Thanks for the quick reply! Is this documented anywhere? Maybe there could be a warning somewhere if one attempts to have the source directory directly at the root of a drive letter on windows? But then why does it work with cmake-gui on windows? Is this a bug that can be fixed? Thanks! cheers, josch -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: signature URL: From DLRdave at aol.com Fri Aug 7 12:47:14 2015 From: DLRdave at aol.com (David Cole) Date: Fri, 7 Aug 2015 12:47:14 -0400 Subject: [CMake] emulating cmake-gui behaviour with cmake commandline on windows In-Reply-To: <20150807163740.16465.23278@localhost> References: <20150807090808.16465.89378@localhost> <20150807163740.16465.23278@localhost> Message-ID: It's in the bug database here: http://www.cmake.org/Bug/view.php?id=15134 Not sure how easy it would be to fix... Also, this CLOSED bug is in there (and some related issues): http://www.cmake.org/Bug/view.php?id=10072 D On Fri, Aug 7, 2015 at 12:37 PM, Johannes Schauer wrote: > Hi, > > Quoting David Cole (2015-08-07 18:27:40) >> Put your source in a sub-directory. CMake simply does not work at the >> root of a drive letter on Windows. CMakeLists.txt MUST be in at least >> one sub-directory underneath a root drive letter path. > > oh wow that was a simple fix. Thanks for the quick reply! > > Is this documented anywhere? > > Maybe there could be a warning somewhere if one attempts to have the source > directory directly at the root of a drive letter on windows? > > But then why does it work with cmake-gui on windows? > > Is this a bug that can be fixed? > > Thanks! > > cheers, josch From petr.kmoch at gmail.com Mon Aug 10 09:51:18 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Mon, 10 Aug 2015 15:51:18 +0200 Subject: [CMake] Possible to dynamically construct macro/function names to invoke? In-Reply-To: References: Message-ID: Hi, Eric. On Mon, Jul 20, 2015 at 12:52 AM, Eric Wing wrote: > I would like to dynamically construct a macro or function name to > invoke. I basically have a core CMake system I want users to be able > to extend/plug stuff into without knowing about a lot of the core > CMake implementation. Callback functions would be an easy way for me > to accomplish this. > > As an example, > > # In my core code, I have a macro designed to callback other macros > macro(DO_PACKAGE _TARGET_NAME) > foreach(callback ${DO_PACKAGE_CALLBACK_LIST}) > DO_PACKAGE_FOR_${callback}(${_TARGET_NAME}) > endforeach() > endmacro(BLURRR_PACKAGE_EXTRAS) > > > ### Also in my core code, I pick an appropriate time to trigger my > macro to call user callbacks > DERIVE_SOME_NAME() > ADD_EXECUTABLE(${SOME_NAME} ...) > DO_PACKAGE(${SOME_NAME}) > > > > # So in user modules provided by others, they follow a convention where > # they define a macro DO_PACKAGE_ appended by their module name. > macro(DO_PACKAGE_FOR_MYMODULE _TARGET_NAME) > MESSAGE("in mymod callback") > # do stuff > endmacro() > > # And I make them add their module name to a global list so I can call > it back at the right time > list(APPEND DO_PACKAGE_CALLBACK_LIST "MYMODULE") > > > So in my attempts to do this, I'm getting errors like: > Parse error. Expected a command name, got unquoted argument with text > > Is there way to do this (or something similar)? > > Thanks, > Eric > We had need for something similar in our system, and the best we could come up with was to write the dynamically-named function invocation into a file and include() it. Something like this: foreach(callback ${DO_PACKAGE_CALLBACK_LIST}) file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/invocation.${callback}.cmake "DO_PACKAGE_FOR_${callback}(${_TARGET_NAME})\n") include(${CMAKE_CURRENT_BINARY_DIR}/invocation.${callback}.cmake) endforeach() It feels hacky (and would probably scale poorly for performance reasons), but it gets the job done. Petr -------------- next part -------------- An HTML attachment was scrubbed... URL: From dank at kegel.com Mon Aug 10 18:51:19 2015 From: dank at kegel.com (Dan Kegel) Date: Mon, 10 Aug 2015 15:51:19 -0700 Subject: [CMake] Does SET_TARGET_PROPERTIES(foo PROPERTIES INSTALL_RPATH /path1; /path2) still silently ignore path2? Message-ID: With cmake 2.8.12.2, SET_TARGET_PROPERTIES (foo PROPERTIES INSTALL_RPATH ${my_install_rpath}) silently only obeys the first directory in the rpath, but SET_TARGET_PROPERTIES (foo PROPERTIES INSTALL_RPATH "${my_install_rpath}") works.? Is it still that way in the latest cmake, and is there already a bug for this? I looked, but didn't see one. From nilsgladitz at gmail.com Tue Aug 11 02:42:56 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 11 Aug 2015 08:42:56 +0200 Subject: [CMake] Does SET_TARGET_PROPERTIES(foo PROPERTIES INSTALL_RPATH /path1; /path2) still silently ignore path2? In-Reply-To: References: Message-ID: <55C99970.1000400@gmail.com> On 08/11/2015 12:51 AM, Dan Kegel wrote: > With cmake 2.8.12.2, > > SET_TARGET_PROPERTIES (foo PROPERTIES INSTALL_RPATH ${my_install_rpath}) > > silently only obeys the first directory in the rpath, but > > SET_TARGET_PROPERTIES (foo PROPERTIES INSTALL_RPATH "${my_install_rpath}") > > works.? Is it still that way in the latest cmake, and is there > already a bug for this? I looked, > but didn't see one. It should still be this way. The command takes any number of key value pairs where each key and value are a single argument. A CMake list when expanded unquoted results in one argument per list item. When a list is quoted it is a single argument. Expansion of variables happens before the command itself gets its arguments. Without the quotes the first item in my_install_rpath will be interpreted as a value while the second will be a key etc. It might therefor be more of a language rather than command specific issue. One clean alternative is to use set_property() instead since unlike set_target_properties() it takes a single key but any number of value arguments. Nils From laasunde at hotmail.com Tue Aug 11 03:05:14 2015 From: laasunde at hotmail.com (Lars) Date: Tue, 11 Aug 2015 09:05:14 +0200 Subject: [CMake] Install targets and component Message-ID: Hello, The following cmake script appears to work but the target is associated with "Unspecified" group according to cmake_install.cmake file. INSTALL( TARGETS MyLib RUNTIME DESTINATION "${BIN_PATH}" LIBRARY DESTINATION "${LIB_PATH}" COMPONENT COMP_APP) By removing the following section the target is associated with COMP_APP as expected. LIBRARY DESTINATION "${LIB_PATH}" We are now using CMake 3.3. This worked great with CMake 2.8.12. Any ideas? kind regards, Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Tue Aug 11 03:41:22 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 11 Aug 2015 09:41:22 +0200 Subject: [CMake] Install targets and component In-Reply-To: References: Message-ID: <55C9A722.8020503@gmail.com> On 08/11/2015 09:05 AM, Lars wrote: > Hello, > > The following cmake script appears to work but the target is associated > with "Unspecified" group according to cmake_install.cmake file. > INSTALL( > TARGETS MyLib > RUNTIME DESTINATION "${BIN_PATH}" > LIBRARY DESTINATION "${LIB_PATH}" > COMPONENT COMP_APP) > > By removing the following section the target is associated with COMP_APP > as expected. > LIBRARY DESTINATION "${LIB_PATH}" > > We are now using CMake 3.3. This worked great with CMake 2.8.12. The behavior should be the same in 2.8.12 and 3.3. Like DESTINATION the COMPONENT option is scoped by the RUNTIME, LIBRARY, ARCHIVE etc. keywords. The last of those in your call is LIBRARY hence the COMPONENT will apply only to "LIBRARY" files installed by this command. If you want COMPONENT to apply to all kinds of installed target files list it before any of the scoping options e.g. install( TARGETS MyLib COMPONENT COMP_APP RUNTIME DESTINATION "${BIN_PATH}" LIBRARY DESTINATION "${LIB_PATH}" ) or repeat it for each scope: install( TARGETS MyLib RUNTIME DESTINATION "${BIN_PATH}" COMPONENT COMP_APP LIBRARY DESTINATION "${LIB_PATH}" COMPONENT COMP_APP ) Nils From laasunde at hotmail.com Tue Aug 11 04:51:29 2015 From: laasunde at hotmail.com (Lars) Date: Tue, 11 Aug 2015 10:51:29 +0200 Subject: [CMake] Install targets and component In-Reply-To: <55C9A722.8020503@gmail.com> References: , <55C9A722.8020503@gmail.com> Message-ID: Thank you Nils, that solved the issue. Cannot believe I missed that in the documentation. Regards, Lars > Date: Tue, 11 Aug 2015 09:41:22 +0200 > From: nilsgladitz at gmail.com > To: laasunde at hotmail.com; cmake at cmake.org > Subject: Re: [CMake] Install targets and component > > On 08/11/2015 09:05 AM, Lars wrote: > > Hello, > > > > The following cmake script appears to work but the target is associated > > with "Unspecified" group according to cmake_install.cmake file. > > INSTALL( > > TARGETS MyLib > > RUNTIME DESTINATION "${BIN_PATH}" > > LIBRARY DESTINATION "${LIB_PATH}" > > COMPONENT COMP_APP) > > > > By removing the following section the target is associated with COMP_APP > > as expected. > > LIBRARY DESTINATION "${LIB_PATH}" > > > > We are now using CMake 3.3. This worked great with CMake 2.8.12. > > The behavior should be the same in 2.8.12 and 3.3. > > Like DESTINATION the COMPONENT option is scoped by the RUNTIME, LIBRARY, > ARCHIVE etc. keywords. > > The last of those in your call is LIBRARY hence the COMPONENT will apply > only to "LIBRARY" files installed by this command. > > If you want COMPONENT to apply to all kinds of installed target files > list it before any of the scoping options e.g. > > install( > TARGETS MyLib > COMPONENT COMP_APP > RUNTIME DESTINATION "${BIN_PATH}" > LIBRARY DESTINATION "${LIB_PATH}" > ) > > or repeat it for each scope: > > install( > TARGETS MyLib > > RUNTIME > DESTINATION "${BIN_PATH}" > COMPONENT COMP_APP > LIBRARY > DESTINATION "${LIB_PATH}" > COMPONENT COMP_APP > ) > > Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From dank at kegel.com Tue Aug 11 09:23:41 2015 From: dank at kegel.com (Dan Kegel) Date: Tue, 11 Aug 2015 06:23:41 -0700 Subject: [CMake] Does SET_TARGET_PROPERTIES(foo PROPERTIES INSTALL_RPATH /path1; /path2) still silently ignore path2? In-Reply-To: <55C99970.1000400@gmail.com> References: <55C99970.1000400@gmail.com> Message-ID: Thanks. Should set_target_properties throw an error if given too many arguments, to catch this problem? Am 10.08.2015 11:43 nachm. schrieb "Nils Gladitz" : > On 08/11/2015 12:51 AM, Dan Kegel wrote: > >> With cmake 2.8.12.2, >> >> SET_TARGET_PROPERTIES (foo PROPERTIES INSTALL_RPATH ${my_install_rpath}) >> >> silently only obeys the first directory in the rpath, but >> >> SET_TARGET_PROPERTIES (foo PROPERTIES INSTALL_RPATH "${my_install_rpath}") >> >> works.? Is it still that way in the latest cmake, and is there >> already a bug for this? I looked, >> but didn't see one. >> > > It should still be this way. > > The command takes any number of key value pairs where each key and value > are a single argument. > > A CMake list when expanded unquoted results in one argument per list item. > > When a list is quoted it is a single argument. > > Expansion of variables happens before the command itself gets its > arguments. > > Without the quotes the first item in my_install_rpath will be interpreted > as a value while the second will be a key etc. > > It might therefor be more of a language rather than command specific issue. > > One clean alternative is to use set_property() instead since unlike > set_target_properties() it takes a single key but any number of value > arguments. > > Nils > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Tue Aug 11 09:52:04 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 11 Aug 2015 15:52:04 +0200 Subject: [CMake] Does SET_TARGET_PROPERTIES(foo PROPERTIES INSTALL_RPATH /path1; /path2) still silently ignore path2? In-Reply-To: References: <55C99970.1000400@gmail.com> Message-ID: <55C9FE04.1000004@gmail.com> On 08/11/2015 03:23 PM, Dan Kegel wrote: > Thanks. Should set_target_properties throw an error if given too many > arguments, to catch this problem? There is no limit to the number of key value pairs set_target_properties() can process and it already diagnoses when there is a key without a value. Nils From DLRdave at aol.com Tue Aug 11 09:57:50 2015 From: DLRdave at aol.com (David Cole) Date: Tue, 11 Aug 2015 09:57:50 -0400 Subject: [CMake] Does SET_TARGET_PROPERTIES(foo PROPERTIES INSTALL_RPATH /path1; /path2) still silently ignore path2? In-Reply-To: References: <55C99970.1000400@gmail.com> Message-ID: The final args to set_target_properties are any number of name/value pairs: http://www.cmake.org/cmake/help/v3.3/command/set_target_properties.html The only thing we could do there is look for an even number of args, and catch possible problems half the time... I'm not sure if there are any restrictions on property names, but for this command, and its historical args composition, we are stuck with "prop1 value1 prop2 value2 ..." as the final args. Having said all that, there are some checks on the args to the function, so it looks like you got "unlucky" with the number of paths in the prop value. I would advise against playing roulette for a while... ;-) https://github.com/Kitware/CMake/blob/422d3f68/Source/cmSetTargetPropertiesCommand.cxx#L36-L40 HTH, David C. On Tuesday, August 11, 2015, Dan Kegel wrote: > Thanks. Should set_target_properties throw an error if given too many > arguments, to catch this problem? > Am 10.08.2015 11:43 nachm. schrieb "Nils Gladitz" >: > >> On 08/11/2015 12:51 AM, Dan Kegel wrote: >> >>> With cmake 2.8.12.2, >>> >>> SET_TARGET_PROPERTIES (foo PROPERTIES INSTALL_RPATH ${my_install_rpath}) >>> >>> silently only obeys the first directory in the rpath, but >>> >>> SET_TARGET_PROPERTIES (foo PROPERTIES INSTALL_RPATH >>> "${my_install_rpath}") >>> >>> works.? Is it still that way in the latest cmake, and is there >>> already a bug for this? I looked, >>> but didn't see one. >>> >> >> It should still be this way. >> >> The command takes any number of key value pairs where each key and value >> are a single argument. >> >> A CMake list when expanded unquoted results in one argument per list item. >> >> When a list is quoted it is a single argument. >> >> Expansion of variables happens before the command itself gets its >> arguments. >> >> Without the quotes the first item in my_install_rpath will be interpreted >> as a value while the second will be a key etc. >> >> It might therefor be more of a language rather than command specific >> issue. >> >> One clean alternative is to use set_property() instead since unlike >> set_target_properties() it takes a single key but any number of value >> arguments. >> >> Nils >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dank at kegel.com Tue Aug 11 11:28:21 2015 From: dank at kegel.com (Dan Kegel) Date: Tue, 11 Aug 2015 08:28:21 -0700 Subject: [CMake] Does SET_TARGET_PROPERTIES(foo PROPERTIES INSTALL_RPATH /path1; /path2) still silently ignore path2? In-Reply-To: References: <55C99970.1000400@gmail.com> Message-ID: Aha. Well, how about sanity checks on the names of the properties? Maybe a new policy could be added that property names have to be declared (and the ones supported by cmake itself would be predeclared, of course), and setting an undeclared one would throw an error. On Tue, Aug 11, 2015 at 6:57 AM, David Cole wrote: > The final args to set_target_properties are any number of name/value pairs: > > http://www.cmake.org/cmake/help/v3.3/command/set_target_properties.html > > The only thing we could do there is look for an even number of args, and > catch possible problems half the time... I'm not sure if there are any > restrictions on property names, but for this command, and its historical > args composition, we are stuck with "prop1 value1 prop2 value2 ..." as the > final args. > > Having said all that, there are some checks on the args to the function, so > it looks like you got "unlucky" with the number of paths in the prop value. > I would advise against playing roulette for a while... ;-) > > https://github.com/Kitware/CMake/blob/422d3f68/Source/cmSetTargetPropertiesCommand.cxx#L36-L40 > > > HTH, > David C. > > > On Tuesday, August 11, 2015, Dan Kegel wrote: >> >> Thanks. Should set_target_properties throw an error if given too many >> arguments, to catch this problem? >> >> Am 10.08.2015 11:43 nachm. schrieb "Nils Gladitz" : >>> >>> On 08/11/2015 12:51 AM, Dan Kegel wrote: >>>> >>>> With cmake 2.8.12.2, >>>> >>>> SET_TARGET_PROPERTIES (foo PROPERTIES INSTALL_RPATH ${my_install_rpath}) >>>> >>>> silently only obeys the first directory in the rpath, but >>>> >>>> SET_TARGET_PROPERTIES (foo PROPERTIES INSTALL_RPATH >>>> "${my_install_rpath}") >>>> >>>> works.? Is it still that way in the latest cmake, and is there >>>> already a bug for this? I looked, >>>> but didn't see one. >>> >>> >>> It should still be this way. >>> >>> The command takes any number of key value pairs where each key and value >>> are a single argument. >>> >>> A CMake list when expanded unquoted results in one argument per list >>> item. >>> >>> When a list is quoted it is a single argument. >>> >>> Expansion of variables happens before the command itself gets its >>> arguments. >>> >>> Without the quotes the first item in my_install_rpath will be interpreted >>> as a value while the second will be a key etc. >>> >>> It might therefor be more of a language rather than command specific >>> issue. >>> >>> One clean alternative is to use set_property() instead since unlike >>> set_target_properties() it takes a single key but any number of value >>> arguments. >>> >>> Nils From DLRdave at aol.com Tue Aug 11 12:06:42 2015 From: DLRdave at aol.com (David Cole) Date: Tue, 11 Aug 2015 12:06:42 -0400 Subject: [CMake] Does SET_TARGET_PROPERTIES(foo PROPERTIES INSTALL_RPATH /path1; /path2) still silently ignore path2? In-Reply-To: References: <55C99970.1000400@gmail.com> Message-ID: A totally reasonable suggestion. Patches welcome. ;-) On Tuesday, August 11, 2015, Dan Kegel wrote: > Aha. Well, how about sanity checks on the names of the properties? > Maybe a new policy could be added that property names have to be > declared (and the ones supported by cmake itself would be predeclared, > of course), and setting an undeclared one would throw an error. > > On Tue, Aug 11, 2015 at 6:57 AM, David Cole > wrote: > > The final args to set_target_properties are any number of name/value > pairs: > > > > http://www.cmake.org/cmake/help/v3.3/command/set_target_properties.html > > > > The only thing we could do there is look for an even number of args, and > > catch possible problems half the time... I'm not sure if there are any > > restrictions on property names, but for this command, and its historical > > args composition, we are stuck with "prop1 value1 prop2 value2 ..." as > the > > final args. > > > > Having said all that, there are some checks on the args to the function, > so > > it looks like you got "unlucky" with the number of paths in the prop > value. > > I would advise against playing roulette for a while... ;-) > > > > > https://github.com/Kitware/CMake/blob/422d3f68/Source/cmSetTargetPropertiesCommand.cxx#L36-L40 > > > > > > HTH, > > David C. > > > > > > On Tuesday, August 11, 2015, Dan Kegel > > wrote: > >> > >> Thanks. Should set_target_properties throw an error if given too many > >> arguments, to catch this problem? > >> > >> Am 10.08.2015 11:43 nachm. schrieb "Nils Gladitz" < > nilsgladitz at gmail.com >: > >>> > >>> On 08/11/2015 12:51 AM, Dan Kegel wrote: > >>>> > >>>> With cmake 2.8.12.2, > >>>> > >>>> SET_TARGET_PROPERTIES (foo PROPERTIES INSTALL_RPATH > ${my_install_rpath}) > >>>> > >>>> silently only obeys the first directory in the rpath, but > >>>> > >>>> SET_TARGET_PROPERTIES (foo PROPERTIES INSTALL_RPATH > >>>> "${my_install_rpath}") > >>>> > >>>> works.? Is it still that way in the latest cmake, and is there > >>>> already a bug for this? I looked, > >>>> but didn't see one. > >>> > >>> > >>> It should still be this way. > >>> > >>> The command takes any number of key value pairs where each key and > value > >>> are a single argument. > >>> > >>> A CMake list when expanded unquoted results in one argument per list > >>> item. > >>> > >>> When a list is quoted it is a single argument. > >>> > >>> Expansion of variables happens before the command itself gets its > >>> arguments. > >>> > >>> Without the quotes the first item in my_install_rpath will be > interpreted > >>> as a value while the second will be a key etc. > >>> > >>> It might therefor be more of a language rather than command specific > >>> issue. > >>> > >>> One clean alternative is to use set_property() instead since unlike > >>> set_target_properties() it takes a single key but any number of value > >>> arguments. > >>> > >>> Nils > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gilles.Khouzam at microsoft.com Wed Aug 12 12:36:08 2015 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Wed, 12 Aug 2015 16:36:08 +0000 Subject: [CMake] on cmake supporting one arch per project (from CMake IR) In-Reply-To: <0b9a01d0d069$3030ea80$9092bf80$@motionview3d.com> References: <0b9a01d0d069$3030ea80$9092bf80$@motionview3d.com> Message-ID: Yes, this change was done specifically to support VS and does not address some of the hard issues that arise from multiplatform support. This is why we're keeping it in our fork and are not pushing too hard to get it integrated into the official product. It does make it easier for people that want to produce multiple architectures but don't necessarily have different settings for each. The latest change has been updated to CMake 3.3.0 with Windows 10 support: https://github.com/microsoft/cmake/tree/feature/Win10MultiPlatform -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of James Johnston Sent: Thursday, August 6, 2015 09:59 To: cmake at cmake.org Subject: Re: [CMake] on cmake supporting one arch per project (from CMake IR) > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Greg Marr > Sent: Wednesday, August 05, 2015 18:42 > To: Raymond Wan; Scott Aron Bloom > Cc: cmake at cmake.org > Subject: Re: [CMake] on cmake supporting one arch per project (from > CMake IR) > > > Gilles Khouzam from Microsoft has created an experimental fork, > current as of 3.2.1, that adds this support. > https://github.com/Microsoft/CMake/tree/feature/MSMultiPlatform > > Adding experimental MultiPlatform support to CMake for Windows and VS > 2012 and above. > > By setting the CMAKE_VS_EFFECTIVE_PLATFORMS variable, the user is able > to specify that multiple platforms should be produced for the same project. > > The supported platforms are Win32, ARM and x64 (not applicable to > Windows Phone) and should be specified as a delimited string > Win32;ARM;x64 for example. I read this and also glanced through the patch (look for commit ID 065bdceb0fbe5253b229faa843fce6b1c271f047 in his repo). It feels a little goofy and too VS-centric to me. How should existing end-user code like this be handled? if(MSVC90 AND NOT CMAKE_CL_64) # set 32-bit VC2008 flags set(CMAKE_CXX_FLAGS ) # snip elseif(MSVC90 AND CMAKE_CL_64) # set some 64-bit VC2008 flags set(CMAKE_CXX_FLAGS ) # snip endif() Well, it seems like you would need platform-specific CXX_FLAGS variables, in addition to the configuration-specific CXX_FLAGS variables already offered. So you'd need a lot new CMake variables for the compiler, linker, etc. Ideally you'd want to figure out how to do this without completely breaking every piece of user code that previously ever touched those variables. While you're at it, you'd want platform-specific variables containing platform-specific paths to each compiler. (e.g. path to 32-bit cl.exe, path to 64-bit cl.exe.) Of course, that opens the door to mixing VC++ and non-VC++ compilers in the same CMake project... Also, the meaning of variables like "MSVC90" or even "CMAKE_CL_64" change: previously CMAKE_CL_64 meant "building for 64-bit" whereas maybe now it means "you may or may not be building for 64-bit" ??? What is CMAKE_CL_64 supposed to do if CMAKE_VS_EFFECTIVE_PLATFORMS is set to Win32;x64? Also, you're still limited to VS generator in his patch, as evidenced by "VS" in "CMAKE_VS_EFFECTIVE_PLATFORMS". I guess that's all fine & well as far as Microsoft's concerned. What if I want to build multi-platforms with the Ninja generator? GNU Make generator? Multi-platforms on Linux? Mac? (Personally I dislike the VS generator / MSBuild on Windows for big builds because the parallelization in MSBuild and cl.exe isn't coordinated, leading to significant over/under-subscription problems that can be avoided with any other generator on Windows.) I'm not making this up, if CMake supported multi-platform building, I would be needing/wanting to specify multiple platforms for the project I'm working on right now: (1) VC++ 32-bit, (2) VC++ 64-bit, (3) GCC cross-compiler, (4) C++ Builder. Some targets would be built for multiple platforms; others would be built for only one of those four platforms. I have annoying requirements that multi-platform could help with like: the cross-compiler requires a custom build step/tool that is built using Visual Studio. Very flexible multi-platform can/should be "easy" for the makefile generators to handle. And the VS generator can handle #1 and #2 fine enough but what if I want it to generate a CMake project containing the GCC/BCC32 targets, for example? How the heck does that work? And what if I want multiple VC++ versions in my platform list - say, VC2008 and VS2013? (After all, I could point to differing versions of cl.exe with my platform-specific COMPILER variables). Again that's something that multi-platform makefile generators can/should handle "easily" but what if the VS generator is asked to generate for VC2008 and VC2013 platforms? Right now the VS generators have it easy - they only have one cl.exe version to contend with (and it's guaranteed to be a cl.exe to begin with). I guess you could have the Ninja/makefile generators happily generate true multi-platform stuff while have the VS generator just croak, but then what if I want to use the VS IDE for my VC++ targets? It would be awesome if CMake could support multi-platform - it could really simplify things for me (as now I am working on a superbuild that iterates through all the above platforms) - but I'd rather see it in a form that is baked into the core of CMake, rather than something VS-specific hacked onto the VS generator that I feel won't interact well with anything non-VS. Best regards, James Johnston -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake From gurenchan at gmail.com Thu Aug 13 12:57:35 2015 From: gurenchan at gmail.com (Owen Alanzo Hogarth) Date: Fri, 14 Aug 2015 00:57:35 +0800 Subject: [CMake] setting up a library with cmake Message-ID: I initially setup a project like this: PROJECT/ .../build/ .../cmake_modules/ .../resources/ .../source/ <-- subfolders under sources are shared libs .../source/components/ .../source/core_math/ .../source/ren_opengl/ .../source/utils/ .../source/main.c <-- main() and imported all the shared libs this setup worked great now I wanted to add another layer to this project I want to add a top level folder that would contain the project PROJECT/ .../build/ .../cmake_modules/ *.../project/ <-- want to move main here* .../project/game.c .../project/game.h .../resources/ .../source/ <-- subfolders under sources are shared libs .../source/components/ .../source/core_math/ .../source/ren_opengl/ .../source/utils/ .../source/main.c <-- main() and imported all the shared libs I want to move the main application starter from under the sources folder to it's own folder under the project sub folder and be able to just import say main_libs.h which would in turn bring all the functions that I described in the sources/ part of the tree. How can I accomplish this with cmake? This is what the main.c cmakelists file looks like atm. This is the cmakelists.txt that starts the whole build down through all the dynamic libs. Each dynamic lib folder just has a .h .c and maybe some simple header includes. CMAKE_MINIMUM_REQUIRED(VERSION 2.8) PROJECT(main) set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib) set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib) set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin) set(CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/cmake_modules) FIND_PACKAGE(SDL2 REQUIRED) INCLUDE_DIRECTORIES(${SDL2_INCLUDE_DIR}) INCLUDE_DIRECTORIES("${PROJECT_SOURCE_DIR}/source/core_math") INCLUDE_DIRECTORIES("${PROJECT_SOURCE_DIR}/source/utils/time_utils") INCLUDE_DIRECTORIES("${PROJECT_SOURCE_DIR}/source/utils/resource_utils") INCLUDE_DIRECTORIES("${PROJECT_SOURCE_DIR}/source/ren_opengl") INCLUDE_DIRECTORIES("${PROJECT_SOURCE_DIR}/source/components/renderable2d") INCLUDE_DIRECTORIES("${PROJECT_SOURCE_DIR}/source/glm/vec3.hpp") FIND_PACKAGE(SDL2 REQUIRED) INCLUDE_DIRECTORIES(${SDL2_INCLUDE_DIR}) REQUIRED_VARS SDL2_IMAGE_LIBRARY SDL2_IMAGE_INCLUDE_DIR) FIND_PACKAGE(SDL2_IMAGE) INCLUDE_DIRECTORIES(${SDL2_IMAGE_INCLUDE_DIR}) ADD_SUBDIRECTORY(source) ADD_SUBDIRECTORY(project) //my attempt to add the new directory SET(SRC_FILES main.c) SET(EXTERNAL_TARGET_LIBS ${SDL2_LIBRARY} ${SDL2_IMAGE_LIBRARY}) SET(COMPONENTS renderable2d) SET(INTERNAL_TARGET_LIBS core_math time_utils resource_utils ren_opengl) SET(TARGET_LIBS ${INTERNAL_TARGET_LIBS} ${EXTERNAL_TARGET_LIBS} ${COMPONENTS}) ADD_EXECUTABLE(blulauncher ${SRC_FILES}) TARGET_LINK_LIBRARIES(blulauncher ${TARGET_LIBS}) FILE(COPY ${CMAKE_CURRENT_SOURCE_DIR}/resources/ DESTINATION ${CMAKE_CURRENT_BINARY_DIR}/bin/resources/) -------------- next part -------------- An HTML attachment was scrubbed... URL: From nils.guillermin at gmail.com Thu Aug 13 14:15:18 2015 From: nils.guillermin at gmail.com (Nils Guillermin) Date: Thu, 13 Aug 2015 14:15:18 -0400 Subject: [CMake] Where does link.txt come from? Message-ID: I am using an outside tool that uses cmake (the tool is rosmake, from the Robot Operating System). The problem is it is generating a link.txt file that has multiples instances of arguments that look like -l:/usr/lib/libopencv_blahblahblah.dylib Asked on stackoverflow and confirmed what I expected, that those arguments should look like -L/usr/lib/libopencv_blahblah or -lopencv_blahblah I was wondering where would I find the file responsible for creating link.txt? I am trying to parse all these Makefile2's and CMakeFiles/*.make files and getting confused. Thanks, Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From sonyablade2010 at hotmail.com Thu Aug 13 14:19:05 2015 From: sonyablade2010 at hotmail.com (Sonya Blade) Date: Thu, 13 Aug 2015 19:19:05 +0100 Subject: [CMake] CMake Error at build/modules/add_boost.cmake:156 (message): Message-ID: Dear All, I'm attempting to build the open license manager from that location .https://github.com/open-license-manager As can be seen, there is not much info what needs to be done to configure and compile it, I'm not even sure that it is been configured to work with GCC 4.7.1 and Code Blocks. Anyway if attempt to run the configuration with CMake-GUI then I receive the following error, AFAIU this library requires the boost library and Cmake-GUI downloads the boost automatically but at th middle of configuration throws the following error how am I supposed further procedd on that? CMake Error at build/modules/add_boost.cmake:156 (message): Failed running ./bootstrap.sh;--with-toolset=gcc: Call Stack (most recent call first): CMakeLists.txt:73 (add_boost) Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas-Naumann at gmx.net Thu Aug 13 15:18:58 2015 From: Andreas-Naumann at gmx.net (Andreas Naumann) Date: Thu, 13 Aug 2015 21:18:58 +0200 Subject: [CMake] CMake Error at build/modules/add_boost.cmake:156 (message): In-Reply-To: References: Message-ID: <55CCEDA2.3010704@gmx.net> Hey, at the first sight, it seems to me an error in their build system. But the error message is surrounded by an if-clause. Your error message does not show any error or output, so I assume, there was no error with bootstrap, but the (executable? file?) b2 was not found. To test it, you could print the result of the find_program call in their file add_boost.cmake just after the line 154. Good luck, Andreas Am 13.08.2015 um 20:19 schrieb Sonya Blade: > Dear All, > > I'm attempting to build the open license manager from that location > .https://github.com/open-license-manager > As can be seen, there is not much info what needs to be done to > configure and compile it, I'm not even sure that > it is been configured to work with GCC 4.7.1 and Code Blocks. > > Anyway if attempt to run the configuration with CMake-GUI then I > receive the following error, > AFAIU this library requires the boost library and Cmake-GUI downloads > the boost automatically > but at th middle of configuration throws the following error how am I > supposed further procedd on that? > > CMake Error at build/modules/add_boost.cmake:156 (message): > Failed running ./bootstrap.sh;--with-toolset=gcc: > > Call Stack (most recent call first): > CMakeLists.txt:73 (add_boost) > > Regards, > > From robert.maynard at kitware.com Thu Aug 13 16:04:33 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 13 Aug 2015 16:04:33 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.3.1 available for download Message-ID: We are pleased to announce that CMake 3.3.1 is now available for download. Please use the latest release from our download page: http://www.cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.3.1 since 3.3.0: Ben Boeckel (1): ctest: fix add_subdirectory() crash Brad King (3): add_subdirectory: Fix error message on missing CMakeLists.txt (#15680) Fortran: Store detected compiler version persistently (#15684) CMake 3.3.1 Gregor Jasny (1): Xcode: Quote strings containing a tilde (#15672) From parag at ionicsecurity.com Thu Aug 13 21:15:43 2015 From: parag at ionicsecurity.com (Parag Chandra) Date: Fri, 14 Aug 2015 01:15:43 +0000 Subject: [CMake] Generating Windows 10 universal project? Message-ID: <2C821CA5-CD99-4A6E-B802-9B9E23534B5E@ionicsecurity.com> Hi, I?m trying to generate a static library project that targets the Windows 10 Universal App platform. I found the following post on SO: http://stackoverflow.com/questions/31857315/how-can-i-use-cmake-to-generate-windows-10-universal-project However, specifying -DCMAKE_SYSTEM_VERSION=10.0 (or none at all), yields the following error: CMake Error at CMakeLists.txt:5 (project): Visual Studio 14 2015 supports Windows Store '8.0' and '8.1', but not '10.0'. Check CMAKE_SYSTEM_VERSION. Is this supported yet? Thanks, Parag Chandra Senior Software Engineer, Mobile Team Mobile: +1.919.824.1410 [https://www.ionicsecurity.com/IonicSigHz.png] Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sonyablade2010 at hotmail.com Fri Aug 14 00:46:12 2015 From: sonyablade2010 at hotmail.com (Sonya Blade) Date: Fri, 14 Aug 2015 05:46:12 +0100 Subject: [CMake] CMake Error at build/modules/add_boost.cmake:156 (message): Message-ID: Hi Andreas, Where do you see all of this, I couldn't even make out single meaningfu sentence out of it.The only thing that I can understand is that bootstrap cmake file is executed but bootstrap.shfile is failing. I don't even understand from where and how boost has dependency on bootstrap. Cmake GUI downloaded the boost, does that mean that I have downloaded also the bootstrapautomatically? At the attachment you can find the fulll error log during that execution, Your further enlightement will be appriciated , Regards, >Hey, >at the first sight, it seems to me an error in their build system. >But the error message is surrounded by an if-clause. Your error message >does not show any error or output, so I assume, there was no error with >bootstrap, but the (executable? file?) b2 was not found. >To test it, you could print the result of the find_program call in their >file add_boost.cmake just after the line 154. >>Good luck, >Andreas > Dear All, > > I'm attempting to build the open license manager from that location > .https://github.com/open-license-manager> As can be seen, there is not much info what needs to be done to > configure and compile it, I'm not even sure that > it is been configured to work with GCC 4.7.1 and Code Blocks. > > Anyway if attempt to run the configuration with CMake-GUI then I > receive the following error, > AFAIU this library requires the boost library and Cmake-GUI downloads > the boost automatically > but at th middle of configuration throws the following error how am I > supposed further procedd on that? > > CMake Error at build/modules/add_boost.cmake:156 (message): > Failed running ./bootstrap.sh;--with-toolset=gcc: > > Call Stack (most recent call first): > CMakeLists.txt:73 (add_boost) > > Regards, > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: CMakeOutput.log URL: From rwan.work at gmail.com Fri Aug 14 00:55:48 2015 From: rwan.work at gmail.com (Raymond Wan) Date: Fri, 14 Aug 2015 12:55:48 +0800 Subject: [CMake] CMake Error at build/modules/add_boost.cmake:156 (message): In-Reply-To: References: Message-ID: Hi Sonya, On Fri, Aug 14, 2015 at 12:46 PM, Sonya Blade wrote: > Where do you see all of this, I couldn't even make out single meaningfu > sentence out of it. > The only thing that I can understand is that bootstrap cmake file is > executed but bootstrap.sh > file is failing. I don't even understand from where and how boost has > dependency on bootstrap. > Cmake GUI downloaded the boost, does that mean that I have downloaded also > the bootstrap > automatically? At the attachment you can find the fulll error log during > that execution, I don't know the program you are trying to compile, but bootstrap.sh is how Boost compiles itself. i.e., it is included in the Boost distribution. See: http://www.boost.org/doc/libs/1_55_0/more/getting_started/windows.html#simplified-build-from-source Without looking at the CMake module myself, I guess it has gone off and downloaded Boost, unpacked it, and is trying to compile it using the bootstrap.sh / bootstrap.bat command and is failing. Sounds like a problem with the developers of the program and how they made the CMake module? You could probably look at the lines in the modules, according to the error message. I'm not sure if it's just a problem of the formatting of the error message, but this looked funny to me: > Failed running ./bootstrap.sh;--with-toolset=gcc: --with-toolset=gcc is an argument to the bootstrap.sh script. Why is there a semi-colon between them? But maybe this is nothing... Ray From Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de Fri Aug 14 10:06:33 2015 From: Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de (Mueller-Roemer, Johannes Sebastian) Date: Fri, 14 Aug 2015 14:06:33 +0000 Subject: [CMake] Function to get a list of all (recursively) linked libraries? Message-ID: <8D981219EEA621479C112DA9BDC39A8E348A2BDD@EXMBS1.ad.igd.fraunhofer.de> Is there any simple method of acquiring a list of (absolute paths, generator expressions for debug/release are ok) all libraries linked to an executable or shared target? The LINK_LIBRARIES property contains targets and aliased targets and makes creating such a list quite complicated, but CMake must internally be able to create such a list for linking. -- Johannes S. Mueller-Roemer, MSc Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD Fraunhoferstr. 5 | 64283 Darmstadt | Germany Tel +49 6151 155-606 | Fax +49 6151 155-139 johannes.mueller-roemer at igd.fraunhofer.de | www.igd.fraunhofer.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gilles.Khouzam at microsoft.com Fri Aug 14 13:29:31 2015 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Fri, 14 Aug 2015 17:29:31 +0000 Subject: [CMake] Generating Windows 10 universal project? In-Reply-To: <2C821CA5-CD99-4A6E-B802-9B9E23534B5E@ionicsecurity.com> References: <2C821CA5-CD99-4A6E-B802-9B9E23534B5E@ionicsecurity.com> Message-ID: Hi Parag, Please use our fork for Windows 10 universal support. I?m working on getting the patch ready to be integrated in the official code. https://github.com/Microsoft/CMake. The branch is feature/Win10 Thanks. ~Gilles From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Parag Chandra Sent: Thursday, August 13, 2015 18:16 To: David Cole via CMake Subject: [CMake] Generating Windows 10 universal project? Hi, I?m trying to generate a static library project that targets the Windows 10 Universal App platform. I found the following post on SO: http://stackoverflow.com/questions/31857315/how-can-i-use-cmake-to-generate-windows-10-universal-project However, specifying -DCMAKE_SYSTEM_VERSION=10.0 (or none at all), yields the following error: CMake Error at CMakeLists.txt:5 (project): Visual Studio 14 2015 supports Windows Store '8.0' and '8.1', but not '10.0'. Check CMAKE_SYSTEM_VERSION. Is this supported yet? Thanks, Parag Chandra Senior Software Engineer, Mobile Team Mobile: +1.919.824.1410 [https://www.ionicsecurity.com/IonicSigHz.png] Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wonder.mice at gmail.com Fri Aug 14 17:49:45 2015 From: wonder.mice at gmail.com (Andrey Pokrovskiy) Date: Fri, 14 Aug 2015 14:49:45 -0700 Subject: [CMake] Best practices question: Organizing a library project Message-ID: Hi, What is best way to organize a library project that uses CMake as its build system? One advantage that I would expect from a library project with CMake build system is easy integration with another projects that also use CMake. In other words it should be very simple to include (add a dependency on) such a library in any CMake based project. However, more often than not, it's impossible to use library's provided CMakeLists.txt without some modifications or without dreaded ExternalProject_Add() invocation. So, I want to collect some best practices on creating such library projects. Bellow is my experience/observation about that. I consider ExternalProject_Add() as a last resort when everything else fails. It's clumsy to write and maintain and also it will not add library source code to the generated IDE project (like Qt Creator). Also forwarding toolchain settings and other options (like build type, etc.) into ExternalProject is a pain. Using library's main CMakeLists.txt is _often_ not a good option either. Many of those will add tons of cache variables (options, settings) that are not relevant for the main project. Also they add many unnecessary targets (which also can have the same name as targets in the main project, like "tags", "docs", etc). Also the common problem is that they don't provide an easy way to control library's dependencies. For example, library depends on OpenSSL, but I build OpenSSL as part of my main project and want library to use it. Yes, if it uses FindOpenSSL() than it's possible to fool FindOpenSSL() that OpenSSL was already found by tampering with OPENSSL_FOUND and other OPENSSL_XXX variables, but looks more like a hack to me. Choosing shared/static version of a library could also be a pain, especially when you need both. >From my personal experience, the most practical scheme is when library has two CMakeLists.txt files. One is for building the library as a standalone project and another for inclusion with add_subdirectory(). Obviously, the first includes the second (with add_subdirectory) for DRYness. That way the first script has cache option definitions, manages all the tests, docs and other things that are of no interest to the projects that depend on that library. The second one only builds the library, providing minimal set of targets. A small example to illustrate what I'm talking about: https://github.com/wonder-mice/zf_log This approach is not perfect in many ways, but was good enough in my experiments. From avi.a.tevet at intel.com Fri Aug 14 19:54:29 2015 From: avi.a.tevet at intel.com (Tevet, Avi A) Date: Fri, 14 Aug 2015 23:54:29 +0000 Subject: [CMake] ExternalProject git clone hangs on windows Message-ID: Hi all, I've developed some source code in an SVN repo, with dependencies on a few git repos. My cmake build uses the ExternalProject_add module to manage the git dependencies. I developed everything (code, cmake files) on linux, but I decided to use cmake because I knew that I would be cross-compiling the code to target various Intel processors. I'm able to easily compile natively and cross-compile on linux, with the cmake-generated makefiles cloning/building/updating/installing when required. Now I would also like to build this code on Windows 8.1 in VS2015. I'm able to configure and generate the VS2015 solution/projects using CMake 3.2.3 without any cmake failures, however, VS2015 hangs when cloning the git repos. The destination directories are created, but they are empty, and the build just doesn't progress past the "Cloning into XYZ..." message. I've got git-gui and git-bash installed from git-scm.com (1.9.5). I don't know if this is related, but when I look inside the generated VS projects for the dependencies, I see the "CMake Rules" directory full of *.rule files, but they are all effectively empty, containing just the text "# generated from CMake". Can someone please tell me what I need to do so that I can use VS2015 to build a project with git dependencies managed through ExternalProject_add? Thanks, Avi -------------- next part -------------- An HTML attachment was scrubbed... URL: From sonyablade2010 at hotmail.com Fri Aug 14 22:12:13 2015 From: sonyablade2010 at hotmail.com (Sonya Blade) Date: Sat, 15 Aug 2015 03:12:13 +0100 Subject: [CMake] =?cp1256?q?CMake_Error_at_build/modules/add=5Fboost=2Ecma?= =?cp1256?b?a2U6MTU2IChtZXNzYWdlKTr+?= Message-ID: Hi Raymond Wan-2 Thank you in advance, your guess is correct Cmake module downloaded the boost and tried to compile it.Much more interestingly, it has extracted the current compiler suit on my machine (GCC 4.7.1) and downloaded the appropriate boost version "boost_1_55_0_GNU_4_7_1" then it get stuck with previously stated message in CMake-GUI. At the end of it since there is not error reporting on open-license-manager Cmake module side of does that mean that this discrepancy is on boost side ? I hardly believe that it is on boost side because boost is more stable toolkit and is tested with numerous volunteers over the years. I'm not that much of configurator lover but one way or the other I face with it very ferociously especeially with open source libraries.And for this library I also desire ardently to compile and testify its functionality. I checked the bootsrap.sh there is nothing abnormal which caught my eye, there is variable named TOOLSET which holds the Intel, gcc, sun etc.. and uses it for some code execution, but still doesn't explain your catch about semi column at the middle, so I'm surprised as well. I really will appreciate your guidance and enlightement, I attach the CMakeLists.txt and bootsrap.sh, I'm sure that trained eye will cath the malfunctioning immediately, can you simply point out at which direction I'm supposed to head forward? P.S. Is there a method to debug those type of scripts during execution? Regards, I don't know the program you are trying to compile, but bootstrap.sh is how Boost compiles itself. i.e., it is included in the Boost distribution. See: http://www.boost.org/doc/libs/1_55_0/more/getting_started/windows.html#simplified-build-from-source Without looking at the CMake module myself, I guess it has gone off and downloaded Boost, unpacked it, and is trying to compile it using the bootstrap.sh / bootstrap.bat command and is failing. Sounds like a problem with the developers of the program and how they made the CMake module? You could probably look at the lines in the modules, according to the error message. I'm not sure if it's just a problem of the formatting of the error message, but this looked funny to me: > Failed running ./bootstrap.sh;--with-toolset=gcc: --with-toolset=gcc is an argument to the bootstrap.sh script. Why is there a semi-colon between them? But maybe this is nothing... Ray -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: CMakeLists.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bootstrap.sh Type: application/x-sh Size: 10324 bytes Desc: not available URL: From sergey.nikulov at gmail.com Sat Aug 15 02:05:37 2015 From: sergey.nikulov at gmail.com (Sergei Nikulov) Date: Sat, 15 Aug 2015 09:05:37 +0300 Subject: [CMake] ExternalProject git clone hangs on windows In-Reply-To: References: Message-ID: 15 ???. 2015 ?. 3:04 AM ???????????? "Tevet, Avi A" ???????: > > Hi all, > > > Can someone please tell me what I need to do so that I can use VS2015 to build a project with git dependencies managed through ExternalProject_add? > Try clone git project using url from ExternalPoject_add. Possible git will request something interactively - like add ssh key of remote host or request password. If so, this was a reason for hang. As solution - add host keys permanently or change url to https/local clone scheme. If password used on ssh key - remove it if possible. HTH, > > Thanks, > > > > Avi > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwan.work at gmail.com Sat Aug 15 03:35:15 2015 From: rwan.work at gmail.com (Raymond Wan) Date: Sat, 15 Aug 2015 15:35:15 +0800 Subject: [CMake] =?utf-8?q?CMake_Error_at_build/modules/add=5Fboost=2Ecmak?= =?utf-8?b?ZToxNTYgKG1lc3NhZ2UpOuKAjw==?= In-Reply-To: References: Message-ID: Hi Sonya, On Sat, Aug 15, 2015 at 10:12 AM, Sonya Blade wrote: > Thank you in advance, your guess is correct Cmake module downloaded the > boost and tried to compile it. > Much more interestingly, it has extracted the current compiler suit on my > machine (GCC 4.7.1) and downloaded > the appropriate boost version "boost_1_55_0_GNU_4_7_1" then it get stuck > with previously stated message in CMake-GUI. I suppose there are a few things you could try. One is try using CMake on the command-line. Clone the repository and from another directory, run "cmake ". I just tried and this is what I got: ... -- Downloading boost 1.55.0 to /tmp/test/build -- Extracting boost 1.55.0 to /tmp/test/build/boost_unzip -- Building b2 (bjam) -- Boost linking: libs static , C++ runtime shared -- Building date_time: ./b2;link=static;threading=multi;runtime-link=shared;--build-dir=Build;stage;-d+2;--hash;variant=release;cxxflags=-fPIC;cxxflags=-std=c++11;-sNO_BZIP2=1;--layout=tagged;toolset=gcc-4.9 -- Building test: ./b2;link=static;threading=multi;runtime-link=shared;--build-dir=Build;stage;-d+2;--hash;variant=release;cxxflags=-fPIC;cxxflags=-std=c++11;-sNO_BZIP2=1;--layout=tagged;toolset=gcc-4.9 -- Building program_options: ./b2;link=static;threading=multi;runtime-link=shared;--build-dir=Build;stage;-d+2;--hash;variant=release;cxxflags=-fPIC;cxxflags=-std=c++11;-sNO_BZIP2=1;--layout=tagged;toolset=gcc-4.9 -- Building system: ./b2;link=static;threading=multi;runtime-link=shared;--build-dir=Build;stage;-d+2;--hash;variant=release;cxxflags=-fPIC;cxxflags=-std=c++11;-sNO_BZIP2=1;--layout=tagged;toolset=gcc-4.9 -- Building filesystem: ./b2;link=static;threading=multi;runtime-link=shared;--build-dir=Build;stage;-d+2;--hash;variant=release;cxxflags=-fPIC;cxxflags=-std=c++11;-sNO_BZIP2=1;--layout=tagged;toolset=gcc-4.9 -- Boost version: 1.55.0 -- Found the following Boost libraries: -- date_time -- unit_test_framework -- program_options -- system -- filesystem ... So, at least you can see how far it got (I've never used CMake-GUI before, but I presume such verbose information is being hidden?). > At the end of it since there is not error reporting on open-license-manager > Cmake module side of does that mean > that this discrepancy is on boost side ? I hardly believe that it is on > boost side because boost is more stable toolkit > and is tested with numerous volunteers over the years. No, that isn't what my previous message implied. Boost is probably fine; I've installed 1.55 before with no problems. Though that doesn't mean it must work on every possible configuration, I guess it is less likely that is the problem. One possible problem is that your version of GCC is too old. It is 4.7.1? That seems to be a June 2012 release [https://gcc.gnu.org/gcc-4.7/]. Boost 1.55 is from November 2013 [http://www.boost.org/users/history/version_1_55_0.html]. Close enough? Possibly, but I've had problems with Boost before with a slightly older compiler. As you can tell from the output above, I got past where you were by using GCC 4.9 . > the Intel, gcc, sun etc.. and uses it for some > code execution, but still doesn't explain your catch about semi column at > the middle, so I'm surprised as well. Seems I was barking up the wrong tree. I got past where you are without changing the CMakeLists.txt (NB: Where you're stuck isn't the file you sent but build/modules/add_boost.cmake, line 156). > CMakeLists.txt and bootsrap.sh, I'm sure that trained eye > will cath the malfunctioning immediately, can you simply point out at which > direction I'm supposed to head forward? > > P.S. Is there a method to debug those type of scripts during execution? Again, I don't think the problem is with bootstrap.sh . That's part of Boost and everyone who installs Boost must run it. I'd be a bit surprise if you caught something that no one else had. I think the problem is with add_boost.cmake in the software you're trying to install. And the problem might not be with that file per se, but with the compiling step and that *maybe* it is failing with an older compiler. You can add MESSAGE () lines [see the CMake documentation] within add_boost.cmake to make sure various values are set correctly. But, a more fruitful direction might be to go into the directory where Boost was downloaded and unzipped and then try to compile it using Boost's installation instructions (see its web site). Whether you succeed or fail, you'll probably have a better idea of what (i.e., the program you're trying to install, its CMakeLists.txt, or Boost) you should be looking at. Hope this helps and good luck! Ray From rcdailey.lists at gmail.com Sun Aug 16 09:32:08 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Sun, 16 Aug 2015 08:32:08 -0500 Subject: [CMake] How to depend on external cmake projects? Message-ID: There are certain repositories on Github I'd like to pull in as a dependency. These repositories already use CMake to build their source code. Based on personal experience and reading material online, there are a couple of different options: 1. Pull down the repository as a submodule to my own git repository. Then call add_subdirectory() on it to make it part of the build, allowing me to refer to those targets as dependencies in my own targets. 2. Use ExternalProject_Add(). This seems like legacy, I'm not sure if I should use this. It also seems very verbose and boilerplate. 3. Use packages. The [CMake package documentation][1] does not go into great detail on support for both installed versions and build tree for a single package. Does this require two scripts? Can it share a single one? Where are the examples? How do I accomplish this? [1]: http://www.cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html#creating-a-package-configuration-file-for-the-build-tree From audiofanatic at gmail.com Sun Aug 16 17:56:14 2015 From: audiofanatic at gmail.com (Craig Scott) Date: Mon, 17 Aug 2015 07:56:14 +1000 Subject: [CMake] How to depend on external cmake projects? Message-ID: > ---------- Forwarded message ---------- > From: Robert Dailey > To: CMake > Cc: > Date: Sun, 16 Aug 2015 08:32:08 -0500 > Subject: [CMake] How to depend on external cmake projects? > > There are certain repositories on Github I'd like to pull in as a > dependency. These repositories already use CMake to build their source > code. Based on personal experience and reading material online, there > are a couple of different options: > In addition to the options you listed (omitted here), since the projects you want to pull in are CMake-based, another choice is to simply add them to your project directly via add_subdirectory(). This can be convenient for linking against the 3rd party libraries, etc. since CMake will already know about the 3rd party targets and CMake will also build them with the same settings as the rest of your build. If you want, you can use ExternalProject to download the source code at configure time, a technique I recently mentioned on this list. You can find the article about that approach (with Google Test as the example) here: http://crascit.com/2015/07/25/cmake-gtest/ -- Craig Scott Melbourne, Australia http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From digitalriptide at gmail.com Sun Aug 16 19:01:41 2015 From: digitalriptide at gmail.com (digitalriptide) Date: Sun, 16 Aug 2015 16:01:41 -0700 Subject: [CMake] target_include_directories SYSTEM adds -isystem to Clang, but not GCC Message-ID: Dear CMake Community, When I add SYSTEM to target_include_directories, for example using target_include_directories( my_target SYSTEM PUBLIC ${MY_LIBRARIES} ) in Clang, CMake prepends -isystem to the relavent -I/my/library/path type flags. With GCC, however, I see no -isystem added. For reference, this is CMake 3.2.3 on OS X with Apple LLVM version 6.0 and GCC 5 provided via MacPorts. Should SYSTEM add -isystem with GCC? Thank you for any tips! -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Mon Aug 17 04:04:59 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Mon, 17 Aug 2015 10:04:59 +0200 Subject: [CMake] ExternalProject git clone hangs on windows In-Reply-To: References: Message-ID: Hi Avi. On Sat, Aug 15, 2015 at 1:54 AM, Tevet, Avi A wrote: > Hi all, > > > [...] > > > > I don?t know if this is related, but when I look inside the generated VS > projects for the dependencies, I see the ?CMake Rules? directory full of > *.rule files, but they are all effectively empty, containing just the text ?# > generated from CMake?. > Just to address this bit: that's correct. The rule file's contents are irrelevant, it just has to exist as a file. CMake attaches "custom build rules" to this file in the VS project, and these rules are stored in the vc[x]proj. Petr -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Mon Aug 17 08:51:14 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 17 Aug 2015 07:51:14 -0500 Subject: [CMake] Crawling documentation to find named argument keywords Message-ID: I've attached a python script I'm using to obtain a list of keywords across all CMake commands that I can use. Can someone let me know if this is a reliable way to craw the help documentation to find these keywords? Note that the keywords I'm referring to are things like APPEND in the list() command, or PUBLIC and PRIVATE in the target_link_libraries() command. Each command has a set of all-upper-case keywords it uses to separate out arguments. I want a list of these keywords for all commands in one big list. I'm doing this to support syntax highlighting in a text editor. To use the script, first pipe out CMake's help to a file like this: $ cmake --help-full > help.txt Then run it through the python script attached: $ python-3.4 strip-options.py help.txt This should output to console the list of keywords. I feel like a lot are missing. I also got a lot of false positives. Can anyone suggest a better way to isolate true argument keywords in the help text? -------------- next part -------------- # This script requires Python 3.x import re import sys matched_words = [] help_file = sys.argv[1] with open(help_file, 'r') as f: for line in f: if line.startswith(' ') or line.startswith('\t'): for match in re.finditer('[^\w\d]([A-Z]+)(?=[^\w\d])', line): matched_words.append(match.group(1)) for word in set(matched_words): if len(word) > 1: print(word) From mike.jackson at bluequartz.net Mon Aug 17 09:15:18 2015 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Mon, 17 Aug 2015 09:15:18 -0400 Subject: [CMake] Crawling documentation to find named argument keywords In-Reply-To: References: Message-ID: I thought there used to be a DocBook version of the documentation? At one point I had an XML parser that used that as input to process the documentation in the same way. Mike Jackson On Aug 17, 2015, at 8:51 AM, Robert Dailey wrote: > I've attached a python script I'm using to obtain a list of keywords > across all CMake commands that I can use. Can someone let me know if > this is a reliable way to craw the help documentation to find these > keywords? > > Note that the keywords I'm referring to are things like APPEND in the > list() command, or PUBLIC and PRIVATE in the target_link_libraries() > command. Each command has a set of all-upper-case keywords it uses to > separate out arguments. I want a list of these keywords for all > commands in one big list. > > I'm doing this to support syntax highlighting in a text editor. > > To use the script, first pipe out CMake's help to a file like this: > > $ cmake --help-full > help.txt > > Then run it through the python script attached: > > $ python-3.4 strip-options.py help.txt > > This should output to console the list of keywords. I feel like a lot > are missing. I also got a lot of false positives. Can anyone suggest a > better way to isolate true argument keywords in the help text? > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From taylor at braun-jones.org Mon Aug 17 10:43:46 2015 From: taylor at braun-jones.org (Taylor Braun-Jones) Date: Mon, 17 Aug 2015 10:43:46 -0400 Subject: [CMake] Modern superbuild template including support for module dependencies Message-ID: Hi all, I'm looking for a template or example project that shows the how to setup a cmake-based project in the cleanest and simplest way (i.e. using all the latest features of 3.3 release) and with support for the following build features: - Superbuild mode that can be turned on or off (on by default) - Simple system for defining modules (libraries that get built either as static or dynamic libraries) and their dependencies. - install target that works with good default behaviors so that the CMakeLists.txt for modules and applications need minimal extra configuration. Should work in both superbuild mode (the project and all external projects get installed to the same CMAKE_INSTALL_PREFIX/DESTDIR when invoked at the top superbuild level) and in non-superbuild mode I've seen many examples of projects like this but my impression is that they have been around since long before the latest CMake releases and therefore weren't designed to take advantage of all the latest CMake features. My current attempt to setup a cmake-based build with these features is based on the MITK cmake build system[1] since it's something I was already familiar with. I have something that mostly works, but the number of lines of cmake code to make it all happen with simple interfaces like mitk_create_module, mitk_create_executable seems more than should be necessary which is going to make switching to CMake harder for me to "sell" to my team. I found this very simplistic CMake project example[2] but the resulting CMakeLists.txt to build an executable in that project looks like this: find_package (Threads REQUIRED) set (Boost_USE_STATIC_LIBS ON) # set (Boost_NO_SYSTEM_PATHS ON) find_package (Boost 1.55.0 REQUIRED COMPONENTS date_time filesystem system) include_directories (${Boost_INCLUDE_DIRS}) add_executable (blah main.cpp) target_link_libraries (blah ${Boost_LIBRARIES} ${CMAKE_THREAD_LIBS_INIT}) Whereas I'm looking for something that would allow me to write something like this: xxx_add_executable(blah PACKAGE_DEPENDS Boost DEPENDS mymodule main.cpp) (or some other similarly simple interface) Thanks in advance, Taylor [1] https://github.com/MITK/MITK [2] https://github.com/Sarcasm/cmake-superbuild From JamesJ at motionview3d.com Mon Aug 17 11:17:29 2015 From: JamesJ at motionview3d.com (James Johnston) Date: Mon, 17 Aug 2015 15:17:29 -0000 Subject: [CMake] How to depend on external cmake projects? In-Reply-To: References: Message-ID: <12d201d0d8ff$d58e3070$80aa9150$@motionview3d.com> > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Robert > Dailey > Sent: Sunday, August 16, 2015 13:32 > To: CMake > Subject: [CMake] How to depend on external cmake projects? > > There are certain repositories on Github I'd like to pull in as a dependency. > These repositories already use CMake to build their source code. Based on > personal experience and reading material online, there are a couple of > different options: > > 1. Pull down the repository as a submodule to my own git repository. > Then call add_subdirectory() on it to make it part of the build, allowing me to > refer to those targets as dependencies in my own targets. That's one way to do it. It might be a good way if the dependency is relatively small. Benefits: * Simpler/flattened build process (no hierarchy of makefiles are generated) * No need to delete timestamp files generated by ExternalProject_Add if you need to incrementally build the project. Problems: * Everything must be built with same compiler, generator, build settings, etc. (benefit for some projects, a problem for others). * The dependency must use CMake. * Potential for interference between CMake variables/properties set by your top-level project and your included submodule. ExternalProject_Add is guaranteed to work because this can't happen, but add_subdirectory is not guaranteed to work. * Incrementally building a bunch of these projects, or a big project, could be slow (e.g. your make tool has to check if the files in the submodule changed, in addition to your own. ExternalProject_Add sidesteps this with the timestamps). > > 2. Use ExternalProject_Add(). This seems like legacy, I'm not sure if I should > use this. It also seems very verbose and boilerplate. I don't think it's legacy at all, lots of projects use it. It exists because of the problems of add_subdirectory shown above. The downside is you get these goofy timestamp files you have to manually delete now & again if your submodule changes. You can still include the project as a submodule, just use SOURCE_DIR parameter to pass the submodule path and skip the preliminary steps before CONFIGURE. Even if CMake in the distant future supports different C++ compilers/architectures in the same project, there will still be a need to build non-CMake dependencies and thus a place for ExternalProject. > > 3. Use packages. The [CMake package documentation][1] does not go into > great detail on support for both installed versions and build tree for a single > package. Does this require two scripts? Can it share a single one? Where are > the examples? Well, you'd do this in conjunction with ExternalProject_Add. A well-written CMake external project will provide a Config.cmake file which you will then find using find_package. > > How do I accomplish this? > A high-level CMake project that does nothing but call ExternalProject_Add; this is called a superbuild. Your own CMake projects will be ExternalProjects to this high-level project and the superbuild would pass the location to your project via -D_DIR= so that find_package can locate the Config file. Best regards, James Johnston From ggarra13 at gmail.com Mon Aug 17 11:57:12 2015 From: ggarra13 at gmail.com (Gonzalo) Date: Mon, 17 Aug 2015 12:57:12 -0300 Subject: [CMake] Problem with cpack in latest cmake v3.3.1 and ninja Message-ID: <55D20458.9090203@gmail.com> I upgraded my cmake just recently and I am using the Ninja generator. The compilation and linking seems to work fine. However, when I run make package, I get the following: [2/2] Run CPack packaging tool... FAILED: cd /media/Linux/code/applications/mrViewer/BUILD/Linux-3.16.0-45-generic-64/Release/tmp && /usr/bin/cpack --config ./CPackConfig.cmake CPack: Create package using DEB CPack: Install projects CPack: - Install project: mrViewer CPack: Create package CPack Error: Problem running cmake -E md5sum "/usr/bin/cmake" -E md5sum "/media/Linux/code/applications/mrViewer/BUILD/Linux-3.16.0-45-generic-64/Release/tmp/_CPack_Packages/Linux/DEB/mrViewer-v2.9.0-Linux-64/usr/local/mrViewer-v2.9.0-Linux-64/bin/ctl" CPack Error: Problem running cmake -E md5sum "/usr/bin/cmake" -E md5sum "/media/Linux/code/applications/mrViewer/BUILD/Linux-3.16.0-45-generic-64/Release/tmp/_CPack_Packages/Linux/DEB/mrViewer-v2.9.0-Linux-64/usr/local/mrViewer-v2.9.0-Linux-64/bin/docs" CPack Error: Problem running cmake -E md5sum "/usr/bin/cmake" -E md5sum "/media/Linux/code/applications/mrViewer/BUILD/Linux-3.16.0-45-generic-64/Release/tmp/_CPack_Packages/Linux/DEB/mrViewer-v2.9.0-Linux-64/usr/local/mrViewer-v2.9.0-Linux-64/bin/rails" CPack Error: Problem compressing the directory CPack Error: Error when generating package: mrViewer ninja: build stopped: subcommand failed. If I try running one of the md5sum lines manually, I get: cmake -E md5sum "/usr/bin/cmake" -E md5sum "/media/Linux/code/applications/mrViewer/BUILD/Linux-3.16.0-45-generic-64/Release/tmp/_CPack_Packages/Linux/DEB/mrViewer-v2.9.0-Linux-64/usr/local/mrViewer-v2.9.0-Linux-64/bin/docs" ece6ba4e4e8c69337be88aa69e27d95c /usr/bin/cmake -E: No such file or directory md5sum: No such file or directory /media/Linux/code/applications/mrViewer/BUILD/Linux-3.16.0-45-generic-64/Release/tmp/_CPack_Packages/Linux/DEB/mrViewer-v2.9.0-Linux-64/usr/local/mrViewer-v2.9.0-Linux-64/bin/docs: No such file or directory It seems the latest cmake is not accepting multiple -E commands. Or the ninja generator is creating an incorrect run line. From avi.a.tevet at intel.com Mon Aug 17 13:10:06 2015 From: avi.a.tevet at intel.com (Tevet, Avi A) Date: Mon, 17 Aug 2015 17:10:06 +0000 Subject: [CMake] ExternalProject git clone hangs on windows In-Reply-To: References: Message-ID: Thanks for the information. From: Petr Kmoch [mailto:petr.kmoch at gmail.com] Sent: Monday, August 17, 2015 1:05 AM To: Tevet, Avi A Cc: cmake at cmake.org Subject: Re: [CMake] ExternalProject git clone hangs on windows Hi Avi. On Sat, Aug 15, 2015 at 1:54 AM, Tevet, Avi A > wrote: Hi all, [...] I don?t know if this is related, but when I look inside the generated VS projects for the dependencies, I see the ?CMake Rules? directory full of *.rule files, but they are all effectively empty, containing just the text ?# generated from CMake?. Just to address this bit: that's correct. The rule file's contents are irrelevant, it just has to exist as a file. CMake attaches "custom build rules" to this file in the VS project, and these rules are stored in the vc[x]proj. Petr -------------- next part -------------- An HTML attachment was scrubbed... URL: From avi.a.tevet at intel.com Mon Aug 17 13:09:33 2015 From: avi.a.tevet at intel.com (Tevet, Avi A) Date: Mon, 17 Aug 2015 17:09:33 +0000 Subject: [CMake] ExternalProject git clone hangs on windows In-Reply-To: References: Message-ID: Thanks, I hadn?t thought about the SSH problem. I?ll investigate. From: Sergei Nikulov [mailto:sergey.nikulov at gmail.com] Sent: Friday, August 14, 2015 11:06 PM To: Tevet, Avi A Cc: cmake at cmake.org Subject: Re: [CMake] ExternalProject git clone hangs on windows 15 ???. 2015 ?. 3:04 AM ???????????? "Tevet, Avi A" > ???????: > > Hi all, > > > Can someone please tell me what I need to do so that I can use VS2015 to build a project with git dependencies managed through ExternalProject_add? > Try clone git project using url from ExternalPoject_add. Possible git will request something interactively - like add ssh key of remote host or request password. If so, this was a reason for hang. As solution - add host keys permanently or change url to https/local clone scheme. If password used on ssh key - remove it if possible. HTH, > > Thanks, > > > > Avi > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From Barthelemy.Von.Haller at cern.ch Tue Aug 18 03:54:54 2015 From: Barthelemy.Von.Haller at cern.ch (Barthelemy Von Haller) Date: Tue, 18 Aug 2015 07:54:54 +0000 (UTC) Subject: [CMake] [CPack]Call References: <9511D70A3F79B342A045E67C062DD28FDEDF01D7@CERNXCHG43.cern.ch> Message-ID: Barthelemy Von Haller writes: > > > Hello, > > I have a projects looking like this : > Repo > . > ??? CMakeLists.txt > ??? ProjA > ??? ??? cmake > ??? ??? ??? CPackConfig.cmake > ??? ??? CMakeLists.txt > ??? ??? doc > ??? ??? include > ??? ??? src > ??? ??? test > ??? ProjB > ??? ??? cmake > ??? ??? ??? CPackConfig.cmake > ??? ??? CMakeLists.txt > ??? ??? doc > ??? ??? include > ??? ??? src > ??? ??? test > ??? More projects... > Each project (ProjA, ProjB, ...) is buildable on its own. It can be tested, installed and packaged alone. > > I want to be able to do the same from the top directory as well. In this case, it would apply the target to all subprojects. > > It works fine for "make", "make test", "make install" but not for "make package". With the latter, only the last project is packaged not the others. > > Is there a clean way to call CPack from the top directory ? > Thank you, > Barthelemy > > > Dear all, I did not get any reply to my enquiry about running "make package" from a top directory containing several sub projects. Does anyone has an idea ? Best regards, Barth From Anthony.R.Ette at controlsdata.com Tue Aug 18 14:29:45 2015 From: Anthony.R.Ette at controlsdata.com (Ette, Anthony (CDS)) Date: Tue, 18 Aug 2015 18:29:45 +0000 Subject: [CMake] Imported libraries and cross platform target names Message-ID: <2A375B5C08C24643A8A3F8CC2B98C1084BB207F0@USINDPR-MBX003.Rolls-Royce.Local> Given that add_library() produces a unique filename per platform (the "actual file name of the library built is constructed based on conventions of the native platform (such as lib.a or.lib"), how does one add the library to the final application without having to deal with the filename difference? In other words, I've got one library that, by default, produces 'libtest.a' on Linux and 'test.lib' on Windows. How can I add this imported library into the final application in a cross platform manner? I know I can specify two different imported locations (see below), but it seems odd to me that Cmake - the cross-platform build env generator - doesn't have a better native way of dealing with this.... The snippet below will work, but just seems wrong given the nature of what CMake is intended to do...is there a better way that I'm missing?! If not, can I request that a future release of Cmake handle platform naming convention difference internally when invoking ADD_LIBRARY with the IMPORTED tag set? Ok so, to be fair, Cmake can be used to cross compile and that certainly complicates my feature request but, when not cross compiling, CMake knows what platform it's being executed on so it should be able to resolve static archive platform decorations internally. ADD_LIBRARY(test STATIC IMPORTED) if(WIN32) SET_PROPERTY(TARGET test PROPERTY IMPORTED_LOCATION ${LIB_D}/timer.lib) endif() if(UNIX) SET_PROPERTY(TARGET test PROPERTY IMPORTED_LOCATION ${LIB_D}/libtimer.a) endif() Thanks in advance, Anthony Ette Control Systems Engineer Rolls-Royce Controls and Data Services 7661 N Perimeter Rd Indianapolis, IN 46241 tel: +1 (317) 230-6943 mob: +1 (317) 864-7975 email: Anthony.R.Ette at controlsdata.com This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Anthony.R.Ette at controlsdata.com Tue Aug 18 14:51:54 2015 From: Anthony.R.Ette at controlsdata.com (Ette, Anthony (CDS)) Date: Tue, 18 Aug 2015 18:51:54 +0000 Subject: [CMake] Imported libraries and cross platform target names In-Reply-To: <35F6921410093E4CA40D524BD5C18D4C30395D08@EDXMB57.jdnet.deere.com> References: <2A375B5C08C24643A8A3F8CC2B98C1084BB207F0@USINDPR-MBX003.Rolls-Royce.Local> <35F6921410093E4CA40D524BD5C18D4C30395D08@EDXMB57.jdnet.deere.com> Message-ID: <2A375B5C08C24643A8A3F8CC2B98C1084BB20818@USINDPR-MBX003.Rolls-Royce.Local> Thank you for the response, I will look into find_library. Note however that these static libraries are ours built from a separate CMake project (so I always know where they are "installed"). Anthony Ette Control Systems Engineer Rolls-Royce Controls and Data Services 7661 N Perimeter Rd Indianapolis, IN 46241 tel: +1 (317) 230-6943 mob: +1 (317) 864-7975 email: Anthony.R.Ette at controlsdata.com From: Miller Henry [mailto:MillerHenry at JohnDeere.com] Sent: Tuesday, August 18, 2015 2:44 PM To: Ette, Anthony (CDS); CMake at cmake.org Subject: RE: Imported libraries and cross platform target names Use find_library to find the library. You will probably need this anyway because different systems install libraries in different locations. http://www.cmake.org/cmake/help/v3.3/command/find_library.html From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Ette, Anthony (CDS) Sent: Tuesday, August 18, 2015 1:30 PM To: CMake at cmake.org Subject: [CMake] Imported libraries and cross platform target names Importance: High Given that add_library() produces a unique filename per platform (the "actual file name of the library built is constructed based on conventions of the native platform (such as lib.a or.lib"), how does one add the library to the final application without having to deal with the filename difference? In other words, I've got one library that, by default, produces 'libtest.a' on Linux and 'test.lib' on Windows. How can I add this imported library into the final application in a cross platform manner? I know I can specify two different imported locations (see below), but it seems odd to me that Cmake - the cross-platform build env generator - doesn't have a better native way of dealing with this.... The snippet below will work, but just seems wrong given the nature of what CMake is intended to do...is there a better way that I'm missing?! If not, can I request that a future release of Cmake handle platform naming convention difference internally when invoking ADD_LIBRARY with the IMPORTED tag set? Ok so, to be fair, Cmake can be used to cross compile and that certainly complicates my feature request but, when not cross compiling, CMake knows what platform it's being executed on so it should be able to resolve static archive platform decorations internally. ADD_LIBRARY(test STATIC IMPORTED) if(WIN32) SET_PROPERTY(TARGET test PROPERTY IMPORTED_LOCATION ${LIB_D}/timer.lib) endif() if(UNIX) SET_PROPERTY(TARGET test PROPERTY IMPORTED_LOCATION ${LIB_D}/libtimer.a) endif() Thanks in advance, Anthony Ette Control Systems Engineer Rolls-Royce Controls and Data Services 7661 N Perimeter Rd Indianapolis, IN 46241 tel: +1 (317) 230-6943 mob: +1 (317) 864-7975 email: Anthony.R.Ette at controlsdata.com This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. ______________________________________________________________________ This email has been scanned. This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From calebwherry at gmail.com Tue Aug 18 14:55:13 2015 From: calebwherry at gmail.com (J. Caleb Wherry) Date: Tue, 18 Aug 2015 14:55:13 -0400 Subject: [CMake] Imported libraries and cross platform target names In-Reply-To: <2A375B5C08C24643A8A3F8CC2B98C1084BB207F0@USINDPR-MBX003.Rolls-Royce.Local> References: <2A375B5C08C24643A8A3F8CC2B98C1084BB207F0@USINDPR-MBX003.Rolls-Royce.Local> Message-ID: CMAKE_IMPORT_LIBRARY_PREFIX and CMAKE_IMPORT_LIBRARY_POSTFIX should get you what you want. Then you just have to have one set property: SET_PROPERTY(TARGET test PROPERTY IMPORTED_LOCATION ${LIB_D}/${CMAKE_IMPORT_LIBRARY_PREFIX} timer.${CMAKE_IMPORT_LIBRARY_POSTFIX}) -Caleb On Tuesday, August 18, 2015, Ette, Anthony (CDS) < Anthony.R.Ette at controlsdata.com > wrote: > Given that add_library() produces a unique filename per platform (the ?actual > file name of the library built is constructed based on conventions of the > native platform (such as lib.a or.lib?), how does one add the > library to the final application without having to deal with the filename > difference? In other words, I?ve got one library that, by default, > produces ?libtest.a? on Linux and ?test.lib? on Windows. How can I add > this imported library into the final application in a cross platform > manner? I know I can specify two different imported locations (see below), > but it seems odd to me that Cmake ? the cross-platform build env generator > ? doesn?t have a better native way of dealing with this?. > > > > The snippet below will work, but just seems wrong given the nature of what > CMake is intended to do?is there a better way that I?m missing?! If not, > can I request that a future release of Cmake handle platform naming > convention difference internally when invoking ADD_LIBRARY with the > IMPORTED tag set? Ok so, to be fair, Cmake can be used to cross compile > and that certainly complicates my feature request but, when not cross > compiling, CMake knows what platform it?s being executed on so it should be > able to resolve static archive platform decorations internally. > > > > ADD_LIBRARY(test STATIC IMPORTED) > > if(WIN32) > > SET_PROPERTY(TARGET test PROPERTY IMPORTED_LOCATION ${LIB_D}/timer.lib) > > endif() > > if(UNIX) > > SET_PROPERTY(TARGET test PROPERTY IMPORTED_LOCATION > ${LIB_D}/libtimer.a) > > endif() > > > > Thanks in advance, > > > *Anthony Ette *Control Systems Engineer > > > > Rolls-Royce Controls and Data Services > > 7661 N Perimeter Rd > > Indianapolis, IN 46241 > > tel: +1 (317) 230-6943 > > mob: +1 (317) 864-7975 > > email: Anthony.R.Ette at controlsdata.com > > > This e-mail (including attachments) contains contents owned by Rolls-Royce > plc and its subsidiaries, affiliated companies or customers and covered by > the laws of England and Wales, Brazil, US, or Canada (federal, state or > provincial). The information contained in this email is intended to be > confidential, may be legally privileged and subject to export controls > which may restrict the access to and transfer of the information. If you > are not the intended recipient, you are hereby notified that any retention, > dissemination, distribution, interception or copying of this communication > is strictly prohibited and may subject you to further legal action. Reply > to the sender if you received this email by accident, and then delete the > email and any attachments. > -- Sent from my iPhone 4s -------------- next part -------------- An HTML attachment was scrubbed... URL: From Anthony.R.Ette at controlsdata.com Tue Aug 18 14:59:11 2015 From: Anthony.R.Ette at controlsdata.com (Ette, Anthony (CDS)) Date: Tue, 18 Aug 2015 18:59:11 +0000 Subject: [CMake] Imported libraries and cross platform target names In-Reply-To: <2C950720-E61E-4D10-93BF-231D3E733B6D@ionicsecurity.com> References: <2C950720-E61E-4D10-93BF-231D3E733B6D@ionicsecurity.com> Message-ID: <2A375B5C08C24643A8A3F8CC2B98C1084BB20830@USINDPR-MBX003.Rolls-Royce.Local> Thank you, I will take a look at find_library. The static libraries are ones we build in-house but in a separate CMake-generated build system. The reason we use a separate build system is because our common library code is used by all applications and, as such, is on a separate development cycle than the applications themselves. In other words, while there may be advantages to combining them, I don?t think it would really make sense in our case?.any thoughts? Are you in a similar situation? Anthony Ette Control Systems Engineer Rolls-Royce Controls and Data Services 7661 N Perimeter Rd Indianapolis, IN 46241 tel: +1 (317) 230-6943 mob: +1 (317) 864-7975 email: Anthony.R.Ette at controlsdata.com From: Parag Chandra [mailto:parag at ionicsecurity.com] Sent: Tuesday, August 18, 2015 2:45 PM To: Ette, Anthony (CDS); CMake at cmake.org Subject: Re: [CMake] Imported libraries and cross platform target names You just specify the ?basename? of the library, so something like this: find_library (timer NAMES timer PATHS your/library/directory) target_link_libraries(test timer) And Cmake takes care of the rest. It?s even easier if ?timer? is also part of the same CMake-generated build system. In that case, the find_library isn?t even needed. Things do get a little more complicated when you want to distinguish between release/debug variants of the same library. For that you can use the DEBUG and OPTIMIZED keywords of target_link_libraries(). Parag Chandra Senior Software Engineer, Mobile Team Mobile: +1.919.824.1410 [https://www.ionicsecurity.com/IonicSigHz.png] Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 From: , "Anthony (CDS)" > Date: Tuesday, August 18, 2015 at 2:29 PM To: "CMake at cmake.org" > Subject: [CMake] Imported libraries and cross platform target names Given that add_library() produces a unique filename per platform (the ?actual file name of the library built is constructed based on conventions of the native platform (such as lib.a or.lib?), how does one add the library to the final application without having to deal with the filename difference? In other words, I?ve got one library that, by default, produces ?libtest.a? on Linux and ?test.lib? on Windows. How can I add this imported library into the final application in a cross platform manner? I know I can specify two different imported locations (see below), but it seems odd to me that Cmake ? the cross-platform build env generator ? doesn?t have a better native way of dealing with this?. The snippet below will work, but just seems wrong given the nature of what CMake is intended to do?is there a better way that I?m missing?! If not, can I request that a future release of Cmake handle platform naming convention difference internally when invoking ADD_LIBRARY with the IMPORTED tag set? Ok so, to be fair, Cmake can be used to cross compile and that certainly complicates my feature request but, when not cross compiling, CMake knows what platform it?s being executed on so it should be able to resolve static archive platform decorations internally. ADD_LIBRARY(testSTATICIMPORTED) if(WIN32) SET_PROPERTY(TARGETtestPROPERTYIMPORTED_LOCATION ${LIB_D}/timer.lib) endif() if(UNIX) SET_PROPERTY(TARGETtest PROPERTYIMPORTED_LOCATION ${LIB_D}/libtimer.a) endif() Thanks in advance, Anthony Ette Control Systems Engineer Rolls-Royce Controls and Data Services 7661 N Perimeter Rd Indianapolis, IN 46241 tel: +1 (317) 230-6943 mob: +1 (317) 864-7975 email: Anthony.R.Ette at controlsdata.com This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. ______________________________________________________________________ This email has been scanned. This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Tue Aug 18 15:01:04 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 18 Aug 2015 21:01:04 +0200 Subject: [CMake] Imported libraries and cross platform target names In-Reply-To: <2A375B5C08C24643A8A3F8CC2B98C1084BB207F0@USINDPR-MBX003.Rolls-Royce.Local> References: <2A375B5C08C24643A8A3F8CC2B98C1084BB207F0@USINDPR-MBX003.Rolls-Royce.Local> Message-ID: <55D380F0.7020400@gmail.com> On 18.08.2015 20:29, Ette, Anthony (CDS) wrote: > > Given that add_library() produces a unique filename per platform (the > ?actual file name of the library built is constructed based on > conventions of the native platform (such as lib.aor.lib?), > how does one add the library to the final application without having > to deal with the filename difference? In other words, I?ve got one > library that, by default, produces ?libtest.a? on Linux and ?test.lib? > on Windows. How can I add this imported library into the final > application in a cross platform manner? I know I can specify two > different imported locations (see below), but it seems odd to me that > Cmake ? the cross-platform build env generator ? doesn?t have a better > native way of dealing with this?. > > Assuming the project producing the libraries and the project consuming them are distinct you could export targets from your library project with install(EXPORT) and import them in the other project with find_package(). Creation of package configuration files (using target exports) is explained here: http://www.cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html#creating-packages Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From parag at ionicsecurity.com Tue Aug 18 15:07:41 2015 From: parag at ionicsecurity.com (Parag Chandra) Date: Tue, 18 Aug 2015 19:07:41 +0000 Subject: [CMake] Imported libraries and cross platform target names In-Reply-To: <2A375B5C08C24643A8A3F8CC2B98C1084BB20830@USINDPR-MBX003.Rolls-Royce.Local> References: <2C950720-E61E-4D10-93BF-231D3E733B6D@ionicsecurity.com> <2A375B5C08C24643A8A3F8CC2B98C1084BB20830@USINDPR-MBX003.Rolls-Royce.Local> Message-ID: <7328A63D-CA1F-4C63-A911-BAB774BED54F@ionicsecurity.com> Yes, very similar. When I set out to convert our existing build system, which consists of many individual .sln and .vcxproj files, I got a requirement that the developers do not all want to work out of the same ?uber? Xcode workspace/VS solution that contains all of the projects. They want to continue working with solutions that contain only the library of interest plus its associated test project. So when a developer runs CMake, a dependency like ?timer? may refer to another CMake-generated project within the current build system, or it may refer to an already-built/downloaded dependency of the same name. Parag Chandra Senior Software Engineer, Mobile Team Mobile: +1.919.824.1410 [https://www.ionicsecurity.com/IonicSigHz.png] Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 From: , "Anthony (CDS)" > Date: Tuesday, August 18, 2015 at 2:59 PM To: Parag Chandra >, "CMake at cmake.org" > Subject: RE: [CMake] Imported libraries and cross platform target names Thank you, I will take a look at find_library. The static libraries are ones we build in-house but in a separate CMake-generated build system. The reason we use a separate build system is because our common library code is used by all applications and, as such, is on a separate development cycle than the applications themselves. In other words, while there may be advantages to combining them, I don?t think it would really make sense in our case?.any thoughts? Are you in a similar situation? Anthony Ette Control Systems Engineer Rolls-Royce Controls and Data Services 7661 N Perimeter Rd Indianapolis, IN 46241 tel: +1 (317) 230-6943 mob: +1 (317) 864-7975 email: Anthony.R.Ette at controlsdata.com From: Parag Chandra [mailto:parag at ionicsecurity.com] Sent: Tuesday, August 18, 2015 2:45 PM To: Ette, Anthony (CDS); CMake at cmake.org Subject: Re: [CMake] Imported libraries and cross platform target names You just specify the ?basename? of the library, so something like this: find_library (timer NAMES timer PATHS your/library/directory) target_link_libraries(test timer) And Cmake takes care of the rest. It?s even easier if ?timer? is also part of the same CMake-generated build system. In that case, the find_library isn?t even needed. Things do get a little more complicated when you want to distinguish between release/debug variants of the same library. For that you can use the DEBUG and OPTIMIZED keywords of target_link_libraries(). Parag Chandra Senior Software Engineer, Mobile Team Mobile: +1.919.824.1410 [https://www.ionicsecurity.com/IonicSigHz.png] Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 From: , "Anthony (CDS)" > Date: Tuesday, August 18, 2015 at 2:29 PM To: "CMake at cmake.org" > Subject: [CMake] Imported libraries and cross platform target names Given that add_library() produces a unique filename per platform (the ?actual file name of the library built is constructed based on conventions of the native platform (such as lib.a or.lib?), how does one add the library to the final application without having to deal with the filename difference? In other words, I?ve got one library that, by default, produces ?libtest.a? on Linux and ?test.lib? on Windows. How can I add this imported library into the final application in a cross platform manner? I know I can specify two different imported locations (see below), but it seems odd to me that Cmake ? the cross-platform build env generator ? doesn?t have a better native way of dealing with this?. The snippet below will work, but just seems wrong given the nature of what CMake is intended to do?is there a better way that I?m missing?! If not, can I request that a future release of Cmake handle platform naming convention difference internally when invoking ADD_LIBRARY with the IMPORTED tag set? Ok so, to be fair, Cmake can be used to cross compile and that certainly complicates my feature request but, when not cross compiling, CMake knows what platform it?s being executed on so it should be able to resolve static archive platform decorations internally. ADD_LIBRARY(testSTATICIMPORTED) if(WIN32) SET_PROPERTY(TARGETtestPROPERTYIMPORTED_LOCATION ${LIB_D}/timer.lib) endif() if(UNIX) SET_PROPERTY(TARGETtestPROPERTYIMPORTED_LOCATION ${LIB_D}/libtimer.a) endif() Thanks in advance, Anthony Ette Control Systems Engineer Rolls-Royce Controls and Data Services 7661 N Perimeter Rd Indianapolis, IN 46241 tel: +1 (317) 230-6943 mob: +1 (317) 864-7975 email: Anthony.R.Ette at controlsdata.com This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. ______________________________________________________________________ This email has been scanned. This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From parag at ionicsecurity.com Tue Aug 18 14:44:37 2015 From: parag at ionicsecurity.com (Parag Chandra) Date: Tue, 18 Aug 2015 18:44:37 +0000 Subject: [CMake] Imported libraries and cross platform target names Message-ID: <2C950720-E61E-4D10-93BF-231D3E733B6D@ionicsecurity.com> You just specify the ?basename? of the library, so something like this: find_library (timer NAMES timer PATHS your/library/directory) target_link_libraries(test timer) And Cmake takes care of the rest. It?s even easier if ?timer? is also part of the same CMake-generated build system. In that case, the find_library isn?t even needed. Things do get a little more complicated when you want to distinguish between release/debug variants of the same library. For that you can use the DEBUG and OPTIMIZED keywords of target_link_libraries(). Parag Chandra Senior Software Engineer, Mobile Team Mobile: +1.919.824.1410 [https://www.ionicsecurity.com/IonicSigHz.png] Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 From: , "Anthony (CDS)" > Date: Tuesday, August 18, 2015 at 2:29 PM To: "CMake at cmake.org" > Subject: [CMake] Imported libraries and cross platform target names Given that add_library() produces a unique filename per platform (the ?actual file name of the library built is constructed based on conventions of the native platform (such as lib.a or.lib?), how does one add the library to the final application without having to deal with the filename difference? In other words, I?ve got one library that, by default, produces ?libtest.a? on Linux and ?test.lib? on Windows. How can I add this imported library into the final application in a cross platform manner? I know I can specify two different imported locations (see below), but it seems odd to me that Cmake ? the cross-platform build env generator ? doesn?t have a better native way of dealing with this?. The snippet below will work, but just seems wrong given the nature of what CMake is intended to do?is there a better way that I?m missing?! If not, can I request that a future release of Cmake handle platform naming convention difference internally when invoking ADD_LIBRARY with the IMPORTED tag set? Ok so, to be fair, Cmake can be used to cross compile and that certainly complicates my feature request but, when not cross compiling, CMake knows what platform it?s being executed on so it should be able to resolve static archive platform decorations internally. ADD_LIBRARY(testSTATICIMPORTED) if(WIN32) SET_PROPERTY(TARGETtestPROPERTYIMPORTED_LOCATION ${LIB_D}/timer.lib) endif() if(UNIX) SET_PROPERTY(TARGETtest PROPERTYIMPORTED_LOCATION ${LIB_D}/libtimer.a) endif() Thanks in advance, Anthony Ette Control Systems Engineer Rolls-Royce Controls and Data Services 7661 N Perimeter Rd Indianapolis, IN 46241 tel: +1 (317) 230-6943 mob: +1 (317) 864-7975 email: Anthony.R.Ette at controlsdata.com This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From MillerHenry at JohnDeere.com Tue Aug 18 14:44:03 2015 From: MillerHenry at JohnDeere.com (Miller Henry) Date: Tue, 18 Aug 2015 18:44:03 +0000 Subject: [CMake] Imported libraries and cross platform target names In-Reply-To: <2A375B5C08C24643A8A3F8CC2B98C1084BB207F0@USINDPR-MBX003.Rolls-Royce.Local> References: <2A375B5C08C24643A8A3F8CC2B98C1084BB207F0@USINDPR-MBX003.Rolls-Royce.Local> Message-ID: <35F6921410093E4CA40D524BD5C18D4C30395D08@EDXMB57.jdnet.deere.com> Use find_library to find the library. You will probably need this anyway because different systems install libraries in different locations. http://www.cmake.org/cmake/help/v3.3/command/find_library.html From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Ette, Anthony (CDS) Sent: Tuesday, August 18, 2015 1:30 PM To: CMake at cmake.org Subject: [CMake] Imported libraries and cross platform target names Importance: High Given that add_library() produces a unique filename per platform (the "actual file name of the library built is constructed based on conventions of the native platform (such as lib.a or.lib"), how does one add the library to the final application without having to deal with the filename difference? In other words, I've got one library that, by default, produces 'libtest.a' on Linux and 'test.lib' on Windows. How can I add this imported library into the final application in a cross platform manner? I know I can specify two different imported locations (see below), but it seems odd to me that Cmake - the cross-platform build env generator - doesn't have a better native way of dealing with this.... The snippet below will work, but just seems wrong given the nature of what CMake is intended to do...is there a better way that I'm missing?! If not, can I request that a future release of Cmake handle platform naming convention difference internally when invoking ADD_LIBRARY with the IMPORTED tag set? Ok so, to be fair, Cmake can be used to cross compile and that certainly complicates my feature request but, when not cross compiling, CMake knows what platform it's being executed on so it should be able to resolve static archive platform decorations internally. ADD_LIBRARY(test STATIC IMPORTED) if(WIN32) SET_PROPERTY(TARGET test PROPERTY IMPORTED_LOCATION ${LIB_D}/timer.lib) endif() if(UNIX) SET_PROPERTY(TARGET test PROPERTY IMPORTED_LOCATION ${LIB_D}/libtimer.a) endif() Thanks in advance, Anthony Ette Control Systems Engineer Rolls-Royce Controls and Data Services 7661 N Perimeter Rd Indianapolis, IN 46241 tel: +1 (317) 230-6943 mob: +1 (317) 864-7975 email: Anthony.R.Ette at controlsdata.com This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Tue Aug 18 15:40:39 2015 From: d3ck0r at gmail.com (J Decker) Date: Tue, 18 Aug 2015 12:40:39 -0700 Subject: [CMake] Imported libraries and cross platform target names In-Reply-To: <2A375B5C08C24643A8A3F8CC2B98C1084BB207F0@USINDPR-MBX003.Rolls-Royce.Local> References: <2A375B5C08C24643A8A3F8CC2B98C1084BB207F0@USINDPR-MBX003.Rolls-Royce.Local> Message-ID: target_link_libraries( final_project library ) ? On Tue, Aug 18, 2015 at 11:29 AM, Ette, Anthony (CDS) < Anthony.R.Ette at controlsdata.com> wrote: > Given that add_library() produces a unique filename per platform (the ?actual > file name of the library built is constructed based on conventions of the > native platform (such as lib.a or.lib?), how does one add the > library to the final application without having to deal with the filename > difference? In other words, I?ve got one library that, by default, > produces ?libtest.a? on Linux and ?test.lib? on Windows. How can I add > this imported library into the final application in a cross platform > manner? I know I can specify two different imported locations (see below), > but it seems odd to me that Cmake ? the cross-platform build env generator > ? doesn?t have a better native way of dealing with this?. > > > > The snippet below will work, but just seems wrong given the nature of what > CMake is intended to do?is there a better way that I?m missing?! If not, > can I request that a future release of Cmake handle platform naming > convention difference internally when invoking ADD_LIBRARY with the > IMPORTED tag set? Ok so, to be fair, Cmake can be used to cross compile > and that certainly complicates my feature request but, when not cross > compiling, CMake knows what platform it?s being executed on so it should be > able to resolve static archive platform decorations internally. > > > > ADD_LIBRARY(test STATIC IMPORTED) > > if(WIN32) > > SET_PROPERTY(TARGET test PROPERTY IMPORTED_LOCATION ${LIB_D}/timer.lib) > > endif() > > if(UNIX) > > SET_PROPERTY(TARGET test PROPERTY IMPORTED_LOCATION > ${LIB_D}/libtimer.a) > > endif() > > > > Thanks in advance, > > > *Anthony Ette *Control Systems Engineer > > > > Rolls-Royce Controls and Data Services > > 7661 N Perimeter Rd > > Indianapolis, IN 46241 > > tel: +1 (317) 230-6943 > > mob: +1 (317) 864-7975 > > email: Anthony.R.Ette at controlsdata.com > > > This e-mail (including attachments) contains contents owned by Rolls-Royce > plc and its subsidiaries, affiliated companies or customers and covered by > the laws of England and Wales, Brazil, US, or Canada (federal, state or > provincial). The information contained in this email is intended to be > confidential, may be legally privileged and subject to export controls > which may restrict the access to and transfer of the information. If you > are not the intended recipient, you are hereby notified that any retention, > dissemination, distribution, interception or copying of this communication > is strictly prohibited and may subject you to further legal action. Reply > to the sender if you received this email by accident, and then delete the > email and any attachments. > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsvanbethlehem at gmail.com Wed Aug 19 01:55:18 2015 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Wed, 19 Aug 2015 07:55:18 +0200 Subject: [CMake] [CPack]Call In-Reply-To: References: <9511D70A3F79B342A045E67C062DD28FDEDF01D7@CERNXCHG43.cern.ch> Message-ID: Barth, Personally I have no experience at all with packaging through CMake, but presumably you?ll need something like a CPackConfig.cmake in the top level folder? Beyond that, I think you?ll need to provide a bit more details about your environment. My guess is you work on linux, as the setup you provide and the behaviour you describe wouldn?t work on Windows with Visual Studio for instance. Thinking a bit more, actually I think there is nothing in CMake that allows you to do the ?make?, ?make test? etc both from the top level as well as the sub projects. My feeling is you did some magic in the top level to make this happen. You?ll need to provide some details for others to be able to help you further Sincerely, Jakob > On 18 Aug 2015, at 09:54, Barthelemy Von Haller wrote: > > > Barthelemy Von Haller writes: > >> >> >> Hello, >> >> I have a projects looking like this : >> Repo >> . >> ??? CMakeLists.txt >> ??? ProjA >> ? ??? cmake >> ? ? ??? CPackConfig.cmake >> ? ??? CMakeLists.txt >> ? ??? doc >> ? ??? include >> ? ??? src >> ? ??? test >> ??? ProjB >> ? ??? cmake >> ? ? ??? CPackConfig.cmake >> ? ??? CMakeLists.txt >> ? ??? doc >> ? ??? include >> ? ??? src >> ? ??? test >> ??? More projects... >> Each project (ProjA, ProjB, ...) is buildable on its own. It can be > tested, installed and packaged alone. >> >> I want to be able to do the same from the top directory as well. In this > case, it would apply the target to all subprojects. >> >> It works fine for "make", "make test", "make install" but not for "make > package". With the latter, only the last project is packaged not the others. >> >> Is there a clean way to call CPack from the top directory ? >> Thank you, >> Barthelemy >> >> >> > > Dear all, > > I did not get any reply to my enquiry about running "make package" from a > top directory containing several sub projects. > > Does anyone has an idea ? > > Best regards, > Barth > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From tamas.kenez at gmail.com Wed Aug 19 17:30:03 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Wed, 19 Aug 2015 23:30:03 +0200 Subject: [CMake] Imported libraries and cross platform target names In-Reply-To: <2A375B5C08C24643A8A3F8CC2B98C1084BB20818@USINDPR-MBX003.Rolls-Royce.Local> References: <2A375B5C08C24643A8A3F8CC2B98C1084BB207F0@USINDPR-MBX003.Rolls-Royce.Local> <35F6921410093E4CA40D524BD5C18D4C30395D08@EDXMB57.jdnet.deere.com> <2A375B5C08C24643A8A3F8CC2B98C1084BB20818@USINDPR-MBX003.Rolls-Royce.Local> Message-ID: Anthony, instead of `find_library` I do think you should look into the config-module feature and the command `install(EXPORT ...)` which helps you generating them, as Nils Gladitz has already suggested. As you wrote, these libraries are already building from CMakeLists so you don't even need to cmakefy them. Tamas On Tue, Aug 18, 2015 at 8:51 PM, Ette, Anthony (CDS) < Anthony.R.Ette at controlsdata.com> wrote: > Thank you for the response, I will look into find_library. Note however > that these static libraries are ours built from a separate CMake project > (so I always know where they are ?installed?). > > > > > *Anthony Ette *Control Systems Engineer > > > > Rolls-Royce Controls and Data Services > > 7661 N Perimeter Rd > > Indianapolis, IN 46241 > > tel: +1 (317) 230-6943 > > mob: +1 (317) 864-7975 > > email: Anthony.R.Ette at controlsdata.com > > > > *From:* Miller Henry [mailto:MillerHenry at JohnDeere.com] > *Sent:* Tuesday, August 18, 2015 2:44 PM > *To:* Ette, Anthony (CDS); CMake at cmake.org > *Subject:* RE: Imported libraries and cross platform target names > > > > Use find_library to find the library. You will probably need this anyway > because different systems install libraries in different locations. > > > > http://www.cmake.org/cmake/help/v3.3/command/find_library.html > > > > > > *From:* CMake [mailto:cmake-bounces at cmake.org ] *On > Behalf Of *Ette, Anthony (CDS) > *Sent:* Tuesday, August 18, 2015 1:30 PM > *To:* CMake at cmake.org > *Subject:* [CMake] Imported libraries and cross platform target names > *Importance:* High > > > > Given that add_library() produces a unique filename per platform (the ?actual > file name of the library built is constructed based on conventions of the > native platform (such as lib.a or.lib?), how does one add the > library to the final application without having to deal with the filename > difference? In other words, I?ve got one library that, by default, > produces ?libtest.a? on Linux and ?test.lib? on Windows. How can I add > this imported library into the final application in a cross platform > manner? I know I can specify two different imported locations (see below), > but it seems odd to me that Cmake ? the cross-platform build env generator > ? doesn?t have a better native way of dealing with this?. > > > > The snippet below will work, but just seems wrong given the nature of what > CMake is intended to do?is there a better way that I?m missing?! If not, > can I request that a future release of Cmake handle platform naming > convention difference internally when invoking ADD_LIBRARY with the > IMPORTED tag set? Ok so, to be fair, Cmake can be used to cross compile > and that certainly complicates my feature request but, when not cross > compiling, CMake knows what platform it?s being executed on so it should be > able to resolve static archive platform decorations internally. > > > > ADD_LIBRARY(test STATIC IMPORTED) > > if(WIN32) > > SET_PROPERTY(TARGET test PROPERTY IMPORTED_LOCATION ${LIB_D}/timer.lib) > > endif() > > if(UNIX) > > SET_PROPERTY(TARGET test PROPERTY IMPORTED_LOCATION > ${LIB_D}/libtimer.a) > > endif() > > > > Thanks in advance, > > > *Anthony Ette *Control Systems Engineer > > > > Rolls-Royce Controls and Data Services > > 7661 N Perimeter Rd > > Indianapolis, IN 46241 > > tel: +1 (317) 230-6943 > > mob: +1 (317) 864-7975 > > email: Anthony.R.Ette at controlsdata.com > > > > This e-mail (including attachments) contains contents owned by Rolls-Royce > plc and its subsidiaries, affiliated companies or customers and covered by > the laws of England and Wales, Brazil, US, or Canada (federal, state or > provincial). The information contained in this email is intended to be > confidential, may be legally privileged and subject to export controls > which may restrict the access to and transfer of the information. If you > are not the intended recipient, you are hereby notified that any retention, > dissemination, distribution, interception or copying of this communication > is strictly prohibited and may subject you to further legal action. Reply > to the sender if you received this email by accident, and then delete the > email and any attachments. > > > ______________________________________________________________________ > This email has been scanned. > This e-mail (including attachments) contains contents owned by Rolls-Royce > plc and its subsidiaries, affiliated companies or customers and covered by > the laws of England and Wales, Brazil, US, or Canada (federal, state or > provincial). The information contained in this email is intended to be > confidential, may be legally privileged and subject to export controls > which may restrict the access to and transfer of the information. If you > are not the intended recipient, you are hereby notified that any retention, > dissemination, distribution, interception or copying of this communication > is strictly prohibited and may subject you to further legal action. Reply > to the sender if you received this email by accident, and then delete the > email and any attachments. > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tamas.kenez at gmail.com Wed Aug 19 17:56:18 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Wed, 19 Aug 2015 23:56:18 +0200 Subject: [CMake] How to depend on external cmake projects? In-Reply-To: References: Message-ID: Robert, 1. If it's a library you are not modifying, only linking to, then you don't need its targets in your projects. You just need to clone, build and install it before running cmake for your actual project. It can be accomplished in various ways: - you can clone it as a submodule or manually by a script (shell or CMake script or CMakeLists.txt) - write a shell script that builds and installs it by calling `cmake` and `cmake --build` - write a super-project CMakeLists.txt which builds and installs it with execute_process(${CMAKE_COMMAND} ...) (or ExternalProject, but it's a bit cumbersome because you need to build the super-project to install the dependency) - build and install your dependency with execute_process(${CMAKE_COMMAND} ...) in your project's CMakeLists.txt (that is, in cmake configure-time) 2. If it's a library you will modify then: - if it's not a submodule, you need to clone it either in a shell script or in the super-project or in your project's CMakeLists - use add_library to add it into your project In first case you will need to use packages, or more precisely, config-modules but I would not complicate things by creating config-packages for the build tree. Create regular config modules (install(EXPORT ...) and install the projects. Tamas On Sun, Aug 16, 2015 at 3:32 PM, Robert Dailey wrote: > There are certain repositories on Github I'd like to pull in as a > dependency. These repositories already use CMake to build their source > code. Based on personal experience and reading material online, there > are a couple of different options: > > 1. Pull down the repository as a submodule to my own git repository. > Then call add_subdirectory() on it to make it part of the build, > allowing me to refer to those targets as dependencies in my own > targets. > > 2. Use ExternalProject_Add(). This seems like legacy, I'm not sure if > I should use this. It also seems very verbose and boilerplate. > > 3. Use packages. The [CMake package documentation][1] does not go into > great detail on support for both installed versions and build tree for > a single package. Does this require two scripts? Can it share a single > one? Where are the examples? > > How do I accomplish this? > > [1]: > http://www.cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html#creating-a-package-configuration-file-for-the-build-tree > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roman.wueger at gmx.at Thu Aug 20 05:37:47 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Thu, 20 Aug 2015 11:37:47 +0200 Subject: [CMake] Issue: 12592 New componentwise extra install commands for NSIS-generator Message-ID: <77FD51A2-FB99-4C05-9156-28D347367A79@gmx.at> Hello, did someone work on this? (http://public.kitware.com/Bug/view.php?id=12592) Is there an alternative to use extra install commands per component? Thanks in advance Best Regards Roman -------------- next part -------------- An HTML attachment was scrubbed... URL: From gjasny at googlemail.com Thu Aug 20 07:04:51 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Thu, 20 Aug 2015 13:04:51 +0200 Subject: [CMake] cmake iOS application + framework link error In-Reply-To: References: Message-ID: <55D5B453.6050305@googlemail.com> Hi David, On 04/05/15 20:12, David Hirvonen wrote: > Thanks for the response. I've moved to a more standard *nix layout for > all platforms, and will rely on a post-build step to create my framework > (for now). If I find a fix, I'll be sure to share it here. > > > On Wed, Apr 29, 2015 at 5:22 AM, Eric Wing > wrote: > > On 4/25/15, David Hirvonen > wrote: > > I'm hitting a link error when linking an iOS application with an internally > > created framework/library using the the CMake Xcode generator and an iOS > > toolchain. I've put together a minimal CMakeLists.txt example here: > > > >https://github.com/headupinclouds/cmake_framework_test/ With the ios-app-bundle-layout topic [1] branch I successfully compiled your test: > Touch _builds/ios/Debug-iphoneos/testa.app > cd /Users/gjasny/src/cmake_framework_test > export PATH="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/Users/gjasny/src/cmake/_build/bin:/Users/gjasny/bin:/usr/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin" > /usr/bin/touch -c /Users/gjasny/src/cmake_framework_test/_builds/ios/Debug-iphoneos/testa.app > > ProcessProductPackaging /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.4.sdk/Entitlements.plist _builds/ios/tf.build/Debug-iphoneos/testa.build/testa.app.xcent > cd /Users/gjasny/src/cmake_framework_test > export PATH="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/Users/gjasny/src/cmake/_build/bin:/Users/gjasny/bin:/usr/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin" > builtin-productPackagingUtility /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.4.sdk/Entitlements.plist -entitlements -format xml -o /Users/gjasny/src/cmake_framework_test/_builds/ios/tf.build/Debug-iphoneos/testa.build/testa.app.xcent > > CodeSign _builds/ios/Debug-iphoneos/testa.app > cd /Users/gjasny/src/cmake_framework_test > export CODESIGN_ALLOCATE=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate > export PATH="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/Users/gjasny/src/cmake/_build/bin:/Users/gjasny/bin:/usr/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin" > > Signing Identity: "iPhone Developer: Gregor Jasny (V73ULL766M)" > Provisioning Profile: "iOSTeam Provisioning Profile: *" > (34a9855a-c998-49e6-b12e-91f5fe28079a) > > /usr/bin/codesign --force --sign A8CFBE1BA1116F2E590774A39ED25D7E8DFC5344 --entitlements /Users/gjasny/src/cmake_framework_test/_builds/ios/tf.build/Debug-iphoneos/testa.build/testa.app.xcent /Users/gjasny/src/cmake_framework_test/_builds/ios/Debug-iphoneos/testa.app > > ** BUILD SUCCEEDED ** > > library path: _builds/ios/Debug-iphoneos/TF.framework/TF > _builds/ios/Debug-iphoneos/TF.framework.dSYM/Contents/Resources/DWARF/TF Thanks, Gregor [1] http://www.cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/ios-app-bundle-layout From Joseph.Gagnon at ll.mit.edu Thu Aug 20 09:14:57 2015 From: Joseph.Gagnon at ll.mit.edu (Gagnon, Joseph - 0553 - MITLL) Date: Thu, 20 Aug 2015 13:14:57 +0000 Subject: [CMake] How do I build conditionally required libraries? Message-ID: Please refer to this structure in the description below. project_root CMakeLists.txt build Debug Release src CMakeLists.txt COTS <- Third party packages used by various components COTS_Package_A ... Marshalling CMakeLists.txt intf <- contains pure virtual class representing interface implemented by Marshaller A, B and C Utility <- used only by Marshaller A and B requires COTS_Package_A (include paths/libraries) CMakeLists.txt Utility source files, etc. Marshaller A CMakeLists.txt Marshaller_A source files, etc. Marshaller B CMakeLists.txt ... Marshaller C CMakeLists.txt ... ... (other plug-ins) Description The project depicted above is intended to build various "plug-ins" (e.g. marshallers) that will be used by another larger application. Using the marshaller example, for a given installation of the application, only one of the marshaller implementations will be used. The plan is that only the selected implementation is built and provided as a shared library, along with other components it depends on (e.g. COTS_Package_A) to the larger application being installed. For the other implementations that were not chosen, nothing related to them (code, required 3rd party packages, etc.) should be included. For a scenario, let's assume that Marshaller A is chosen. It requires the Utility package, which in itself requires COTS_Package_A (Marshaller C doesn't have these requirements, but Marshaller B does). So, when Marshaller A is built, I also need to build Utility (along with its dependency on COTS A). I am assuming that each implementation should be built as EXCLUDE_FROM_ALL so that they aren't all automatically built when make is run and instead must be explicitly built (manually or by some other means) by running make with the specific target. Problem I have not been able to figure out how to make this kind of behavior occur using CMake. I have tried add_custom_target and add_dependencies to build the Utility package when Marshaller A (or B) is being built, but have had no luck. At first I thought I had it because when I ran make, the make build messages seemed to indicate success. However, I knew it was not actually doing the build because I deliberately left out the include_directories call (for COTS A) in the Utility CMakeLists.txt to force compilation errors and no errors were reported when the target build was performed. Obviously something is not right. If anyone has run into this type of scenario and has figured out a way to do this with CMake, I would really appreciate any information you could provide. I'm still new at using CMake and have not used, not do I understand (yet) many of its functions and more advanced techniques. Thank you, Joe Gagnon Engineer II Group 53 - Secure Resilient Systems and Technology MIT Lincoln Laboratory Lexington, MA -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5625 bytes Desc: not available URL: From gjasny at googlemail.com Thu Aug 20 11:12:43 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Thu, 20 Aug 2015 17:12:43 +0200 Subject: [CMake] target_include_directories SYSTEM adds -isystem to Clang, but not GCC In-Reply-To: References: Message-ID: <55D5EE6B.80405@googlemail.com> Hello, On 17/08/15 01:01, digitalriptide wrote: > When I add SYSTEM to target_include_directories, for example using > target_include_directories( my_target SYSTEM PUBLIC ${MY_LIBRARIES} ) > in Clang, CMake prepends -isystem to the relavent -I/my/library/path > type flags. With GCC, however, I see no -isystem added. > > For reference, this is CMake 3.2.3 on OS X with Apple LLVM version 6.0 > and GCC 5 provided via MacPorts. > > Should SYSTEM add -isystem with GCC? this is a know bug: http://www.cmake.org/Bug/view.php?id=15687 I plan to work on it during the next days so that it may be fixed with CMake 3.4. Thanks, Gregor From normanmr at ornl.gov Thu Aug 20 11:46:39 2015 From: normanmr at ornl.gov (Norman, Matthew R.) Date: Thu, 20 Aug 2015 15:46:39 +0000 Subject: [CMake] ":" character in flags Message-ID: <1440085601575.23244@ornl.gov> I have some flags for the PGI compiler that use the ":" character. Needless to say, things break whenever that character is in the CMAKE_Fortran_FLAGS variable. Any ideas how to work around this? Thanks, -Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From howard.rubin at hl.konicaminolta.us Thu Aug 20 11:33:51 2015 From: howard.rubin at hl.konicaminolta.us (Howard Rubin) Date: Thu, 20 Aug 2015 09:33:51 -0600 Subject: [CMake] How to use lib from include_external_msproject Message-ID: <01a101d0db5d$9daa4e90$d8feebb0$@hl.konicaminolta.us> I have a C++/CLI LIB (and DLL) that I generate with include_external_msproject. I need to link to it from my C++ project, which I'm trying to do with target_link_libraries. This gives the below error message. Since I'm not creating it with add_library I don't see how to indicate it's a shared lib. How can I indicate the lib is a SHARED lib, or otherwise link to it in a CMake project? CMake Error at modules/PptxWriterCpp/sample/CMakeLists.txt:4 (target_link_libraries): Target "PptxWriterCpp" of type UTILITY may not be linked into another target. One may link only to STATIC or SHARED libraries, or to executables with the ENABLE_EXPORTS property set. References: http://stackoverflow.com/questions/6399493/what-is-cli-c-exactly-how-does-it -differ-from-normal-c http://www.cmake.org/cmake/help/v2.8.10/cmake.html#command:include_external_ msproject http://www.cmake.org/cmake/help/v2.8.10/cmake.html#command:target_link_libra ries http://www.cmake.org/cmake/help/v2.8.10/cmake.html#command:add_library -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kent.Knox at amd.com Thu Aug 20 12:28:20 2015 From: Kent.Knox at amd.com (Knox, Kent) Date: Thu, 20 Aug 2015 16:28:20 +0000 Subject: [CMake] Modern superbuild template including support for Message-ID: <19F649914E0E4A4C82F9972E886B16CA44CC15D4@satlexdag04.amd.com> > I'm looking for a template or example project that shows the how to > setup a cmake-based project in the cleanest and simplest way (i.e. > using all the latest features of 3.3 release) and with support for the > following build features: I waited a few days to see if anybody else would volunteer their project, but I'm happy to ask for critique of the superbuild approach I set up recently. This is for an opencl sparse matrix library: https://github.com/clMathLibraries/clSPARSE Build instructions: https://github.com/clMathLibraries/clSPARSE/wiki/Build I think I only require features up to 2.8.12. I have 2 dependencies that I configure/build with the superbuild: boost & googlemock. The main clsparse library is also set up as an external dependency, so that it could be used independently. The root CMakeLists.txt file defines the superbuild, the cmake/External*.cmake files house the ExternalProject_Add() commands, and the library/CMakeLists.txt defines the library build. Would welcome comments/critiques from anybody with time. Kent ---------------------------------------------------------------------- Message: 6 Date: Mon, 17 Aug 2015 10:43:46 -0400 From: Taylor Braun-Jones To: cmake Subject: [CMake] Modern superbuild template including support for module dependencies Message-ID: Content-Type: text/plain; charset=UTF-8 Hi all, I'm looking for a template or example project that shows the how to setup a cmake-based project in the cleanest and simplest way (i.e. using all the latest features of 3.3 release) and with support for the following build features: - Superbuild mode that can be turned on or off (on by default) - Simple system for defining modules (libraries that get built either as static or dynamic libraries) and their dependencies. - install target that works with good default behaviors so that the CMakeLists.txt for modules and applications need minimal extra configuration. Should work in both superbuild mode (the project and all external projects get installed to the same CMAKE_INSTALL_PREFIX/DESTDIR when invoked at the top superbuild level) and in non-superbuild mode I've seen many examples of projects like this but my impression is that they have been around since long before the latest CMake releases and therefore weren't designed to take advantage of all the latest CMake features. My current attempt to setup a cmake-based build with these features is based on the MITK cmake build system[1] since it's something I was already familiar with. I have something that mostly works, but the number of lines of cmake code to make it all happen with simple interfaces like mitk_create_module, mitk_create_executable seems more than should be necessary which is going to make switching to CMake harder for me to "sell" to my team. I found this very simplistic CMake project example[2] but the resulting CMakeLists.txt to build an executable in that project looks like this: find_package (Threads REQUIRED) set (Boost_USE_STATIC_LIBS ON) # set (Boost_NO_SYSTEM_PATHS ON) find_package (Boost 1.55.0 REQUIRED COMPONENTS date_time filesystem system) include_directories (${Boost_INCLUDE_DIRS}) add_executable (blah main.cpp) target_link_libraries (blah ${Boost_LIBRARIES} ${CMAKE_THREAD_LIBS_INIT}) Whereas I'm looking for something that would allow me to write something like this: xxx_add_executable(blah PACKAGE_DEPENDS Boost DEPENDS mymodule main.cpp) (or some other similarly simple interface) Thanks in advance, Taylor [1] https://github.com/MITK/MITK [2] https://github.com/Sarcasm/cmake-superbuild From wonder.mice at gmail.com Thu Aug 20 15:29:56 2015 From: wonder.mice at gmail.com (Andrey Pokrovskiy) Date: Thu, 20 Aug 2015 12:29:56 -0700 Subject: [CMake] Modern superbuild template including support for In-Reply-To: <19F649914E0E4A4C82F9972E886B16CA44CC15D4@satlexdag04.amd.com> References: <19F649914E0E4A4C82F9972E886B16CA44CC15D4@satlexdag04.amd.com> Message-ID: Such approach doesn't work with IDE. For example, when I open main CMakeLists.txt in Qt Creator I only see two *.cmake files. Superbuilds use ExternalProject_Add() which kills a lot CMake benefits when used for CMake project from CMake project. On Thu, Aug 20, 2015 at 9:28 AM, Knox, Kent wrote: >> I'm looking for a template or example project that shows the how to >> setup a cmake-based project in the cleanest and simplest way (i.e. >> using all the latest features of 3.3 release) and with support for the >> following build features: > > I waited a few days to see if anybody else would volunteer their project, > but I'm happy to ask for critique of the superbuild approach I set up > recently. This is for an opencl sparse matrix library: > https://github.com/clMathLibraries/clSPARSE > Build instructions: > https://github.com/clMathLibraries/clSPARSE/wiki/Build > > I think I only require features up to 2.8.12. > I have 2 dependencies that I configure/build with the superbuild: > boost & googlemock. The main clsparse library is also set up as an > external dependency, so that it could be used independently. > > The root CMakeLists.txt file defines the superbuild, the cmake/External*.cmake > files house the ExternalProject_Add() commands, and the library/CMakeLists.txt > defines the library build. > > Would welcome comments/critiques from anybody with time. > > Kent > ---------------------------------------------------------------------- > Message: 6 > Date: Mon, 17 Aug 2015 10:43:46 -0400 > From: Taylor Braun-Jones > To: cmake > Subject: [CMake] Modern superbuild template including support for > module dependencies > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > Hi all, > > I'm looking for a template or example project that shows the how to > setup a cmake-based project in the cleanest and simplest way (i.e. > using all the latest features of 3.3 release) and with support for the > following build features: > > - Superbuild mode that can be turned on or off (on by default) > > - Simple system for defining modules (libraries that get built either > as static or dynamic libraries) and their dependencies. > > - install target that works with good default behaviors so that the > CMakeLists.txt for modules and applications need minimal extra > configuration. Should work in both superbuild mode (the project and > all external projects get installed to the same > CMAKE_INSTALL_PREFIX/DESTDIR when invoked at the top superbuild level) > and in non-superbuild mode > > I've seen many examples of projects like this but my impression is > that they have been around since long before the latest CMake releases > and therefore weren't designed to take advantage of all the latest > CMake features. My current attempt to setup a cmake-based build with > these features is based on the MITK cmake build system[1] since it's > something I was already familiar with. I have something that mostly > works, but the number of lines of cmake code to make it all happen > with simple interfaces like mitk_create_module, mitk_create_executable > seems more than should be necessary which is going to make switching > to CMake harder for me to "sell" to my team. > > I found this very simplistic CMake project example[2] but the > resulting CMakeLists.txt to build an executable in that project looks > like this: > > find_package (Threads REQUIRED) > > set (Boost_USE_STATIC_LIBS ON) > # set (Boost_NO_SYSTEM_PATHS ON) > find_package (Boost 1.55.0 REQUIRED COMPONENTS date_time filesystem system) > > include_directories (${Boost_INCLUDE_DIRS}) > > add_executable (blah > main.cpp) > > target_link_libraries (blah > ${Boost_LIBRARIES} > ${CMAKE_THREAD_LIBS_INIT}) > > > Whereas I'm looking for something that would allow me to write > something like this: > > xxx_add_executable(blah > PACKAGE_DEPENDS Boost > DEPENDS mymodule > main.cpp) > > (or some other similarly simple interface) > > Thanks in advance, > Taylor > > [1] https://github.com/MITK/MITK > [2] https://github.com/Sarcasm/cmake-superbuild > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From Kent.Knox at amd.com Thu Aug 20 16:11:35 2015 From: Kent.Knox at amd.com (Knox, Kent) Date: Thu, 20 Aug 2015 20:11:35 +0000 Subject: [CMake] Modern superbuild template including support for In-Reply-To: References: <19F649914E0E4A4C82F9972E886B16CA44CC15D4@satlexdag04.amd.com>, Message-ID: <19F649914E0E4A4C82F9972E886B16CA44CC2A89@satlexdag04.amd.com> I can vouch that the superbuild project works fine both for visual studio and for xcode. Using visual studio as an example, you generate a visual studio solution which downloads and compiles all dependencies, inclulding the library. After the initial build, you just use the solution file generated for the library thereafter. I've not tested QT Creater, but I'll see if I can verify your difficulties next week. ________________________________________ From: Andrey Pokrovskiy [wonder.mice at gmail.com] Sent: Thursday, August 20, 2015 2:29 PM To: Knox, Kent Cc: cmake at cmake.org Subject: Re: [CMake] Modern superbuild template including support for Such approach doesn't work with IDE. For example, when I open main CMakeLists.txt in Qt Creator I only see two *.cmake files. Superbuilds use ExternalProject_Add() which kills a lot CMake benefits when used for CMake project from CMake project. From wonder.mice at gmail.com Thu Aug 20 18:35:06 2015 From: wonder.mice at gmail.com (Andrey Pokrovskiy) Date: Thu, 20 Aug 2015 15:35:06 -0700 Subject: [CMake] Modern superbuild template including support for In-Reply-To: <19F649914E0E4A4C82F9972E886B16CA44CC2A89@satlexdag04.amd.com> References: <19F649914E0E4A4C82F9972E886B16CA44CC15D4@satlexdag04.amd.com> <19F649914E0E4A4C82F9972E886B16CA44CC2A89@satlexdag04.amd.com> Message-ID: Hm, I don't understand how that possibly could work (maybe there some explicit support for that in the project generator for MSVS). And are you able to browse the source code of all your dependencies (that were downloaded)? On Thu, Aug 20, 2015 at 1:11 PM, Knox, Kent wrote: > I can vouch that the superbuild project works fine both for visual studio and for xcode. Using visual studio as an example, you generate a visual studio solution which downloads and compiles all dependencies, inclulding the library. After the initial build, you just use the solution file generated for the library thereafter. I've not tested QT Creater, but I'll see if I can verify your difficulties next week. > ________________________________________ > From: Andrey Pokrovskiy [wonder.mice at gmail.com] > Sent: Thursday, August 20, 2015 2:29 PM > To: Knox, Kent > Cc: cmake at cmake.org > Subject: Re: [CMake] Modern superbuild template including support for > > Such approach doesn't work with IDE. For example, when I open main > CMakeLists.txt in Qt Creator I only see two *.cmake files. Superbuilds > use ExternalProject_Add() which kills a lot CMake benefits when used > for CMake project from CMake project. > From mjklaim at gmail.com Thu Aug 20 18:37:01 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Fri, 21 Aug 2015 00:37:01 +0200 Subject: [CMake] Modern superbuild template including support for In-Reply-To: <19F649914E0E4A4C82F9972E886B16CA44CC2A89@satlexdag04.amd.com> References: <19F649914E0E4A4C82F9972E886B16CA44CC15D4@satlexdag04.amd.com> <19F649914E0E4A4C82F9972E886B16CA44CC2A89@satlexdag04.amd.com> Message-ID: On 20 August 2015 at 22:11, Knox, Kent wrote: > I can vouch that the superbuild project works fine both for visual studio > and for xcode. Using visual studio as an example, you generate a visual > studio solution which downloads and compiles all dependencies, inclulding > the library. After the initial build, you just use the solution file > generated for the library thereafter. I've not tested QT Creater, but I'll > see if I can verify your difficulties next week. > I had major pains managing the dependencies of my main project via copy/pasting specific versions of the sources of my dependencies in a dependency repository. (which don't work well when updating and on other platforms than windows) Also note that not all my dependencies uses CMake so some of these are major pains. This version worked well enough until I tried to make it work on linux and I also have plans to change some dependencies and it's a major pain to update correctly. There were other issues but less important than that. So now I am trying to setup the something similar but with ExternalProject_Add() : https://bitbucket.org/klaim/netrush-dependencies-cmake This one is a work in progress but the dependencies currently does build on Windows and Linux. What's missing: - I want to setup package config files in the install directory, but I am having major troubles with this because; - the package file will need to provide imported targets to my dependencies under a specific namespace (like Qt does); - gtest and protobuf do not have install targets ( ;O; ) so I have to setup more stuffs so that the package config will have the right paths; - once this dependencies install works with my current version of my project, I will need to My experience so far: the copy pasting strategy ends up easier to setup than using externaldependencies, because you don't have to think with 2-steps download-build-instal&link; I am tempted to stop my efforts on this now, but I still have a few bits of energy left. Also I seem close to the end and couldn't evaluate the actual benefits (which I first assumed would have been ease of first-setup/update/patch/totally-change). I also can't pay someone to setup and manage the dependencies, like we have in the company where I work (so far I was talking about my biggest personal project which is still quite massive). Any help is welcome of course, if you have time to kill on this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjklaim at gmail.com Thu Aug 20 18:43:19 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Fri, 21 Aug 2015 00:43:19 +0200 Subject: [CMake] Modern superbuild template including support for In-Reply-To: References: <19F649914E0E4A4C82F9972E886B16CA44CC15D4@satlexdag04.amd.com> <19F649914E0E4A4C82F9972E886B16CA44CC2A89@satlexdag04.amd.com> Message-ID: On 21 August 2015 at 00:35, Andrey Pokrovskiy wrote: > And are you able to browse the source code of all your dependencies > (that were downloaded)? > I forgot to say that indeed if you use ExternalDependencies OR any non-source based way of linking your dependencies to your project, you don't get dependencies code in your IDE indeed. It's the major reason I started with copy/pasting code of my dependencies in my dependency repository. My dayjob uses the other aproach where you have only the code of your project in your IDE and must manually add dependencies targets when you need to. Most of the time it's not a problem but I suspect it depends a lot on the stability of the project. Not sure which is better, frankly, I am exploring ways to manage my dependencies in a fast way, and so far it's only major pain as long as I am targetting more than one platform and using C++. (note: no current dependency management tools attempts I tried solve my problems because they are all too intrusive and assume too much) Maybe a file format to represent any library in a platform-independant way would help. CMake is really describing a process to build a library, not the library itself and not in a way that allow any other tool to benefit from the library representation. There was discussions about this in the beginning of the year apparently but if my memory is correct it have been abandoned. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjklaim at gmail.com Thu Aug 20 18:45:23 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Fri, 21 Aug 2015 00:45:23 +0200 Subject: [CMake] Modern superbuild template including support for In-Reply-To: References: <19F649914E0E4A4C82F9972E886B16CA44CC15D4@satlexdag04.amd.com> <19F649914E0E4A4C82F9972E886B16CA44CC2A89@satlexdag04.amd.com> Message-ID: On 21 August 2015 at 00:43, Klaim - Jo?l Lamotte wrote: > On 21 August 2015 at 00:35, Andrey Pokrovskiy > wrote: > >> And are you able to browse the source code of all your dependencies >> (that were downloaded)? >> > > I forgot to say that indeed if you use ExternalDependencies OR any > non-source based way of linking your dependencies to your project, > you don't get dependencies code in your IDE indeed. > By the way there is another thing I didn't try because it don't work easily with dependencies not using cmake: - use externaldependencies but only to download the sources or binaries of the dependencies, deactivate all other steps (really it should be a separate function) - use add_subdirectory() to add the dependencies or other solutions appropriate for each dependency. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjklaim at gmail.com Thu Aug 20 18:53:48 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Fri, 21 Aug 2015 00:53:48 +0200 Subject: [CMake] How to use lib from include_external_msproject In-Reply-To: <01a101d0db5d$9daa4e90$d8feebb0$@hl.konicaminolta.us> References: <01a101d0db5d$9daa4e90$d8feebb0$@hl.konicaminolta.us> Message-ID: On 20 August 2015 at 17:33, Howard Rubin wrote: > I have a C++/CLI LIB (and DLL) that I generate with > include_external_msproject. I need to link to it from my C++ project, which > I?m trying to do with target_link_libraries. This gives the below error > message. Since I?m not creating it with add_library I don?t see how to > indicate it?s a shared lib. > > > > How can I indicate the lib is a SHARED lib, or otherwise link to it in a > CMake project? > > > Simply put, you cannot use target_link_libraries() with targets created with include_external_msproject(). To make it work, just use add_dependencies() instead. I don't remember how to specify SHARED in this case but I think it totally depends on the settings of the VS project file. It's one of the reasons some old project distribute the project file twice, one as shared library, the other as static library. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kent.Knox at amd.com Thu Aug 20 19:30:34 2015 From: Kent.Knox at amd.com (Knox, Kent) Date: Thu, 20 Aug 2015 23:30:34 +0000 Subject: [CMake] Modern superbuild template including support for In-Reply-To: References: <19F649914E0E4A4C82F9972E886B16CA44CC15D4@satlexdag04.amd.com> <19F649914E0E4A4C82F9972E886B16CA44CC2A89@satlexdag04.amd.com>, Message-ID: <19F649914E0E4A4C82F9972E886B16CA44CC2CA4@satlexdag04.amd.com> >And are you able to browse the source code of all your dependencies >(that were downloaded)? When you open the generated solution file to the superbuild, targets are made for all dependencies (in my case: boost, gmock, clsparse). From the superbuild view, you can not browse the source of the dependencies (the source is not even present until you build the first time). You build the solution, cmake merrily downloads the code for the dependencies (aside from clsparse that lives in the same repository) and builds the dependencies according the build instructions in the cmake/External*.cmake files. After the first build of the superbuild, close the superbuild solution as it's job is done. Open the solution file for the clsparse library, which was generated as part of the superbuild and is the 'meat' of the project. This solution file contains browse-able source code to all the files in the clsparse project. The Boost and gmock files are not directly browse-able (i.e. files listed in the solution/project), because do not want to rebuild dependencies if rebuilding the clsparse project (the dependencies change very seldom). However, visual studio's intellisense does start indexing boost and gmock because they are included in clsparse like any other header file or library, so they become 'browseable' through the IDE. I believe the same behavior happens with xcode. ________________________________________ From: Andrey Pokrovskiy [wonder.mice at gmail.com] Sent: Thursday, August 20, 2015 5:35 PM To: Knox, Kent Cc: cmake at cmake.org Subject: Re: [CMake] Modern superbuild template including support for Hm, I don't understand how that possibly could work (maybe there some explicit support for that in the project generator for MSVS). And are you able to browse the source code of all your dependencies (that were downloaded)? From Anthony.R.Ette at controlsdata.com Thu Aug 20 20:06:37 2015 From: Anthony.R.Ette at controlsdata.com (Ette, Anthony (CDS)) Date: Fri, 21 Aug 2015 00:06:37 +0000 Subject: [CMake] Imported libraries and cross platform target names In-Reply-To: <7328A63D-CA1F-4C63-A911-BAB774BED54F@ionicsecurity.com> References: <2C950720-E61E-4D10-93BF-231D3E733B6D@ionicsecurity.com> <2A375B5C08C24643A8A3F8CC2B98C1084BB20830@USINDPR-MBX003.Rolls-Royce.Local> <7328A63D-CA1F-4C63-A911-BAB774BED54F@ionicsecurity.com> Message-ID: <2A375B5C08C24643A8A3F8CC2B98C1084BB2110E@USINDPR-MBX003.Rolls-Royce.Local> Ok so I?ve got this going now (kind of) but FIND_LIBRARY doesn?t seem to update when the specified PATH changes. Since we are developing and releasing our own static libraries on a separate development cycle from the final applications, a final application may use a different library release than another. This means the application developer needs a method to point to different library releases (different locations on the filesystem). We?ve always used environment variables for this and the developer issues a ?workon? prior to developing an application. The workon sets up all the necessary env vars but FIND_LIBRARY doesn?t update when the env var does. For example, using either method 1 or 2 below to set an internal cmake variable doesn?t do the trick for the FIND_LIBRARY command to pick up a new libtest file in the new location. 1) FILE(TO_CMAKE_PATH $ENV{LIB_DIR} LIB_D) 2) SET(LIB_D $ENV{LIB_DIR} CACHE STRING "lib dir" FORCE) FIND_LIBRARY(libtest NAMES test PATHS {LIB_D} NO_DEFAULT_PATH) I?ve also tried using the env string directly in the FIND_LIBRARY command as below, but the library being used in the build tree Makefiles still does not get updated. I?ve also confirmed that the env var is updated when CMake is rerun using MESSAGE command, so I believe it is merely a problem with triggering a change to the FIND_LIBRARY command. How does this triggering work? How can I force FIND_LIBRARY to check again each time CMake runs? FIND_LIBRARY(libtest NAMES test PATHS $ENV{LIB_DIR} NO_DEFAULT_PATH) Thanks, Anthony Ette Control Systems Engineer Rolls-Royce Controls and Data Services 7661 N Perimeter Rd Indianapolis, IN 46241 tel: +1 (317) 230-6943 mob: +1 (317) 864-7975 email: Anthony.R.Ette at controlsdata.com From: Parag Chandra [mailto:parag at ionicsecurity.com] Sent: Tuesday, August 18, 2015 3:08 PM To: Ette, Anthony (CDS); CMake at cmake.org Subject: Re: [CMake] Imported libraries and cross platform target names Yes, very similar. When I set out to convert our existing build system, which consists of many individual .sln and .vcxproj files, I got a requirement that the developers do not all want to work out of the same ?uber? Xcode workspace/VS solution that contains all of the projects. They want to continue working with solutions that contain only the library of interest plus its associated test project. So when a developer runs CMake, a dependency like ?timer? may refer to another CMake-generated project within the current build system, or it may refer to an already-built/downloaded dependency of the same name. Parag Chandra Senior Software Engineer, Mobile Team Mobile: +1.919.824.1410 [https://www.ionicsecurity.com/IonicSigHz.png] Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 From: , "Anthony (CDS)" > Date: Tuesday, August 18, 2015 at 2:59 PM To: Parag Chandra >, "CMake at cmake.org" > Subject: RE: [CMake] Imported libraries and cross platform target names Thank you, I will take a look at find_library. The static libraries are ones we build in-house but in a separate CMake-generated build system. The reason we use a separate build system is because our common library code is used by all applications and, as such, is on a separate development cycle than the applications themselves. In other words, while there may be advantages to combining them, I don?t think it would really make sense in our case?.any thoughts? Are you in a similar situation? Anthony Ette Control Systems Engineer Rolls-Royce Controls and Data Services 7661 N Perimeter Rd Indianapolis, IN 46241 tel: +1 (317) 230-6943 mob: +1 (317) 864-7975 email: Anthony.R.Ette at controlsdata.com From: Parag Chandra [mailto:parag at ionicsecurity.com] Sent: Tuesday, August 18, 2015 2:45 PM To: Ette, Anthony (CDS); CMake at cmake.org Subject: Re: [CMake] Imported libraries and cross platform target names You just specify the ?basename? of the library, so something like this: find_library (timer NAMES timer PATHS your/library/directory) target_link_libraries(test timer) And Cmake takes care of the rest. It?s even easier if ?timer? is also part of the same CMake-generated build system. In that case, the find_library isn?t even needed. Things do get a little more complicated when you want to distinguish between release/debug variants of the same library. For that you can use the DEBUG and OPTIMIZED keywords of target_link_libraries(). Parag Chandra Senior Software Engineer, Mobile Team Mobile: +1.919.824.1410 [https://www.ionicsecurity.com/IonicSigHz.png] Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 From: , "Anthony (CDS)" > Date: Tuesday, August 18, 2015 at 2:29 PM To: "CMake at cmake.org" > Subject: [CMake] Imported libraries and cross platform target names Given that add_library() produces a unique filename per platform (the ?actual file name of the library built is constructed based on conventions of the native platform (such as lib.a or.lib?), how does one add the library to the final application without having to deal with the filename difference? In other words, I?ve got one library that, by default, produces ?libtest.a? on Linux and ?test.lib? on Windows. How can I add this imported library into the final application in a cross platform manner? I know I can specify two different imported locations (see below), but it seems odd to me that Cmake ? the cross-platform build env generator ? doesn?t have a better native way of dealing with this?. The snippet below will work, but just seems wrong given the nature of what CMake is intended to do?is there a better way that I?m missing?! If not, can I request that a future release of Cmake handle platform naming convention difference internally when invoking ADD_LIBRARY with the IMPORTED tag set? Ok so, to be fair, Cmake can be used to cross compile and that certainly complicates my feature request but, when not cross compiling, CMake knows what platform it?s being executed on so it should be able to resolve static archive platform decorations internally. ADD_LIBRARY(testSTATICIMPORTED) if(WIN32) SET_PROPERTY(TARGETtestPROPERTYIMPORTED_LOCATION ${LIB_D}/timer.lib) endif() if(UNIX) SET_PROPERTY(TARGETtestPROPERTYIMPORTED_LOCATION ${LIB_D}/libtimer.a) endif() Thanks in advance, Anthony Ette Control Systems Engineer Rolls-Royce Controls and Data Services 7661 N Perimeter Rd Indianapolis, IN 46241 tel: +1 (317) 230-6943 mob: +1 (317) 864-7975 email: Anthony.R.Ette at controlsdata.com This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. ______________________________________________________________________ This email has been scanned. This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. ______________________________________________________________________ This email has been scanned. This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wonder.mice at gmail.com Thu Aug 20 20:30:55 2015 From: wonder.mice at gmail.com (Andrey Pokrovskiy) Date: Thu, 20 Aug 2015 17:30:55 -0700 Subject: [CMake] Modern superbuild template including support for In-Reply-To: <19F649914E0E4A4C82F9972E886B16CA44CC2CA4@satlexdag04.amd.com> References: <19F649914E0E4A4C82F9972E886B16CA44CC15D4@satlexdag04.amd.com> <19F649914E0E4A4C82F9972E886B16CA44CC2A89@satlexdag04.amd.com> <19F649914E0E4A4C82F9972E886B16CA44CC2CA4@satlexdag04.amd.com> Message-ID: > After the first build of the superbuild, close the superbuild solution as it's job is done. > ... > Open the solution file for the clsparse library, which was generated as part of the superbuild > and is the 'meat' of the project. Heh, that's exactly what I meant - superbuilds don't work with IDE (meaning that CMake doesn't adds anything valuable in terms of integration of several CMake based packages here). You are still working with each sub-project (solution) individually as it was an independent project. For that reason I try to use add_subdirectory() for CMake-based 3rd-party dependencies (some make it incredibly hard though). Maybe I didn't worked with CMake that much, but I consider superbuilds a "hackish" solution. I know there is no a better one, though :) On Thu, Aug 20, 2015 at 4:30 PM, Knox, Kent wrote: >>And are you able to browse the source code of all your dependencies >>(that were downloaded)? > When you open the generated solution file to the superbuild, targets are made for all dependencies (in my case: boost, gmock, clsparse). From the superbuild view, you can not browse the source of the dependencies (the source is not even present until you build the first time). You build the solution, cmake merrily downloads the code for the dependencies (aside from clsparse that lives in the same repository) and builds the dependencies according the build instructions in the cmake/External*.cmake files. After the first build of the superbuild, close the superbuild solution as it's job is done. > > Open the solution file for the clsparse library, which was generated as part of the superbuild and is the 'meat' of the project. This solution file contains browse-able source code to all the files in the clsparse project. The Boost and gmock files are not directly browse-able (i.e. files listed in the solution/project), because do not want to rebuild dependencies if rebuilding the clsparse project (the dependencies change very seldom). However, visual studio's intellisense does start indexing boost and gmock because they are included in clsparse like any other header file or library, so they become 'browseable' through the IDE. I believe the same behavior happens with xcode. > > ________________________________________ > From: Andrey Pokrovskiy [wonder.mice at gmail.com] > Sent: Thursday, August 20, 2015 5:35 PM > To: Knox, Kent > Cc: cmake at cmake.org > Subject: Re: [CMake] Modern superbuild template including support for > > Hm, I don't understand how that possibly could work (maybe there some > explicit support for that in the project generator for MSVS). > And are you able to browse the source code of all your dependencies > (that were downloaded)? From DLRdave at aol.com Fri Aug 21 08:17:02 2015 From: DLRdave at aol.com (David Cole) Date: Fri, 21 Aug 2015 08:17:02 -0400 Subject: [CMake] Imported libraries and cross platform target names In-Reply-To: <2A375B5C08C24643A8A3F8CC2B98C1084BB2110E@USINDPR-MBX003.Rolls-Royce.Local> References: <2C950720-E61E-4D10-93BF-231D3E733B6D@ionicsecurity.com> <2A375B5C08C24643A8A3F8CC2B98C1084BB20830@USINDPR-MBX003.Rolls-Royce.Local> <7328A63D-CA1F-4C63-A911-BAB774BED54F@ionicsecurity.com> <2A375B5C08C24643A8A3F8CC2B98C1084BB2110E@USINDPR-MBX003.Rolls-Royce.Local> Message-ID: Find_library results are cached. If you want to re-find a potentially moved library every time you run, you would have to unset the cache variable prior to finding it. D On Thursday, August 20, 2015, Ette, Anthony (CDS) < Anthony.R.Ette at controlsdata.com> wrote: > Ok so I?ve got this going now (kind of) but FIND_LIBRARY doesn?t seem to > update when the specified PATH changes. Since we are developing and > releasing our own static libraries on a separate development cycle from the > final applications, a final application may use a different library release > than another. This means the application developer needs a method to point > to different library releases (different locations on the filesystem). > We?ve always used environment variables for this and the developer issues a > ?workon? prior to developing an application. The workon sets up all the > necessary env vars but FIND_LIBRARY doesn?t update when the env var does. > For example, using either method 1 or 2 below to set an internal cmake > variable doesn?t do the trick for the FIND_LIBRARY command to pick up a new > libtest file in the new location. > > > > > > 1) FILE(TO_CMAKE_PATH $ENV{LIB_DIR} LIB_D) > > 2) SET(LIB_D $ENV{LIB_DIR} CACHE STRING "lib dir" FORCE) > > > > FIND_LIBRARY(libtest NAMES test PATHS {LIB_D} NO_DEFAULT_PATH) > > > > > > > > I?ve also tried using the env string directly in the FIND_LIBRARY command > as below, but the library being used in the build tree Makefiles still does > not get updated. I?ve also confirmed that the env var *is* updated when > CMake is rerun using MESSAGE command, so I believe it is merely a problem > with triggering a change to the FIND_LIBRARY command. How does this > triggering work? How can I force FIND_LIBRARY to check again each time > CMake runs? > > > > FIND_LIBRARY(libtest NAMES test PATHS $ENV{LIB_DIR} > NO_DEFAULT_PATH) > > > > > > Thanks, > > > *Anthony Ette *Control Systems Engineer > > > > Rolls-Royce Controls and Data Services > > 7661 N Perimeter Rd > > Indianapolis, IN 46241 > > tel: +1 (317) 230-6943 > > mob: +1 (317) 864-7975 > > email: Anthony.R.Ette at controlsdata.com > > > > > *From:* Parag Chandra [mailto:parag at ionicsecurity.com > ] > *Sent:* Tuesday, August 18, 2015 3:08 PM > *To:* Ette, Anthony (CDS); CMake at cmake.org > > *Subject:* Re: [CMake] Imported libraries and cross platform target names > > > > Yes, very similar. When I set out to convert our existing build system, > which consists of many individual .sln and .vcxproj files, I got a > requirement that the developers do not all want to work out of the same > ?uber? Xcode workspace/VS solution that contains all of the projects. They > want to continue working with solutions that contain only the library of > interest plus its associated test project. So when a developer runs CMake, > a dependency like ?timer? may refer to another CMake-generated project > within the current build system, or it may refer to an > already-built/downloaded dependency of the same name. > > > *Parag Chandra* > Senior Software Engineer, Mobile Team > Mobile: +1.919.824.1410 > > > > Ionic Security Inc. > 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 > > > > *From: *, "Anthony (CDS)" > > *Date: *Tuesday, August 18, 2015 at 2:59 PM > *To: *Parag Chandra >, " > CMake at cmake.org " < > CMake at cmake.org > > *Subject: *RE: [CMake] Imported libraries and cross platform target names > > > > Thank you, I will take a look at find_library. The static libraries are > ones we build in-house but in a separate CMake-generated build system. The > reason we use a separate build system is because our common library code is > used by all applications and, as such, is on a separate development cycle > than the applications themselves. In other words, while there may be > advantages to combining them, I don?t think it would really make sense in > our case?.any thoughts? Are you in a similar situation? > > > > > *Anthony Ette *Control Systems Engineer > > > > Rolls-Royce Controls and Data Services > > 7661 N Perimeter Rd > > Indianapolis, IN 46241 > > tel: +1 (317) 230-6943 > > mob: +1 (317) 864-7975 > > email: Anthony.R.Ette at controlsdata.com > > > > > *From:* Parag Chandra [mailto:parag at ionicsecurity.com > ] > *Sent:* Tuesday, August 18, 2015 2:45 PM > *To:* Ette, Anthony (CDS); CMake at cmake.org > > *Subject:* Re: [CMake] Imported libraries and cross platform target names > > > > You just specify the ?basename? of the library, so something like this: > > > > find_library (timer NAMES timer PATHS your/library/directory) > > target_link_libraries(test timer) > > > > And Cmake takes care of the rest. It?s even easier if ?timer? is also part > of the same CMake-generated build system. In that case, the find_library > isn?t even needed. > > > > Things do get a little more complicated when you want to distinguish > between release/debug variants of the same library. For that you can use > the DEBUG and OPTIMIZED keywords of target_link_libraries(). > > > > > *Parag Chandra* > Senior Software Engineer, Mobile Team > Mobile: +1.919.824.1410 > > > > Ionic Security Inc. > 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 > > > > *From: *, "Anthony (CDS)" > > *Date: *Tuesday, August 18, 2015 at 2:29 PM > *To: *"CMake at cmake.org " > > > *Subject: *[CMake] Imported libraries and cross platform target names > > > > Given that add_library() produces a unique filename per platform (the > ?actual file name of the library built is constructed based on conventions > of the native platform (such as lib.a or.lib?), how does one > add the library to the final application without having to deal with the > filename difference? In other words, I?ve got one library that, by > default, produces ?libtest.a? on Linux and ?test.lib? on Windows. How can > I add this imported library into the final application in a cross platform > manner? I know I can specify two different imported locations (see below), > but it seems odd to me that Cmake ? the cross-platform build env generator > ? doesn?t have a better native way of dealing with this?. > > > > The snippet below will work, but just seems wrong given the nature of what > CMake is intended to do?is there a better way that I?m missing?! If not, > can I request that a future release of Cmake handle platform naming > convention difference internally when invoking ADD_LIBRARY with the > IMPORTED tag set? Ok so, to be fair, Cmake can be used to cross compile > and that certainly complicates my feature request but, when not cross > compiling, CMake knows what platform it?s being executed on so it should be > able to resolve static archive platform decorations internally. > > > > ADD_LIBRARY(testSTATICIMPORTED) > > if(WIN32) > > SET_PROPERTY(TARGETtestPROPERTYIMPORTED_LOCATION ${LIB_D}/timer.lib) > > endif() > > if(UNIX) > > SET_PROPERTY(TARGETtestPROPERTYIMPORTED_LOCATION ${LIB_D}/libtimer.a) > > endif() > > > > Thanks in advance, > > > *Anthony Ette *Control Systems Engineer > > > > Rolls-Royce Controls and Data Services > > 7661 N Perimeter Rd > > Indianapolis, IN 46241 > > tel: +1 (317) 230-6943 > > mob: +1 (317) 864-7975 > > email: Anthony.R.Ette at controlsdata.com > > > > > This e-mail (including attachments) contains contents owned by Rolls-Royce > plc and its subsidiaries, affiliated companies or customers and covered by > the laws of England and Wales, Brazil, US, or Canada (federal, state or > provincial). The information contained in this email is intended to be > confidential, may be legally privileged and subject to export controls > which may restrict the access to and transfer of the information. If you > are not the intended recipient, you are hereby notified that any retention, > dissemination, distribution, interception or copying of this communication > is strictly prohibited and may subject you to further legal action. Reply > to the sender if you received this email by accident, and then delete the > email and any attachments. > > > ______________________________________________________________________ > This email has been scanned. > > This e-mail (including attachments) contains contents owned by Rolls-Royce > plc and its subsidiaries, affiliated companies or customers and covered by > the laws of England and Wales, Brazil, US, or Canada (federal, state or > provincial). The information contained in this email is intended to be > confidential, may be legally privileged and subject to export controls > which may restrict the access to and transfer of the information. If you > are not the intended recipient, you are hereby notified that any retention, > dissemination, distribution, interception or copying of this communication > is strictly prohibited and may subject you to further legal action. Reply > to the sender if you received this email by accident, and then delete the > email and any attachments. > > > ______________________________________________________________________ > This email has been scanned. > This e-mail (including attachments) contains contents owned by Rolls-Royce > plc and its subsidiaries, affiliated companies or customers and covered by > the laws of England and Wales, Brazil, US, or Canada (federal, state or > provincial). The information contained in this email is intended to be > confidential, may be legally privileged and subject to export controls > which may restrict the access to and transfer of the information. If you > are not the intended recipient, you are hereby notified that any retention, > dissemination, distribution, interception or copying of this communication > is strictly prohibited and may subject you to further legal action. Reply > to the sender if you received this email by accident, and then delete the > email and any attachments. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Micha.Renner at t-online.de Fri Aug 21 08:20:48 2015 From: Micha.Renner at t-online.de (Micha Renner) Date: Fri, 21 Aug 2015 14:20:48 +0200 Subject: [CMake] CMAKE_PUSH_CHECK_STATE() Message-ID: <1440159648.8650.1.camel@t-online.de> Hallo, CMAKE_PUSH_CHECK_STATE() CMAKE_POP_CHECK_STATE() affect CMAKE_REQUIRED_FLAGS, CMAKE_REQUIRED_DEFINITIONS, CMAKE_REQUIRED_LIBRARIES and CMAKE_REQUIRED_INCLUDES. Maybe one can extend CMAKE_PUSH_CHECK_STATE() CMAKE_POP_CHECK_STATE() to controll CMAKE_EXTRA_INCLUDE_FILES also. Michael Renner From Anthony.R.Ette at controlsdata.com Fri Aug 21 09:03:54 2015 From: Anthony.R.Ette at controlsdata.com (Ette, Anthony (CDS)) Date: Fri, 21 Aug 2015 13:03:54 +0000 Subject: [CMake] Imported libraries and cross platform target names In-Reply-To: References: <2C950720-E61E-4D10-93BF-231D3E733B6D@ionicsecurity.com> <2A375B5C08C24643A8A3F8CC2B98C1084BB20830@USINDPR-MBX003.Rolls-Royce.Local> <7328A63D-CA1F-4C63-A911-BAB774BED54F@ionicsecurity.com> <2A375B5C08C24643A8A3F8CC2B98C1084BB2110E@USINDPR-MBX003.Rolls-Royce.Local> Message-ID: <2A375B5C08C24643A8A3F8CC2B98C1084BB212AE@USINDPR-MBX003.Rolls-Royce.Local> Thank you; unset works perfectly. Anthony Ette Control Systems Engineer Rolls-Royce Controls and Data Services 7661 N Perimeter Rd Indianapolis, IN 46241 tel: +1 (317) 230-6943 mob: +1 (317) 864-7975 email: Anthony.R.Ette at controlsdata.com From: David Cole [mailto:DLRdave at aol.com] Sent: Friday, August 21, 2015 8:17 AM To: Ette, Anthony (CDS) Cc: Parag Chandra; CMake at cmake.org Subject: Re: [CMake] Imported libraries and cross platform target names Find_library results are cached. If you want to re-find a potentially moved library every time you run, you would have to unset the cache variable prior to finding it. D On Thursday, August 20, 2015, Ette, Anthony (CDS) > wrote: Ok so I?ve got this going now (kind of) but FIND_LIBRARY doesn?t seem to update when the specified PATH changes. Since we are developing and releasing our own static libraries on a separate development cycle from the final applications, a final application may use a different library release than another. This means the application developer needs a method to point to different library releases (different locations on the filesystem). We?ve always used environment variables for this and the developer issues a ?workon? prior to developing an application. The workon sets up all the necessary env vars but FIND_LIBRARY doesn?t update when the env var does. For example, using either method 1 or 2 below to set an internal cmake variable doesn?t do the trick for the FIND_LIBRARY command to pick up a new libtest file in the new location. 1) FILE(TO_CMAKE_PATH $ENV{LIB_DIR} LIB_D) 2) SET(LIB_D $ENV{LIB_DIR} CACHE STRING "lib dir" FORCE) FIND_LIBRARY(libtest NAMES test PATHS {LIB_D} NO_DEFAULT_PATH) I?ve also tried using the env string directly in the FIND_LIBRARY command as below, but the library being used in the build tree Makefiles still does not get updated. I?ve also confirmed that the env var is updated when CMake is rerun using MESSAGE command, so I believe it is merely a problem with triggering a change to the FIND_LIBRARY command. How does this triggering work? How can I force FIND_LIBRARY to check again each time CMake runs? FIND_LIBRARY(libtest NAMES test PATHS $ENV{LIB_DIR} NO_DEFAULT_PATH) Thanks, Anthony Ette Control Systems Engineer Rolls-Royce Controls and Data Services 7661 N Perimeter Rd Indianapolis, IN 46241 tel: +1 (317) 230-6943 mob: +1 (317) 864-7975 email: Anthony.R.Ette at controlsdata.com From: Parag Chandra [mailto:parag at ionicsecurity.com] Sent: Tuesday, August 18, 2015 3:08 PM To: Ette, Anthony (CDS); CMake at cmake.org Subject: Re: [CMake] Imported libraries and cross platform target names Yes, very similar. When I set out to convert our existing build system, which consists of many individual .sln and .vcxproj files, I got a requirement that the developers do not all want to work out of the same ?uber? Xcode workspace/VS solution that contains all of the projects. They want to continue working with solutions that contain only the library of interest plus its associated test project. So when a developer runs CMake, a dependency like ?timer? may refer to another CMake-generated project within the current build system, or it may refer to an already-built/downloaded dependency of the same name. Parag Chandra Senior Software Engineer, Mobile Team Mobile: +1.919.824.1410 [https://www.ionicsecurity.com/IonicSigHz.png] Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 From: , "Anthony (CDS)" > Date: Tuesday, August 18, 2015 at 2:59 PM To: Parag Chandra >, "CMake at cmake.org" > Subject: RE: [CMake] Imported libraries and cross platform target names Thank you, I will take a look at find_library. The static libraries are ones we build in-house but in a separate CMake-generated build system. The reason we use a separate build system is because our common library code is used by all applications and, as such, is on a separate development cycle than the applications themselves. In other words, while there may be advantages to combining them, I don?t think it would really make sense in our case?.any thoughts? Are you in a similar situation? Anthony Ette Control Systems Engineer Rolls-Royce Controls and Data Services 7661 N Perimeter Rd Indianapolis, IN 46241 tel: +1 (317) 230-6943 mob: +1 (317) 864-7975 email: Anthony.R.Ette at controlsdata.com From: Parag Chandra [mailto:parag at ionicsecurity.com] Sent: Tuesday, August 18, 2015 2:45 PM To: Ette, Anthony (CDS); CMake at cmake.org Subject: Re: [CMake] Imported libraries and cross platform target names You just specify the ?basename? of the library, so something like this: find_library (timer NAMES timer PATHS your/library/directory) target_link_libraries(test timer) And Cmake takes care of the rest. It?s even easier if ?timer? is also part of the same CMake-generated build system. In that case, the find_library isn?t even needed. Things do get a little more complicated when you want to distinguish between release/debug variants of the same library. For that you can use the DEBUG and OPTIMIZED keywords of target_link_libraries(). Parag Chandra Senior Software Engineer, Mobile Team Mobile: +1.919.824.1410 [https://www.ionicsecurity.com/IonicSigHz.png] Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 From: , "Anthony (CDS)" > Date: Tuesday, August 18, 2015 at 2:29 PM To: "CMake at cmake.org" > Subject: [CMake] Imported libraries and cross platform target names Given that add_library() produces a unique filename per platform (the ?actual file name of the library built is constructed based on conventions of the native platform (such as lib.a or.lib?), how does one add the library to the final application without having to deal with the filename difference? In other words, I?ve got one library that, by default, produces ?libtest.a? on Linux and ?test.lib? on Windows. How can I add this imported library into the final application in a cross platform manner? I know I can specify two different imported locations (see below), but it seems odd to me that Cmake ? the cross-platform build env generator ? doesn?t have a better native way of dealing with this?. The snippet below will work, but just seems wrong given the nature of what CMake is intended to do?is there a better way that I?m missing?! If not, can I request that a future release of Cmake handle platform naming convention difference internally when invoking ADD_LIBRARY with the IMPORTED tag set? Ok so, to be fair, Cmake can be used to cross compile and that certainly complicates my feature request but, when not cross compiling, CMake knows what platform it?s being executed on so it should be able to resolve static archive platform decorations internally. ADD_LIBRARY(testSTATICIMPORTED) if(WIN32) SET_PROPERTY(TARGETtestPROPERTYIMPORTED_LOCATION ${LIB_D}/timer.lib) endif() if(UNIX) SET_PROPERTY(TARGETtestPROPERTYIMPORTED_LOCATION ${LIB_D}/libtimer.a) endif() Thanks in advance, Anthony Ette Control Systems Engineer Rolls-Royce Controls and Data Services 7661 N Perimeter Rd Indianapolis, IN 46241 tel: +1 (317) 230-6943 mob: +1 (317) 864-7975 email: Anthony.R.Ette at controlsdata.com This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. ______________________________________________________________________ This email has been scanned. This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. ______________________________________________________________________ This email has been scanned. This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. ______________________________________________________________________ This email has been scanned. This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kent.Knox at amd.com Fri Aug 21 13:33:50 2015 From: Kent.Knox at amd.com (Knox, Kent) Date: Fri, 21 Aug 2015 17:33:50 +0000 Subject: [CMake] Modern superbuild template including support for In-Reply-To: References: <19F649914E0E4A4C82F9972E886B16CA44CC15D4@satlexdag04.amd.com> <19F649914E0E4A4C82F9972E886B16CA44CC2A89@satlexdag04.amd.com> <19F649914E0E4A4C82F9972E886B16CA44CC2CA4@satlexdag04.amd.com> Message-ID: <19F649914E0E4A4C82F9972E886B16CA44CCD406@satlexdag05.amd.com> I think I have a different perspective. I don't want Boost or gmock to be considered a part of clsparse in any visible way (I don't want them in my IDE); I want them truly separate and external. I like cmake to download and build dependencies for me in an automated fashion, but I don't want the requirement to either check in the source of the dependency, or to set up my git repository to use submodules. I shouldn't rebuild dependencies when I rebuild my project. Superbuilds have been working quite nicely for me in these ways. -----Original Message----- From: Andrey Pokrovskiy [mailto:wonder.mice at gmail.com] Sent: Thursday, August 20, 2015 7:31 PM To: Knox, Kent Cc: cmake at cmake.org Subject: Re: [CMake] Modern superbuild template including support for > After the first build of the superbuild, close the superbuild solution as it's job is done. > ... > Open the solution file for the clsparse library, which was generated > as part of the superbuild and is the 'meat' of the project. Heh, that's exactly what I meant - superbuilds don't work with IDE (meaning that CMake doesn't adds anything valuable in terms of integration of several CMake based packages here). You are still working with each sub-project (solution) individually as it was an independent project. For that reason I try to use add_subdirectory() for CMake-based 3rd-party dependencies (some make it incredibly hard though). Maybe I didn't worked with CMake that much, but I consider superbuilds a "hackish" solution. I know there is no a better one, though :) From mauro.ziliani.tmp at gmail.com Sat Aug 22 13:11:12 2015 From: mauro.ziliani.tmp at gmail.com (Mauro Ziliani) Date: Sat, 22 Aug 2015 19:11:12 +0200 Subject: [CMake] CMake and Visual Studio multiconfig solution Message-ID: Hi all. My name is mauro and i am a freelance programmer and I work different platforms: windows and Linux. I'm trying cmake 3.3.1 and I am in trouble to do this. I need to compile my app with visual studio and achieve the follow behavior. If I compile the app in debug configuration I need to append the suffix _dbg to the app name, nothing in release configuration. That is, if the app's name is test in debug configuration I'd like to obtain test_dbg.exe. Using makefile and make command I can obtain the same behavior by conditional compilation with command make BUILD=debug ====> test_dbg.exe My CMakeLists.txt is -------- cmake_minimum_required(VERSION 3.3) Project(test_vs) add_executable(test test.cpp) set_target_properties(test PROPERTIES DEBUG_SUFFIX "_dbg") ------ But it doesn't work. Either for debug and release configuration the app's name is test.exe Any ideas? Best regards, Mauro -------------- next part -------------- An HTML attachment was scrubbed... URL: From iosif.neitzke+cmake at gmail.com Sat Aug 22 13:42:05 2015 From: iosif.neitzke+cmake at gmail.com (Iosif Neitzke) Date: Sat, 22 Aug 2015 12:42:05 -0500 Subject: [CMake] CMake and Visual Studio multiconfig solution In-Reply-To: References: Message-ID: DEBUG_POSTFIX? http://www.cmake.org/cmake/help/v3.3/prop_tgt/DEBUG_POSTFIX.html On Sat, Aug 22, 2015 at 12:11 PM, Mauro Ziliani wrote: > Hi all. > My name is mauro and i am a freelance programmer and I work different > platforms: windows and Linux. > I'm trying cmake 3.3.1 and I am in trouble to do this. > > I need to compile my app with visual studio and achieve the follow behavior. > If I compile the app in debug configuration I need to append the suffix _dbg > to the app name, nothing in release configuration. > That is, if the app's name is test in debug configuration I'd like to obtain > test_dbg.exe. > > Using makefile and make command I can obtain the same behavior by > conditional compilation with command > > make BUILD=debug ====> test_dbg.exe > > My CMakeLists.txt is > > -------- > cmake_minimum_required(VERSION 3.3) > > Project(test_vs) > > add_executable(test test.cpp) > > set_target_properties(test PROPERTIES DEBUG_SUFFIX "_dbg") > ------ > > But it doesn't work. > > Either for debug and release configuration the app's name is test.exe > > Any ideas? > > Best regards, > Mauro > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From mauro.ziliani.tmp at gmail.com Sat Aug 22 14:42:28 2015 From: mauro.ziliani.tmp at gmail.com (Mauro Ziliani) Date: Sat, 22 Aug 2015 20:42:28 +0200 Subject: [CMake] CMake and Visual Studio multiconfig solution In-Reply-To: References: Message-ID: Oh Yes I mean DEBUG_POSTFIX. DEBUG_POSTFIX? http://www.cmake.org/cmake/help/v3.3/prop_tgt/DEBUG_POSTFIX.html On Sat, Aug 22, 2015 at 12:11 PM, Mauro Ziliani wrote: > Hi all. > My name is mauro and i am a freelance programmer and I work different > platforms: windows and Linux. > I'm trying cmake 3.3.1 and I am in trouble to do this. > > I need to compile my app with visual studio and achieve the follow behavior. > If I compile the app in debug configuration I need to append the suffix _dbg > to the app name, nothing in release configuration. > That is, if the app's name is test in debug configuration I'd like to obtain > test_dbg.exe. > > Using makefile and make command I can obtain the same behavior by > conditional compilation with command > > make BUILD=debug ====> test_dbg.exe > > My CMakeLists.txt is > > -------- > cmake_minimum_required(VERSION 3.3) > > Project(test_vs) > > add_executable(test test.cpp) > > set_target_properties(test PROPERTIES DEBUG_SUFFIX "_dbg") > ------ > > But it doesn't work. > > Either for debug and release configuration the app's name is test.exe > > Any ideas? > > Best regards, > Mauro > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Sat Aug 22 22:43:17 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Sat, 22 Aug 2015 21:43:17 -0500 Subject: [CMake] How to depend on external cmake projects? In-Reply-To: <12d201d0d8ff$d58e3070$80aa9150$@motionview3d.com> References: <12d201d0d8ff$d58e3070$80aa9150$@motionview3d.com> Message-ID: On Mon, Aug 17, 2015 at 10:17 AM, James Johnston wrote: > Well, you'd do this in conjunction with ExternalProject_Add. A well-written > CMake external project will provide a Config.cmake file which you > will then find using find_package. After toying around with this idea for a bit, I've found out that ExternalProject_Add() actually builds the project from a custom target within Visual Studio (I'm using VS as my generator). However, find_package() works at CMake configure time, so this is a chicken & egg problem. find_package() won't work because the external project has not been built yet. How do you solve this problem? > A high-level CMake project that does nothing but call ExternalProject_Add; > this is called a superbuild. Your own CMake projects will be > ExternalProjects to this high-level project and the superbuild would pass > the location to your project via -D_DIR= so that > find_package can locate the Config file. I'm not sure I understand this. This smells related to my question above, maybe an answer even. Can you clarify/go into more detail? Thanks a bunch. From ovz at yahoo.com Sun Aug 23 00:46:17 2015 From: ovz at yahoo.com (Oleg Zhylin) Date: Sun, 23 Aug 2015 04:46:17 +0000 (UTC) Subject: [CMake] Use CMAKE_MACOSX_RPATH to link a library outside build tree Message-ID: <876554837.8735323.1440305177088.JavaMail.yahoo@mail.yahoo.com> Hi All, I still need help with?0015708: Use CMAKE_MACOSX_RPATH to link a library outside build tree - MantisBT. Could you please suggest are there any CMake mechanisms to ensure a library outside build tree on mac is linked with either @rpath and using hard-coded path on build machine? Either option would actually help.? | ? | | ? | ? | ? | ? | ? | | 0015708: Use CMAKE_MACOSX_RPATH to link a library outside build tree - MantisBTThis issue is Mac OS X specific. I would like to link a library lib_xxx that sits outside my build tree at some arbitrary location. It will be at the same location in all systems. | | | | View on www.cmake.org | Preview by Yahoo | | | | ? | ?WBR ovz -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dave at Yost.com Sun Aug 23 20:04:47 2015 From: Dave at Yost.com (Dave Yost) Date: Sun, 23 Aug 2015 17:04:47 -0700 Subject: [CMake] dates on web site Message-ID: Hi. To many people in the world, partly because you use periods, 03.12.2015 looks like December 3 10.09.2014 looks like Sept 10 whereas 2015-03.12 means March 12 to everyone. 2014-10-09 means Oct 9 to everyone I suggest you switch to ISO 8601 for dates, which will cause no difficulties for non-American users. Dave The dates currently on the home page are unambiguous Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-1.png Type: image/png Size: 54315 bytes Desc: not available URL: From ovz at yahoo.com Sun Aug 23 23:10:38 2015 From: ovz at yahoo.com (Oleg Zhylin) Date: Mon, 24 Aug 2015 03:10:38 +0000 (UTC) Subject: [CMake] =?utf-8?q?CMake_generates_=E2=80=9C-L/usr/local/lib?= =?utf-8?q?=E2=80=9D_on_Mac_OSX?= Message-ID: <1290984953.9126484.1440385838662.JavaMail.yahoo@mail.yahoo.com> I have a CMake C++ dylib project that builds correctly in one MacOS X environment but fails in another. Environments are on the same machine, but under different users. I'm seeking help how to do I troubleshoot where the failure in the second one comes from.What I managed to figure out is that in failing configuration CMake adds the following flags in link.txt (the commands used to link the executable)-arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -mmacosx-version-min=10.6 -L/usr/local/lib The last one causes havoc as it makes ld pick up dependencies from /usr/local/lib instead of link directories I configured in CMake.I would appreciate any insight what triggers generating the flags above and what is the best way to squelch them, especially -L/usr/local/lib??WBR Oleg Zhylin ovz at yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From JamesJ at motionview3d.com Mon Aug 24 10:32:10 2015 From: JamesJ at motionview3d.com (James Johnston) Date: Mon, 24 Aug 2015 14:32:10 -0000 Subject: [CMake] How to depend on external cmake projects? In-Reply-To: References: <12d201d0d8ff$d58e3070$80aa9150$@motionview3d.com> Message-ID: <021201d0de79$a9fb4450$fdf1ccf0$@motionview3d.com> > -----Original Message----- > From: rcdailey at gmail.com [mailto:rcdailey at gmail.com] On Behalf Of Robert > Dailey > Sent: Sunday, August 23, 2015 02:43 > To: James Johnston > Cc: CMake > Subject: Re: [CMake] How to depend on external cmake projects? > > On Mon, Aug 17, 2015 at 10:17 AM, James Johnston > wrote: > > Well, you'd do this in conjunction with ExternalProject_Add. A > > well-written CMake external project will provide a > > Config.cmake file which you will then find using find_package. > > After toying around with this idea for a bit, I've found out that > ExternalProject_Add() actually builds the project from a custom target within > Visual Studio (I'm using VS as my generator). However, > find_package() works at CMake configure time, so this is a chicken & egg > problem. find_package() won't work because the external project has not > been built yet. > > How do you solve this problem? By following the following suggestion from earlier: > > > A high-level CMake project that does nothing but call > > ExternalProject_Add; this is called a superbuild. Your own CMake > > projects will be ExternalProjects to this high-level project and the > > superbuild would pass the location to your project via > > -D_DIR= so that find_package can locate the Config > file. > > I'm not sure I understand this. This smells related to my question above, > maybe an answer even. Can you clarify/go into more detail? > Thanks a bunch. Here is an example: https://github.com/InsightSoftwareConsortium/ITKWikiExamples/tree/master/Superbuild This CMakeLists.txt is the root CMakeLists.txt for the superbuild. Notice that: 1. It calls ExternalProject_Add to build VTK/ITK, **as well as** its own project. 2. find_package is not called from the superbuild, thus avoiding the chicken and egg problem. Best regards, James Johnston From clinton at elemtech.com Mon Aug 24 10:22:13 2015 From: clinton at elemtech.com (Clinton Stimpson) Date: Mon, 24 Aug 2015 08:22:13 -0600 Subject: [CMake] Use CMAKE_MACOSX_RPATH to link a library outside build tree In-Reply-To: <876554837.8735323.1440305177088.JavaMail.yahoo@mail.yahoo.com> References: <876554837.8735323.1440305177088.JavaMail.yahoo@mail.yahoo.com> Message-ID: <96038260.arOBJrlSTh@stryke> On Sunday, August 23, 2015 04:46:17 AM Oleg Zhylin via CMake wrote: > Hi All, > I still need help with 0015708: Use CMAKE_MACOSX_RPATH to link a library > outside build tree - MantisBT. Could you please suggest are there any CMake > mechanisms to ensure a library outside build tree on mac is linked with > either @rpath and using hard-coded path on build machine? Either option > would actually help. > | | > | | | | | | > | 0015708: Use CMAKE_MACOSX_RPATH to link a library outside build tree - > | MantisBTThis issue is Mac OS X specific. I would like to link a library > | lib_xxx that sits outside my build tree at some arbitrary location. It > | will be at the same location in all systems. | > | > | View on www.cmake.org | Preview by Yahoo | > | > | | > > WBR ovz There is no CMake mechanism to control references when linking with external libraries. If you still want to do this, you'll need to edit the references in your binaries after linking. You'll be much better off if you modify the external libraries. For @rpath, use a command like this: or For absolute path If those external libraries have additional dependencies using @executable_path, you may also need to use "install_name_tool -change ..." Clint From tamas.kenez at gmail.com Mon Aug 24 12:26:33 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Mon, 24 Aug 2015 18:26:33 +0200 Subject: [CMake] How to depend on external cmake projects? In-Reply-To: <12d201d0d8ff$d58e3070$80aa9150$@motionview3d.com> References: <12d201d0d8ff$d58e3070$80aa9150$@motionview3d.com> Message-ID: On Mon, Aug 17, 2015 at 5:17 PM, James Johnston wrote: > [...] Your own CMake projects will be > ExternalProjects to this high-level project and the superbuild would pass > the location to your project via -D_DIR= so that > find_package can locate the Config file. > I think a more convenient and also more conforming solution would be to pass the location of a single install directory (-DCMAKE_INSTALL_PREFIX=...) and pass the same dir also as prefix path (-DCMAKE_PREFIX_PATH=...) to all projects. All the projects of the superbuild will search for dependencies (config modules) in this directory and also install their own config modules into this directory. This directory is best to create inside the superbuild dir (like /out) and of course removed from source control. CMAKE_PREFIX_PATH may additionally contain other, central locations for other libraries built outside of the superbuild. Tamas -------------- next part -------------- An HTML attachment was scrubbed... URL: From ovz at yahoo.com Mon Aug 24 15:14:35 2015 From: ovz at yahoo.com (Oleg Zhylin) Date: Mon, 24 Aug 2015 19:14:35 +0000 (UTC) Subject: [CMake] Use CMAKE_MACOSX_RPATH to link a library outside build tree In-Reply-To: <96038260.arOBJrlSTh@stryke> References: <96038260.arOBJrlSTh@stryke> Message-ID: <1374801347.9539612.1440443675840.JavaMail.yahoo@mail.yahoo.com> Thanks for your response Clint.? I ended up copying my external library to?${CMAKE_RUNTIME_OUTPUT_DIRECTORY}. Works for my use case better than patching that external library that might get updated by a 3rd party installer.??WBR Oleg Zhylin ovz at yahoo.com On Monday, August 24, 2015 7:22 AM, Clinton Stimpson wrote: On Sunday, August 23, 2015 04:46:17 AM Oleg Zhylin via CMake wrote: > Hi All, > I still need help with 0015708: Use CMAKE_MACOSX_RPATH to link a library > outside build tree - MantisBT. Could you please suggest are there any CMake > mechanisms to ensure a library outside build tree on mac is linked with > either @rpath and using hard-coded path on build machine? Either option > would actually help. > |? | > |? |? |? |? |? | > | 0015708: Use CMAKE_MACOSX_RPATH to link a library outside build tree - > | MantisBTThis issue is Mac OS X specific. I would like to link a library > | lib_xxx that sits outside my build tree at some arbitrary location. It > | will be at the same location in all systems.? | > | > | View on www.cmake.org | Preview by Yahoo | > | > |? | > >? WBR ovz There is no CMake mechanism to control references when linking with external libraries.? If you still want to do this, you'll need to edit the references in your binaries after linking. You'll be much better off if you modify the external libraries. For @rpath, use a command like this: or For absolute path If those external libraries have additional dependencies using @executable_path, you may also need to use "install_name_tool -change ..." Clint -------------- next part -------------- An HTML attachment was scrubbed... URL: From ovz at yahoo.com Mon Aug 24 15:15:00 2015 From: ovz at yahoo.com (Oleg Zhylin) Date: Mon, 24 Aug 2015 19:15:00 +0000 (UTC) Subject: [CMake] =?utf-8?q?CMake_generates_=E2=80=9C-L/usr/local/lib?= =?utf-8?q?=E2=80=9D_on_Mac_OSX?= In-Reply-To: <1290984953.9126484.1440385838662.JavaMail.yahoo@mail.yahoo.com> References: <1290984953.9126484.1440385838662.JavaMail.yahoo@mail.yahoo.com> Message-ID: <147079060.9629657.1440443700178.JavaMail.yahoo@mail.yahoo.com> Gonzalo, Could you please elaborate, where should I check it? Will CMake indeed generate -L/usr/local/lib argument for the linker if it sees something in LD_LIBRARY_PATH? Do you have any insight why other flags (-arch, -isysroot) get generated in one environment, but not the other?????? ?WBR Oleg Zhylin ovz at yahoo.com On Sunday, August 23, 2015 8:10 PM, Oleg Zhylin wrote: I have a CMake C++ dylib project that builds correctly in one MacOS X environment but fails in another. Environments are on the same machine, but under different users. I'm seeking help how to do I troubleshoot where the failure in the second one comes from.What I managed to figure out is that in failing configuration CMake adds the following flags in link.txt (the commands used to link the executable)-arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -mmacosx-version-min=10.6 -L/usr/local/lib The last one causes havoc as it makes ld pick up dependencies from /usr/local/lib instead of link directories I configured in CMake.I would appreciate any insight what triggers generating the flags above and what is the best way to squelch them, especially -L/usr/local/lib??WBR Oleg Zhylin ovz at yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggarra13 at gmail.com Mon Aug 24 15:16:08 2015 From: ggarra13 at gmail.com (Gonzalo) Date: Mon, 24 Aug 2015 16:16:08 -0300 Subject: [CMake] =?utf-8?q?CMake_generates_=E2=80=9C-L/usr/local/lib?= =?utf-8?q?=E2=80=9D_on_Mac_OSX?= In-Reply-To: <1362713907.5143719.1440443584066.JavaMail.yahoo@mail.yahoo.com> References: <55DB33D7.6020006@gmail.com> <1362713907.5143719.1440443584066.JavaMail.yahoo@mail.yahoo.com> Message-ID: <55DB6D78.4030502@gmail.com> El 24/08/15 a las 16:13, Oleg Zhylin escibi?: > Gonzalo, > > Could you please elaborate, where should I check it? In the shell, do: echo $LD_LIBRARY_PATH and check the directories. I am not sure cmake pays attention to it, but I believe it might. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fifteenknots505 at gmail.com Mon Aug 24 16:02:05 2015 From: fifteenknots505 at gmail.com (Martin Weber) Date: Mon, 24 Aug 2015 22:02:05 +0200 Subject: [CMake] dates on web site In-Reply-To: References: Message-ID: <2380091.D6YPk7cTHs@linux> Am Sonntag, 23. August 2015, 17:04:47 schrieb Dave Yost: ... > I suggest you switch to ISO 8601 > for dates, which will cause no difficulties for non-American users. +1 I always get confused with middle-endian dates. -- Cd wrttn wtht vwls s mch trsr. From ond at semanchuk.com Tue Aug 25 10:30:14 2015 From: ond at semanchuk.com (Philip Semanchuk) Date: Tue, 25 Aug 2015 10:30:14 -0400 Subject: [CMake] How to add to CMAKE_C_FLAGS during cache priming? Message-ID: <55DC7BF6.4030507@semanchuk.com> Hi there, I'm relatively new to CMake. I'm trying to build a 3rd party library under Windows. (The 3rd party library happens to be an old-ish version of ITK.) I want to add a compile flag (/bigobj) during the cache priming step, but I can't figure out how to do it. Either my changes get ignored, or I overwrite the default flags completely which is not what I want either. I just want to add my flag to the default flags for all compile steps. Here's what I'm doing: I have a file called prime_cache.cmake, and I invoke CMake like so: cmake -C prime_cache.cmake ..\the_source_code prime_cache.cmake contains this: set(COMPILE_FLAGS /bigobj) set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${COMPILE_FLAGS}" CACHE STRING "") set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${COMPILE_FLAGS}" CACHE STRING "") When CMake is done, CMakeLists.txt contains this: CMAKE_C_FLAGS:STRING= /bigobj But I want this: CMAKE_C_FLAGS:STRING= /bigobj /DWIN32 /D_WINDOWS /W3 I've also tried modifying CMAKE_C_FLAGS_INIT, but that didn't affect CMAKE_C_FLAGS. I realize that I can hand-edit CMakeCache.txt to get the flags I want, but this is a small part of a much larger process and hand-editing is tedious and error-prone so I want to avoid it if possible. I'm using CMake 2.8.12.2 and would prefer to continue using this version even though it's not current. Thanks for a great tool, Philip From parag at ionicsecurity.com Tue Aug 25 11:34:06 2015 From: parag at ionicsecurity.com (Parag Chandra) Date: Tue, 25 Aug 2015 15:34:06 +0000 Subject: [CMake] How to add to CMAKE_C_FLAGS during cache priming? In-Reply-To: <55DC7BF6.4030507@semanchuk.com> References: <55DC7BF6.4030507@semanchuk.com> Message-ID: Hi Philip, I think I had a similar problem a while back. You basically need to initialize CMake?s cache values the first time you run it to create a new build system. So something like this: cmake -C InitialCacheValues.cmake And then your InitialCacheValues.cmake would contain the extra stuff you need to prime the cache with. For example, I do something like this to add additional configurations: set (CMAKE_CONFIGURATION_TYPES Debug;Release;RelWithDebInfo;MinSizeRel;Debug_RTLDLL;Release_RTLDLL;RelWith DebInfo_RTLDLL;MinSizeRel_RTLDLL CACHE INTERNAL "Configuration types" FORCE) foreach (cfg "DEBUG" "RELEASE" "MINSIZEREL" "RELWITHDEBINFO") foreach (flag "CXX" "C" "EXE_LINKER" "MODULE_LINKER" "SHARED_LINKER" "STATIC_LINKER") set (CMAKE_${flag}_FLAGS_${cfg}_RTLDLL ${CMAKE_${flag}_FLAGS_${cfg}} CACHE STRING "${flag} flags for ${cfg}_RTLDLL" FORCE) endforeach () endforeach () Here you can see that I essentially copy all the important flags from existing configurations that CMake is already going to create, and then later on in my CMakeLists I adjust them as needed. Hope this helps. Parag Chandra Senior Software Engineer, Mobile Team Mobile: +1.919.824.1410 Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 On 8/25/15, 2:30 PM, "Philip Semanchuk" wrote: >Hi there, >I'm relatively new to CMake. I'm trying to build a 3rd party library >under Windows. (The 3rd party library happens to be an old-ish version >of ITK.) I want to add a compile flag (/bigobj) during the cache priming >step, but I can't figure out how to do it. Either my changes get >ignored, or I overwrite the default flags completely which is not what I >want either. I just want to add my flag to the default flags for all >compile steps. > >Here's what I'm doing: I have a file called prime_cache.cmake, and I >invoke CMake like so: >cmake -C prime_cache.cmake ..\the_source_code > >prime_cache.cmake contains this: >set(COMPILE_FLAGS /bigobj) >set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${COMPILE_FLAGS}" CACHE STRING "") >set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${COMPILE_FLAGS}" CACHE STRING "") > >When CMake is done, CMakeLists.txt contains this: >CMAKE_C_FLAGS:STRING= /bigobj > >But I want this: >CMAKE_C_FLAGS:STRING= /bigobj /DWIN32 /D_WINDOWS /W3 > >I've also tried modifying CMAKE_C_FLAGS_INIT, but that didn't affect >CMAKE_C_FLAGS. > >I realize that I can hand-edit CMakeCache.txt to get the flags I want, >but this is a small part of a much larger process and hand-editing is >tedious and error-prone so I want to avoid it if possible. > >I'm using CMake 2.8.12.2 and would prefer to continue using this version >even though it's not current. > >Thanks for a great tool, >Philip > >-- > >Powered by www.kitware.com > >Please keep messages on-topic and check the CMake FAQ at: >http://www.cmake.org/Wiki/CMake_FAQ > >Kitware offers various services to support the CMake community. For more >information on each offering, please visit: > >CMake Support: http://cmake.org/cmake/help/support.html >CMake Consulting: http://cmake.org/cmake/help/consulting.html >CMake Training Courses: http://cmake.org/cmake/help/training.html > >Visit other Kitware open-source projects at >http://www.kitware.com/opensource/opensource.html > >Follow this link to subscribe/unsubscribe: >http://public.kitware.com/mailman/listinfo/cmake From avi.a.tevet at intel.com Tue Aug 25 19:04:12 2015 From: avi.a.tevet at intel.com (Tevet, Avi A) Date: Tue, 25 Aug 2015 23:04:12 +0000 Subject: [CMake] ExternalProject git clone hangs on windows In-Reply-To: References: Message-ID: Just to close the loop: the problem is, I believe, some kind of network problem and not a cmake, git, or ssh misconfiguration problem. I have found that the clone is very, very slow when using VPN & Samba, even for small repos. It is intermittently slow when using Samba but not using VPN. It turns out that what I thought was a hang was actually just an extremely slow git clone, which I found out by letting the MSVC build run for 30 minutes; when I returned, the clone had completed. Avi From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Tevet, Avi A Sent: Monday, August 17, 2015 10:10 AM To: Sergei Nikulov Cc: cmake at cmake.org Subject: Re: [CMake] ExternalProject git clone hangs on windows Thanks, I hadn?t thought about the SSH problem. I?ll investigate. From: Sergei Nikulov [mailto:sergey.nikulov at gmail.com] Sent: Friday, August 14, 2015 11:06 PM To: Tevet, Avi A Cc: cmake at cmake.org Subject: Re: [CMake] ExternalProject git clone hangs on windows 15 ???. 2015 ?. 3:04 AM ???????????? "Tevet, Avi A" > ???????: > > Hi all, > > > Can someone please tell me what I need to do so that I can use VS2015 to build a project with git dependencies managed through ExternalProject_add? > Try clone git project using url from ExternalPoject_add. Possible git will request something interactively - like add ssh key of remote host or request password. If so, this was a reason for hang. As solution - add host keys permanently or change url to https/local clone scheme. If password used on ssh key - remove it if possible. HTH, > > Thanks, > > > > Avi > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From ovz at yahoo.com Tue Aug 25 19:38:09 2015 From: ovz at yahoo.com (Oleg Zhylin) Date: Tue, 25 Aug 2015 23:38:09 +0000 (UTC) Subject: [CMake] =?utf-8?q?CMake_generates_=E2=80=9C-L/usr/local/lib?= =?utf-8?q?=E2=80=9D_on_Mac_OSX?= In-Reply-To: <55DB6D78.4030502@gmail.com> References: <55DB6D78.4030502@gmail.com> Message-ID: <1686074806.559536.1440545889382.JavaMail.yahoo@mail.yahoo.com> I confirmed there's nothing in?$LD_LIBRARY_PATH??in both the environment where the build succeeds and where it fails.? I will gladly try other suggestions.? WBR Oleg Zhylin ovz at yahoo.com On Monday, August 24, 2015 12:16 PM, Gonzalo wrote: El 24/08/15 a las 16:13, Oleg Zhylin escibi?: Gonzalo, Could you please elaborate, where should I check it? In the shell, do: echo $LD_LIBRARY_PATH and check the directories.? I am not sure cmake pays attention to it, but I believe it might. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.shaitorov at gmail.com Wed Aug 26 05:48:58 2015 From: andrew.shaitorov at gmail.com (Andrew Shaitorov) Date: Wed, 26 Aug 2015 12:48:58 +0300 Subject: [CMake] Prefix header for Makefiles Message-ID: Hi All! I have a very annoying problem with CMake Makefiles generator. I'm using prefix header (see attached archive for minimized test). There is one source file named Main.cpp and two header files: Prefix.h and DependHeader.h. Prefix.h includes DependHeader.h and Main.cpp includes Prefix.h by using prefix header compiler flag (-include for GCC/Clang and /FI for MSVC): set_source_files_properties(Main.cpp PROPERTIES COMPILE_FLAGS "-include Prefix.h" OBJECT_DEPENDS ${CMAKE_CURRENT_LIST_DIR}/Prefix.h) When I change Prefix.h, then make recompiles Main.cpp as needed. But when I make a change in DependHeader.h, then no recompilation happens. Its clear for me that I have to specify all depend files in OBJECT_DEPENDS option, but in real project there may be a lot of depend files with nested includes. And the most annoying thing is that the project compiles without any errors and may just crash because of struct layout or other critical changes in depend headers. I seems like the following script have the same problem when using FORCE_INCLUDE option: https://github.com/larsch/cmake-precompiled-header/blob/master/PrecompiledHeader.cmake I looked in CMake source code and didn't find a way to add Prefix.h in a list for dependency scanning. Also I don't know how to run depend scanner on Prefix.h in CMake script to generate a list of all depend files for OBJECT_DEPENDS option. Any advise? Best, Andrew. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CMakePrefixHeaderTest.zip Type: application/zip Size: 1028 bytes Desc: not available URL: From jsvanbethlehem at gmail.com Wed Aug 26 09:10:32 2015 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Wed, 26 Aug 2015 15:10:32 +0200 Subject: [CMake] Prefix header for Makefiles In-Reply-To: References: Message-ID: Hej Andrew, CMake does never scan source files (as far as I know), as it is not a compiler. From your question it almost seem you are making this assumption, so I just wanted to make sure to mention at least this. Then, for your particular issue: two things that come to my mind: * I?d imagine you have somewhere a add_executable(main Main.cpp Prefix.h DependHeader.h) - as far as I can tell, the only thing that really matters, is that the main executable gets recompiled whenever you make a change in any of the headers. To put it differently, I *don?t* think you (should) need the OBJECT_DEPENDS. * If you?re worried about scaling, maybe you could have a look at the file(GLOB ) command. However, be sure to also carefully read the potential problems with that approach. In my current (big) project, we explicitly list each source file for most parts of the source tree. In practice you?re surely *not* going to add all 50 new files at once. It is a very simple thing to add the newly created file to some variable in the correct CMakeLists.txt file. You just have to remember to do it, it?s really not a big deal. By the way, we?re actually using the PrecompiledHeader script - it works flawlessly. Sincerely, Jakob > On 26 Aug 2015, at 11:48, Andrew Shaitorov wrote: > > Hi All! > > I have a very annoying problem with CMake Makefiles generator. > > I'm using prefix header (see attached archive for minimized test). > > There is one source file named Main.cpp and two header files: Prefix.h and DependHeader.h. Prefix.h includes DependHeader.h and Main.cpp includes Prefix.h by using prefix header compiler flag (-include for GCC/Clang and /FI for MSVC): > > set_source_files_properties(Main.cpp PROPERTIES > COMPILE_FLAGS "-include Prefix.h" > OBJECT_DEPENDS ${CMAKE_CURRENT_LIST_DIR}/Prefix.h) > > When I change Prefix.h, then make recompiles Main.cpp as needed. But when I make a change in DependHeader.h, then no recompilation happens. Its clear for me that I have to specify all depend files in OBJECT_DEPENDS option, but in real project there may be a lot of depend files with nested includes. And the most annoying thing is that the project compiles without any errors and may just crash because of struct layout or other critical changes in depend headers. > > I seems like the following script have the same problem when using FORCE_INCLUDE option: > > https://github.com/larsch/cmake-precompiled-header/blob/master/PrecompiledHeader.cmake > > I looked in CMake source code and didn't find a way to add Prefix.h in a list for dependency scanning. Also I don't know how to run depend scanner on Prefix.h in CMake script to generate a list of all depend files for OBJECT_DEPENDS option. > > Any advise? > > Best, > 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: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at sap.com Wed Aug 26 09:45:40 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Wed, 26 Aug 2015 13:45:40 +0000 Subject: [CMake] Prefix header for Makefiles In-Reply-To: References: Message-ID: Hi, You are wrong. CMake, during configuration/generation phase generates dependencies over C/C++ files. So, the simple approach to handle dependency between Cpp and h files is to let CMake handle it: add_executable (my_exe Main.cpp) And, that it! By default current source directory is passed to the compiler for resolving #include directives. And for adding other directories, use command target_include_directories. Marc From: CMake on behalf of Jakob van Bethlehem Date: Wednesday 26 August 2015 15:10 To: "cmake at cmake.org" Subject: Re: [CMake] Prefix header for Makefiles Hej Andrew, CMake does never scan source files (as far as I know), as it is not a compiler. From your question it almost seem you are making this assumption, so I just wanted to make sure to mention at least this. Then, for your particular issue: two things that come to my mind: * I?d imagine you have somewhere a add_executable(main Main.cpp Prefix.h DependHeader.h) - as far as I can tell, the only thing that really matters, is that the main executable gets recompiled whenever you make a change in any of the headers. To put it differently, I *don?t* think you (should) need the OBJECT_DEPENDS. * If you?re worried about scaling, maybe you could have a look at the file(GLOB ) command. However, be sure to also carefully read the potential problems with that approach. In my current (big) project, we explicitly list each source file for most parts of the source tree. In practice you?re surely *not* going to add all 50 new files at once. It is a very simple thing to add the newly created file to some variable in the correct CMakeLists.txt file. You just have to remember to do it, it?s really not a big deal. By the way, we?re actually using the PrecompiledHeader script - it works flawlessly. Sincerely, Jakob On 26 Aug 2015, at 11:48, Andrew Shaitorov > wrote: Hi All! I have a very annoying problem with CMake Makefiles generator. I'm using prefix header (see attached archive for minimized test). There is one source file named Main.cpp and two header files: Prefix.h and DependHeader.h. Prefix.h includes DependHeader.h and Main.cpp includes Prefix.h by using prefix header compiler flag (-include for GCC/Clang and /FI for MSVC): set_source_files_properties(Main.cpp PROPERTIES COMPILE_FLAGS "-include Prefix.h" OBJECT_DEPENDS ${CMAKE_CURRENT_LIST_DIR}/Prefix.h) When I change Prefix.h, then make recompiles Main.cpp as needed. But when I make a change in DependHeader.h, then no recompilation happens. Its clear for me that I have to specify all depend files in OBJECT_DEPENDS option, but in real project there may be a lot of depend files with nested includes. And the most annoying thing is that the project compiles without any errors and may just crash because of struct layout or other critical changes in depend headers. I seems like the following script have the same problem when using FORCE_INCLUDE option: https://github.com/larsch/cmake-precompiled-header/blob/master/PrecompiledHeader.cmake I looked in CMake source code and didn't find a way to add Prefix.h in a list for dependency scanning. Also I don't know how to run depend scanner on Prefix.h in CMake script to generate a list of all depend files for OBJECT_DEPENDS option. Any advise? Best, 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: http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From apaku at gmx.de Wed Aug 26 10:43:27 2015 From: apaku at gmx.de (Andreas Pakulat) Date: Wed, 26 Aug 2015 16:43:27 +0200 Subject: [CMake] Prefix header for Makefiles In-Reply-To: References: Message-ID: Hi, On Wed, Aug 26, 2015 at 3:10 PM, Jakob van Bethlehem < jsvanbethlehem at gmail.com> wrote: > Hej Andrew, > > CMake does never scan source files (as far as I know), as it is not a > compiler. From your question it almost seem you are making this assumption, > so I just wanted to make sure to mention at least this. > Thats wrong, CMake has to parse the source files you add to a target to be able to determine its dependencies (recursively) so it can generate makefile rules that ensure that if one of the (indirectly) included headers changes the source file is recompiled. You can see this in cmDependsC.cxx in the CMake sources for C (and possibly C++) source files. It of course does not parse the C/C++ code, it merely finds lines that start with #include or #import and figures out the absolute path of the mentioned header file based on the targets include directories. Of course you can help CMake here by specifying all headers in the add_executable/add_library call, but that easily ends up being a maintenance nightmare for files outside of your actual project (system headers, third-party libraries etc.). Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Wed Aug 26 12:37:54 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Wed, 26 Aug 2015 12:37:54 -0400 Subject: [CMake] Prefix header for Makefiles In-Reply-To: References: Message-ID: <55DDEB62.7000901@kitware.com> CMake does not really support this. At build time CMake scans the source files and builds the depend list. Since your file is not actually included it does not end up in the depend list. To add this as a feature you would have to put the information into DependInfo.cmake and have cmDependsC.cxx read the information. If you are interested, I would suggest you come up with a patch and post it to the cmake-developer mailing list. You could also try the ninja generator as it uses the compiler to compute depends and should have the correct information. -Bill From ond at semanchuk.com Wed Aug 26 13:10:45 2015 From: ond at semanchuk.com (Philip Semanchuk) Date: Wed, 26 Aug 2015 13:10:45 -0400 Subject: [CMake] How to add to CMAKE_C_FLAGS during cache priming? In-Reply-To: References: <55DC7BF6.4030507@semanchuk.com> Message-ID: <55DDF315.4070106@semanchuk.com> On 8/25/2015 11:34 AM, Parag Chandra wrote: > Hi Philip, > > I think I had a similar problem a while back. You basically need to > initialize CMake?s cache values the first time you run it to create a new > build system. So something like this: > > cmake -C InitialCacheValues.cmake > > And then your InitialCacheValues.cmake would contain the extra stuff you > need to prime the cache with. For example, I do something like this to add > additional configurations: > > set (CMAKE_CONFIGURATION_TYPES > Debug;Release;RelWithDebInfo;MinSizeRel;Debug_RTLDLL;Release_RTLDLL;RelWith > DebInfo_RTLDLL;MinSizeRel_RTLDLL CACHE INTERNAL "Configuration types" > FORCE) > foreach (cfg "DEBUG" "RELEASE" "MINSIZEREL" "RELWITHDEBINFO") > foreach (flag "CXX" "C" "EXE_LINKER" "MODULE_LINKER" "SHARED_LINKER" > "STATIC_LINKER") > set (CMAKE_${flag}_FLAGS_${cfg}_RTLDLL ${CMAKE_${flag}_FLAGS_${cfg}} > CACHE STRING "${flag} flags for ${cfg}_RTLDLL" FORCE) > endforeach () > endforeach () > > > Here you can see that I essentially copy all the important flags from > existing configurations that CMake is already going to create, and then > later on in my CMakeLists I adjust them as needed. Thanks, Parag. I thought what I wanted to do would be almost trivial. Your suggestion confirms that it's a little more complicated than I expected. I appreciate the input. Cheers Philip > > On 8/25/15, 2:30 PM, "Philip Semanchuk" wrote: > >> Hi there, >> I'm relatively new to CMake. I'm trying to build a 3rd party library >> under Windows. (The 3rd party library happens to be an old-ish version >> of ITK.) I want to add a compile flag (/bigobj) during the cache priming >> step, but I can't figure out how to do it. Either my changes get >> ignored, or I overwrite the default flags completely which is not what I >> want either. I just want to add my flag to the default flags for all >> compile steps. >> >> Here's what I'm doing: I have a file called prime_cache.cmake, and I >> invoke CMake like so: >> cmake -C prime_cache.cmake ..\the_source_code >> >> prime_cache.cmake contains this: >> set(COMPILE_FLAGS /bigobj) >> set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${COMPILE_FLAGS}" CACHE STRING "") >> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${COMPILE_FLAGS}" CACHE STRING "") >> >> When CMake is done, CMakeLists.txt contains this: >> CMAKE_C_FLAGS:STRING= /bigobj >> >> But I want this: >> CMAKE_C_FLAGS:STRING= /bigobj /DWIN32 /D_WINDOWS /W3 >> >> I've also tried modifying CMAKE_C_FLAGS_INIT, but that didn't affect >> CMAKE_C_FLAGS. >> >> I realize that I can hand-edit CMakeCache.txt to get the flags I want, >> but this is a small part of a much larger process and hand-editing is >> tedious and error-prone so I want to avoid it if possible. >> >> I'm using CMake 2.8.12.2 and would prefer to continue using this version >> even though it's not current. >> >> Thanks for a great tool, >> Philip >> From daniel.wirtz at simtech.uni-stuttgart.de Thu Aug 27 03:24:25 2015 From: daniel.wirtz at simtech.uni-stuttgart.de (Daniel Wirtz) Date: Thu, 27 Aug 2015 09:24:25 +0200 Subject: [CMake] Missing -lgfortran with FortranCInterface verify calls Message-ID: <55DEBB29.1050904@simtech.uni-stuttgart.de> Hey all, i'm encountering link errors on C-Fortran interface verification on MSYS2 (fully updated) / MinGW (x86_64-4.9.2-posix-seh-rt_v4-rev2) / CMake 3.3.0. Here's a minimal example: cmake_minimum_required(VERSION 3.0 FATAL_ERROR) project(C_Fortran_Mingw VERSION 1.0 LANGUAGES C Fortran) include(FortranCInterface) FortranCInterface_VERIFY() this fails with link errors D:/MSYS2_64/mingw64/bin/gcc.exe -O3 -DNDEBUG -Wl,--whole-archive CMakeFiles/VerifyFortranC.dir/objects.a -Wl,--no-whole-archive -o VerifyFortranC.exe -Wl,--out-implib,libVerifyFortranC.dll.a -Wl,--major-image-version,0,--minor-image-version,0 @CMakeFiles/VerifyFortranC.dir/linklibs.rsp libVerifyFortran.a(VerifyFortran.f.obj):VerifyFortran.f:(.text+0x35): undefined reference to `_gfortran_st_write' libVerifyFortran.a(VerifyFortran.f.obj):VerifyFortran.f:(.text+0x4a): undefined reference to `_gfortran_transfer_character_write' libVerifyFortran.a(VerifyFortran.f.obj):VerifyFortran.f:(.text+0x52): undefined reference to `_gfortran_st_write_done' after checking, the @CMakeFiles/VerifyFortranC.dir/linklibs.rsp does not contain the "-lgfortran" library include, hence the fuss. however, while that might fix the issue, i've found no way to tell the FortranCInterface scripts to add that, and following Brad's argumentation in http://cmake.3232098.n2.nabble.com/mixing-c-fortran-missing-gfortran-sometimes-td5563701.html, CMake should pick those things up automatically. so am i missing something obvious here or is this still an (mingw-only) issue? to be clear, i can just skip the verification tests and everything works, but i'd like to think that if that is the case the FortranCInterface_VERIFY() should work as well. thanks! Daniel -- Dr. Daniel Wirtz Dipl. Math. Dipl. Inf. SRC SimTech Pfaffenwaldring 5a, D-70569 Stuttgart +49 (711) 685-60044 From asynodin at mech.upatras.gr Thu Aug 27 04:11:59 2015 From: asynodin at mech.upatras.gr (Aris Synodinos) Date: Thu, 27 Aug 2015 11:11:59 +0300 Subject: [CMake] CMake/CPack Docker Integration Message-ID: [Apologies for cross posting] Dear all, We have received funding from the Greek Free/Open Source Software Society to develop Docker integration to CMake and CPack. As a first step, we have created a simple questionnaire for collecting user and developer input towards the features that would be most useful. We would appreciate it if you could spend some time to answer it by following this link . It will take less than 5 minutes of your time and your feedback is valuable. Thank you very much, Best regards, Aris Synodinos & Konstantinos Chatzilygeroudis Aris Synodinos PhD Student Robotics Group Mechanical and Aeronautics Engineering Department Tel. +30-2610-996248 e-mail: asynodin at mech.upatras.gr Web: http://progtologist.github.io/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.froger.ml at mailoo.org Thu Aug 27 19:14:05 2015 From: david.froger.ml at mailoo.org (David Froger) Date: Fri, 28 Aug 2015 01:14:05 +0200 Subject: [CMake] compiler in not standard path and secondary dependence for shared libraries Message-ID: <20150827231405.31363.54697@fl-58186.rocq.inria.fr> Hello, When linking an executable with a library `libfoo.so` that depedent on a library `libbar.so` in a non standard directory, flag `-Wl,-rpath-link=...` is required so that `ld` can find `libar.so`. It works well with /usr/bin/gcc and libraries somewhere in a non standard directory, CMake uses the flag `-Wl,-rpath-link`. But in this case: /path/to/somewhere/bin/gcc /path/to/somewhere/lib/libfoo.so /path/to/somewhere/lib/libbar.so and with /path/to/somewhere/bin in the PATH, without setting LD_LIBRARY_PATH, CMake drops the flag `-Wl,-rpath-link=...` and the build fails. My context is using the Conda package manager. GCC, CMake and ITK are installed in a Conda environment (which is in the PATH), and the user want to link with ITK libraries. I would like to fix the problem without requiring user's "hack", for example setting LD_LIBRARY_PATH or -DCMAKE_EXE_LINKER_FLAGS. Any idea? I have this "foo bar" example to reproduce the problem: https://github.com/dfroger/secondary_dep Thanks, David From nico.schloemer at gmail.com Fri Aug 28 04:23:47 2015 From: nico.schloemer at gmail.com (=?UTF-8?Q?Nico_Schl=C3=B6mer?=) Date: Fri, 28 Aug 2015 08:23:47 +0000 Subject: [CMake] linking: absolute path vs -l Message-ID: Hi everyone, I'm curious about when CMake decides to link a library by its absolute path and when it links using the `-l*` syntax. I came across this for the very simple test problem ``` cmake_minimum_required(VERSION 3.0) project(mytest) find_package(ZLIB REQUIRED) find_package(netCDF REQUIRED) add_executable(mytest main.cpp) target_link_libraries( mytest ${ZLIB_LIBRARIES} ${netCDF_LIBRARIES} ) ``` The resulting link line is ``` /usr/bin/c++ CMakeFiles/mytest.dir/main.cpp.o -o mytest -rdynamic -lz /usr/lib/x86_64-linux-gnu/libnetcdf.so.7.3.0 ``` so ZLIB is linked with `-lz`, netCDF with the full absolute path. Seems inconsistent? (ZLIB by the way is found through CMake's FindZLIB.cmake, netCDF by their own export files.) So far, I had been under the impression that `-l*` defeats the purpose of CMake a little bit as it asks the linker to search in the system's paths for a libz.so, something CMake has already done. A little clarification here would be great. Cheers, Nico -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Aug 28 11:15:28 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 28 Aug 2015 11:15:28 -0400 Subject: [CMake] Missing -lgfortran with FortranCInterface verify calls In-Reply-To: <55DEBB29.1050904@simtech.uni-stuttgart.de> References: <55DEBB29.1050904@simtech.uni-stuttgart.de> Message-ID: <55E07B10.30809@kitware.com> On 08/27/2015 03:24 AM, Daniel Wirtz wrote: > CMake 3.3.0. [snip] > after checking, the @CMakeFiles/VerifyFortranC.dir/linklibs.rsp does not > contain the "-lgfortran" library include, hence the fuss. I managed to reproduce this and track down the problem. Here is a fix based on 3.3.1: Makefile: Print color escapes only when necessary http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=371fe92e Please try out that version. Thanks, -Brad From jamesbigler at gmail.com Fri Aug 28 11:59:57 2015 From: jamesbigler at gmail.com (James Bigler) Date: Fri, 28 Aug 2015 15:59:57 +0000 Subject: [CMake] Adding file to IDE folder without adding files to targets Message-ID: I want to have some files show up in the IDE. I know I can add files to targets, but the problem is these files don't belong to a particular target. It would be nice to have them show up in a folder (similar to how the target FOLDER property or source_group function works). Is this possible? Thanks, James -------------- next part -------------- An HTML attachment was scrubbed... URL: From mauro.ziliani.tmp at gmail.com Sat Aug 29 04:29:13 2015 From: mauro.ziliani.tmp at gmail.com (Mauro Ziliani) Date: Sat, 29 Aug 2015 10:29:13 +0200 Subject: [CMake] wxWidgets and Visual Studio Message-ID: Hi all. I'm porting my projects from bakefile (legacy) generator to cmake. The projects will be generated for vs2008 e gcc linux. When I generate for vs2008 either for Debug and Release the wx include directory is ${WXWIN}/include/vc_lib/mswu, while i expected that for Debug the include dir should be ${WXWIN}/include/vc_lib/mswud for Release the include dir should be ${WXWIN}/include/vc_lib/mswu Any experience about that? Best regards, Mauro -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.froger.ml at mailoo.org Sun Aug 30 04:41:12 2015 From: david.froger.ml at mailoo.org (David Froger) Date: Sun, 30 Aug 2015 10:41:12 +0200 Subject: [CMake] do not hardcode system library absolute path Message-ID: <20150830084112.15554.31185@fl-58186.rocq.inria.fr> Hi, When CMake exports libraries that depend on system library, absolute path to these system libraries are hardcoded in CMakefile configuration files. For example, when building and installing ITK, the file lib/cmake/ITK-4.7ITKTargets-release.cmake is installed and contain a reference to /usr/lib64/libm.so . My problem is that I want to build a conda package for ITK on Centos OS 5.11, then install this ITK package on Ubuntu 14.04, and link with ITK libraries. But it fails as libm is search in /usr/lib64/libm.so instead of /lib/x86_64-linux-gnu/libm.so.6 . Here is a minimal example to reproduce the problem without ITK: https://github.com/dfroger/gravitation Is there an way in CMake to export libraries without absolute path to dependant system libraries? Thanks, David From eric.noulard at gmail.com Sun Aug 30 05:31:00 2015 From: eric.noulard at gmail.com (Eric Noulard) Date: Sun, 30 Aug 2015 11:31:00 +0200 Subject: [CMake] do not hardcode system library absolute path In-Reply-To: <20150830084112.15554.31185@fl-58186.rocq.inria.fr> References: <20150830084112.15554.31185@fl-58186.rocq.inria.fr> Message-ID: 2015-08-30 10:41 GMT+02:00 David Froger : > Hi, > > When CMake exports libraries that depend on system library, absolute path > to > these system libraries are hardcoded in CMakefile configuration files. > > For example, when building and installing ITK, the file > lib/cmake/ITK-4.7ITKTargets-release.cmake is installed and contain > a reference to /usr/lib64/libm.so . > > My problem is that I want to build a conda package for ITK on Centos OS > 5.11, > then install this ITK package on Ubuntu 14.04, and link with ITK libraries. > > But it fails as libm is search in /usr/lib64/libm.so instead of > /lib/x86_64-linux-gnu/libm.so.6 . > > Here is a minimal example to reproduce the problem without ITK: > https://github.com/dfroger/gravitation > > Is there an way in CMake to export libraries without absolute path to > dependant system libraries? > I guess that you can set INSTALL_RPATH on a particular target that needs it; see http://www.cmake.org/Wiki/CMake_RPATH_handling and http://www.cmake.org/cmake/help/v3.0/prop_tgt/INSTALL_RPATH.html http://www.cmake.org/cmake/help/v3.0/prop_tgt/INSTALL_RPATH_USE_LINK_PATH.html -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From snake.scaly at gmail.com Sun Aug 30 12:34:27 2015 From: snake.scaly at gmail.com (SnakE) Date: Sun, 30 Aug 2015 19:34:27 +0300 Subject: [CMake] Creating a derived executable target on Windows/Visual Studio Message-ID: Hello CMake pros, I wonder if what I'm trying to do is possible. I have an executable target, let's call it "normal". I want to create another target, called "derived", which would be a UPX-compressed version of "normal", and which I would be able to install as if it was a regular CMake target. E.g. add_executable(normal ${sources} ${libs}) # magic happens here install(TARGET derived DESTINATION bin) I tried several approaches but didn't succeed. I don't seem to be able to create a custom target that CMake would consider installable. I'm also struggling with rules that would automatically work for all configurations in Visual Studio. Is there a way? Thanks, SnakE -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergiu.dotenco at gmail.com Sun Aug 30 19:11:06 2015 From: sergiu.dotenco at gmail.com (Sergiu Dotenco) Date: Mon, 31 Aug 2015 01:11:06 +0200 Subject: [CMake] Per build configuration variables Message-ID: <55E38D8A.7060405@gmail.com> I would like to pass different library directories to fixup_bundle, depending what configuration is currently active. Right now, I define a cache variable consisting of DLL directories: set (RUNTIME_LIBRARY_DIRS "C:/Foo/Release/bin;..." CACHE STRING "") This is problematic, since for a different build configuration (for instance RelWithDebInfo or even Debug) this set of directories would probably be different as well. For Makefile generators I can use CMAKE_BUILD_TYPE to decide which variables to select. However, this does not work in an environment that supports multiconfiguration, such as Visual Studio or Xcode, because the selection must be done at build time. Any ideas how can one achieve this? From dumont.guillaume at gmail.com Mon Aug 31 10:35:01 2015 From: dumont.guillaume at gmail.com (Guillaume Dumont) Date: Mon, 31 Aug 2015 10:35:01 -0400 Subject: [CMake] Visual Studio - Ninja Generator Message-ID: Hi all, I would like to know what kind of effort would it take to generate a Visual Studio generator that bypasses the normal MSBuild build and uses Ninja instead. I have been working on different projects which build much faster with ninja than MSBuild (several orders of magnitude on a machine with 24 cores). Still I like to use the Visual Studio environment to use the debugger. Using ninja is especially useful for projects with a lot of CUDA files which are built sequentially for every target using MSVS. I would like to contribute but I don't really know where to start and if such an effort already exists. -- Guillaume Dumont ========================= dumont.guillaume at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Mon Aug 31 11:49:13 2015 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Mon, 31 Aug 2015 17:49:13 +0200 Subject: [CMake] Visual Studio - Ninja Generator In-Reply-To: References: Message-ID: <2B4322E3-BF6B-4180-9B1D-D4B5C569B78C@hendrik-sattler.de> Hi, did you really enable parallel compiling in VS with /MP24 or the like? Note that using devenv to build uses the number from the IDE user settings but using msbuild needs a command line option. Else just create a custom target that calls cmake for ninja and afterwards ninja itself in yet another build tree. you can limit the creation of that target to if(MSVC_IDE). HS Am 31. August 2015 16:35:01 MESZ, schrieb Guillaume Dumont : >Hi all, > >I would like to know what kind of effort would it take to generate a >Visual >Studio generator that bypasses the normal MSBuild build and uses Ninja >instead. I have been working on different projects which build much >faster >with ninja than MSBuild (several orders of magnitude on a machine with >24 >cores). Still I like to use the Visual Studio environment to use the >debugger. Using ninja is especially useful for projects with a lot of >CUDA >files which are built sequentially for every target using MSVS. > >I would like to contribute but I don't really know where to start and >if >such an effort already exists. > >-- >Guillaume Dumont >========================= >dumont.guillaume at 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: >http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggarra13 at gmail.com Mon Aug 31 12:29:53 2015 From: ggarra13 at gmail.com (Gonzalo) Date: Mon, 31 Aug 2015 13:29:53 -0300 Subject: [CMake] Visual Studio - Ninja Generator In-Reply-To: References: Message-ID: <55E48101.2010502@gmail.com> El 31/08/15 a las 11:35, Guillaume Dumont escribi?: > Hi all, > Using ninja is especially useful for projects with a lot of CUDA files > which are built sequentially for every target using MSVS. > > I would like to contribute but I don't really know where to start and > if such an effort already exists. > Hi, Guillaume. Currently cmake offers support for Ninja Makefiles. You need to set up your build environment by running the microsoft setenv.bat file (or whatever is called in your version of msdev, as it has changed names a couple of times). That should allow cmake to find the proper compiler. Then, if you specify: $ cd $ mkdir ninja_build $ cd ninja_build $ cmake .. -G Ninja You will get ninja files for your project. From dumont.guillaume at gmail.com Mon Aug 31 12:48:33 2015 From: dumont.guillaume at gmail.com (Guillaume Dumont) Date: Mon, 31 Aug 2015 12:48:33 -0400 Subject: [CMake] Visual Studio - Ninja Generator In-Reply-To: <55E48101.2010502@gmail.com> References: <55E48101.2010502@gmail.com> Message-ID: @Hendrik Sattler I have not experimented with the /MP flag that much, but this won't solve my problem when the project contains a lot of CUDA files. The /MP flag as not effect there. Yes I could indeed create a custom build target and create additional build trees to build using ninja in there but this is suboptimal in my opinion. @Gonzalo Yes this is precisely what I do but then you only get the ninja build files. No solution for debugging etc. My question is more about the difficulty of creating a new generator that makes the use of ninja as transparent as possible to the user instead of writing custom CMake code to do this in my own projects. On Mon, Aug 31, 2015 at 12:29 PM, Gonzalo wrote: > s it has changed names a couple of times). That shoul -- Guillaume Dumont ========================= dumont.guillaume at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.neundorf-work at gmx.net Mon Aug 31 16:27:27 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Mon, 31 Aug 2015 22:27:27 +0200 Subject: [CMake] Crawling documentation to find named argument keywords In-Reply-To: References: Message-ID: <14559523.A72P9Qbo9D@tuxedo.neundorf.net> On Monday, August 17, 2015 09:15:18 Michael Jackson wrote: > I thought there used to be a DocBook version of the documentation? At one > point I had an XML parser that used that as input to process the > documentation in the same way. the way the documentation is generated has changed with version 3.0 I think, cmake now is sphinx-based. I'm not quite sure whether it still supports docbook. Alex From a.neundorf-work at gmx.net Mon Aug 31 16:34:34 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Mon, 31 Aug 2015 22:34:34 +0200 Subject: [CMake] linking: absolute path vs -l In-Reply-To: References: Message-ID: <4451129.mAJvdXgu70@tuxedo.neundorf.net> On Friday, August 28, 2015 08:23:47 Nico Schl?mer wrote: > Hi everyone, > > I'm curious about when CMake decides to link a library by its absolute path > and when it links using the `-l*` syntax. I came across this for the very > simple test problem > ``` > cmake_minimum_required(VERSION 3.0) > > project(mytest) > > find_package(ZLIB REQUIRED) > find_package(netCDF REQUIRED) > > add_executable(mytest main.cpp) > target_link_libraries( > mytest > ${ZLIB_LIBRARIES} > ${netCDF_LIBRARIES} > ) > ``` > The resulting link line is > ``` > /usr/bin/c++ CMakeFiles/mytest.dir/main.cpp.o -o mytest -rdynamic > -lz /usr/lib/x86_64-linux-gnu/libnetcdf.so.7.3.0 > ``` > so ZLIB is linked with `-lz`, netCDF with the full absolute path. > > Seems inconsistent? (ZLIB by the way is found through CMake's > FindZLIB.cmake, netCDF by their own export files.) > > So far, I had been under the impression that `-l*` defeats the purpose of > CMake a little bit as it asks the linker to search in the system's paths > for a libz.so, something CMake has already done. > > A little clarification here would be great. it uses -l if the full path is not know or if the full path is one of the system library dirs (like e.g. /usr/lib/ or the, IIRC, $LIBRARY_PATH env.var) Alex From bill.hoffman at kitware.com Mon Aug 31 17:10:32 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Mon, 31 Aug 2015 17:10:32 -0400 Subject: [CMake] Happy Birthday CMake! Message-ID: <55E4C2C8.1040501@kitware.com> Today is the 15th birthday of CMake: http://www.kitware.com/blog/home/post/959 Thanks to everyone that has used and contributed to CMake over the years! -Bill