From j.kreuzberger at procitec.de Thu Oct 1 02:35:34 2015 From: j.kreuzberger at procitec.de (=?utf-8?Q?J=C3=B6rg_Kreuzberger?=) Date: Thu, 1 Oct 2015 08:35:34 +0200 Subject: [CMake] =?utf-8?q?cmake_install_behaviour_with_git?= Message-ID: > > > > Now install behaves differnt, cause cmake checks only file time difference. > Files previously overwritten are now > > considered Up-to-date > > Why would you want to overwrite files that have not changed? This comes from installs, there we install some configuration files with the builded targets. e.g. you install a builded executable, together with an config xml file from SCM. If you make a product install, you want to "overwrite" the original config xml with an "product" xml config file, also from the SCM. So there are two install steps, the second "configure/modify" some files of the first. This worked cause the file timestamps differed. Now not, cause the second install gets "Up-to-date" message and has to use CMAKE_ALWAYS_INSTALL. The same "application install" is used in "product install" there we bundle several applications to an "product" and then apply product specific configuration, modifying some xml files (same name, different size, normaly different timestamp :-) ) The idea behind this install overwrite is that we could provide an install for an application with "default" configuration, so that any developer could use the application without further need to add additonal files (all files to run the application like config files, shared libraries and so on). > We?re using CMake with git without any trouble - no solution to be found. The > install target works flawlessly and as expected. I do agree with you, except for this scenario of non-builded files. So the question is ok, why not consider the file size in up-to-date check. Should be not to expensive to get this information together with the file time from the os. > I think you?ll need to provide some more details about what you?re doing. Are > you by any chance doing in-source builds? Why are you so focussed on 'git > clone?? That is the kind of thing you would do once, and then almost never > again, so I don?t see how that can be related to running an install target. We do not make an in-source-builds. i am focused on git clone cause we do it on our SOFTWARE RELEASE systems. These are virtual machines, upstarting for any release build, cloning (with depth=1) the software and start builds, install, and package creation (rpm and msi). For those builds the "former" behaviour is broken. I do also not want to start a discussion about this git clone behaviour, i accepted this as is. I think the solutions provided in groups, aplying the timestamps after checkout from any meta data is also no good idea. The concept of the modified timestamps is also still good for the builded install files. Thanks for your patience, if you read this mail to the end :-) Joerg From nilsgladitz at gmail.com Thu Oct 1 03:37:40 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 1 Oct 2015 09:37:40 +0200 Subject: [CMake] cmake install behaviour with git In-Reply-To: References: Message-ID: <560CE2C4.5020901@gmail.com> On 10/01/2015 08:35 AM, J?rg Kreuzberger wrote: > This comes from installs, there we install some configuration files with the builded targets. > e.g. you install a builded executable, together with an config xml file from SCM. > If you make a product install, you want to "overwrite" the original config xml with an "product" xml config > file, also from the SCM. > > So there are two install steps, the second "configure/modify" some files of the first. This worked cause the file > timestamps differed. Now not, cause the second install gets "Up-to-date" message and has to use CMAKE_ALWAYS_INSTALL. I don't comprehend this at all. Why would the two instances of the config file with distinct content have the same modification time in this scenario? Could you provide a minimal, self-contained test case that reproduces this issue? > I do agree with you, except for this scenario of non-builded files. So the question is ok, why not consider the file size in up-to-date check. > Should be not to expensive to get this information together with the file time from the os. I don't think that makes much sense. A modified file is much more likely to retain its size than its modification time. So if modification times really stay the same for some reason the file size on its own would be a very error prone change indicator. Nils From roman.wueger at gmx.at Thu Oct 1 04:07:07 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Thu, 1 Oct 2015 10:07:07 +0200 Subject: [CMake] Rename suffix of Mac OS Framework Message-ID: <7C68D75D-3BC9-4729-8DC5-B720A7AADB34@gmx.at> Hello, at the moment I build my frameworks with the following property: set_target_properties(${PROJECT_NAME} PROPERTIES FRAMEWORK TRUE) If my project is called "Test" for example, then a folder structure with the name "Test.framework" is created. Is there a way to rename the suffix ".framework"? Thanks in advance Best regards Roman From j.kreuzberger at procitec.de Thu Oct 1 04:12:35 2015 From: j.kreuzberger at procitec.de (=?utf-8?Q?J=C3=B6rg_Kreuzberger?=) Date: Thu, 1 Oct 2015 10:12:35 +0200 Subject: [CMake] =?utf-8?q?cmake_install_behaviour_with_git?= Message-ID: -----Urspr?ngliche Nachricht----- Von: Nils Gladitz Gesendet: Do 01.10.2015 09:40 Betreff: Re: [CMake] cmake install behaviour with git An: J?rg Kreuzberger ; cmake at cmake.org; > On 10/01/2015 08:35 AM, J?rg Kreuzberger wrote: > > This comes from installs, there we install some configuration files with the > builded targets. > > e.g. you install a builded executable, together with an config xml file from > SCM. > > If you make a product install, you want to "overwrite" the original config > xml with an "product" xml config > > file, also from the SCM. > > > > So there are two install steps, the second "configure/modify" some files of > the first. This worked cause the file > > timestamps differed. Now not, cause the second install gets "Up-to-date" > message and has to use CMAKE_ALWAYS_INSTALL. > > I don't comprehend this at all. > Why would the two instances of the config file with distinct content > have the same modification time in this scenario? cause they come from git clone and git sets the timestamp of the files to the time of the clone, not of the "original" modification time. So after a clone all files(!) have the same timestamp. > Could you provide a minimal, self-contained test case that reproduces > this issue? should be now problem, i send it later to you. > I don't think that makes much sense. > > A modified file is much more likely to retain its size than its > modification time. i sense of "builded files" yes, in sense of files only coming from SCM not > So if modification times really stay the same for some reason the file > size on its own would be a very error prone change indicator. But better than noting. best would be a hash to detect modified content, but this will take some time to prove... Ok, as i now understood nobody has a similar scenario and i will try to get it workaround by myself Thanks all for support! From nilsgladitz at gmail.com Thu Oct 1 04:28:21 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 1 Oct 2015 10:28:21 +0200 Subject: [CMake] cmake install behaviour with git In-Reply-To: References: Message-ID: <560CEEA5.7040707@gmail.com> On 10/01/2015 10:12 AM, J?rg Kreuzberger wrote: > -----Urspr?ngliche Nachricht----- > Von: Nils Gladitz > Gesendet: Do 01.10.2015 09:40 > Betreff: Re: [CMake] cmake install behaviour with git > An: J?rg Kreuzberger ; cmake at cmake.org; >> On 10/01/2015 08:35 AM, J?rg Kreuzberger wrote: >>> This comes from installs, there we install some configuration files with the >> builded targets. >>> e.g. you install a builded executable, together with an config xml file from >> SCM. >>> If you make a product install, you want to "overwrite" the original config >> xml with an "product" xml config >>> file, also from the SCM. >>> >>> So there are two install steps, the second "configure/modify" some files of >> the first. This worked cause the file >>> timestamps differed. Now not, cause the second install gets "Up-to-date" >> message and has to use CMAKE_ALWAYS_INSTALL. >> >> I don't comprehend this at all. >> Why would the two instances of the config file with distinct content >> have the same modification time in this scenario? > > cause they come from git clone and git sets the timestamp of the files to the time of the clone, > not of the "original" modification time. So after a clone all files(!) have the same timestamp. Subversion does not restore "original" modification times either (unless you use the non-default 'use-commit-times' option which likely breaks timestamp logic in the build). When you do a fresh checkout with subversion all files will have modification times close to each other as well. I guess the only difference with git is that git might be a bit faster when creating files to a degree where creation time differences might fall below the modification time precision(?) What was unclear to me is that it now sounds like you are installing two distinct files from your repository to the same destination file rather than re-installing a modified version of the same file. I think that is conceptually an error prone thing to do irregardless of the SCM in use. Nils From j.kreuzberger at procitec.de Thu Oct 1 04:40:27 2015 From: j.kreuzberger at procitec.de (=?utf-8?Q?J=C3=B6rg_Kreuzberger?=) Date: Thu, 1 Oct 2015 10:40:27 +0200 Subject: [CMake] =?utf-8?q?cmake_install_behaviour_with_git?= Message-ID: > What was unclear to me is that it now sounds like you are installing two > distinct files from your repository to the same destination file rather > than re-installing a modified version of the same file. Yes, your are right i am doing exactly this > I think that is conceptually an error prone thing to do irregardless of > the SCM in use. yes you are right, but it worked until the git change :-) i will fix it in your CMakeLists.txt From jackie at sdiwc.info Thu Oct 1 04:42:05 2015 From: jackie at sdiwc.info (Jackie Blanco) Date: Thu, 01 Oct 2015 02:42:05 -0600 Subject: [CMake] Approaching Deadline: ICGCTI2015 - Malaysia Message-ID: <6305d92d5eae64654901f33e9ac62f21@sdiwc.info> The Third International Conference on Green Computing, Technology and Innovation (ICGCTI2015) Universiti Putra Malaysia, Selangor, Malaysia 8-10 December 2015 http://sdiwc.net/conferences/icgcti2015/ The proposed conference on the above theme will held over three days, with presentations delivered by researchers from the international community, including presentations from keynote speakers and state-of-the-art lectures. ICGCTI2015 aims to enable researchers build connections between different digital applications. The conference welcomes papers on the following (but not limited to) research topics: - Benefits of, and barriers to, adopting greener IT practices - Carbon metering and user feedback - Climate and ecosystem monitoring - Energy harvesting, storage, and recycling - Energy-aware high performance computing and applications - Energy-aware software - Energy-efficient network services and operations - Green IT metrics, maturity models, standards, and regulations - Green computing models, methodologies and paradigms - Green networking and communication - Life-cycle analysis of IT equipment - Management and profiling tools for energy efficient systems - Modeling-representations, simulation and validation for energy consumption optimization problems - Online dynamic optimization for energy efficient systems - Power-aware algorithms and protocols - Power-efficient delivery and cooling - Renewable energy models and prediction - Smart buildings and urban development - Smart homes, buildings, offices, streets - Stability of smart energy systems - Using IT to reduce carbon emissions - Carbon management policies and ecology- related issues with ICT - Characterization, metrics, and modeling - Creating green awareness using IT - Energy-aware computing - Energy-aware large scale distributed systems, such as Grids, Clouds and service computing - Energy-efficient mass data storage and processing - Governments? roles in fostering and enforcing green initiatives - Green business process reengineering and management - Green design, manufacture, use, disposal, and recycling of computers and communication systems - Green software engineering - Low-power electronics and systems - Matching energy supply and demand - Network design optimization - Optimization of energy-efficient protocols - Power-aware software and hardware - Reliability, thermal behavior and control - Robustness and performance guarantees - Smart grid and microgrids - Smart transportation and manufacturing - Sustainable computing Researchers are encouraged to submit their work electronically. All papers will be fully refereed by a minimum of two specialized referees. Before final acceptance, all referees comments must be considered. Important Dates ============== Submission Deadline : November 8, 2015 Final Notification : November 20, 2015 Camera Ready Deadline : November 28, 2015 Registration Deadline : November 28, 2015 Conference Dates : December 8-10, 2015 Drop us an email at icgcti15 at sdiwc.net From jensweh at gmail.com Thu Oct 1 05:39:40 2015 From: jensweh at gmail.com (Jens Weggemann) Date: Thu, 1 Oct 2015 11:39:40 +0200 Subject: [CMake] CMake loses/switches generator, breaking build directories Message-ID: Hello, I've run into a problem where rerunning CMake (for instance, automatically from Visual Studio via the ZERO_CHECK target) would sometimes switch to a different generator, like from 64-bit to 32-bit, completely messing up the build directory. The reason is that CMake can drop information about the previously chosen generator. In such cases, when CMake is called again, it will try to detect the generator anew, and there is no guarantee that will choose the previous generator. It's easily reproduced: A dummy CMakeLists.txt: cmake_minimum_required(VERSION 3.3) project(problem) # message(FATAL_ERROR ouch) # undefined_function() # find_package(missing_package REQUIRED) A call to > cmake -G "Visual Studio 12 2013 Win64" will store this entry in CMakeCache.txt: CMAKE_GENERATOR:INTERNAL=Visual Studio 12 2013 Win64 So far, so good. Now uncomment any of the three commented lines in CMakeLists.txt and either run cmake again without explicitly specifying the generator or build the VS solution (which effectively does the same). The cmake run will fail and the CMakeCache.txt is re-written, but it will now lack the CMAKE_GENERATOR entry. Now the build directory is doomed unless one explicitly specifies the Win64 generator again. To see why, fix the CMakeLists.txt by commenting out the bad line. CMake will detect the generator anew and (depending on platform and installed IDEs, of course) might come up with "Visual Studio 12 2013". Note that detection will never use the Win64 version of that generator, so it will always guess wrong in this case. Furthermore, because there was no generator entry previously, CMake will not fail because of non-matching generators and happily create a mess of broken projects in the build directory. I couldn't so far find a reasonable workaround. Why does CMake rewrite the CMakeCache in the case of a fatal error anyway? Can't it at least preserve the previous value of CMAKE_GENERATOR? Thanks, Jens -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Thu Oct 1 05:43:43 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 1 Oct 2015 11:43:43 +0200 Subject: [CMake] CMake loses/switches generator, breaking build directories In-Reply-To: References: Message-ID: <560D004F.8010705@gmail.com> On 10/01/2015 11:39 AM, Jens Weggemann wrote: > Hello, > > I've run into a problem where rerunning CMake (for instance, > automatically from Visual Studio via the ZERO_CHECK target) would > sometimes switch to a different generator, like from 64-bit to 32-bit, > completely messing up the build directory. That sounds like https://cmake.org/Bug/view.php?id=15640 which should be fixed in the upcoming 3.4. Nils From jensweh at gmail.com Thu Oct 1 08:01:30 2015 From: jensweh at gmail.com (Jens Weggemann) Date: Thu, 1 Oct 2015 14:01:30 +0200 Subject: [CMake] CMake loses/switches generator, breaking build directories In-Reply-To: <560D004F.8010705@gmail.com> References: <560D004F.8010705@gmail.com> Message-ID: And indeed I can't reproduce it with the current 'next' HEAD. Thanks! On Thu, Oct 1, 2015 at 11:43 AM, Nils Gladitz wrote: > On 10/01/2015 11:39 AM, Jens Weggemann wrote: > >> Hello, >> >> I've run into a problem where rerunning CMake (for instance, >> automatically from Visual Studio via the ZERO_CHECK target) would >> sometimes switch to a different generator, like from 64-bit to 32-bit, >> completely messing up the build directory. >> > > That sounds like https://cmake.org/Bug/view.php?id=15640 which should be > fixed in the upcoming 3.4. > > Nils > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bochecha at daitauha.fr Thu Oct 1 09:55:07 2015 From: bochecha at daitauha.fr (Mathieu Bridon) Date: Thu, 01 Oct 2015 15:55:07 +0200 Subject: [CMake] Can't build something with MinGW In-Reply-To: <1443170479.2322.9.camel@daitauha.fr> References: <1443170479.2322.9.camel@daitauha.fr> Message-ID: <1443707707.2465.3.camel@daitauha.fr> Hi, I'm still blocked with this. I found this, though: https://cmake.org/Bug/view.php?id=13855 Using the patch attached to this bug, I'm able to build stuff correctly. However, that patch still feels weird to me, because it makes the Linux -GNU.cmake platform file take into account the fact that I'm using MinGW. But should I really need this? It still seems bizarre that the platform goes from "Windows" to "Linux-GNU" in the middle of my build... Any idea how to fix this? -- Mathieu From tamas.kenez at gmail.com Thu Oct 1 10:57:00 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Thu, 1 Oct 2015 16:57:00 +0200 Subject: [CMake] ExternalProject: pass variable which contains a list Message-ID: Hi, I tried to pass a variable to an ExternalProjects config step which contains a list: ExternalProject_Add(... CMAKE_ARGS "-DVAR=contains\;list" ...) I tried various number of backslashes but none of them worked. I'd be interested in a workaround if there's one. Tamas -------------- next part -------------- An HTML attachment was scrubbed... URL: From tamas.kenez at gmail.com Thu Oct 1 11:08:36 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Thu, 1 Oct 2015 17:08:36 +0200 Subject: [CMake] ExternalProject: pass variable which contains a list In-Reply-To: References: Message-ID: I'm sorry, I got it, LIST_SEPARATOR On Thu, Oct 1, 2015 at 4:57 PM, Tam?s Ken?z wrote: > Hi, > > I tried to pass a variable to an ExternalProjects config step which > contains a list: > > ExternalProject_Add(... CMAKE_ARGS "-DVAR=contains\;list" ...) > > I tried various number of backslashes but none of them worked. > I'd be interested in a workaround if there's one. > > Tamas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damian at sourceryinstitute.org Thu Oct 1 19:51:55 2015 From: damian at sourceryinstitute.org (Damian Rouson) Date: Thu, 1 Oct 2015 16:51:55 -0700 Subject: [CMake] CMake 3.3 and 3.2 bootstrap fails on OS X Yosemite Message-ID: <0A7705BE-E328-4433-9C36-FFD46EC27FC9@sourceryinstitute.org> All, Could someone advise me on building CMake from source on OS X 10.10.5 (Yosemite)? At the bottom of this email is the tail of the output from the following build script: #!/bin/bash version=3.3 wget http://www.cmake.org/files/v$version/cmake-$version.0-1-src.tar.bz2 && tar xvjf cmake-$version.0-1-src.tar.bz2 && tar xvjf cmake-$version.0.tar.bz2 && cd cmake-$version.0 && ./bootstrap --prefix=${PWD} >&1 | tee build.log An identical script completes successfully on Linux (Lubuntu). The complete output of the above script in the ?build.log? file at https://github.com/sourceryinstitute/AdHoc/tree/master/src/cmake/bug-xxxx. A link to the resulting ?cmake_bootstrap.log? file is on the same page. I get the same error with CMake 3.2.3 and have reported this behavior in CMake bug report 0015762 (https://cmake.org/Bug/view.php?id=15762). ________________________________ Damian Rouson, Ph.D., P.E. President, Sourcery Institute http://www.sourceryinstitute.org +1-510-600-2992 (mobile) g++ -I/Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Bootstrap.cmk -I/Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Source -I/Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Bootstrap.cmk -c /Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Source/cmBootstrapCommands1.cxx -o cmBootstrapCommands1.o In file included from /usr/include/dispatch/dispatch.h:51:0, from /System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:15, from /System/Library/Frameworks/CoreFoundation.framework/Headers/CFPropertyList.h:13, from /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:55, from /Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Source/cmFindProgramCommand.cxx:16, from /Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Source/cmBootstrapCommands1.cxx:52: /usr/include/dispatch/object.h:143:15: error: expected unqualified-id before '^' token typedef void (^dispatch_block_t)(void); ^ /usr/include/dispatch/object.h:143:15: error: expected ')' before '^' token /usr/include/dispatch/object.h:362:3: error: 'dispatch_block_t' has not been declared dispatch_block_t notification_block); ^ make: *** [cmBootstrapCommands1.o] Error 1 --------------------------------------------- Error when bootstrapping CMake: Problem while running make --------------------------------------------- Log of errors: /Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Bootstrap.cmk/cmake_bootstrap.log From DLRdave at aol.com Thu Oct 1 22:45:42 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 1 Oct 2015 22:45:42 -0400 Subject: [CMake] CMake 3.3 and 3.2 bootstrap fails on OS X Yosemite In-Reply-To: <0A7705BE-E328-4433-9C36-FFD46EC27FC9@sourceryinstitute.org> References: <0A7705BE-E328-4433-9C36-FFD46EC27FC9@sourceryinstitute.org> Message-ID: <2CF6469B-B6AD-4748-B2FD-7C2F3E9A4840@aol.com> The "-1" bz2 files are for Cygwin... Try the plain old .tar.gz instead. David > On Oct 1, 2015, at 7:51 PM, Damian Rouson wrote: > > All, > > Could someone advise me on building CMake from source on OS X 10.10.5 (Yosemite)? At the bottom of this email is the tail of the output from the following build script: > > #!/bin/bash > version=3.3 > wget http://www.cmake.org/files/v$version/cmake-$version.0-1-src.tar.bz2 && > tar xvjf cmake-$version.0-1-src.tar.bz2 && > tar xvjf cmake-$version.0.tar.bz2 && > cd cmake-$version.0 && > ./bootstrap --prefix=${PWD} >&1 | tee build.log > > An identical script completes successfully on Linux (Lubuntu). The complete output of the above script in the ?build.log? file at https://github.com/sourceryinstitute/AdHoc/tree/master/src/cmake/bug-xxxx. A link to the resulting ?cmake_bootstrap.log? file is on the same page. > > I get the same error with CMake 3.2.3 and have reported this behavior in CMake bug report 0015762 (https://cmake.org/Bug/view.php?id=15762). > > > ________________________________ > Damian Rouson, Ph.D., P.E. > President, Sourcery Institute > http://www.sourceryinstitute.org > +1-510-600-2992 (mobile) > > > > > g++ -I/Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Bootstrap.cmk -I/Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Source -I/Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Bootstrap.cmk -c /Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Source/cmBootstrapCommands1.cxx -o cmBootstrapCommands1.o > In file included from /usr/include/dispatch/dispatch.h:51:0, > from /System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:15, > from /System/Library/Frameworks/CoreFoundation.framework/Headers/CFPropertyList.h:13, > from /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:55, > from /Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Source/cmFindProgramCommand.cxx:16, > from /Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Source/cmBootstrapCommands1.cxx:52: > /usr/include/dispatch/object.h:143:15: error: expected unqualified-id before '^' token > typedef void (^dispatch_block_t)(void); > ^ > /usr/include/dispatch/object.h:143:15: error: expected ')' before '^' token > /usr/include/dispatch/object.h:362:3: error: 'dispatch_block_t' has not been declared > dispatch_block_t notification_block); > ^ > make: *** [cmBootstrapCommands1.o] Error 1 > --------------------------------------------- > Error when bootstrapping CMake: > Problem while running make > --------------------------------------------- > Log of errors: /Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Bootstrap.cmk/cmake_bootstrap.log > > > -- > > 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 dank at kegel.com Thu Oct 1 23:09:54 2015 From: dank at kegel.com (Dan Kegel) Date: Thu, 1 Oct 2015 20:09:54 -0700 Subject: [CMake] CMake 3.3 and 3.2 bootstrap fails on OS X Yosemite In-Reply-To: <2CF6469B-B6AD-4748-B2FD-7C2F3E9A4840@aol.com> References: <0A7705BE-E328-4433-9C36-FFD46EC27FC9@sourceryinstitute.org> <2CF6469B-B6AD-4748-B2FD-7C2F3E9A4840@aol.com> Message-ID: IMHO it's a bug to have different contents in the two archive formats; it leads to confusion like this because it differs from standard practice in the open source world. On Oct 1, 2015 7:45 PM, "David Cole via CMake" wrote: > The "-1" bz2 files are for Cygwin... > > Try the plain old .tar.gz instead. > > > David > > > On Oct 1, 2015, at 7:51 PM, Damian Rouson > wrote: > > > > All, > > > > Could someone advise me on building CMake from source on OS X 10.10.5 > (Yosemite)? At the bottom of this email is the tail of the output from the > following build script: > > > > #!/bin/bash > > version=3.3 > > wget http://www.cmake.org/files/v$version/cmake-$version.0-1-src.tar.bz2 > && > > tar xvjf cmake-$version.0-1-src.tar.bz2 && > > tar xvjf cmake-$version.0.tar.bz2 && > > cd cmake-$version.0 && > > ./bootstrap --prefix=${PWD} >&1 | tee build.log > > > > An identical script completes successfully on Linux (Lubuntu). The > complete output of the above script in the ?build.log? file at > https://github.com/sourceryinstitute/AdHoc/tree/master/src/cmake/bug-xxxx. > A link to the resulting ?cmake_bootstrap.log? file is on the same page. > > > > I get the same error with CMake 3.2.3 and have reported this behavior in > CMake bug report 0015762 (https://cmake.org/Bug/view.php?id=15762). > > > > > > ________________________________ > > Damian Rouson, Ph.D., P.E. > > President, Sourcery Institute > > http://www.sourceryinstitute.org > > +1-510-600-2992 (mobile) > > > > > > > > > > g++ > -I/Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Bootstrap.cmk > -I/Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Source > -I/Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Bootstrap.cmk > -c > /Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Source/cmBootstrapCommands1.cxx > -o cmBootstrapCommands1.o > > In file included from /usr/include/dispatch/dispatch.h:51:0, > > from > /System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:15, > > from > /System/Library/Frameworks/CoreFoundation.framework/Headers/CFPropertyList.h:13, > > from > /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:55, > > from > /Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Source/cmFindProgramCommand.cxx:16, > > from > /Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Source/cmBootstrapCommands1.cxx:52: > > /usr/include/dispatch/object.h:143:15: error: expected unqualified-id > before '^' token > > typedef void (^dispatch_block_t)(void); > > ^ > > /usr/include/dispatch/object.h:143:15: error: expected ')' before '^' > token > > /usr/include/dispatch/object.h:362:3: error: 'dispatch_block_t' has not > been declared > > dispatch_block_t notification_block); > > ^ > > make: *** [cmBootstrapCommands1.o] Error 1 > > --------------------------------------------- > > Error when bootstrapping CMake: > > Problem while running make > > --------------------------------------------- > > Log of errors: > /Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Bootstrap.cmk/cmake_bootstrap.log > > > > > > -- > > > > 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 jay.custin at hpe.com Fri Oct 2 00:15:10 2015 From: jay.custin at hpe.com (Custin, Jay (CSC Sw Middleware)) Date: Fri, 2 Oct 2015 04:15:10 +0000 Subject: [CMake] CMake on OpenVMS - approaching the finish line Message-ID: Had a few environmental issues that bit me (and drew blood)... but have gotten MUCH closer to the goal... except bash-4.3$ ./configure --system-curl --system-zlib --verbose --init=BuildCMakeOpenVMS_CacheFlags.cmake <> /bin/cc -Wc/warnings=disable=all -I/PRJ_ROOT/CMAKE-3_3_2/Bootstrap_cmk -I/PRJ_ROOT/CMAKE-3_3_2/Source -I/PRJ_ROOT/CMAKE-3_3_2/Bootstrap_cmk -DKWSYS_NAMESPACE=cmsys -c /PRJ_ROOT/CMAKE-3_3_2/Source/kwsys/Terminal.c -o Terminal.o cc -Wc/warnings=disable=all -I/PRJ_ROOT/CMAKE-3_3_2/Bootstrap_cmk -I/PRJ_ROOT/CMAKE-3_3_2/Source -I/PRJ_ROOT/CMAKE-3_3_2/Bootstrap_cmk cmake.o cmakemain.o cmcmd.o cmCommandArgumentLexer.o cmCommandArgumentParser.o cmCommandArgumentParserHelper.o cmCPackPropertiesGenerator.o cmDefinitions.o cmDepends.o cmDependsC.o cmDocumentationFormatter.o cmPolicies.o cmProperty.o cmPropertyMap.o cmPropertyDefinition.o cmPropertyDefinitionMap.o cmMakeDepend.o cmMakefile.o cmExportFileGenerator.o cmExportInstallFileGenerator.o cmExportTryCompileFileGenerator.o cmExportSet.o cmExportSetMap.o cmExternalMakefileProjectGenerator.o cmGeneratorExpressionEvaluationFile.o cmGeneratedFileStream.o cmGeneratorTarget.o cmGeneratorExpressionContext.o cmGeneratorExpressionDAGChecker.o cmGeneratorExpressionEvaluator.o cmGeneratorExpressionLexer.o cmGeneratorExpressionNode.o cmGeneratorExpressionParser.o cmGeneratorExpression.o cmGlobalGenerator.o cmInstallDirectoryGenerator.o cmLocalGenerator.o cmInstalledFile.o cmInstallGenerator.o cmInstallExportGenerator.o cmInstallFilesGenerator.o cmInstallScriptGenerator.o cmInstallTargetGenerator.o cmScriptGenerator.o cmSourceFile.o cmSourceFileLocation.o cmState.o cmSystemTools.o cmTestGenerator.o cmVersion.o cmFileTimeComparison.o cmGlobalUnixMakefileGenerator3.o cmLocalUnixMakefileGenerator3.o cmMakefileExecutableTargetGenerator.o cmMakefileLibraryTargetGenerator.o cmMakefileTargetGenerator.o cmMakefileUtilityTargetGenerator.o cmOSXBundleGenerator.o cmNewLineStyle.o cmBootstrapCommands1.o cmBootstrapCommands2.o cmCommandsForBootstrap.o cmTarget.o cmTest.o cmCustomCommand.o cmCustomCommandGenerator.o cmCacheManager.o cmListFileCache.o cmComputeLinkDepends.o cmComputeLinkInformation.o cmOrderDirectories.o cmComputeTargetDepends.o cmComputeComponentGraph.o cmExprLexer.o cmExprParser.o cmExprParserHelper.o cmGlobalNinjaGenerator.o cmLocalNinjaGenerator.o cmNinjaTargetGenerator.o cmNinjaNormalTargetGenerator.o cmNinjaUtilityTargetGenerator.o cmListFileLexer.o vms_crtl_init.o Directory.o EncodingCXX.o FStream.o Glob.o RegularExpression.o SystemTools.o EncodingC.o ProcessUNIX.o String.o System.o Terminal.o -o cmake -- The C compiler identification is HP -- The CXX compiler identification is HP -- Check for working C compiler: /bin/cc -- Check for working C compiler: /bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /bin/cc -- Check for working CXX compiler: /bin/cc -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done <> -- Checking whether CXX compiler has atoll -- Checking whether CXX compiler has atoll - yes -- Checking whether CXX compiler has _atoi64 -- Checking whether CXX compiler has _atoi64 - no -- Looking for C++ include execinfo.h -- Looking for C++ include execinfo.h - not found -- Using system-installed CURL -- Using system-installed ZLIB -- Could NOT find ZLIB (missing: ZLIB_LIBRARY) (found version "1.2.8") CMake Error at CMakeLists.txt:266 (message): CMAKE_USE_SYSTEM_ZLIB is ON but a zlib is not found! Call Stack (most recent call first): CMakeLists.txt:533 (CMAKE_BUILD_UTILITIES) -- Configuring incomplete, errors occurred! See also "/PRJ_ROOT/CMAKE-3_3_2/CMakeFiles/CMakeOutput.log". See also "/PRJ_ROOT/CMAKE-3_3_2/CMakeFiles/CMakeError.log". --------------------------------------------- CMake has bootstrapped. Now run make. ./configure: line 3: /PRJ_ROOT/CMAKE-3_3_2/bootstrap: error 0 bash-4.3$ It appears this error occurs during the execution of FindZLIB.cmake (I added a MESSAGE statement and confirmed that) and when I looked at that file... this strikes me as odd... Lines 70-77: 70 # Normal search. 71 set(_ZLIB_SEARCH_NORMAL 72 PATHS "[HKEY_LOCAL_MACHINE\\SOFTWARE\\GnuWin32\\Zlib;InstallPath]" 73 "$ENV{PROGRAMFILES}/zlib" 74 ) 75 list(APPEND _ZLIB_SEARCHES _ZLIB_SEARCH_NORMAL) 76 77 set(ZLIB_NAMES z zlib zdll zlib1 zlibd zlibd1) Now if I have correctly guessed at this will do... this would ONLY work on a Windows-based platforms (since *nix doesn't use Microsoft's registry keys, thank God!, and it wouldn't go searching in {Programfiles}/zlib on a *nix system either, I wouldn't think). Even more confusing... at least to me... the error message clearly indicates it has found >> a << ZLIB: ...(found version "1.2.8") Which matches the version information of the ZLIB I have installed on the VMS system: ITAN1> product show product zlib ------------------------------------ ----------- --------- PRODUCT KIT TYPE STATE ------------------------------------ ----------- --------- VMSPORTS I64VMS ZLIB V1.2-8 Full LP Installed ------------------------------------ ----------- --------- 1 item found Any suggestions? JayC -------------- next part -------------- An HTML attachment was scrubbed... URL: From damian at sourceryinstitute.org Fri Oct 2 01:53:10 2015 From: damian at sourceryinstitute.org (Damian Rouson) Date: Thu, 1 Oct 2015 22:53:10 -0700 Subject: [CMake] CMake 3.3 and 3.2 bootstrap fails on OS X Yosemite In-Reply-To: <2CF6469B-B6AD-4748-B2FD-7C2F3E9A4840@aol.com> References: <0A7705BE-E328-4433-9C36-FFD46EC27FC9@sourceryinstitute.org> <2CF6469B-B6AD-4748-B2FD-7C2F3E9A4840@aol.com> Message-ID: <9FF29B81-C118-4F0F-8F61-E5D3BBC01E17@sourceryinstitute.org> > On Oct 1, 2015, at 7:45 PM, David Cole wrote: > > The "-1" bz2 files are for Cygwin? Why don?t the Cygwin files have ?Cygwin? in their names like the files with ?Darwin? and ?Linux? in their names? > > Try the plain old .tar.gz instead. > I get the same error with cmake-3.3.2.tar.gz. Damian From nilsgladitz at gmail.com Fri Oct 2 03:23:41 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 2 Oct 2015 09:23:41 +0200 Subject: [CMake] CMake 3.3 and 3.2 bootstrap fails on OS X Yosemite In-Reply-To: <0A7705BE-E328-4433-9C36-FFD46EC27FC9@sourceryinstitute.org> References: <0A7705BE-E328-4433-9C36-FFD46EC27FC9@sourceryinstitute.org> Message-ID: <560E30FD.1030507@gmail.com> On 10/02/2015 01:51 AM, Damian Rouson wrote: > All, > > Could someone advise me on building CMake from source on OS X 10.10.5 (Yosemite)? At the bottom of this email is the tail of the output from the following build script: > > g++ -I/Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Bootstrap.cmk -I/Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Source -I/Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Bootstrap.cmk -c /Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Source/cmBootstrapCommands1.cxx -o cmBootstrapCommands1.o > In file included from /usr/include/dispatch/dispatch.h:51:0, > from /System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:15, > from /System/Library/Frameworks/CoreFoundation.framework/Headers/CFPropertyList.h:13, > from /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:55, > from /Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Source/cmFindProgramCommand.cxx:16, > from /Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-xxxx/cmake-3.3.0/Source/cmBootstrapCommands1.cxx:52: > /usr/include/dispatch/object.h:143:15: error: expected unqualified-id before '^' token > typedef void (^dispatch_block_t)(void); > ^ > /usr/include/dispatch/object.h:143:15: error: expected ')' before '^' token > /usr/include/dispatch/object.h:362:3: error: 'dispatch_block_t' has not been declared > dispatch_block_t notification_block); > ^ I found http://hamelot.co.uk/programming/osx-gcc-dispatch_block_t-has-not-been-declared-invalid-typedef/ which says this is due to that bit of syntax (I've never seen that either) within /usr/include/dispatch/object.h being understood by clang but not by gcc. Other sources [1] seem to say that this bit of syntax is supported by gcc as it used to be provided by Xcode. I am guessing you are also using gcc without apple provided patches (e.g. homebrew)? Nils [1] https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Blocks/Articles/00_Introduction.html From damian at sourceryinstitute.org Fri Oct 2 03:46:55 2015 From: damian at sourceryinstitute.org (Damian Rouson) Date: Fri, 2 Oct 2015 00:46:55 -0700 Subject: [CMake] CMake 3.3 and 3.2 bootstrap fails on OS X Yosemite In-Reply-To: <560E30FD.1030507@gmail.com> References: <0A7705BE-E328-4433-9C36-FFD46EC27FC9@sourceryinstitute.org> <560E30FD.1030507@gmail.com> Message-ID: <0F130586-3280-46A7-A48B-A59D1453974F@sourceryinstitute.org> > On Oct 2, 2015, at 12:23 AM, Nils Gladitz wrote: > > > I found http://hamelot.co.uk/programming/osx-gcc-dispatch_block_t-has-not-been-declared-invalid-typedef/ which says this is due to that bit of syntax (I've never seen that either) within /usr/include/dispatch/object.h being understood by clang but not by gcc. > > Other sources [1] seem to say that this bit of syntax is supported by gcc as it used to be provided by Xcode. > > I am guessing you are also using gcc without apple provided patches (e.g. homebrew)? Correct. I?m using gcc as provided by MacPorts. The goal of this script is to assist users of OpenCoarrays (www.opencoarrays.org) who find it burdensome to install the OpenCoarrays prerequisites. It would also be burdensome if I required them to patch their GCC. In the worst case scenario, I could adjust the provided GCC build script [2] to apply the patch, but it?s kind of a lot to ask people to install a patched GCC in addition to the GCC they might already have on their system. Damian [2] https://github.com/sourceryinstitute/opencoarrays/blob/master/install_prerequisites/buildgcc From sean at rogue-research.com Fri Oct 2 09:23:34 2015 From: sean at rogue-research.com (Sean McBride) Date: Fri, 2 Oct 2015 09:23:34 -0400 Subject: [CMake] CMake 3.3 and 3.2 bootstrap fails on OS X Yosemite In-Reply-To: <0A7705BE-E328-4433-9C36-FFD46EC27FC9@sourceryinstitute.org> References: <0A7705BE-E328-4433-9C36-FFD46EC27FC9@sourceryinstitute.org> Message-ID: <20151002132334.282637676@mail.rogue-research.com> On Thu, 1 Oct 2015 16:51:55 -0700, Damian Rouson said: >/usr/include/dispatch/object.h:143:15: error: expected unqualified-id >before '^' token > typedef void (^dispatch_block_t)(void); > ^ >/usr/include/dispatch/object.h:143:15: error: expected ')' before '^' token >/usr/include/dispatch/object.h:362:3: error: 'dispatch_block_t' has not >been declared > dispatch_block_t notification_block); Your compiler doesn't support "blocks": and the latest OS X SDKs require such support. You could try building CMake against an older SDK, or just use clang, the default compiler on OS X. I think Apple added blocks support to their fork of gcc (long ago), but I don't think it ever went into mainline gcc. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From jay.custin at hpe.com Fri Oct 2 12:40:51 2015 From: jay.custin at hpe.com (Custin, Jay (CSC Sw Middleware)) Date: Fri, 2 Oct 2015 16:40:51 +0000 Subject: [CMake] CMake on OpenVMS - watching CMake build process run through its enormous number of self-tests!!!! Message-ID: Cautiously optimistic... Staring at my terminal session watching self-tests execute... <> -- Performing Test HAVE_RESTRICT -- Performing Test HAVE_RESTRICT - Success -- Performing Test HAVE___RESTRICT -- Performing Test HAVE___RESTRICT - Success -- Performing Test HAVE_INLINE -- Performing Test HAVE_INLINE - Success -- Performing Test HAVE___INLINE -- Performing Test HAVE___INLINE - Success <> -- Looking for symlink -- Looking for symlink - found -- Looking for timegm -- Looking for timegm - not found -- Looking for tzset -- Looking for tzset - found -- Looking for utime -- Looking for utime - found -- Looking for utimes -- Looking for utimes - found -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Fri Oct 2 16:08:40 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Fri, 2 Oct 2015 16:08:40 -0400 Subject: [CMake] CMake on OpenVMS - watching CMake build process run through its enormous number of self-tests!!!! In-Reply-To: References: Message-ID: <560EE448.7050804@kitware.com> On 10/2/2015 12:40 PM, Custin, Jay (CSC Sw Middleware) wrote: > Cautiously optimistic? > > Staring at my terminal session watching self-tests execute? > Hey, that is cool. Hopefully when you are done you can setup a dashboard so we can make sure the changes you put into CMake work into the future. https://cmake.org/Wiki/CMake/Git/Dashboard https://cmake.org/gitweb?p=cmake.git;a=blob_plain;f=cmake_common.cmake;hb=refs/heads/dashboard Good luck! I spent some time about 6 or 7 years ago and got most of it working, but with no testing it did not last.... -Bill From wladimirkroeker at gmail.com Fri Oct 2 16:53:40 2015 From: wladimirkroeker at gmail.com (compix) Date: Fri, 2 Oct 2015 13:53:40 -0700 (MST) Subject: [CMake] Ignoring Visual Studio 2015 warnings in .inl files Message-ID: <1443819220830-7591685.post@n2.nabble.com> Hey, I'm trying to ignore warnings in VS2015 in .inl files with set(CMAKE_CXX_FLAGS "/w") set(CMAKE_C_FLAGS "/w") Unfortunately it doesn't work. I'd be glad if anyone could help me out. Best regards Wladimir -- View this message in context: http://cmake.3232098.n2.nabble.com/Ignoring-Visual-Studio-2015-warnings-in-inl-files-tp7591685.html Sent from the CMake mailing list archive at Nabble.com. From niels_dekker_address_until_2018 at xs4all.nl Fri Oct 2 17:45:55 2015 From: niels_dekker_address_until_2018 at xs4all.nl (Niels Dekker - address until 2018) Date: Fri, 2 Oct 2015 23:45:55 +0200 Subject: [CMake] Ignoring Visual Studio 2015 warnings in .inl files In-Reply-To: <1443819220830-7591685.post@n2.nabble.com> References: <1443819220830-7591685.post@n2.nabble.com> Message-ID: <560EFB13.1000100@xs4all.nl> On 02 Oct 2015 10:53 PM, compix (Wladimir) wrote: > I'm trying to ignore warnings in VS2015 in .inl files with > set(CMAKE_CXX_FLAGS "/w") > set(CMAKE_C_FLAGS "/w") > > Unfortunately it doesn't work. > I'd be glad if anyone could help me out. First of all, it is often preferable to fix warnings, instead of ignoring them. Of course... :-) Then it appears that with VS2010 - VS2015, adding "/w" to CMAKE_CXX_FLAGS may trigger another warning, "warning D9025: overriding '/W1' with '/w'". For details, you may check http://public.kitware.com/pipermail/vtkusers/2015-September/092255.html However, that issue does not occur when you replace your "/w" by "/W0". ITK and VTK basically use the following two CMake commands to disable MSVC warnings: string(REGEX REPLACE "(^| )[/-]W[0-4]( |$)" " " CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}") set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W0") For example, look at macro(itk_module_warnings_disable) in https://github.com/InsightSoftwareConsortium/ITK/blob/master/CMake/ITKModuleMacros.cmake#L327 Keep in mind that doing so disables all warnings in a project. If you want to disable only warnings from header files, you can do #pragma warning(push, 0) before the #include statement, and #pragma warning(pop) afterwards. But of course, that's just Visual C++, not CMake! Good luck! Niels -- Niels Dekker Scientific programmer LKEB, Division of Image Processing Leiden University Medical Center From wladimirkroeker at gmail.com Fri Oct 2 18:25:49 2015 From: wladimirkroeker at gmail.com (compix) Date: Fri, 2 Oct 2015 15:25:49 -0700 (MST) Subject: [CMake] Ignoring Visual Studio 2015 warnings in .inl files In-Reply-To: <560EFB13.1000100@xs4all.nl> References: <1443819220830-7591685.post@n2.nabble.com> <560EFB13.1000100@xs4all.nl> Message-ID: <1443824749353-7591687.post@n2.nabble.com> Thanks for the answer. I should indeed replace the "/w" with "/W0" although msdn states as of 03.10.2015 that the option is called "/w". Both options ignore all warnings in *.h*, *.c* files but /not / in *.inl* files. I fix all my warnings since I usually treat them as errors but not in external libraries. I could fix this by linking it dynamically but then I'd lose potential optimizations and I don't like .dlls. The flags aren't project wide because I use multiple cmake files thus only warnings of subfolders are ignored. Oh and I don't want to spam my project with #pragmas :) -- View this message in context: http://cmake.3232098.n2.nabble.com/Ignoring-Visual-Studio-2015-warnings-in-inl-files-tp7591685p7591687.html Sent from the CMake mailing list archive at Nabble.com. From wladimirkroeker at gmail.com Fri Oct 2 18:48:05 2015 From: wladimirkroeker at gmail.com (compix) Date: Fri, 2 Oct 2015 15:48:05 -0700 (MST) Subject: [CMake] Ignoring Visual Studio 2015 warnings in .inl files In-Reply-To: <1443824749353-7591687.post@n2.nabble.com> References: <1443819220830-7591685.post@n2.nabble.com> <560EFB13.1000100@xs4all.nl> <1443824749353-7591687.post@n2.nabble.com> Message-ID: <1443826085163-7591688.post@n2.nabble.com> Ok, it seems like the .inl files aren't the cause of the problem. I can ignore all warnings in the whole project but it just partially works for subfolders. I guess it was just a coincidence that all *.h*, *.c* warnings were ignored and .inl remained in my case. -- View this message in context: http://cmake.3232098.n2.nabble.com/Ignoring-Visual-Studio-2015-warnings-in-inl-files-tp7591685p7591688.html Sent from the CMake mailing list archive at Nabble.com. From mcodev31 at gmail.com Sun Oct 4 01:37:56 2015 From: mcodev31 at gmail.com (Marcus Johansson) Date: Sun, 4 Oct 2015 07:37:56 +0200 Subject: [CMake] GenerateExportHeader C-only projects Message-ID: Hi everyone I hope this is the right place to ask Whatever happened to this commit to include support for C-only projects when generating export headers? https://cmake.org/pipermail/cmake-commits/2012-August/013142.html Are there any plans to support this in the future? /Marcus From attila.krasznahorkay at gmail.com Mon Oct 5 09:23:01 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Mon, 5 Oct 2015 15:23:01 +0200 Subject: [CMake] Removing duplicate entries from CXXFLAGS Message-ID: <4991AB9F-E597-4D79-8DDE-60FC7377EB76@gmail.com> Dear All, Let me try a simpler question this time. (I'm a bit disappointed that nobody had any comments on my question about sub-projects.) I'm trying to clean up my project's build a bit. As it collects compilation flags from a few separate places, by the time it finishes collecting everything, the compilation commands are usually very long. As they have many duplications. Like: -m64 -pipe -W -Wall -Woverloaded-virtual -fsigned-char -fno-common -Qunused-arguments -pthread -std=c++11 -Wno-deprecated-declaration s -stdlib=libc++ -m64 -pipe -W -Wall -Woverloaded-virtual -fsigned-char -fno-common -Qunused-arguments -pthread -std=c++ 11 -Wno-deprecated-declarations -stdlib=libc++ -Wno-unused-local-typedefs -Wno-tautological-undefined-compare -Wno-incon sistent-missing-override -m64 -pipe -W -Wall -Woverloaded-virtual -fsigned-char -fno-common -Qunused-arguments -pthread -std=c++11 -Wno-deprecated-declarations -stdlib=libc++ -m64 -pipe -W -Wall -Woverloaded-virtual -fsigned-char -fno-commo n -Qunused-arguments -pthread -std=c++11 -Wno-deprecated-declarations -stdlib=libc++ -m64 -pipe -W -Wall -Woverloaded-vi rtual -fsigned-char -fno-common -Qunused-arguments -pthread -std=c++11 -Wno-deprecated-declarations -stdlib=libc++ -m64 -pipe -W -Wall -Woverloaded-virtual -fsigned-char -fno-common -Qunused-arguments -pthread -std=c++11 -Wno-deprecated-dec larations -stdlib=libc++ -m64 -pipe -fsigned-char -fno-common -Qunused-arguments -pthread -std=c++11 -stdlib=libc++ Naturally it would help the build log reading tremendously if I could remove the duplications from these lines. But I can't find a good way of doing it. How could I weed out all the duplications in the CXXFLAGS associated to a given target? Cheers, Attila From tom.kacvinsky at vectorcast.com Mon Oct 5 11:09:40 2015 From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky) Date: Mon, 5 Oct 2015 11:09:40 -0400 Subject: [CMake] jom and cmake Message-ID: We are using "JOM Makefiles NMakefiles" as our generator. Everything is fine, but every now and again I need to investigate the temporary files tha jom produces. I can do this by using the /KEEPTEMPFILES option to jom, but where I am stymied is how to configure cmake so that when jom is invoked when cmake is invoked with --build, jom gets this option. Does anyone here know how to do this? Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Oct 5 11:31:04 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 05 Oct 2015 11:31:04 -0400 Subject: [CMake] [cmake-developers] Rename suffix of Mac OS Framework In-Reply-To: <7C68D75D-3BC9-4729-8DC5-B720A7AADB34@gmx.at> References: <7C68D75D-3BC9-4729-8DC5-B720A7AADB34@gmx.at> Message-ID: <561297B8.2010507@kitware.com> On 10/01/2015 04:07 AM, Roman W?ger wrote: > set_target_properties(${PROJECT_NAME} PROPERTIES FRAMEWORK TRUE) > > Is there a way to rename the suffix ".framework"? Not currently. It is hard-coded here: https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmGeneratorTarget.cxx;hb=679a5d21#l2981 What is the use case for changing the framework extension? Doing so breaks the basic layout defined in "man ld": -framework name[,suffix] This option tells the linker to search for `name.frame- work/name' the framework search path. If the optional suffix is specified the framework is first searched for the name with the suffix and then without (e.g. look for `name.framework/name_suffix' first, if not there try `name.framework/name'). -Brad From nilsgladitz at gmail.com Mon Oct 5 11:38:34 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 5 Oct 2015 17:38:34 +0200 Subject: [CMake] jom and cmake In-Reply-To: References: Message-ID: <5612997A.3020808@gmail.com> On 05.10.2015 17:09, Tom Kacvinsky wrote: > We are using "JOM Makefiles NMakefiles" as our generator. Everything > is fine, but every now and again I need to investigate the temporary > files tha jom produces. I can do this by using the /KEEPTEMPFILES > option to jom, but where I am stymied is how to configure cmake so > that when jom is invoked when cmake is invoked with --build, jom gets > this option. From the manual: cmake --build [] [-- ...] so something like e.g. cmake --build . -- /KEEPTEMPFILES should work(?) Nils From parag at ionicsecurity.com Mon Oct 5 13:16:53 2015 From: parag at ionicsecurity.com (Parag Chandra) Date: Mon, 5 Oct 2015 17:16:53 +0000 Subject: [CMake] jom and cmake In-Reply-To: References: Message-ID: <148847F1-98D0-4DBD-B20E-B1680376ABAE@ionicsecurity.com> If I?m not mistaken, anything you place after a ??? (that?s two dash characters) will be passed directly to the underlying build tool that cmake is driving. See here: https://cmake.org/cmake/help/v3.3/manual/cmake.1.html 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: CMake on behalf of Tom Kacvinsky Date: Monday, October 5, 2015 at 11:09 AM To: "cmake at cmake.org" Subject: [CMake] jom and cmake We are using "JOM Makefiles NMakefiles" as our generator. Everything is fine, but every now and again I need to investigate the temporary files tha jom produces. I can do this by using the /KEEPTEMPFILES option to jom, but where I am stymied is how to configure cmake so that when jom is invoked when cmake is invoked with --build, jom gets this option. Does anyone here know how to do this? Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.kacvinsky at vectorcast.com Mon Oct 5 13:19:27 2015 From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky) Date: Mon, 5 Oct 2015 13:19:27 -0400 Subject: [CMake] jom and cmake In-Reply-To: <148847F1-98D0-4DBD-B20E-B1680376ABAE@ionicsecurity.com> References: <148847F1-98D0-4DBD-B20E-B1680376ABAE@ionicsecurity.com> Message-ID: On Mon, Oct 5, 2015 at 1:16 PM, Parag Chandra wrote: > If I?m not mistaken, anything you place after a ??? (that?s two dash > characters) will be passed directly to the underlying build tool that cmake > is driving. See here: > > https://cmake.org/cmake/help/v3.3/manual/cmake.1.html > > Thanks guys, that is exactly what I was looking for. I should have realized this as we pass -j8 after the -- on Linux, so make gets invoked in parallel mode -------------- next part -------------- An HTML attachment was scrubbed... URL: From roolebo at gmail.com Tue Oct 6 06:58:02 2015 From: roolebo at gmail.com (Roman Bolshakov) Date: Tue, 06 Oct 2015 03:58:02 -0700 (PDT) Subject: [CMake] Removing duplicate entries from CXXFLAGS In-Reply-To: <4991AB9F-E597-4D79-8DDE-60FC7377EB76@gmail.com> References: <4991AB9F-E597-4D79-8DDE-60FC7377EB76@gmail.com> Message-ID: <1444129082163.230215fd@Nodemailer> CMake performs deduplication of per-target flags for sure. However I'm not sure if CMAKE_CXX_FLAGS is deduplicated. But I consider this variable as global flags for the whole project which is defined at topmost CMakeLists.txt. If you need to specify some flags specifically for a target use target_compile_options. ? Sent from Mailbox On Mon, Oct 5, 2015 at 4:23 PM, Attila Krasznahorkay wrote: > Dear All, > Let me try a simpler question this time. (I'm a bit disappointed that nobody had any comments on my question about sub-projects.) > I'm trying to clean up my project's build a bit. As it collects compilation flags from a few separate places, by the time it finishes collecting everything, the compilation commands are usually very long. As they have many duplications. Like: > -m64 -pipe -W > -Wall -Woverloaded-virtual -fsigned-char -fno-common -Qunused-arguments -pthread -std=c++11 -Wno-deprecated-declaration > s -stdlib=libc++ -m64 -pipe -W -Wall -Woverloaded-virtual -fsigned-char -fno-common -Qunused-arguments -pthread -std=c++ > 11 -Wno-deprecated-declarations -stdlib=libc++ -Wno-unused-local-typedefs -Wno-tautological-undefined-compare -Wno-incon > sistent-missing-override -m64 -pipe -W -Wall -Woverloaded-virtual -fsigned-char -fno-common -Qunused-arguments -pthread > -std=c++11 -Wno-deprecated-declarations -stdlib=libc++ -m64 -pipe -W -Wall -Woverloaded-virtual -fsigned-char -fno-commo > n -Qunused-arguments -pthread -std=c++11 -Wno-deprecated-declarations -stdlib=libc++ -m64 -pipe -W -Wall -Woverloaded-vi > rtual -fsigned-char -fno-common -Qunused-arguments -pthread -std=c++11 -Wno-deprecated-declarations -stdlib=libc++ -m64 > -pipe -W -Wall -Woverloaded-virtual -fsigned-char -fno-common -Qunused-arguments -pthread -std=c++11 -Wno-deprecated-dec > larations -stdlib=libc++ -m64 -pipe -fsigned-char -fno-common -Qunused-arguments -pthread -std=c++11 -stdlib=libc++ > Naturally it would help the build log reading tremendously if I could remove the duplications from these lines. But I can't find a good way of doing it. How could I weed out all the duplications in the CXXFLAGS associated to a given target? > Cheers, > Attila > -- > 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 Tue Oct 6 07:18:09 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Tue, 6 Oct 2015 11:18:09 +0000 Subject: [CMake] How to check if test exists Message-ID: <282013D2-3E63-4EC8-BAE5-FF0C9C4918DC@sap.com> Hi, What is the best way to check if a test is already defined using function add_test? My initial though was that if() can be used for that purpose but, unfortunately, if (TEST ) is not supported for now. Thanks. Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.krasznahorkay at gmail.com Tue Oct 6 07:23:05 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Tue, 6 Oct 2015 13:23:05 +0200 Subject: [CMake] Removing duplicate entries from CXXFLAGS In-Reply-To: <1444129082163.230215fd@Nodemailer> References: <4991AB9F-E597-4D79-8DDE-60FC7377EB76@gmail.com> <1444129082163.230215fd@Nodemailer> Message-ID: <5E005D39-34D8-43CD-B914-4FA27837A045@gmail.com> Hi Roman, I'm not necessarily only talking about CMAKE_CXX_FLAGS here. I define compile flags for my targets in a number of different ways. Like: find_package( ROOT COMPONENTS ${ROOT_LINK_COMPONENTS} REQUIRED ) include( ${ROOT_USE_FILE} ) ... add_definitions( ${ATLAS_DEFINITIONS} ) ... add_definitions( -Wno-unused-local-typedefs ) if( APPLE ) add_definitions( -Wno-tautological-undefined-compare ) add_definitions( -Wno-inconsistent-missing-override ) endif() ... include_directories( BEFORE ${CMAKE_CURRENT_SOURCE_DIR} ${CMAKE_INCLUDE_OUTPUT_DIRECTORY} ) if( ARG_INCLUDE_DIRS ) target_include_directories( ${libName} PUBLIC ${ARG_INCLUDE_DIRS} ) endif() The trickiest are the definitions that I pull in from external packages. For instance the second line in this example produces a *lot* of duplicate entries in the compilation flags. In this particular case the flags *are* defined like the following in the file that I include with ${ROOT_USE_FILE}: add_definitions(${ROOT_DEFINITIONS}) set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${ROOT_CXX_FLAGS}") Now, CMake definitely doesn't remove the duplicates that enter in all these ways. So now I was wondering what I could do to improve on the situation... Cheers, Attila > On 06 Oct 2015, at 12:58, Roman Bolshakov wrote: > > CMake performs deduplication of per-target flags for sure. > > However I'm not sure if CMAKE_CXX_FLAGS is deduplicated. But I consider this variable as global flags for the whole project which is defined at topmost CMakeLists.txt. If you need to specify some flags specifically for a target use target_compile_options. > > ? > Sent from Mailbox > > > On Mon, Oct 5, 2015 at 4:23 PM, Attila Krasznahorkay wrote: > > Dear All, > > Let me try a simpler question this time. (I'm a bit disappointed that nobody had any comments on my question about sub-projects.) > > I'm trying to clean up my project's build a bit. As it collects compilation flags from a few separate places, by the time it finishes collecting everything, the compilation commands are usually very long. As they have many duplications. Like: > > -m64 -pipe -W > -Wall -Woverloaded-virtual -fsigned-char -fno-common -Qunused-arguments -pthread -std=c++11 -Wno-deprecated-declaration > s -stdlib=libc++ -m64 -pipe -W -Wall -Woverloaded-virtual -fsigned-char -fno-common -Qunused-arguments -pthread -std=c++ > 11 -Wno-deprecated-declarations -stdlib=libc++ -Wno-unused-local-typedefs -Wno-tautological-undefined-compare -Wno-incon > sistent-missing-override -m64 -pipe -W -Wall -Woverloaded-virtual -fsigned-char -fno-common -Qunused-arguments -pthread > -std=c++11 -Wno-deprecated-declarations -stdlib=libc++ -m64 -pipe -W -Wall -Woverloaded-virtual -fsigned-char -fno-commo > n -Qunused-arguments -pthread -std=c++11 -Wno-deprecated-declarations -stdlib=libc++ -m64 -pipe -W -Wall -Woverloaded-vi > rtual -fsigned-char -fno-common -Qunused-arguments -pthread -std=c++11 -Wno-deprecated-declarations -stdlib=libc++ -m64 > -pipe -W -Wall -Woverloaded-virtual -fsigned-char -fno-common -Qunused-arguments -pthread -std=c++11 -Wno-deprecated-dec > larations -stdlib=libc++ -m64 -pipe -fsigned-char -fno-common -Qunused-arguments -pthread -std=c++11 -stdlib=libc++ > > Naturally it would help the build log reading tremendously if I could remove the duplications from these lines. But I can't find a good way of doing it. How could I weed out all the duplications in the CXXFLAGS associated to a given target? > > Cheers, > Attila > -- > > 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 mike.jackson at bluequartz.net Tue Oct 6 09:14:41 2015 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Tue, 6 Oct 2015 09:14:41 -0400 Subject: [CMake] Multiple Executables for every target in Xcode Message-ID: <3AF3090D-7872-41C4-82F7-A0A67FD1E062@bluequartz.net> hello list, I am running Xcode (5 & 6) and using CMake to generate the Xcode project files. We have a lot of targets for our project and we were looking into ways of refactoring the Cmake codes in order to reduce the number of targets. For example we have a lot of plugins that we compile and each plugin is its own "project()" command. One of the things that we have noticed is that just about every "add_executable()" command results in 2 executable targets in the generated Xcode project. I was just wondering if anyone has seen anything like this. We are using CMake 3.3.1 on OS X (10.8/10.9/10.10). Thanks Mike Jackson From robert.maynard at kitware.com Tue Oct 6 11:42:58 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 6 Oct 2015 11:42:58 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.4.0-rc1 is now ready! Message-ID: I am proud to announce the first CMake 3.4 release candidate. Sources and binaries are available at: https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.4 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.4/release/3.4.html Some of the more significant features of CMake 3.4 are: * The "if()" command learned a new "TEST" operator that evaluates to true if a given test name has been defined by the "add_test()" command. See policy "CMP0064". * The "install(DIRECTORY)" command "DESTINATION" option learned to support "generator expressions". * The "install(FILES)" command "DESTINATION" option learned to support "generator expressions". * CMake learned to honor "*.manifest" source files with MSVC tools. Manifest files named as sources of ".exe" and ".dll" targets will be merged with linker-generated manifests and embedded in the binary. Deprecated and Removed Features: * The "CMakeExpandImportedTargets" module is now documented as deprecated. See module documentation for an explanation. * The "CMAKE_USE_RELATIVE_PATHS" variable no longer has any effect. Previously it was partially implemented and unreliable. CMake 3.4 Release Notes *********************** Changes made since CMake 3.3 include the following. New Features ============ Generators ---------- * The "Visual Studio 14 2015" generator learned to select a Windows 10 SDK based on the value of the "CMAKE_SYSTEM_VERSION" variable and the SDKs available on the host. * CMake learned rudimentary support for the Apple Swift language. When using the "Xcode" generator with Xcode 6.1 or higher, one may enable the "Swift" language with the "enable_language()" command or the "project()" command (this is an error with other generators or when Xcode is too old). Then one may list ".swift" source files in targets for compilation. Commands -------- * The "find_program()" command learned a "NAMES_PER_DIR" option to consider all given "NAMES" in each directory before moving on to the next directory. * The "get_filename_component()" command learned a new "BASE_DIR" subcommand. This is used to specify a base directory when calculating an absolute path from a relative path. * The "if()" command learned a new "TEST" operator that evaluates to true if a given test name has been defined by the "add_test()" command. See policy "CMP0064". * The "install(DIRECTORY)" command "DESTINATION" option learned to support "generator expressions". * The "install(FILES)" command "DESTINATION" option learned to support "generator expressions". * The "string()" command learned a new "APPEND" subcommand. Variables --------- * The Makefile Generators and the "Ninja" generator learned to add compiler launcher tools like distcc and ccache along with the compiler for "C" and "CXX" languages. See the "CMAKE__COMPILER_LAUNCHER" variable and "_COMPILER_LAUNCHER" target property for details. * New "CMAKE_LINK_SEARCH_START_STATIC" and "CMAKE_LINK_SEARCH_END_STATIC" variables were introduced to initialize the "LINK_SEARCH_START_STATIC" and "LINK_SEARCH_END_STATIC" target properties, respectively. Properties ---------- * Visual Studio Generators learned to support additonal target properties to customize projects for NVIDIA Nsight Tegra Visual Studio Edition: * "ANDROID_ANT_ADDITIONAL_OPTIONS" * "ANDROID_ARCH" * "ANDROID_ASSETS_DIRECTORIES" * "ANDROID_JAR_DEPENDENCIES" * "ANDROID_JAR_DIRECTORIES" * "ANDROID_JAVA_SOURCE_DIR" * "ANDROID_NATIVE_LIB_DEPENDENCIES" * "ANDROID_NATIVE_LIB_DIRECTORIES" * "ANDROID_PROCESS_MAX" * "ANDROID_PROGUARD" * "ANDROID_PROGUARD_CONFIG_PATH" * "ANDROID_SECURE_PROPS_PATH" * "ANDROID_SKIP_ANT_STEP" * "ANDROID_STL_TYPE" * The "ARCHIVE_OUTPUT_DIRECTORY", "LIBRARY_OUTPUT_DIRECTORY", and "RUNTIME_OUTPUT_DIRECTORY" target properties learned to support "generator expressions". * The "SOURCE_DIR" and "BINARY_DIR" target properties were introduced to allow project code to query where a target is defined. * The "OUTPUT_NAME" target property and its variants learned to support "generator expressions". * A "TARGET_MESSAGES" global property was added to tell the Makefile Generators whether to generate commands to print output after each target is completed. * On Windows with MS-compatible tools, CMake learned to optionally generate a module definition (".def") file for "SHARED" libraries. See the "WINDOWS_EXPORT_ALL_SYMBOLS" target property. Modules ------- * The "ExternalProject" module "ExternalProject_Add()" function "GIT_SUBMODULES" option now also limits the set of submodules that are initialized in addition to the prior behavior of limiting the set of submodules that are updated. * The "ExternalProject" module learned new "USES_TERMINAL" arguments for giving steps exclusive terminal access. This is useful with the "Ninja" generator to monitor CMake superbuild progress and prevent CPU oversubscription. * The "FindBISON" module "BISON_TARGET" macro learned a new "DEFINES_FILE" option to specify a custom output header to be generated. * The "FindHDF5" module learend a new "HDF5_PREFER_PARALLEL" option allowing users to specify that a parallel HDF5 tool is preferred if both are available. * The "FindIce" module now provides imported targets. * The "FindJava" module learned to optionally find the "idlj" and "jarsigner" tools. * The "FindOpenSSL" module now provides imported targets. * The "FindOpenSSL" module learned a new "OPENSSL_USE_STATIC_LIBS" option to search only for static libraries. * The "FindPkgConfig" learned a new "pkg_get_variable()" command which may be used to query for arbitrary variables from a package (such as for related tools or data and plugin install paths). * The "FindProtobuf" module gained a new "protobuf_generate_python()" function to generate python sources from ".proto" files. * The "FindTIFF" module learned to search separately for debug and release variants. * The "FindwxWidgets" module learned to support version requests. * The "FindXercesC" module learned to search separately for debug and release variants. * The "FindZLIB" module learned to search separately for debug and release variants. * The "GNUInstallDirs" module learned special default values for certain installation prefixes according to the GNU Coding Standards and the Filesystem Hierarchy Standard. * The "UseJava" module "add_jar" function learned to support response files (e.g. "@srcs.txt") for source specification. * The "UseJava" module "install_jar" function learned new "DESTINATION" and "COMPONENT" options to specify the corresponding "install()" command options. * The "UseJava" module gained a new "create_javah" function to create C headers from Java classes. Generator Expressions --------------------- * A new "$" "generator expression" has been added. CTest ----- * CTest learned to optionally measure the CPU load during parallel testing and avoid starting tests that may cause the load to exceed a given threshold. See the "ctest(1)" command "--test-load" option, the "TestLoad" setting of the CTest Test Step, the "CTEST_TEST_LOAD" variable, and the "TEST_LOAD" option of the "ctest_test()" command. * "ctest(1)" learned options "--test-output-size-passed" and "-- test- output-size-failed" to customize the limit on test output size submitted when running as a Dashboard Client. CPack ----- * The "CPackDeb" module learned to set package dependencies per component. See variables: * "CPACK_DEBIAN__PACKAGE_BREAKS" * "CPACK_DEBIAN__PACKAGE_CONFLICTS" * "CPACK_DEBIAN__PACKAGE_ENHANCES" * "CPACK_DEBIAN__PACKAGE_PREDEPENDS" * "CPACK_DEBIAN__PACKAGE_PROVIDES" * "CPACK_DEBIAN__PACKAGE_RECOMMENDS" * "CPACK_DEBIAN__PACKAGE_REPLACES" * "CPACK_DEBIAN__PACKAGE_SUGGESTS" * The "CPack" module learned to package empty directories. * The "CPack" module gained a new setting, "CPACK_VERBATIM_VARIABLES", which can be used to ensure the cpack program receives the settings' values exactly as they were set, even if they contain CMake-special characters. For compatibility, it's off by default. Other ----- * The "Compile Features" functionality is now aware of features supported by GNU C compilers on Windows. * CMake learned to honor "*.manifest" source files with MSVC tools. Manifest files named as sources of ".exe" and ".dll" targets will be merged with linker-generated manifests and embedded in the binary. * The Concurrent Fortran 77 compiler is now supported. Its "compiler id" is "CCur". * "cmake(1)" gained a new "--trace-expand" command line option that is like "--trace" but expands variable references in the output. Deprecated and Removed Features =============================== * The "CMakeExpandImportedTargets" module is now documented as deprecated. See module documentation for an explanation. * The "CMAKE_USE_RELATIVE_PATHS" variable no longer has any effect. Previously it was partially implemented and unreliable. Other Changes ============= * The "CheckFunctionExists", "CheckLibraryExists", "CheckSymbolExists", and "FindThreads" modules learned to work in environments where only CXX is enabled. * The "CPackDeb" module now correctly excludes symlinks during package checksum calculation. * The "CPackDeb" no longer uses fakeroot and system tar program for packaging. * The "CPack" module no longer mangles settings with CMake-special characters when they're used as defaults for other settings. The macro "cpack_set_if_not_set", which was responsible for this, is now deprecated. * CMake no longer links executables with flags to export symbols unless the "ENABLE_EXPORTS" target property is set. See policy "CMP0065". * The "SONAME" field is no longer set for "MODULE" libraries created with the "add_library()" command. "MODULE" libraries are meant for explicit dynamic loading at runtime. They cannot be linked so "SONAME" is not useful. From podenok at lsi.bas-net.by Tue Oct 6 11:55:04 2015 From: podenok at lsi.bas-net.by (podenok) Date: Tue, 6 Oct 2015 18:55:04 +0300 Subject: [CMake] FindPNG can not find files to set PNG_PNG_INCLUDE_DIR, PNG_LIBRARY Message-ID: <5613EED8.8020104@lsi.bas-net.by> I have libpng16.dll, libpng16.lib, and png.h Where should I put these files to cmake:FindPNG foud them? From thibaut.neiger at gmail.com Tue Oct 6 13:49:01 2015 From: thibaut.neiger at gmail.com (Thibaut Neiger) Date: Tue, 6 Oct 2015 14:49:01 -0300 Subject: [CMake] FindCUDA discard any previous value of CUDA_USE_STATIC_CUDA_RUNTIME Message-ID: <5614098D.6010900@gmail.com> Hello. I am using cmake 3.3.2. The following script sets the CUDA_USE_STATIC_CUDA_RUNTIME option, then finds the CUDA package. cmake_minimum_required(VERSION 3.3) option(CUDA_USE_STATIC_CUDA_RUNTIME OFF) set(CUDA_TOOLKIT_ROOT_DIR "d:/work/CUDAToolkit") message(STATUS CUDA_USE_STATIC_CUDA_RUNTIME=${CUDA_USE_STATIC_CUDA_RUNTIME}) find_package(CUDA) message(STATUS CUDA_USE_STATIC_CUDA_RUNTIME=${CUDA_USE_STATIC_CUDA_RUNTIME}) In the find_package, the variable CUDA_TOOLKIT_ROOT_DIR is compared to the variable CUDA_TOOLKIT_ROOT_DIR_INTERNAL (line 556). Since this variable is not defined, the cuda_unset_include_and_libraries function is called. This function wipes the CUDA_USE_STATIC_CUDA_RUNTIME option from the cache. In order to correctly set this variable, I need to restart change it back to OFF, then the FindCUDA script doesn't call cuda_unset_include_and_libraries function. Thibaut. From iraytrace at gmail.com Tue Oct 6 16:21:38 2015 From: iraytrace at gmail.com (Lee Butler) Date: Tue, 6 Oct 2015 16:21:38 -0400 Subject: [CMake] Release and Debug build linking Message-ID: <56142D52.1040801@gmail.com> I am looking for a way to tell my project to link against external debug libraries with a debug build and external release libraries with a release build with Visual Studio. I sort of want to be able to say something like if (BuildingReleaseConfig) find_package(OtherPackage REQUIRED COMPONENTS one two three PATHS OtherPkgDir/Release) endif() if (BuildingDebugConfig) find_package(OtherPackage REQUIRED COMPONENTS oned twod threed PATHS OtherPkgDir/Debug) endif() the idea is that the if () tells CMake which build configuration the find_package results should go into. Is there any way to tell CMake what to write into each VS configuration? I realize the traditional CMake way is to create only one build at a time and specify CMAKE_BUILD_TYPE, but we seem to have stepped beyond that with the Visual Studio generator. Lee From tamas.kenez at gmail.com Tue Oct 6 17:19:25 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Tue, 6 Oct 2015 23:19:25 +0200 Subject: [CMake] Release and Debug build linking In-Reply-To: <56142D52.1040801@gmail.com> References: <56142D52.1040801@gmail.com> Message-ID: CMake supports multi-config generators such as Visual Studio and Xcode for a long time. There are two flavors of config-modules (and find-modules), the legacy one which creates variables like MY_PACKAGE_LIBRARIES and the install-export kind which creates IMPORTED targets. Both kinds of modules support providing Debug and Release versions of the same library from a single find-module or config-module. So if your package's find-module or config-module is written correctly you don't need any if's just a single find_package(). Tamas On Tue, Oct 6, 2015 at 10:21 PM, Lee Butler wrote: > I am looking for a way to tell my project to link against external debug > libraries with a debug build and external release libraries with a release > build with Visual Studio. > > I sort of want to be able to say something like > if (BuildingReleaseConfig) > find_package(OtherPackage REQUIRED COMPONENTS one two three PATHS > OtherPkgDir/Release) > endif() > > if (BuildingDebugConfig) > find_package(OtherPackage REQUIRED COMPONENTS oned twod threed PATHS > OtherPkgDir/Debug) > endif() > > the idea is that the if () tells CMake which build configuration the > find_package results should go into. Is there any way to tell CMake what > to write into each VS configuration? > > I realize the traditional CMake way is to create only one build at a time > and specify CMAKE_BUILD_TYPE, but we seem to have stepped beyond that with > the Visual Studio generator. > > Lee > -- > > 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 iraytrace at gmail.com Tue Oct 6 18:06:46 2015 From: iraytrace at gmail.com (Lee Butler) Date: Tue, 6 Oct 2015 18:06:46 -0400 Subject: [CMake] Release and Debug build linking In-Reply-To: References: Message-ID: <561445F6.3020105@gmail.com> So if this is the case, how does one "write correctly" the find/config module so that both debug and release libraries are found? I've got a library I depend on whose maintainer may not have built the best Find module in the world. I've looked at https://cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file already. It doesn't seem to address picking up both release and debug libraries. I gather from another example that the goal is to create a list of the form: optimized;foolib.lib;debug;foolibd.lib and provide that in the FOO_LIBRARY variable? From orion at cora.nwra.com Tue Oct 6 23:00:10 2015 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 6 Oct 2015 21:00:10 -0600 Subject: [CMake] [ANNOUNCE] CMake 3.4.0-rc1 is now ready! In-Reply-To: References: Message-ID: <56148ABA.5070303@cora.nwra.com> On 10/06/2015 09:42 AM, Robert Maynard wrote: > I am proud to announce the first CMake 3.4 release candidate. This appears to have broken plplot's ada build on Fedora. Previous good (cmake 3.3.2): [ 22%] Building Ada object examples/ada/CMakeFiles/x00a.dir/x00a.o cd /builddir/build/BUILD/plplot-5.11.1/fedora/examples/ada && /usr/bin/gnatgcc -I/builddir/build/BUILD/plplot-5.11.1/fedora/examples/ada -I/builddir/build/BUILD/plplot-5.11.1/bindings/ada -c /builddir/build/BUILD/plplot-5.11.1/examples/ada/x00a.adb -o CMakeFiles/x00a.dir/x00a.o New bad: [ 22%] Building Ada object examples/ada/CMakeFiles/x00a.dir/x00a.o cd /builddir/build/BUILD/plplot-5.11.1/fedora/examples/ada && /usr/bin/gnatgcc -c /builddir/build/BUILD/plplot-5.11.1/examples/ada/x00a.adb -o CMakeFiles/x00a.dir/x00a.o x00a.adb:28:05: file "plplot_auxiliary.ads" not found x00a.adb:29:05: file "plplot_traditional.ads" not found examples/ada/CMakeFiles/x00a.dir/build.make:65: recipe for target 'examples/ada/CMakeFiles/x00a.dir/x00a.o' failed So we're now missing the -I include dir options. That's all I have for now, I'll try to take a closer look later. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From roman.wueger at gmx.at Wed Oct 7 04:48:04 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Wed, 7 Oct 2015 10:48:04 +0200 Subject: [CMake] [cmake-developers] Rename suffix of Mac OS Framework In-Reply-To: <561297B8.2010507@kitware.com> References: <7C68D75D-3BC9-4729-8DC5-B720A7AADB34@gmx.at> <561297B8.2010507@kitware.com> Message-ID: <03EBF395-0BA4-40FB-B835-70DB7297621A@gmx.at> Hi Brad, A use case for example is when an InDesign plugin should be developed. The InDesign plugin on Mac OS is a framework with the file extension ".InDesignPlugin". It works if the "Xcode" generator is used and the target property "XCODE_ATTRIBUTE_WRAPPER_EXTENSION" is set to "InDesignPlugin". But it doesn't work if the "Unix Makefiles" generator is used. See also https://cmake.org/Bug/view.php?id=14742 Best Regards Roman > Am 05.10.2015 um 17:31 schrieb Brad King : > >> On 10/01/2015 04:07 AM, Roman W?ger wrote: >> set_target_properties(${PROJECT_NAME} PROPERTIES FRAMEWORK TRUE) >> >> Is there a way to rename the suffix ".framework"? > > Not currently. It is hard-coded here: > > https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmGeneratorTarget.cxx;hb=679a5d21#l2981 > > What is the use case for changing the framework extension? > Doing so breaks the basic layout defined in "man ld": > > -framework name[,suffix] > This option tells the linker to search for `name.frame- > work/name' the framework search path. If the optional > suffix is specified the framework is first searched for > the name with the suffix and then without (e.g. look > for `name.framework/name_suffix' first, if not there > try `name.framework/name'). > > -Brad > From orion at cora.nwra.com Wed Oct 7 12:45:09 2015 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 7 Oct 2015 10:45:09 -0600 Subject: [CMake] [ANNOUNCE] CMake 3.4.0-rc1 is now ready! In-Reply-To: <56148ABA.5070303@cora.nwra.com> References: <56148ABA.5070303@cora.nwra.com> Message-ID: <56154C15.3030806@cora.nwra.com> On 10/06/2015 09:00 PM, Orion Poplawski wrote: > On 10/06/2015 09:42 AM, Robert Maynard wrote: >> I am proud to announce the first CMake 3.4 release candidate. > > This appears to have broken plplot's ada build on Fedora. Previous good (cmake > 3.3.2): > > [ 22%] Building Ada object examples/ada/CMakeFiles/x00a.dir/x00a.o > cd /builddir/build/BUILD/plplot-5.11.1/fedora/examples/ada && /usr/bin/gnatgcc > -I/builddir/build/BUILD/plplot-5.11.1/fedora/examples/ada > -I/builddir/build/BUILD/plplot-5.11.1/bindings/ada -c > /builddir/build/BUILD/plplot-5.11.1/examples/ada/x00a.adb -o > CMakeFiles/x00a.dir/x00a.o > > New bad: > > [ 22%] Building Ada object examples/ada/CMakeFiles/x00a.dir/x00a.o > cd /builddir/build/BUILD/plplot-5.11.1/fedora/examples/ada && > /usr/bin/gnatgcc -c > /builddir/build/BUILD/plplot-5.11.1/examples/ada/x00a.adb -o > CMakeFiles/x00a.dir/x00a.o > x00a.adb:28:05: file "plplot_auxiliary.ads" not found > x00a.adb:29:05: file "plplot_traditional.ads" not found > examples/ada/CMakeFiles/x00a.dir/build.make:65: recipe for target > 'examples/ada/CMakeFiles/x00a.dir/x00a.o' failed > > So we're now missing the -I include dir options. > > That's all I have for now, I'll try to take a closer look later. > There also appears to be a similar issue with building Paraview where the MPI_INLCUDE_PATH is no longer being passed to the compile line. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From jewel960 at gmail.com Wed Oct 7 17:14:34 2015 From: jewel960 at gmail.com (Velho Joel) Date: Thu, 8 Oct 2015 00:14:34 +0300 Subject: [CMake] Comments; GlobalVS10Gen Message-ID: Is the comment correct here? /** \class cmGlobalVisualStudio10Generator * \brief Write a Unix makefiles. * * cmGlobalVisualStudio10Generator manages UNIX build process for a tree */ File: cmGlobalVisualStudio11Generator.h Line: 18 Velho -------------- next part -------------- An HTML attachment was scrubbed... URL: From lbmgmusic at gmail.com Wed Oct 7 18:42:53 2015 From: lbmgmusic at gmail.com (Jay Cotton) Date: Wed, 7 Oct 2015 15:42:53 -0700 Subject: [CMake] Abstracting part of path name in CMakeCache Message-ID: Hi: I have a need to abstract part of the build path name in CMakeCache: Here is an excerpt # This is the CMakeCache file. # For build in directory: /export/home/xxxxx/x-s12-clone/open-src/xserver/xvnc/unpacked-src This string is seen 5 times in the cache file. I need it to look like: # For build in directory: [DISCOVERD_AT_RUNTIME]/unpacked-src This is needed because I have to modify the Cache file, and I want to keep the modified version, and not try to patch it at build time. But, it there is a way to fill in the front of the build directory name, that will solve a major problem. We use build farms and there is no way to predict what the path name will be prior to the build. I did check the -[D/etc] commands, they don't seem to provide an answer. Thanks for your help jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From dflogeras2 at gmail.com Thu Oct 8 09:47:29 2015 From: dflogeras2 at gmail.com (Dave Flogeras) Date: Thu, 8 Oct 2015 10:47:29 -0300 Subject: [CMake] CMake implicit behaviour change between 3.2.2 and 3.3.1 Message-ID: Hi list, I recently upgraded from CMake-3.2.2 to 3.3.1 (well, Gentoo did). I notice the following change. From time to time I cross compile some CMake projects against an Arm chroot. I (admittedly) do not use a toolchain file, but use the following invocation: CC="armv6j-hardfloat-linux-gnueabi-gcc --sysroot=/path/to/my/arm/root" CXX="[same idea...]" cmake .. Then it does the standard pre-configuration, and I go on my merry way with configure, make. Part of the project in question is that it uses a call to find_package_handle_standard_args() to find SQlite3 library and its headers. This has historically worked for me. As of 3.3.1, it fails when configuring, and when I dig in to the CMakeError.log I see the reason: /usr/bin/armv6j-hardfloat-linux-uclibceabi-gcc --sysroot=/mnt/data/chroots/upie -D_SQLITE3_TEST CMakeFiles/cmTC_358ee.dir/src.c.o -o cmTC_358ee -rdynamic /usr/lib/libsqlite3.so /usr/lib/libsqlite3.so: file not recognized: File format not recognized Of course the library is not recognized since it is giving an absolute path to the amd64 one. while on CMake-3.2.2 it used a different (relative) linker invocation which works: /usr/bin/armv6j-hardfloat-linux-gnueabi-gcc --sysroot=/mnt/data/chroots/pie/ -D_SQLITE3_TEST CMakeFiles/cmTryCompileExec1680248064.dir/src.c.o -o cmTryCompileExec1680248064 -rdynamic -lsqlite3 Now I realize that I was probably getting away with murder before by not using a toolchain file, and am fine if that is the only supported way of doing such a cross-compile. However, I did find it interesting that this changed and thought perhaps it was an unwanted side-effect of something else since usually any kind of behaviour changes in CMake are documented and show up as a CMPXXXX policy warning. Please advise, Dave From magnus at therning.org Fri Oct 9 07:42:34 2015 From: magnus at therning.org (Magnus Therning) Date: Fri, 9 Oct 2015 13:42:34 +0200 Subject: [CMake] DESTDIR and ExternalProject Message-ID: <20151009114234.GA1246@sobel.cipherstone.com> How can I refer to an environment variable in a generator-agnostic way? I'm struggling with constructing a functioning install command when using ExternalProject. I want to allow the following sequence of commands: % cmake .. % make % make DESTDIR=foo install The issue I run into is that I somehow have to pass DESTDIR from the environment into the install command of my ExternalProject, but how do I do that? $ENV{DESTDIR} gets expanded at generation time, which is too early. I can use $(DESTDIR), CMake happily passes that through and it works with GNU make. However, it doesn't work with e.g. Ninja (to pick just one). /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus Don't worry about other people stealing your ideas. If your ideas are any good, you?ll have to ram them down people's throats. -- Howard Aiken, IBM Engineer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From robert.bielik at dirac.se Fri Oct 9 08:21:27 2015 From: robert.bielik at dirac.se (Robert Bielik) Date: Fri, 9 Oct 2015 14:21:27 +0200 Subject: [CMake] CPack Debian Message-ID: <5617B147.7030407@dirac.se> Hi all, Is there a way to prevent CPack debian backend to tar files as "sparse" ? We have a crossdevelopment project that needs to be unpacked on distro having BusyBox v.1.20.2, which does not support sparse files. Also we need to be able to set owner/group of the extracted files (i.e. tar should be given the --owner and --group options). Ideas how to achieve these objectives ? Regards /Rob From robert.bielik at dirac.se Fri Oct 9 09:36:58 2015 From: robert.bielik at dirac.se (Robert Bielik) Date: Fri, 9 Oct 2015 15:36:58 +0200 Subject: [CMake] CPack Debian In-Reply-To: <5617B147.7030407@dirac.se> References: <5617B147.7030407@dirac.se> Message-ID: <5617C2FA.70802@dirac.se> I saw that Rafael introduced libarchive in commit 7044e8ee4, which seems to be set to both produce tars without sparse files, and having root:root as user. Correct me if I'm wrong :) Regards /R Den 2015-10-09 kl. 14:21, skrev Robert Bielik: > Hi all, > > Is there a way to prevent CPack debian backend to tar files as > "sparse" ? We have a crossdevelopment project that needs to be > unpacked on distro having BusyBox v.1.20.2, > which does not support sparse files. > > Also we need to be able to set owner/group of the extracted files > (i.e. tar should be given the --owner and --group options). > > Ideas how to achieve these objectives ? > > Regards > /Rob > From robert.bielik at dirac.se Fri Oct 9 09:37:36 2015 From: robert.bielik at dirac.se (Robert Bielik) Date: Fri, 9 Oct 2015 15:37:36 +0200 Subject: [CMake] CPack Debian In-Reply-To: <5617C2FA.70802@dirac.se> References: <5617B147.7030407@dirac.se> <5617C2FA.70802@dirac.se> Message-ID: <5617C320.2000705@dirac.se> Den 2015-10-09 kl. 15:36, skrev Robert Bielik: > I saw that Rafael introduced libarchive in commit 7044e8ee4, which > seems to be set to both produce tars without sparse files, and having > root:root as user. Sorry, that would be Raffi ;) Regards /R From laura.medioni at logilab.fr Fri Oct 9 09:53:08 2015 From: laura.medioni at logilab.fr (=?UTF-8?B?TGF1cmEgTcOpZGlvbmk=?=) Date: Fri, 09 Oct 2015 15:53:08 +0200 Subject: [CMake] CMake keeps on referencing an uninstalled Qt In-Reply-To: <5617C0D3.4000409@logilab.fr> References: <5617C0D3.4000409@logilab.fr> Message-ID: <5617C6C4.1010500@logilab.fr> Hi, I am facing a problem with CMake 3.4 under Windows. My CMake project is using Qt. Recently I uninstalled Qt and reinstalled it. Since then, the previous Qt install keeps on appearing in the CMakeCache.txt, leading to link edition errors. Extract of CMakeCache.txt content: ///Dependencies for the target// //tympan_lib_LIB_DEPENDS:STATIC=general;C:/DevelTools/CGAL-4.3/auxiliary/gmp/lib/libmpfr-4.lib;general;C:/DevelTools/CGAL-4.3/auxiliary/gmp/lib/libgmp-10.lib;optimized;C:/QtSDK/Desktop/Qt/4.8.1/msvc2010/lib/qtmain.lib;debug;C:/QtSDK/Desktop/Qt/4.8.1/msvc2010/lib/qtmaind.lib;optimized;C:/QtSDK/Desktop/Qt/4.8.1/msvc2010/lib/QtOpenGL4.lib;debug;C:/QtSDK/Desktop/Qt/4.8.1/msvc2010/lib/QtOpenGLd4.lib;optimized;C:/QtSDK/Desktop/Qt/4.8.1/msvc2010/lib/QtGui4.lib;debug;C:/QtSDK/Desktop/Qt/4.8.1/msvc2010/lib/QtGuid4.lib;optimized;C:/QtSDK/Desktop/Qt/4.8.1/msvc2010/lib/QtCore4.lib;debug;C:/QtSDK/Desktop/Qt/4.8.1/msvc2010/lib/QtCored4.lib;general;glu32;general;opengl32;optimized;C:/Qt/4.8.4/lib/QtOpenGL4.lib;debug;C:/Qt/4.8.4/lib/QtOpenGLd4.lib;optimized;C:/Qt/4.8.4/lib/QtGui4.lib;debug;C:/Qt/4.8.4/lib/QtGuid4.lib;optimized;C:/Qt/4.8.4/lib/QtTest4.lib;debug;C:/Qt/4.8.4/lib/QtTestd4.lib;optimized;C:/Qt/4.8.4/lib/QtXml4.lib;debug;C:/Qt/4.8.4/lib/QtXmld4.lib;optimized;C:/Qt/4.8.4/lib/QtCore4 .lib;debug;C:/Qt/4.8.4/lib/QtCored4.lib;general;glu32;general;opengl32;general;glu32;general;opengl32;general;RoadEmissionNMPB;general;tympan_common;general;rply;/ Example of link edition error: /39>LINK : fatal error LNK1104: cannot open file 'C:\QtSDK\Desktop\Qt\4.8.1\msvc2010\lib\qtmaind.lib'/ The uninstalled Qt was in C:/QtSDK/ directory, the new one is in C:/Qt/. The libraries of the two installs are linked to all the libraries that depend on Qt. However, C:/QtSDK/ directory doesn't exist anymore. QtSDK was properly uninstalled, there is no more track of it in the registry, nor in the environment variables. When I search for the keyword "QtSDK" at C: root (including all the file contents), the only occurence found is this CMakeCache.txt. I tried to remove all the build files, delete CMake cache and re-run the configure and generate steps, it doesn't change anything: CMakeCache.txt is re-generated with C:/Qt AND C:/QtSDK libs. When I print the content of variable ${QT_LIBRARIES} from a CMakeLists.txt, everything seems alright (no mention of QtSDK): optimized;C:/Qt/4.8.4/lib/QtOpenGL4.lib;debug;C:/Qt/4.8.4/lib/QtOpenGLd4.lib;optimized;C:/Qt/4.8.4/lib/QtGui4.lib;debug;C:/Qt/4.8.4/lib/QtGuid4.lib;optimized;C:/Qt/4.8.4/lib/QtTest4.lib;debug;C:/Qt/4.8.4/lib/QtTestd4.lib;optimized;C:/Qt/4.8.4/lib/QtXml4.lib;debug;C:/Qt/4.8.4/lib/QtXmld4.lib;optimized;C:/Qt/4.8.4/lib/QtCore4.lib;debug;C:/Qt/4.8.4/lib/QtCored4.lib I tried re-installing CMake (I was using 2.8 version), but it changed nothing. When I open the .sln with Visual Studio, on each library linked to Qt I can see the following list of libraries among others: C:\QtSDK\Desktop\Qt\4.8.1\msvc2010\lib\qtmaind.lib C:\QtSDK\Desktop\Qt\4.8.1\msvc2010\lib\QtOpenGLd4.lib C:\QtSDK\Desktop\Qt\4.8.1\msvc2010\lib\QtGuid4.lib C:\QtSDK\Desktop\Qt\4.8.1\msvc2010\lib\QtCored4.lib C:\Qt\4.8.4\lib\QtOpenGLd4.lib C:\Qt\4.8.4\lib\QtGuid4.lib C:\Qt\4.8.4\lib\QtTestd4.lib C:\Qt\4.8.4\lib\QtXmld4.lib C:\Qt\4.8.4\lib\QtCored4.lib If I manually remove the 4 first ones (still from Visual Studio) and recompile, there is no more link edition error. But each time I update the solution with cmake, the problem comes back. Any ideas? Regards, Laura M?dioni -------------- next part -------------- An HTML attachment was scrubbed... URL: From roman.wueger at gmx.at Fri Oct 9 11:51:12 2015 From: roman.wueger at gmx.at (=?iso-8859-1?Q?Roman_W=FCger?=) Date: Fri, 9 Oct 2015 17:51:12 +0200 Subject: [CMake] Xcode build settings and BullseyeCoverage Message-ID: <1a3b01d102aa$541715f0$fc4541d0$@gmx.at> Hello, I?m trying to configure and build a project with the ?Xcode? generator and the bullseye coverage tool. Without the bullseye coverage tool it works fine but if I want to use it I had to do the following workaround: http://www.bullseye.com/help/tool-xcode.html In short words, the clang and clang++ ExecPath would be changed from ?clang? => ?$(PLATFORM_DEVELOPER_BIN_DIR)/clang? and ?clang++? => ?$(PLATFORM_DEVELOPER_BIN_DIR)/clang++? Before I made the changes, CMake finds clang/clang++ under ?/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolch ain/usr/bin/clang?, with the changes CMake tries to find clang/clang++ under ?/Applications/Xcode.app/Contents/Developer/usr/bin/clang? which doesn?t exist. And I got the following error: -- The C compiler identification is unknown -- The CXX compiler identification is unknown CMake Error at CMakeLists.txt:3 (project): No CMAKE_C_COMPILER could be found. CMake Error at CMakeLists.txt:3 (project): No CMAKE_CXX_COMPILER could be found. -- Configuring incomplete, errors occurred! However, without the changes I could build the project with ?cmake ?build . -- -showBuildSettings? which gives me the following information . . . PLATFORM_DEVELOPER_APPLICATIONS_DIR = /Applications/Xcode.app/Contents/Developer/Applications PLATFORM_DEVELOPER_BIN_DIR = /Applications/Xcode.app/Contents/Developer/usr/bin PLATFORM_DEVELOPER_LIBRARY_DIR = /Applications/Xcode.app/Contents/Developer/Library PLATFORM_DEVELOPER_SDK_DIR = /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Develop er/SDKs PLATFORM_DEVELOPER_TOOLS_DIR = /Applications/Xcode.app/Contents/Developer/Tools PLATFORM_DEVELOPER_USR_DIR = /Applications/Xcode.app/Contents/Developer/usr PLATFORM_DIR = /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform . . . Why doesn?t find CMake Xcode with the modified path? Is there also a way to set generator specific things during configure time? At the moment it is only possible with the build command: ?cmake -build . -- PLATFORM_DEVELOPER_BIN_DIR=PointToSomething? which sets the build settings for Xcode Thanks in advance Best Regards Roman -------------- next part -------------- An HTML attachment was scrubbed... URL: From drescherjm at gmail.com Fri Oct 9 12:48:32 2015 From: drescherjm at gmail.com (John Drescher) Date: Fri, 9 Oct 2015 12:48:32 -0400 Subject: [CMake] CMake keeps on referencing an uninstalled Qt In-Reply-To: <5617C6C4.1010500@logilab.fr> References: <5617C0D3.4000409@logilab.fr> <5617C6C4.1010500@logilab.fr> Message-ID: On Fri, Oct 9, 2015 at 9:53 AM, Laura M?dioni wrote: > Hi, > > I am facing a problem with CMake 3.4 under Windows. > My CMake project is using Qt. Recently I uninstalled Qt and reinstalled it. > Since then, the previous Qt install keeps on appearing in the > CMakeCache.txt, leading to link edition errors. > > You may want to look at the CMake Package Registry https://cmake.org/Wiki/CMake/Tutorials/Package_Registry John From domen.vrankar at gmail.com Fri Oct 9 13:17:39 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Fri, 9 Oct 2015 19:17:39 +0200 Subject: [CMake] CPack Debian In-Reply-To: <5617C320.2000705@dirac.se> References: <5617B147.7030407@dirac.se> <5617C2FA.70802@dirac.se> <5617C320.2000705@dirac.se> Message-ID: 2015-10-09 15:37 GMT+02:00 Robert Bielik : > Den 2015-10-09 kl. 15:36, skrev Robert Bielik: >> >> I saw that Rafael introduced libarchive in commit 7044e8ee4, which seems >> to be set to both produce tars without sparse files, and having root:root as >> user. > > Sorry, that would be Raffi ;) Yes you're correct root:root is set as user:group - that's not configurable. I'm not certain regarding sparse files but if I remember correctly libarchive doesn't support creating packages with sparse file gnu tar extension so in that case deb packages are now created without sparse files. Regards, Domen From domen.vrankar at gmail.com Fri Oct 9 13:19:10 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Fri, 9 Oct 2015 19:19:10 +0200 Subject: [CMake] CPack Debian In-Reply-To: References: <5617B147.7030407@dirac.se> <5617C2FA.70802@dirac.se> <5617C320.2000705@dirac.se> Message-ID: 2015-10-09 19:17 GMT+02:00 Domen Vrankar : > 2015-10-09 15:37 GMT+02:00 Robert Bielik : >> Den 2015-10-09 kl. 15:36, skrev Robert Bielik: >>> >>> I saw that Rafael introduced libarchive in commit 7044e8ee4, which seems >>> to be set to both produce tars without sparse files, and having root:root as >>> user. >> >> Sorry, that would be Raffi ;) > > Yes you're correct root:root is set as user:group - that's not configurable. > I'm not certain regarding sparse files but if I remember correctly > libarchive doesn't support creating packages with sparse file gnu tar > extension so in that case deb packages are now created without sparse > files. Will be as of next release - 3.4 Regards, Domen From raffi.enficiaud at mines-paris.org Fri Oct 9 13:56:32 2015 From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud) Date: Fri, 9 Oct 2015 19:56:32 +0200 Subject: [CMake] CPack Debian In-Reply-To: <5617C320.2000705@dirac.se> References: <5617B147.7030407@dirac.se> <5617C2FA.70802@dirac.se> <5617C320.2000705@dirac.se> Message-ID: Le 09/10/15 15:37, Robert Bielik a ?crit : > Den 2015-10-09 kl. 15:36, skrev Robert Bielik: >> I saw that Rafael introduced libarchive in commit 7044e8ee4, which >> seems to be set to both produce tars without sparse files, and having >> root:root as user. > Sorry, that would be Raffi ;) > Yep :) Targeted for cmake 3.4. Maybe you can give a try to the RC? Best, Raffi From robert.bielik at dirac.se Fri Oct 9 15:14:07 2015 From: robert.bielik at dirac.se (=?utf-8?B?cm9iZXJ0LmJpZWxpaw==?=) Date: Fri, 9 Oct 2015 19:14:07 GMT Subject: [CMake] CPack Debian Message-ID: <000f4242.63b5521812be1fc6@dirac.se> Absolutely, as soon as I figure out how to get the overlays working on my gentoo machine :) Regards /R ------ Ursprungligt meddelande------ Fr?n: Raffi Enficiaud Datum: fre, 9 okt 2015 21:10 Till: cmake at cmake.org; ?mne:Re: [CMake] CPack Debian Le 09/10/15 15:37, Robert Bielik a ?crit : > Den 2015-10-09 kl. 15:36, skrev Robert Bielik: >> I saw that Rafael introduced libarchive in commit 7044e8ee4, which >> seems to be set to both produce tars without sparse files, and having >> root:root as user. > Sorry, that would be Raffi ;) > Yep :) Targeted for cmake 3.4. Maybe you can give a try to the RC? Best, Raffi -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From zbergquist99 at gmail.com Fri Oct 9 17:27:50 2015 From: zbergquist99 at gmail.com (Zac Bergquist) Date: Fri, 9 Oct 2015 17:27:50 -0400 Subject: [CMake] Determining appropriate setting for CMAKE_MINIMUM_REQUIRED Message-ID: Hello, Is there a particular tool or method that one should use to determine the appropriate setting for CMAKE_MINIMUM_REQUIRED? By appropriate, I mean the earliest version that encompasses all of the features used by the project. For example, I'm using the CMakePackageConfigHelpers module in a project, and I'm trying to determine which version of CMake this was introduced in, so that I can ensure my minimum required version is sufficient. I checked both the documentation for this feature and searched through the CMake release notes, but I can't seem to find the right version. The only thing I found was a mention of the module in the release notes for 3.0.2, but the wording suggests that this was just an update and not the initial introduction of the feature. I feel like I'm missing something. This seems like a common task in workflows using CMake. Does anyone have any suggestions? Thanks, Zac -------------- next part -------------- An HTML attachment was scrubbed... URL: From howard.rubin at hl.konicaminolta.us Fri Oct 9 17:09:03 2015 From: howard.rubin at hl.konicaminolta.us (Howard Rubin) Date: Fri, 9 Oct 2015 15:09:03 -0600 Subject: [CMake] Relative path to CMAKE_SOURCE_DIR Message-ID: <01bc01d102d6$ba248ef0$2e6dacd0$@hl.konicaminolta.us> Is it possible to get the relative path from PROJECT_BINARY_DIR (or CMAKE_BINARY_DIR) to CMAKE_SOURCE_DIR? I'm using CMAKE_SOURCE_DIR to add files to *.csproj file (copied with configure_file) using CMake on Windows. This results in lots of warnings like the below that I'd like to get rid of. If I change the absolute path that's inserted by CMake's substitution of CMAKE_SOURCE_DIR to a relative path with dots (e.g. ..\..\somewhere) the warning goes away. Warning 43 The file 'D:/directory1/directory2/directory3\directory4\Open-XML-SDK\DocumentFormat. OpenXml\src\Framework\AlternateContent.cs' could not be added to the project. The specified path contains invalid characters, is an absolute path, or is a path outside of the project directory. DocumentFormat.OpenXml References: https://cmake.org/cmake/help/v2.8.10/cmake.html#command:configure_file https://cmake.org/Wiki/CMake_Useful_Variables -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Fri Oct 9 18:15:41 2015 From: d3ck0r at gmail.com (J Decker) Date: Fri, 9 Oct 2015 15:15:41 -0700 Subject: [CMake] Relative path to CMAKE_SOURCE_DIR In-Reply-To: <01bc01d102d6$ba248ef0$2e6dacd0$@hl.konicaminolta.us> References: <01bc01d102d6$ba248ef0$2e6dacd0$@hl.konicaminolta.us> Message-ID: something like ... ? file(RELATIVE_PATH variable directory file) On Fri, Oct 9, 2015 at 2:09 PM, Howard Rubin wrote: > Is it possible to get the relative path from PROJECT_BINARY_DIR (or > CMAKE_BINARY_DIR) to CMAKE_SOURCE_DIR? > > > > I?m using CMAKE_SOURCE_DIR to add files to *.csproj file (copied with > configure_file) using CMake on Windows. This results in lots of warnings > like the below that I?d like to get rid of. If I change the absolute path > that?s inserted by CMake?s substitution of CMAKE_SOURCE_DIR to a relative > path with dots (e.g. ..\..\somewhere) the warning goes away. > > > > Warning 43 The file > 'D:/directory1/directory2/directory3\directory4\Open-XML-SDK\DocumentFormat.OpenXml\src\Framework\AlternateContent.cs' > could not be added to the project. The specified path contains invalid > characters, is an absolute path, or is a path outside of the project > directory. DocumentFormat.OpenXml > > > > References: > > https://cmake.org/cmake/help/v2.8.10/cmake.html#command:configure_file > > https://cmake.org/Wiki/CMake_Useful_Variables > > > > > -- > > 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 ddomenichelli at drdanz.it Fri Oct 9 19:53:35 2015 From: ddomenichelli at drdanz.it (Daniele E. Domenichelli) Date: Sat, 10 Oct 2015 01:53:35 +0200 Subject: [CMake] Determining appropriate setting for CMAKE_MINIMUM_REQUIRED In-Reply-To: References: Message-ID: <5618537F.2040804@drdanz.it> Hello Zac, On 09/10/2015 23:27, Zac Bergquist wrote: > Is there a particular tool or method that one should use to determine > the appropriate setting for CMAKE_MINIMUM_REQUIRED? By appropriate, I > mean the earliest version that encompasses all of the features used by > the project. This is what I used to do: 1) Check the compatibility matrix[1] (unfortunately it's useful only until CMake 2.8.12). According to this, CMakePackageConfigHelpers was introduced in CMake 2.8.8. 2) Check cmake documentation [2][3][4] for the versions that I'm interested in (just change the version number in the url). For cmake < 3.0 the main page is cmake.html, for 3.0 and later it is index.html 3) Check the release notes[4] for 3.0 or later, changelog (usually available on kitware blog) for previous versions 4) Check bug tracker[5], mailing lists archives, and git history (usually as last resort) by searching for commit that introduced the change that I'm interest in, and then running "git describe --contains " Then, even though I spent a lot of time searching, as soon as I commit the changes, there is someone that complains that on some ancient CMake version, the build is broken, because of some other feature or module that I used without realizing that it was not supported. Recently I switched to a trial and error approach using the ExternalProject module. I have this "superproject" that I called (with not much fantasy) "supercmake" and that downloads and builds all the versions of CMake that I need to test. Then it tries to build my project with all these versions. It takes some time but after the first run, all the CMake versions are already compiled (you could download and extract the binary versions, if you want to improve it), but it is time that you can dedicate to something else while the machine is building, instead of wasting time on it. After building it, you are almost sure that the project will build with all the cmake versions that you have to support, or you can use the results to set CMAKE_MINIMUM_REQUIRED accordingly. Attached is the CMakeLists.txt that I use, you just have to edit the last ExternalProject_Add call, and eventually add or remove tags from "CMAKE_TAGS". I hope this is useful! :) Cheers, Daniele [1]https://cmake.org/Wiki/CMake_Version_Compatibility_Matrix [2]https://cmake.org/cmake/help/v2.8.9/cmake.html [3]https://cmake.org/cmake/help/v3.0/index.html [4]https://cmake.org/cmake/help/git-master/release/index.html [5]http://public.kitware.com/Bug/changelog_page.php?project_id=2 -------------- next part -------------- #============================================================================= # Copyright 2014-2015 Daniele E. Domenichelli # # Distributed under the OSI-approved BSD License (the "License"); # see accompanying file Copyright.txt for details. # # This software is distributed WITHOUT ANY WARRANTY; without even the # implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # See the License for more information. #============================================================================= cmake_minimum_required(VERSION 3.0) project(supercmake NONE) include(ExternalProject) set(CMAKE_REPO "git://cmake.org/cmake.git") set(CMAKE_URL_BASE "http://www.cmake.org/files") if(WIN32) set(CMAKE_EXT "zip") else() set(CMAKE_EXT "tar.gz") endif() set(CMAKE_TAGS v2.8.9 v2.8.10.2 v2.8.11.2 v2.8.12.2 v3.0.2 v3.1.3 v3.2.3 v3.3.2 v3.4.0-rc1 master next) foreach(tag ${CMAKE_TAGS}) unset(url) unset(version) unset(prefix) if(${tag} MATCHES "^v([0-9].[0-9])") string(SUBSTRING ${tag} 1 -1 version) set(url ${CMAKE_URL_BASE}/v${CMAKE_MATCH_1}/cmake-${version}.${CMAKE_EXT}) else() set(version ${tag}) endif() string(REGEX REPLACE "[\\.-]" "_" VERSION ${version}) if(url) set(args URL ${url}) else() set(args GIT_REPOSITORY ${CMAKE_REPO} GIT_TAG ${tag}) endif() set(prefix ${CMAKE_BINARY_DIR}/install/cmake-${version}) ExternalProject_Add(CMake_${VERSION} CONFIGURE_COMMAND /configure --system-libs --prefix=${prefix} ${args}) # This is where you build your project "FOO" ExternalProject_Add(FOO_CMake_${VERSION} GIT_REPOSITORY file:///path/to/your/local/clone/foo GIT_TAG master CMAKE_COMMAND ${prefix}/bin/cmake CMAKE_ARGS "-DCMAKE_INSTALL_PREFIX:PATH=${prefix}" DEPENDS CMake_${VERSION}) endforeach() From robert.bielik at dirac.se Sat Oct 10 08:36:15 2015 From: robert.bielik at dirac.se (Robert Bielik) Date: Sat, 10 Oct 2015 14:36:15 +0200 Subject: [CMake] CPack Debian In-Reply-To: <000f4242.63b5521812be1fc6@dirac.se> References: <000f4242.63b5521812be1fc6@dirac.se> Message-ID: <5619063F.4020401@dirac.se> Hi Raffi, It works nicely with the new debian backend, thanks! Regards /R Den 2015-10-09 kl. 21:14, skrev robert.bielik: > > Absolutely, as soon as I figure out how to get the overlays working on > my gentoo machine :) > > Regards > > /R > > ------ Ursprungligt meddelande------ > > *Fr?n: *Raffi Enficiaud > > *Datum: *fre, 9 okt 2015 21:10 > > *Till: *cmake at cmake.org; > > *?mne:*Re: [CMake] CPack Debian > > Le 09/10/15 15:37, Robert Bielik a ?crit : > > Den 2015-10-09 kl. 15:36, skrev Robert Bielik: > >> I saw that Rafael introduced libarchive in commit 7044e8ee4, which > >> seems to be set to both produce tars without sparse files, and having > >> root:root as user. > > Sorry, that would be Raffi ;) > > > > Yep :) > > Targeted for cmake 3.4. Maybe you can give a try to the RC? > > Best, > Raffi > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gjasny at googlemail.com Sat Oct 10 08:43:09 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Sat, 10 Oct 2015 14:43:09 +0200 Subject: [CMake] [cmake-developers] Xcode build settings and BullseyeCoverage In-Reply-To: <1a3b01d102aa$541715f0$fc4541d0$@gmx.at> References: <1a3b01d102aa$541715f0$fc4541d0$@gmx.at> Message-ID: <561907DD.7010806@googlemail.com> Hello, On 09/10/15 17:51, Roman W?ger wrote: > I?m trying to configure and build a project with the ?Xcode? generator and > the bullseye coverage tool. > > Without the bullseye coverage tool it works fine but if I want to use it I > had to do the following workaround: > http://www.bullseye.com/help/tool-xcode.html IMHO this workaround is way to hackish for a paid tool. The proper thing for Bullseye would be to provide a touchless way of intercepting all compiler invocations like for example Fortify or Coverity provides. You would be able to call it like this: $ bullseye xcodebuild It would trace compiler invocations from xcodebuild and all childs. > And I got the following error: > > > > -- The C compiler identification is unknown > > -- The CXX compiler identification is unknown > > CMake Error at CMakeLists.txt:3 (project): > > No CMAKE_C_COMPILER could be found. > Is there also a way to set generator specific things during configure time? > > At the moment it is only possible with the build command: ?cmake -build . -- > PLATFORM_DEVELOPER_BIN_DIR=PointToSomething? which sets the build settings > for Xcode I have not tested it, but maybe you could add -DCMAKE_C_COMPILER=$(xcrun -find clang) -DCMAKE_CXX_COMPILER=$(xcrun -find clang++) to the cmake command line at configuration time. Thanks, Gregor From raffi.enficiaud at mines-paris.org Sat Oct 10 08:46:08 2015 From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud) Date: Sat, 10 Oct 2015 14:46:08 +0200 Subject: [CMake] CPack Debian In-Reply-To: <5619063F.4020401@dirac.se> References: <000f4242.63b5521812be1fc6@dirac.se> <5619063F.4020401@dirac.se> Message-ID: Le 10/10/15 14:36, Robert Bielik a ?crit : > Hi Raffi, > > It works nicely with the new debian backend, thanks! > > Regards > /R Great! I am on my side still experiencing some issues with Launchpad... Best, Raffi From yves.frederix+cmake at gmail.com Sat Oct 10 11:24:42 2015 From: yves.frederix+cmake at gmail.com (Yves Frederix) Date: Sat, 10 Oct 2015 17:24:42 +0200 Subject: [CMake] Temporarily redefining CMake functions Message-ID: Hi all, I have a use case in which I would like to temporarily overwrite standard CMake functions (e.g., add_library). After searching the mailing list, I found that when a function is redefined, the original function is still available but with an underscore prefix, e.g., function(add_library) message("custom add_library") _add_library(${ARGN}) endfunction() The problem with this solution is that this in fact redefines add_library permanently. My hope was that if I introduced some additional scope, I would get the desired result: function(testfun) function(add_library) message("custom add_library") _add_library(${ARGN}) endfunction() add_library(test SHARED IMPORTED) endfunction() testfun() add_library(test2 SHARED IMPORTED) As it turns out, this is not the case, and the second call to add_library actually still calls my custom version, which is unexpected and of course not what I want. Under the assumption that only for the standard CMake functions the underscore version would be created (I haven't found any official documentation on this behavior), I then tried the following: function(add_library) message("custom add_library") _add_library(${ARGN}) endfunction() add_library(test SHARED IMPORTED) function(add_library) _add_library(${ARGN}) endfunction() add_library(test2 SHARED IMPORTED) This actually creates an infinite recursion loop and CMake crashes with a segmentation fault. This means that the assumption was wrong, and apparently all existing functions, upon redefinition, are renamed to an underscore version (hence the infinite recursion). Using this information, I was able to create the desired behavior in the following way: # Ensure that _add_library points to the original version function(add_library) endfunction() # Ensure that __add_library points to the original version function(_add_library) endfunction(_add_library) # Define the custom version function(add_library) message("custom add_library") __add_library(${ARGN}) endfunction() add_library(test SHARED IMPORTED) # Restore the original implementation function(add_library) __add_library(${ARGN}) endfunction() add_library(test2 SHARED IMPORTED) This works, but looks a bit hackish, so I was wondering if there is maybe a better, more elegant way to achieve the desired behavior? Regards, Yves From roman.wueger at gmx.at Sun Oct 11 14:55:18 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Sun, 11 Oct 2015 20:55:18 +0200 Subject: [CMake] [cmake-developers] Xcode build settings and BullseyeCoverage In-Reply-To: <561907DD.7010806@googlemail.com> References: <1a3b01d102aa$541715f0$fc4541d0$@gmx.at> <561907DD.7010806@googlemail.com> Message-ID: <08D3B01B-37D2-4751-8F42-D203EF77CAF9@gmx.at> Thanks, If anyone is interested, the guys from bullseye updated their website and the coverage is working now. Best Regards Von meinem iPhone gesendet > Am 10.10.2015 um 14:43 schrieb Gregor Jasny : > > Hello, > >> On 09/10/15 17:51, Roman W?ger wrote: >> I?m trying to configure and build a project with the ?Xcode? generator and >> the bullseye coverage tool. >> >> Without the bullseye coverage tool it works fine but if I want to use it I >> had to do the following workaround: >> http://www.bullseye.com/help/tool-xcode.html > > IMHO this workaround is way to hackish for a paid tool. The proper thing > for Bullseye would be to provide a touchless way of intercepting all > compiler invocations like for example Fortify or Coverity provides. You > would be able to call it like this: > > $ bullseye xcodebuild > > It would trace compiler invocations from xcodebuild and all childs. > >> And I got the following error: >> >> >> >> -- The C compiler identification is unknown >> >> -- The CXX compiler identification is unknown >> >> CMake Error at CMakeLists.txt:3 (project): >> >> No CMAKE_C_COMPILER could be found. > >> Is there also a way to set generator specific things during configure time? >> >> At the moment it is only possible with the build command: ?cmake -build . -- >> PLATFORM_DEVELOPER_BIN_DIR=PointToSomething? which sets the build settings >> for Xcode > > I have not tested it, but maybe you could add > -DCMAKE_C_COMPILER=$(xcrun -find clang) -DCMAKE_CXX_COMPILER=$(xcrun > -find clang++) > > to the cmake command line at configuration time. > > Thanks, > Gregor From laura.medioni at logilab.fr Mon Oct 12 03:00:36 2015 From: laura.medioni at logilab.fr (=?UTF-8?B?TGF1cmEgTcOpZGlvbmk=?=) Date: Mon, 12 Oct 2015 09:00:36 +0200 Subject: [CMake] CMake keeps on referencing an uninstalled Qt In-Reply-To: References: <5617C0D3.4000409@logilab.fr> <5617C6C4.1010500@logilab.fr> Message-ID: <561B5A94.6040502@logilab.fr> On 10/09/2015 06:48 PM, John Drescher wrote: > On Fri, Oct 9, 2015 at 9:53 AM, Laura M?dioni wrote: >> Hi, >> >> I am facing a problem with CMake 3.4 under Windows. >> My CMake project is using Qt. Recently I uninstalled Qt and reinstalled it. >> Since then, the previous Qt install keeps on appearing in the >> CMakeCache.txt, leading to link edition errors. >> >> > You may want to look at the CMake Package Registry > > https://cmake.org/Wiki/CMake/Tutorials/Package_Registry > > John Thank you very much for your answer. But as I said, there is no track of "QtSDK" in the Windows registry. Laura From Ch.Ehrlicher at gmx.de Mon Oct 12 03:15:43 2015 From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher) Date: Mon, 12 Oct 2015 09:15:43 +0200 Subject: [CMake] CMake keeps on referencing an uninstalled Qt In-Reply-To: <561B5A94.6040502@logilab.fr> References: <5617C0D3.4000409@logilab.fr> <5617C6C4.1010500@logilab.fr> , <561B5A94.6040502@logilab.fr> Message-ID: An HTML attachment was scrubbed... URL: From laura.medioni at logilab.fr Mon Oct 12 03:27:27 2015 From: laura.medioni at logilab.fr (=?UTF-8?B?TGF1cmEgTcOpZGlvbmk=?=) Date: Mon, 12 Oct 2015 09:27:27 +0200 Subject: [CMake] CMake keeps on referencing an uninstalled Qt In-Reply-To: References: <5617C0D3.4000409@logilab.fr> <5617C6C4.1010500@logilab.fr> , <561B5A94.6040502@logilab.fr> Message-ID: <561B60DF.9040503@logilab.fr> Hi, Yes, I deleted the CMakeCache.txt after changing the Qt installation. Since I still had the same problem, I also tried removing all the cmake generated files. I have a code directory, and a directory where I generate the build. - I removed all the content of this build directory - I opened cmake-gui, I clicked on file > delete cache - I re-did "configure", then "generate" And it didn't work. Laura On 10/12/2015 09:15 AM, Christian Ehrlicher wrote: > Hi, > Did you really recreated (deleted) your CMakeCache.txt after changing > your Qt installation? Or at least removed all references to Qt5 in the > CMakeCache.txt (e.g. with cmake-gui)? > Christian > *Von:* "Laura M?dioni" > *Betreff:* Re: [CMake] CMake keeps on referencing an uninstalled Qt > On 10/09/2015 06:48 PM, John Drescher wrote: > > On Fri, Oct 9, 2015 at 9:53 AM, Laura M?dioni > wrote: > >> Hi, > >> > >> I am facing a problem with CMake 3.4 under Windows. > >> My CMake project is using Qt. Recently I uninstalled Qt and > reinstalled it. > >> Since then, the previous Qt install keeps on appearing in the > >> CMakeCache.txt, leading to link edition errors. > >> > >> > > You may want to look at the CMake Package Registry > > > > https://cmake.org/Wiki/CMake/Tutorials/Package_Registry > > > > John > Thank you very much for your answer. But as I said, there is no track of > "QtSDK" in the Windows registry. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michi.henning at canonical.com Mon Oct 12 03:30:48 2015 From: michi.henning at canonical.com (Michi Henning) Date: Mon, 12 Oct 2015 17:30:48 +1000 Subject: [CMake] CMAKE__COMPILER has disappeared? Message-ID: When using ccmake (cmake-curses-gui), I used to easily be able to switch between clang and gcc by hitting "t" and changing the CMAKE_CXX_COMPILER variable to "c++" or "clang++" as appropriate. Doing this would also automatically adjust the path to point at ccache (if ccache is installed). Now, with version 3.2.2, I no longer see this variable in the list of variables that is shown by ccmake. Any suggestions for how I can get this back? I don't really want to set environment variables, if I can help it. Thanks, Michi. From rjvbertin at gmail.com Mon Oct 12 04:39:37 2015 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Mon, 12 Oct 2015 10:39:37 +0200 Subject: [CMake] CMAKE_BUILD_TYPE and exact control of compiler options Message-ID: <2109999.XjrYudnkv7@patux.local> Hello, I'm using cmake in conjunction with a packaging/distribution system that aims to control the compiler and linker flags, a priori via the usual environment variables. (We're talking about MacPorts.) Using one of the CMAKE_BUILD_TYPE presets, the value of those env. variables appears at most to be added in front of the preset options, which means user options can be overridden. That may be intended behaviour, but not ideal for my use case. Working with Debian and Ubuntu systems, I deduced that using a non-pre-defined BUILD_TYPE make cmake use the values of CFLAGS, CXXFLAGS etc, through CMAKE_C_FLAGS, CMAKE_CXX_FLAGS etc (instead of CMAKE_C*_FLAGS_RELEASE, for instance). Experimenting with -DCMAKE_BUILD_TYPE=MacPorts in the toplevel control file (cmake PortGroup), that appeared indeed to work, but I appear to have been mistaken. Adding -DCMAKE_C*_FLAGS_MACPORTS definitions has no effect, nor has setting CMAKE_C*_FLAGS from the CMake command line. Which leads me to the following questions: - Is it indeed possible to get CMake to take all compiler and linker flags from the environment, and if so, how? - If not, what is the best/official way to get exact control over the compiler and linker options used? - Out of curiosity, what's special about the CMAKE_BUILD_TYPE=Debian build type? Thanks Ren? Bertin From rjvbertin at gmail.com Mon Oct 12 04:55:09 2015 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Mon, 12 Oct 2015 10:55:09 +0200 Subject: [CMake] CMAKE_BUILD_TYPE and exact control of compiler options References: <2109999.XjrYudnkv7@patux.local> Message-ID: <1917543.16iqzrf2YZ@patux.local> Ren? J. V. Bertin wrote: Similarly, is there a way to set preprocessor variables (cf. https://cmake.org/Bug/view.php?id=12928 which has been silent for a long time)? One could do -DINCLUDE_DIRECTORIES=${CPPFLAGS}, but that may lead to unexpected results if CPPFLAGS contains something other than -I options. R. From apaku at gmx.de Mon Oct 12 08:18:54 2015 From: apaku at gmx.de (Andreas Pakulat) Date: Mon, 12 Oct 2015 14:18:54 +0200 Subject: [CMake] CMAKE_BUILD_TYPE and exact control of compiler options In-Reply-To: <2109999.XjrYudnkv7@patux.local> References: <2109999.XjrYudnkv7@patux.local> Message-ID: Hi, On Mon, Oct 12, 2015 at 10:39 AM, Ren? J. V. wrote: > Hello, > > I'm using cmake in conjunction with a packaging/distribution system that > aims to > control the compiler and linker flags, a priori via the usual environment > variables. (We're talking about MacPorts.) > > Using one of the CMAKE_BUILD_TYPE presets, the value of those env. > variables > appears at most to be added in front of the preset options, which means > user > options can be overridden. That may be intended behaviour, but not ideal > for my > use case. > > Working with Debian and Ubuntu systems, I deduced that using a > non-pre-defined > BUILD_TYPE make cmake use the values of CFLAGS, CXXFLAGS etc, through > CMAKE_C_FLAGS, CMAKE_CXX_FLAGS etc (instead of CMAKE_C*_FLAGS_RELEASE, for > instance). > > Experimenting with -DCMAKE_BUILD_TYPE=MacPorts in the toplevel control file > (cmake PortGroup), that appeared indeed to work, but I appear to have been > mistaken. Adding -DCMAKE_C*_FLAGS_MACPORTS definitions has no effect, nor > has > setting CMAKE_C*_FLAGS from the CMake command line. > > Which leads me to the following questions: > - Is it indeed possible to get CMake to take all compiler and linker flags > from > the environment, and if so, how? - If not, what is the best/official way to get exact control over the > compiler > and linker options used? No this is not possible in general. A CMakeLists.txt file can always just set their own compiler/linker flags. However if I understand you correctly (in what kind of flags you want to change), then this could be doable with a toolchain file. These are usually used to teach CMake specialities about compilers/linkers that it does not support itself and behave sufficiently different from one it does know. That is for example gcc builds for doing cross-compilation to some specialized hardware may not work with certain flags CMake uses by default for gcc builds. The toolchain files are just cmake scripts, you can see some examples in the Modules/Platform directory of your cmake install. They set certain special variables that CMake will read out again when creating compiler/linker commandlines. The variables are explained in the documentation of CMake IIRC. > - Out of curiosity, what's special about the CMAKE_BUILD_TYPE=Debian build > type? > There's no such build type in CMake, see the Compilers and Tools section here: https://cmake.org/Wiki/CMake_Useful_Variables#Various_Options that details the built-in types in CMake. Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Mon Oct 12 08:48:42 2015 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Mon, 12 Oct 2015 14:48:42 +0200 Subject: [CMake] CMAKE_BUILD_TYPE and exact control of compiler options References: <2109999.XjrYudnkv7@patux.local> Message-ID: <2570105.PSq12XV5DT@patux.local> Andreas Pakulat wrote: > No this is not possible in general. A CMakeLists.txt file can always just > set their own compiler/linker flags. Which would require patching each and every one of them, which isn't exactly desirable. >> - Out of curiosity, what's special about the CMAKE_BUILD_TYPE=Debian build >> type? >> > > There's no such build type in CMake, see the Compilers and Tools section > here: https://cmake.org/Wiki/CMake_Useful_Variables#Various_Options that > details the built-in types in CMake. I know it doesn't exist as a preset in CMake. But take a look at the CMake files shipped with KDE4's kdelibs: those actually introduce CMAKE_C*_FLAGS_DEBIAN variables (in addition to using specific install locations, for instance). It's quite important that there is such a feature: configure and its alternatives are supposed to take CFLAGS, CXXFLAGS and family into consideration (or at least should have a mode in which they do, IMVHO). I suppose that what happens is that requesting an unknown CMAKE_BUILD_TYPE is equivalent to not requesting one at all, and also prevents downstream CMake files to pick a default preset if CMAKE_BUILD_TYPE hasn't been defined by the caller. I've had a better look at the control file I mentioned, and found the reason why $CFLAGS and $CXXFLAGS weren't being used. It turns out that if you set CMAKE_CXX_FLAGS on the commandline, it is no longer set to include $CXXFLAGS from the environment. Comments in the control file suggest that that wasn't always the case. R. From zbergquist99 at gmail.com Mon Oct 12 08:53:31 2015 From: zbergquist99 at gmail.com (Zac Bergquist) Date: Mon, 12 Oct 2015 08:53:31 -0400 Subject: [CMake] Creating relocatable packages Message-ID: Hello, I'm trying to fix a project so that its output is relocatable. The project is a library that itself depends on libpcap. My goal is to be able to import the library into my CMake application and have CMake automatically link libpcap with it. I'm using a toolchain file that invokes an ARM cross compiler, sets CMAKE_INSTALL_PREFIX and appends it to CMAKE_FIND_ROOT_PATH. This all seems to work well. What I'm seeing is that the exported files that get installed to CMAKE_INSTALL_PREFIX contain absolute paths to libpcap on my machine, which make them useless to other team members. The first thing I changed was to use CONFIGURE_PACKAGE_CONFIG_FILE instead of CONFIGURE_FILE. This got rid of absolute paths in the generated CMake config file. However, I still have absolute paths in the CMake target import file that gets generated. The IMPORTED_LINK_INTERFACE_LIBRARIES target property has an absolute path instead of one relative to CMAKE_INSTALL_PREFIX. I've read the "Creating Relocatable Packages" [1] section of the CMake packages documentation. I'm pretty sure this is what I'm running into, but I don't quite understand how to solve it. The documentation says that I should be using imported targets, but I'm not sure how to do so. The library is just using its own FindPCAP.cmake file to locate libpcap. Does anyone know of an example of a CMake package that imports other libraries? I could also try to create a minimal example project with this setup if it would be helpful. Thanks, Zac [1]: https://cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html#creating-relocatable-packages -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.oehlinger at avibit.com Mon Oct 12 09:14:49 2015 From: r.oehlinger at avibit.com (=?ISO-8859-1?Q?Richard_=D6hlinger?=) Date: Mon, 12 Oct 2015 15:14:49 +0200 Subject: [CMake] qt[45]_add_resources: how to use properly with a build time generated qrc file Message-ID: <561BB249.6090509@avibit.com> Hi! I've already posted the issue to the Qt bug tracker but was referred to you: https://bugreports.qt.io/browse/QTBUG-36959 I use the Qt5CoreMacros.cmake shiped with Qt5, but as far as I know QT5_ADD_RESOURCES is merely the same as your QT4_ADD_RESOURCE macro. I've already got an custom_target which will generate/update a qrc - the file will only be touched if something has changed. But I could not think of a way to make the ADD_RESOURCE macro depend on my custom target. So it will be execued each time. Is there a way without expanding the ADD_RESOURCE target and ADD an DEPENDS parameter. Best regards, Richard From TDlugosz at advaoptical.com Mon Oct 12 11:05:14 2015 From: TDlugosz at advaoptical.com (=?iso-8859-2?Q?Tomasz_D=B3ugosz?=) Date: Mon, 12 Oct 2015 15:05:14 +0000 Subject: [CMake] Cpack components' archive names Message-ID: <43fa6bae77564029bbc96aa77260242e@MUC-S-EX13A.advaoptical.com> Hi All, I'm struggling to set custom names for cpack's components' archive names. I call cpack_add_component(): foreach(COMPONENT_NAME ${CPACK_COMPONENTS_ALL}) if (CMAKE_BUILD_TYPE STREQUAL "Debug") cpack_add_component(${COMPONENT_NAME} ARCHIVE_FILE ${PROJECT_NAME}-${COMPONENT_NAME}-${TOOLCHAIN_PREFIX}-debug-${CPACK_PACKAGE_VERSION}) else() cpack_add_component(${COMPONENT_NAME} ARCHIVE_FILE ${PROJECT_NAME}-${COMPONENT_NAME}-${TOOLCHAIN_PREFIX}-${CPACK_PACKAGE_VERSION}) endif() message(" ----------------------- ${PROJECT_NAME}-${COMPONENT_NAME}-${TOOLCHAIN_PREFIX}-${CPACK_PACKAGE_VERSION}") endforeach() This is the output of cmake: jenkins-slave at moo:~/workspace/platform/build$ docker run --rm -i -v /home/jenkins-slave/workspace/platform:/src -w /src/build -u 1007:1007 artifacts.aos-cloud.com:444/ede-prod-vm64 cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=/etc/ede/cmake/Modules/vm64.toolchain.cmake -DBUILD_NG=y -DCMAKE_INSTALL_PREFIX=Install .. /src/build/Install -- Boost version: 1.55.0 -- Found the following Boost libraries: -- filesystem -- program_options -- serialization -- system INCLUDE: /src/include ----------------------- platform-api-x86_64-vm-linux-gnu-0.0.1.0 ----------------------- platform-config-x86_64-vm-linux-gnu-0.0.1.0 ----------------------- platform-doc-x86_64-vm-linux-gnu-0.0.1.0 ----------------------- platform-example-x86_64-vm-linux-gnu-0.0.1.0 ----------------------- platform-runtime-x86_64-vm-linux-gnu-0.0.1.0 -- Configuring done -- Generating done -- Build files have been written to: /src/build The variables are being set: jenkins-slave at moo:~/workspace/platform/build$ tail CPackConfig.cmake set(CPACK_COMPONENT_CONFIG_ARCHIVE_FILE "platform-config-x86_64-vm-linux-gnu-0.0.1.0") # Configuration for component "doc" set(CPACK_COMPONENT_DOC_ARCHIVE_FILE "platform-doc-x86_64-vm-linux-gnu-0.0.1.0") # Configuration for component "example" set(CPACK_COMPONENT_EXAMPLE_ARCHIVE_FILE "platform-example-x86_64-vm-linux-gnu-0.0.1.0") # Configuration for component "runtime" set(CPACK_COMPONENT_RUNTIME_ARCHIVE_FILE "platform-runtime-x86_64-vm-linux-gnu-0.0.1.0") But in the end, I still get the wrong file names: jenkins-slave at moo:~/workspace/platform/build$ docker run --rm -i -v /home/jenkins-slave/workspace/platform:/src -w /src/build -u 1007:1007 artifacts.aos-cloud.com:444/ede-prod-vm64 cpack CPack: Create package using TBZ2 CPack: Install projects CPack: - Run preinstall target for: platform CPack: - Install project: platform CPack: - Install component: api CPack: - Install component: config CPack: - Install component: doc CPack: - Install component: example CPack: - Install component: runtime CPack: Create package CPack: - package: /src/build/platform-0.0.1.0-Linux-api.tar.bz2 generated. CPack: - package: /src/build/platform-0.0.1.0-Linux-config.tar.bz2 generated. CPack: - package: /src/build/platform-0.0.1.0-Linux-doc.tar.bz2 generated. CPack: - package: /src/build/platform-0.0.1.0-Linux-example.tar.bz2 generated. CPack: - package: /src/build/platform-0.0.1.0-Linux-runtime.tar.bz2 generated. Am I missing something? The cmake version is 3.2.2 Regards, Tomasz From jamesbigler at gmail.com Mon Oct 12 13:32:17 2015 From: jamesbigler at gmail.com (James Bigler) Date: Mon, 12 Oct 2015 11:32:17 -0600 Subject: [CMake] FindCUDA discard any previous value of CUDA_USE_STATIC_CUDA_RUNTIME In-Reply-To: <5614098D.6010900@gmail.com> References: <5614098D.6010900@gmail.com> Message-ID: Whether you can use the static runtime is based on the toolkit found, so if you change the toolkit (checked with the CUDA_TOOLKIT_ROOT_DIR_INTERNAL variable) we need to reset all dependent values. I don't see a clean way to get this to work in the way you want. The script can't tell the difference between you setting the value, and the value being there from a previous toolkit. I don't see the problem of this code: set(CUDA_TOOLKIT_ROOT_DIR "d:/work/CUDAToolkit") find_package(CUDA) unset(CUDA_USE_STATIC_CUDA_RUNTIME CACHE) option(CUDA_USE_STATIC_CUDA_RUNTIME OFF) find_package(CUDA) Or you could set the internal version of the CUDA_TOOLKIT_ROOT_DIR_INTERNAL at the same time you set the CUDA_TOOLKIT_ROOT_DIR: option(CUDA_USE_STATIC_CUDA_RUNTIME OFF) set(CUDA_TOOLKIT_ROOT_DIR "d:/work/CUDAToolkit") set(CUDA_TOOLKIT_ROOT_DIR_INTERNAL "${CUDA_TOOLKIT_ROOT_DIR}") message(STATUS CUDA_USE_STATIC_CUDA_RUNTIME=${CUDA_USE_STATIC_CUDA_RUNTIME}) find_package(CUDA) James On Tue, Oct 6, 2015 at 11:49 AM, Thibaut Neiger wrote: > Hello. > I am using cmake 3.3.2. > The following script sets the CUDA_USE_STATIC_CUDA_RUNTIME option, then > finds the CUDA package. > > cmake_minimum_required(VERSION 3.3) > option(CUDA_USE_STATIC_CUDA_RUNTIME OFF) > set(CUDA_TOOLKIT_ROOT_DIR "d:/work/CUDAToolkit") > message(STATUS > CUDA_USE_STATIC_CUDA_RUNTIME=${CUDA_USE_STATIC_CUDA_RUNTIME}) > find_package(CUDA) > message(STATUS > CUDA_USE_STATIC_CUDA_RUNTIME=${CUDA_USE_STATIC_CUDA_RUNTIME}) > > In the find_package, the variable CUDA_TOOLKIT_ROOT_DIR is compared to the > variable CUDA_TOOLKIT_ROOT_DIR_INTERNAL (line 556). Since this variable is > not defined, the cuda_unset_include_and_libraries function is called. This > function wipes the CUDA_USE_STATIC_CUDA_RUNTIME option from the cache. > > In order to correctly set this variable, I need to restart change it back > to OFF, then the FindCUDA script doesn't call > cuda_unset_include_and_libraries function. > Thibaut. > -- > > 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 cary at txcorp.com Mon Oct 12 19:41:51 2015 From: cary at txcorp.com (JR Cary) Date: Mon, 12 Oct 2015 17:41:51 -0600 Subject: [CMake] cmake_check_build_system is causing a rebuild at "make install" Message-ID: <561C453F.1070602@txcorp.com> In our use of cmake on a particular project, we noticed that after building the project, upon invoking "make install", the build starts all over again. Hence we are building the project twice. It seems that this is occurring because nearly everything depends on the target, cmake_check_build_system, which sometimes causes a reconfiguration, i.e. reinvocation of cmake. In particular, the generated Makefile's have: install: preinstall ... preinstall: all ... all: cmake_check_build_system and then the last target invokes /cmake -H -B --check-build-system CMakeFiles/Makefile.cmake 0 Sometimes this causes a reconfiguration of our project and sometimes not. When it does, the whole project rebuilds because nearly everything depends on some configure_file generated config.h files. How can we tell why this reconfiguring? BTW, I could not find any of the options, -B, -H, or --check-build-system at the documentation, https://cmake.org/cmake/help/v3.3/manual/cmake.1.html. Thanks for any help.....John Cary From mwallace at ccmtrading.com Mon Oct 12 23:22:46 2015 From: mwallace at ccmtrading.com (Matthew S Wallace) Date: Mon, 12 Oct 2015 22:22:46 -0500 Subject: [CMake] Specify compiler flags as list? Message-ID: Consider the following CMakeLists.txt (hello.cpp is some standard hello world program) cmake_minimum_required (VERSION 2.6) project(HelloWorld) add_executable(hello hello.cpp) set(WARNING_FLAGS -Wno-char-subscripts -Wno-unused-local-typedefs) #set(WARNING_FLAGS "-Wno-char-subscripts -Wno-unused-local-typedefs") set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} ${WARNING_FLAGS}?) When I try to run ?cmake . -DCMAKE_BUILD_TYPE=RELEASE && make? - make fails because there are semi-colons in the command line. According to the FAQ (https://cmake.org/Wiki/CMake_FAQ#Why_do_I_have_unwanted_semicolons_.3B_in_my_compiler_flags.3F ) putting the list variable in quotes should cause it to be expanded with spaces, but this doesn?t seem to occur. If I replace the set(WARNING_FLAGS ..) with the commented out line, everything works fine, but I?d rather not do this because it seems cleaner to use lists for compiler options (can put them on multiple lines, append to them, etc). What?s the right way to do this? -Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From dank at kegel.com Tue Oct 13 00:04:37 2015 From: dank at kegel.com (Dan Kegel) Date: Mon, 12 Oct 2015 21:04:37 -0700 Subject: [CMake] Specify compiler flags as list? In-Reply-To: References: Message-ID: On Mon, Oct 12, 2015 at 8:22 PM, Matthew S Wallace wrote: > Consider the following CMakeLists.txt (hello.cpp is some standard hello world program) > > cmake_minimum_required (VERSION 2.6) > project(HelloWorld) > add_executable(hello hello.cpp) > set(WARNING_FLAGS -Wno-char-subscripts -Wno-unused-local-typedefs) > #set(WARNING_FLAGS "-Wno-char-subscripts -Wno-unused-local-typedefs") > set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} ${WARNING_FLAGS}?) > > When I try to run ?cmake . -DCMAKE_BUILD_TYPE=RELEASE && make? - make fails > because there > are semi-colons in the command line. According to the FAQ > (https://cmake.org/Wiki/CMake_FAQ#Why_do_I_have_unwanted_semicolons_.3B_in_my_compiler_flags.3F) > putting the list variable in quotes should cause it to be expanded with > spaces, but this doesn?t seem to occur. > > If I replace the set(WARNING_FLAGS ..) with the commented out line, > everything works fine, but I?d rather not do this because it seems cleaner > to use lists for compiler options (can put them on multiple lines, append to > them, etc). What?s the right way to do this? Add the dang quotes, or if you prefer, translate the semicolons to spaces later, e.g. STRING(REPLACE ";" " " WARNING_FLAGS "${WARNING_FLAGS}") After a while, you start to realize that you really, really need to pay attention to how cmake represents things. Fun fact: when using pkgconfig with cmake, you get to play games like this all day long, e.g. # Grab flags from foo.pc PKG_CHECK_MODULES(foo REQUIRED foo) # Repair damage caused by spaces in library names (thanks, Mac OS X naming conventions) STRING(REPLACE "-framework;Chromium;Embedded;Framework" "-framework 'Chromium Embedded Framework'" foo_LDFLAGS "${foo_LDFLAGS}") # Convert list to string because otherwise cmake thinks link options are libraries, or something STRING(REPLACE ";" " " foo_LDFLAGS "${foo_LDFLAGS}") - Dan From dan at su-root.co.uk Tue Oct 13 06:10:01 2015 From: dan at su-root.co.uk (Dan Liew) Date: Tue, 13 Oct 2015 11:10:01 +0100 Subject: [CMake] CMAKE_BUILD_TYPE and exact control of compiler options In-Reply-To: <2109999.XjrYudnkv7@patux.local> References: <2109999.XjrYudnkv7@patux.local> Message-ID: Hi, > - If not, what is the best/official way to get exact control over the compiler > and linker options used? I had to do something similar recently where I didn't want ``-DNDEBUG`` to be in any of the configurations. I used ``CMAKE_USER_MAKE_RULES_OVERRIDE `` to set the path to file containing overrides, this must be set before calling ``project()`` ``` set(CMAKE_USER_MAKE_RULES_OVERRIDE ${CMAKE_CURRENT_SOURCE_DIR}/cmake/c_flags_override.cmake) project(ABC C) ``` The contents of ``c_flags_override.cmake`` looks like this ``` if (("${CMAKE_C_COMPILER_ID}" MATCHES "Clang") OR ("${CMAKE_C_COMPILER_ID}" MATCHES "GNU")) # Taken from Modules/Compiler/GNU.cmake but -DNDEBUG is removed set(CMAKE_C_FLAGS_INIT "") set(CMAKE_C_FLAGS_DEBUG_INIT "-g") set(CMAKE_C_FLAGS_MINSIZEREL_INIT "-Os") set(CMAKE_C_FLAGS_RELEASE_INIT "-O3") set(CMAKE_C_FLAGS_RELWITHDEBINFO_INIT "-O2 -g") else() message(FATAL_ERROR "Overrides not set for compiler ${CMAKE_C_COMPILER_ID}") endif() ``` I'm not sure if this is really the correct route to go down though for your use case. Dan. From rjvbertin at gmail.com Tue Oct 13 06:52:01 2015 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Tue, 13 Oct 2015 12:52:01 +0200 Subject: [CMake] CMAKE_BUILD_TYPE and exact control of compiler options References: <2109999.XjrYudnkv7@patux.local> Message-ID: <1444760551.8Lrxd2GGWn@portia.local> Dan Liew wrote: > Hi, > > >> - If not, what is the best/official way to get exact control over the >> compiler and linker options used? > > I had to do something similar recently where I didn't want > ``-DNDEBUG`` to be in any of the configurations. > > I used ``CMAKE_USER_MAKE_RULES_OVERRIDE `` to set the path to file > containing overrides, this must be set before calling ``project()`` > I'm not sure if this is really the correct route to go down though for > your use case. That wouldn't be impossible. A more generic way to achieve what you did, one that doesn't require patching "client" CMake files (which I find unacceptable): Store the customised settings in a file (I'd call it cmake.initcache) and call cmake as %> cmake -C./cmake.initcache "$@" This is an approach I follow with a more basic building workflow of my own, one where I keep localised/customised settings (CC/CXX, CFLAGS/CXXFLAGS, LDFLAGS etc) in a ./wconfigure.env file, which is parsed by wrappers to configure and cmake. It's not a usual approach for MacPorts, though. R. From thibaut.neiger at gmail.com Tue Oct 13 10:51:28 2015 From: thibaut.neiger at gmail.com (Thibaut Neiger) Date: Tue, 13 Oct 2015 14:51:28 +0000 Subject: [CMake] FindCUDA discard any previous value of CUDA_USE_STATIC_CUDA_RUNTIME In-Reply-To: References: <5614098D.6010900@gmail.com> Message-ID: Maybe we could make the FindCUDA script check if the caller defined that variable prior to any inclusion. If the user did, then FindCUDA should respect the caller choice. Something like that would make the trick: if(NOT DEFINED CUDA_USE_STATIC_CUDA_RUNTIME_FORCED) if(DEFINED CUDA_USE_STATIC_CUDA_RUNTIME) set(CUDA_USE_STATIC_CUDA_RUNTIME_FORCED TRUE CACHE INTERNAL "If user forced static cuda runtime variable.") else() set(CUDA_USE_STATIC_CUDA_RUNTIME_FORCED FALSE CACHE INTERNAL "If user forced static cuda runtime variable.") endif() endif() ... macro(cuda_unset_include_and_libraries) ... if(NOT CUDA_USE_STATIC_CUDA_RUNTIME_FORCED ) unset(CUDA_USE_STATIC_CUDA_RUNTIME CACHE) endif() endmacro() Le lun. 12 oct. 2015 ? 14:32, James Bigler a ?crit : > Whether you can use the static runtime is based on the toolkit found, so > if you change the toolkit (checked with the CUDA_TOOLKIT_ROOT_DIR_INTERNAL > variable) we need to reset all dependent values. > > I don't see a clean way to get this to work in the way you want. The > script can't tell the difference between you setting the value, and the > value being there from a previous toolkit. > > I don't see the problem of this code: > > > set(CUDA_TOOLKIT_ROOT_DIR "d:/work/CUDAToolkit") > find_package(CUDA) > unset(CUDA_USE_STATIC_CUDA_RUNTIME CACHE) > option(CUDA_USE_STATIC_CUDA_RUNTIME OFF) > find_package(CUDA) > > Or you could set the internal version of the > CUDA_TOOLKIT_ROOT_DIR_INTERNAL at the same time you set the > CUDA_TOOLKIT_ROOT_DIR: > > option(CUDA_USE_STATIC_CUDA_RUNTIME OFF) > set(CUDA_TOOLKIT_ROOT_DIR "d:/work/CUDAToolkit") > set(CUDA_TOOLKIT_ROOT_DIR_INTERNAL "${CUDA_TOOLKIT_ROOT_DIR}") > > message(STATUS CUDA_USE_STATIC_CUDA_RUNTIME=$ > {CUDA_USE_STATIC_CUDA_RUNTIME}) > find_package(CUDA) > > James > > On Tue, Oct 6, 2015 at 11:49 AM, Thibaut Neiger > wrote: > >> Hello. >> I am using cmake 3.3.2. >> The following script sets the CUDA_USE_STATIC_CUDA_RUNTIME option, then >> finds the CUDA package. >> >> cmake_minimum_required(VERSION 3.3) >> option(CUDA_USE_STATIC_CUDA_RUNTIME OFF) >> set(CUDA_TOOLKIT_ROOT_DIR "d:/work/CUDAToolkit") >> message(STATUS >> CUDA_USE_STATIC_CUDA_RUNTIME=${CUDA_USE_STATIC_CUDA_RUNTIME}) >> find_package(CUDA) >> message(STATUS >> CUDA_USE_STATIC_CUDA_RUNTIME=${CUDA_USE_STATIC_CUDA_RUNTIME}) >> >> In the find_package, the variable CUDA_TOOLKIT_ROOT_DIR is compared to >> the variable CUDA_TOOLKIT_ROOT_DIR_INTERNAL (line 556). Since this variable >> is not defined, the cuda_unset_include_and_libraries function is called. >> This function wipes the CUDA_USE_STATIC_CUDA_RUNTIME option from the cache. >> >> In order to correctly set this variable, I need to restart change it back >> to OFF, then the FindCUDA script doesn't call >> cuda_unset_include_and_libraries function. >> Thibaut. >> > -- >> >> 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 jamesbigler at gmail.com Tue Oct 13 11:10:08 2015 From: jamesbigler at gmail.com (James Bigler) Date: Tue, 13 Oct 2015 15:10:08 +0000 Subject: [CMake] FindCUDA discard any previous value of CUDA_USE_STATIC_CUDA_RUNTIME In-Reply-To: References: <5614098D.6010900@gmail.com> Message-ID: Yeah, I thought about this method yesterday, but I'm not really excited about this approach. It adds yet another variable for the configuration that doesn't really match the others. Granted the behavior of the other FindCUDA options allow setting it before the first FindCUDA invocation, so there is already the loss of symmetry. If you were to do this from the GUI, you would configure once, change the defaults to your liking and configure a second time. You would only need this FORCED version of the variable to bypass the default behavior and only on the first configure. I'll need to consider this some more. I'm not trying to dissuade you from wanting the shared version of cudart, but why isn't the static library desirable in your case? You can reply just to me if you want. On Tue, Oct 13, 2015 at 8:51 AM Thibaut Neiger wrote: > Maybe we could make the FindCUDA script check if the caller defined that > variable prior to any inclusion. If the user did, then FindCUDA should > respect the caller choice. > Something like that would make the trick: > > if(NOT DEFINED CUDA_USE_STATIC_CUDA_RUNTIME_FORCED) > if(DEFINED CUDA_USE_STATIC_CUDA_RUNTIME) > set(CUDA_USE_STATIC_CUDA_RUNTIME_FORCED TRUE CACHE INTERNAL "If user > forced static cuda runtime variable.") > else() > set(CUDA_USE_STATIC_CUDA_RUNTIME_FORCED FALSE CACHE INTERNAL "If user > forced static cuda runtime variable.") > endif() > endif() > ... > macro(cuda_unset_include_and_libraries) > ... > if(NOT CUDA_USE_STATIC_CUDA_RUNTIME_FORCED ) > unset(CUDA_USE_STATIC_CUDA_RUNTIME CACHE) > endif() > endmacro() > > > Le lun. 12 oct. 2015 ? 14:32, James Bigler a > ?crit : > >> Whether you can use the static runtime is based on the toolkit found, so >> if you change the toolkit (checked with the CUDA_TOOLKIT_ROOT_DIR_INTERNAL >> variable) we need to reset all dependent values. >> >> I don't see a clean way to get this to work in the way you want. The >> script can't tell the difference between you setting the value, and the >> value being there from a previous toolkit. >> >> I don't see the problem of this code: >> >> >> set(CUDA_TOOLKIT_ROOT_DIR "d:/work/CUDAToolkit") >> find_package(CUDA) >> unset(CUDA_USE_STATIC_CUDA_RUNTIME CACHE) >> option(CUDA_USE_STATIC_CUDA_RUNTIME OFF) >> find_package(CUDA) >> >> Or you could set the internal version of the >> CUDA_TOOLKIT_ROOT_DIR_INTERNAL at the same time you set the >> CUDA_TOOLKIT_ROOT_DIR: >> >> option(CUDA_USE_STATIC_CUDA_RUNTIME OFF) >> set(CUDA_TOOLKIT_ROOT_DIR "d:/work/CUDAToolkit") >> set(CUDA_TOOLKIT_ROOT_DIR_INTERNAL "${CUDA_TOOLKIT_ROOT_DIR}") >> >> message(STATUS CUDA_USE_STATIC_CUDA_RUNTIME=$ >> {CUDA_USE_STATIC_CUDA_RUNTIME}) >> find_package(CUDA) >> >> James >> >> On Tue, Oct 6, 2015 at 11:49 AM, Thibaut Neiger > > wrote: >> >>> Hello. >>> I am using cmake 3.3.2. >>> The following script sets the CUDA_USE_STATIC_CUDA_RUNTIME option, then >>> finds the CUDA package. >>> >>> cmake_minimum_required(VERSION 3.3) >>> option(CUDA_USE_STATIC_CUDA_RUNTIME OFF) >>> set(CUDA_TOOLKIT_ROOT_DIR "d:/work/CUDAToolkit") >>> message(STATUS >>> CUDA_USE_STATIC_CUDA_RUNTIME=${CUDA_USE_STATIC_CUDA_RUNTIME}) >>> find_package(CUDA) >>> message(STATUS >>> CUDA_USE_STATIC_CUDA_RUNTIME=${CUDA_USE_STATIC_CUDA_RUNTIME}) >>> >>> In the find_package, the variable CUDA_TOOLKIT_ROOT_DIR is compared to >>> the variable CUDA_TOOLKIT_ROOT_DIR_INTERNAL (line 556). Since this variable >>> is not defined, the cuda_unset_include_and_libraries function is called. >>> This function wipes the CUDA_USE_STATIC_CUDA_RUNTIME option from the cache. >>> >>> In order to correctly set this variable, I need to restart change it >>> back to OFF, then the FindCUDA script doesn't call >>> cuda_unset_include_and_libraries function. >>> Thibaut. >>> >> -- >>> >>> 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 mwallace at ccmtrading.com Tue Oct 13 11:22:36 2015 From: mwallace at ccmtrading.com (Matthew S Wallace) Date: Tue, 13 Oct 2015 10:22:36 -0500 Subject: [CMake] C++11 flag not being added Message-ID: I have the following two lines in my CMakeLists.txt set_property(GLOBAL PROPERTY CXX_STANDARD 11) set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) However when compiling some of my source files, the -std=c++11 flag is not added. Just for good measure I added: target_compile_features(my_target PRIVATE cxx_strong_enums) to the target that was having the problem. Not sure if it matters, but in this case the compile error I?m getting is complaining because I?m referencing a fully scoped enum. If I explicitly include -std=c++11 in my compile flags, everything works. I?m thinking I?m probably just misunderstanding how CXX_STANDARD works, but any help would be appreciated. -Matt From benapetr at gmail.com Tue Oct 13 11:42:19 2015 From: benapetr at gmail.com (Petr Bena) Date: Tue, 13 Oct 2015 17:42:19 +0200 Subject: [CMake] C++11 flag not being added In-Reply-To: References: Message-ID: I would also like to know this, right now I do this and it works, but it produced warnings on MSVC, so I did this nasty patch: if(WIN32) if(MINGW) SET(CMAKE_CXX_FLAGS "-mwindows -std=c++11") endif() else() SET(CMAKE_CXX_FLAGS "-std=c++11") endif() however doing just the SET statement itself should work On Tue, Oct 13, 2015 at 5:22 PM, Matthew S Wallace wrote: > I have the following two lines in my CMakeLists.txt > > set_property(GLOBAL PROPERTY CXX_STANDARD 11) > set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) > > However when compiling some of my source files, the -std=c++11 flag is not added. > > Just for good measure I added: > target_compile_features(my_target PRIVATE cxx_strong_enums) to the target that was having the problem. > > Not sure if it matters, but in this case the compile error I?m getting is complaining because I?m referencing a fully scoped enum. If I explicitly include -std=c++11 in my compile flags, everything works. > > I?m thinking I?m probably just misunderstanding how CXX_STANDARD works, but any help would be appreciated. > > -Matt > -- > > 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 johannes.zarl-zierl at jku.at Tue Oct 13 11:46:39 2015 From: johannes.zarl-zierl at jku.at (Johannes Zarl-Zierl) Date: Tue, 13 Oct 2015 17:46:39 +0200 Subject: [CMake] C++11 flag not being added In-Reply-To: References: Message-ID: <65672189.Iur57BMnAA@ersa> Hi, CXX_STANDARD is a target property, not a global one. You can either set CXX_STANDARD for every target that needs it, or set it globally by changing the default value. You can do the latter by setting the variable CMAKE_CXX_STANDARD before defining any target that depends on it: set(CMAKE_CXX_STANDARD 11) HTH, Johannes On Tuesday 13 October 2015 10:22:36 Matthew S Wallace wrote: > I have the following two lines in my CMakeLists.txt > > set_property(GLOBAL PROPERTY CXX_STANDARD 11) > set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) > > However when compiling some of my source files, the -std=c++11 flag is not > added. > > Just for good measure I added: > target_compile_features(my_target PRIVATE cxx_strong_enums) to the target > that was having the problem. > > Not sure if it matters, but in this case the compile error I?m getting is > complaining because I?m referencing a fully scoped enum. If I explicitly > include -std=c++11 in my compile flags, everything works. > > I?m thinking I?m probably just misunderstanding how CXX_STANDARD works, but > any help would be appreciated. > > -Matt From mwallace at ccmtrading.com Tue Oct 13 13:12:43 2015 From: mwallace at ccmtrading.com (Matthew S Wallace) Date: Tue, 13 Oct 2015 12:12:43 -0500 Subject: [CMake] C++11 flag not being added In-Reply-To: <65672189.Iur57BMnAA@ersa> References: <65672189.Iur57BMnAA@ersa> Message-ID: <086D546E-6369-47A2-82B1-3830D1F785AC@ccmtrading.com> Thanks, setting the global variable solved my issue. -Matt > On Oct 13, 2015, at 10:46 AM, Johannes Zarl-Zierl wrote: > > Hi, > > CXX_STANDARD is a target property, not a global one. You can either set > CXX_STANDARD for every target that needs it, or set it globally by changing > the default value. > > You can do the latter by setting the variable CMAKE_CXX_STANDARD before > defining any target that depends on it: > > set(CMAKE_CXX_STANDARD 11) > > HTH, > Johannes > > On Tuesday 13 October 2015 10:22:36 Matthew S Wallace wrote: >> I have the following two lines in my CMakeLists.txt >> >> set_property(GLOBAL PROPERTY CXX_STANDARD 11) >> set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) >> >> However when compiling some of my source files, the -std=c++11 flag is not >> added. >> >> Just for good measure I added: >> target_compile_features(my_target PRIVATE cxx_strong_enums) to the target >> that was having the problem. >> >> Not sure if it matters, but in this case the compile error I?m getting is >> complaining because I?m referencing a fully scoped enum. If I explicitly >> include -std=c++11 in my compile flags, everything works. >> >> I?m thinking I?m probably just misunderstanding how CXX_STANDARD works, but >> any help would be appreciated. >> >> -Matt > > -- > > 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 cary at txcorp.com Tue Oct 13 20:01:47 2015 From: cary at txcorp.com (John Cary) Date: Tue, 13 Oct 2015 18:01:47 -0600 Subject: [CMake] cmake_check_build_system is causing a rebuild at "make install" In-Reply-To: References: Message-ID: <561D9B6B.9000207@txcorp.com> For future reference, one can determine what triggered the reconfigure by doing make install VERBOSE=1 It appears not to be enough to have configured with -DCMAKE_VERBOSE_MAKEFILE:BOOL=TRUE. In our case, for reasons we have not yet figured out, the depend file for a particular .cu.o object built for a test was what was newer and causing the rebuild. For so-far not understood reasons, this .depend file is being touched during the build. .........JR On 10/13/2015 8:51 AM, cmake-request at cmake.org wrote: > Date: Mon, 12 Oct 2015 17:41:51 -0600 > From: JR Cary > To: cmake at cmake.org > Subject: [CMake] cmake_check_build_system is causing a rebuild at > "make install" > Message-ID: <561C453F.1070602 at txcorp.com> > > In our use of cmake on a particular project, we noticed that > after building the project, upon invoking "make install", the > build starts all over again. Hence we are building the project > twice. > > It seems that this is occurring because nearly everything depends > on the target, cmake_check_build_system, which sometimes causes a > reconfiguration, i.e. reinvocation of cmake. In particular, the > generated Makefile's have: > > install: preinstall > ... > preinstall: all > ... > all: cmake_check_build_system > > and then the last target invokes > > /cmake -H -B --check-build-system > CMakeFiles/Makefile.cmake 0 > > Sometimes this causes a reconfiguration of our project and > sometimes not. When it does, the whole project rebuilds because > nearly everything depends on some configure_file generated > config.h files. > > How can we tell why this reconfiguring? > > BTW, I could not find any of the options, -B, -H, or > --check-build-system at the documentation, > https://cmake.org/cmake/help/v3.3/manual/cmake.1.html. > From nilsgladitz at gmail.com Wed Oct 14 08:45:09 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 14 Oct 2015 14:45:09 +0200 Subject: [CMake] cmake_check_build_system is causing a rebuild at "make install" In-Reply-To: <561D9B6B.9000207@txcorp.com> References: <561D9B6B.9000207@txcorp.com> Message-ID: <561E4E55.8010606@gmail.com> On 14.10.2015 02:01, John Cary wrote: > For future reference, one can determine what triggered the reconfigure > by doing > > make install VERBOSE=1 > > It appears not to be enough to have configured with > -DCMAKE_VERBOSE_MAKEFILE:BOOL=TRUE. > > In our case, for reasons we have not yet figured out, the depend > file for a particular .cu.o object built for a test was what was newer > and causing the rebuild. For so-far not understood reasons, this I am guessing the behaviour has nothing to do with the "install" target but rather the default "all" target which "install" depends on as well. Hence you should see the same behaviour when running plain "make" twice. FindCUDA.cmake forces reconfiguration so dependencies generated at build time can be reprocessed: https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/FindCUDA.cmake;h=1fc582fae0dee409fca05af6c331c7377596bb7d;hb=refs/heads/master#l396 Nils From cary at txcorp.com Wed Oct 14 08:51:16 2015 From: cary at txcorp.com (JR Cary) Date: Wed, 14 Oct 2015 06:51:16 -0600 Subject: [CMake] cmake_check_build_system is causing a rebuild at "make install" In-Reply-To: <561E4E55.8010606@gmail.com> References: <561D9B6B.9000207@txcorp.com> <561E4E55.8010606@gmail.com> Message-ID: <561E4FC4.10904@txcorp.com> Thanks for your response. This is a big headache for us, as it slows down our builds tremendously. Is there any way to prevent or control this behavior? Thx......John On 10/14/15 6:45 AM, Nils Gladitz wrote: > On 14.10.2015 02:01, John Cary wrote: >> For future reference, one can determine what triggered the >> reconfigure by doing >> >> make install VERBOSE=1 >> >> It appears not to be enough to have configured with >> -DCMAKE_VERBOSE_MAKEFILE:BOOL=TRUE. >> >> In our case, for reasons we have not yet figured out, the depend >> file for a particular .cu.o object built for a test was what was newer >> and causing the rebuild. For so-far not understood reasons, this > > I am guessing the behaviour has nothing to do with the "install" > target but rather the default "all" target which "install" depends on > as well. > Hence you should see the same behaviour when running plain "make" twice. > > FindCUDA.cmake forces reconfiguration so dependencies generated at > build time can be reprocessed: > https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/FindCUDA.cmake;h=1fc582fae0dee409fca05af6c331c7377596bb7d;hb=refs/heads/master#l396 > > > Nils > From nilsgladitz at gmail.com Wed Oct 14 09:04:05 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 14 Oct 2015 15:04:05 +0200 Subject: [CMake] cmake_check_build_system is causing a rebuild at "make install" In-Reply-To: <561E4FC4.10904@txcorp.com> References: <561D9B6B.9000207@txcorp.com> <561E4E55.8010606@gmail.com> <561E4FC4.10904@txcorp.com> Message-ID: <561E52C5.4090400@gmail.com> On 14.10.2015 14:51, JR Cary wrote: > Thanks for your response. This is a big headache for us, as it slows > down > our builds tremendously. > > Is there any way to prevent or control this behavior? I don't see how. You could modify the module itself I suppose but I'd expect that to break incremental builds. Nils From Mayer at beyerdynamic.de Thu Oct 15 08:32:27 2015 From: Mayer at beyerdynamic.de (Mayer, Uwe) Date: Thu, 15 Oct 2015 14:32:27 +0200 Subject: [CMake] call compiler with multiple sources at the same time Message-ID: <66EF341EB377F448900B7E131F324BA84B7570337B@exchange2.bd.intern> I am using cmake for cross-compiling to a TI C55x DSP with Windows as the host system. The build process is basically working, however the produced binaries are significantly larger than what the TI Code Composer Studio 6 (CCS6) would produce. The only difference, according to the CCS6 Makefile, is that CMake will compile each .c file individually and then link them together. The CCS6 Makefile will call the compiler once with all sources, i.e. $ /cl55.exe source1.c source2.c source3.c ... --output_file=target.obj This seems to make a difference because of an optimization flag from the cl55 compiler "--program_level_compile" which optimizes "stuff" across all input source files. (How) is it possible to achieve that behaviour with CMake aswell, i.e. by modifying CMAKE_C_COMPILE_OBJECT? If possible: where can I read up on that? Thanks in advance, Uwe This message has been scanned for malware by Websense. www.websense.com From benapetr at gmail.com Thu Oct 15 11:34:02 2015 From: benapetr at gmail.com (Petr Bena) Date: Thu, 15 Oct 2015 17:34:02 +0200 Subject: [CMake] C++11 flag not being added In-Reply-To: <086D546E-6369-47A2-82B1-3830D1F785AC@ccmtrading.com> References: <65672189.Iur57BMnAA@ersa> <086D546E-6369-47A2-82B1-3830D1F785AC@ccmtrading.com> Message-ID: Can you elaborate on it a bit? I put set(CMAKE_CXX_STANDARD 11) as first line of my CMakeLists and it still doesn't work, without the hack I used I get errors while compiling. Can you give me example file in which it works? I guess there is more needed for it to work. On Tue, Oct 13, 2015 at 7:12 PM, Matthew S Wallace wrote: > Thanks, setting the global variable solved my issue. > > -Matt > >> On Oct 13, 2015, at 10:46 AM, Johannes Zarl-Zierl wrote: >> >> Hi, >> >> CXX_STANDARD is a target property, not a global one. You can either set >> CXX_STANDARD for every target that needs it, or set it globally by changing >> the default value. >> >> You can do the latter by setting the variable CMAKE_CXX_STANDARD before >> defining any target that depends on it: >> >> set(CMAKE_CXX_STANDARD 11) >> >> HTH, >> Johannes >> >> On Tuesday 13 October 2015 10:22:36 Matthew S Wallace wrote: >>> I have the following two lines in my CMakeLists.txt >>> >>> set_property(GLOBAL PROPERTY CXX_STANDARD 11) >>> set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) >>> >>> However when compiling some of my source files, the -std=c++11 flag is not >>> added. >>> >>> Just for good measure I added: >>> target_compile_features(my_target PRIVATE cxx_strong_enums) to the target >>> that was having the problem. >>> >>> Not sure if it matters, but in this case the compile error I?m getting is >>> complaining because I?m referencing a fully scoped enum. If I explicitly >>> include -std=c++11 in my compile flags, everything works. >>> >>> I?m thinking I?m probably just misunderstanding how CXX_STANDARD works, but >>> any help would be appreciated. >>> >>> -Matt >> >> -- >> >> 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 From mwallace at ccmtrading.com Thu Oct 15 11:41:31 2015 From: mwallace at ccmtrading.com (Matthew S Wallace) Date: Thu, 15 Oct 2015 10:41:31 -0500 Subject: [CMake] C++11 flag not being added In-Reply-To: References: <65672189.Iur57BMnAA@ersa> <086D546E-6369-47A2-82B1-3830D1F785AC@ccmtrading.com> Message-ID: <1141001C-A186-4837-AC63-97C1E6FF3ECF@ccmtrading.com> What version of CMake are you using? I?m using 3.3.2. The only other thing I did was: set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) I?m guessing this probably does nothing since it is probably a target property. -Matt > On Oct 15, 2015, at 10:34 AM, Petr Bena wrote: > > Can you elaborate on it a bit? > > I put set(CMAKE_CXX_STANDARD 11) as first line of my CMakeLists and it > still doesn't work, without the hack I used I get errors while > compiling. > > Can you give me example file in which it works? I guess there is more > needed for it to work. > > On Tue, Oct 13, 2015 at 7:12 PM, Matthew S Wallace > wrote: >> Thanks, setting the global variable solved my issue. >> >> -Matt >> >>> On Oct 13, 2015, at 10:46 AM, Johannes Zarl-Zierl wrote: >>> >>> Hi, >>> >>> CXX_STANDARD is a target property, not a global one. You can either set >>> CXX_STANDARD for every target that needs it, or set it globally by changing >>> the default value. >>> >>> You can do the latter by setting the variable CMAKE_CXX_STANDARD before >>> defining any target that depends on it: >>> >>> set(CMAKE_CXX_STANDARD 11) >>> >>> HTH, >>> Johannes >>> >>> On Tuesday 13 October 2015 10:22:36 Matthew S Wallace wrote: >>>> I have the following two lines in my CMakeLists.txt >>>> >>>> set_property(GLOBAL PROPERTY CXX_STANDARD 11) >>>> set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) >>>> >>>> However when compiling some of my source files, the -std=c++11 flag is not >>>> added. >>>> >>>> Just for good measure I added: >>>> target_compile_features(my_target PRIVATE cxx_strong_enums) to the target >>>> that was having the problem. >>>> >>>> Not sure if it matters, but in this case the compile error I?m getting is >>>> complaining because I?m referencing a fully scoped enum. If I explicitly >>>> include -std=c++11 in my compile flags, everything works. >>>> >>>> I?m thinking I?m probably just misunderstanding how CXX_STANDARD works, but >>>> any help would be appreciated. >>>> >>>> -Matt >>> >>> -- >>> >>> 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 From benapetr at gmail.com Thu Oct 15 11:45:24 2015 From: benapetr at gmail.com (Petr Bena) Date: Thu, 15 Oct 2015 17:45:24 +0200 Subject: [CMake] C++11 flag not being added In-Reply-To: <1141001C-A186-4837-AC63-97C1E6FF3ECF@ccmtrading.com> References: <65672189.Iur57BMnAA@ersa> <086D546E-6369-47A2-82B1-3830D1F785AC@ccmtrading.com> <1141001C-A186-4837-AC63-97C1E6FF3ECF@ccmtrading.com> Message-ID: What do you mean by "target" property? I don't see any target mentioned there. I don't have this line in there. I don't know which CMake this is, it failed on server we use for unit tests, but I have required min. version set to 2.8.7 On Thu, Oct 15, 2015 at 5:41 PM, Matthew S Wallace wrote: > What version of CMake are you using? I?m using 3.3.2. The only other thing I did was: > > set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) > > I?m guessing this probably does nothing since it is probably a target property. > > -Matt > >> On Oct 15, 2015, at 10:34 AM, Petr Bena wrote: >> >> Can you elaborate on it a bit? >> >> I put set(CMAKE_CXX_STANDARD 11) as first line of my CMakeLists and it >> still doesn't work, without the hack I used I get errors while >> compiling. >> >> Can you give me example file in which it works? I guess there is more >> needed for it to work. >> >> On Tue, Oct 13, 2015 at 7:12 PM, Matthew S Wallace >> wrote: >>> Thanks, setting the global variable solved my issue. >>> >>> -Matt >>> >>>> On Oct 13, 2015, at 10:46 AM, Johannes Zarl-Zierl wrote: >>>> >>>> Hi, >>>> >>>> CXX_STANDARD is a target property, not a global one. You can either set >>>> CXX_STANDARD for every target that needs it, or set it globally by changing >>>> the default value. >>>> >>>> You can do the latter by setting the variable CMAKE_CXX_STANDARD before >>>> defining any target that depends on it: >>>> >>>> set(CMAKE_CXX_STANDARD 11) >>>> >>>> HTH, >>>> Johannes >>>> >>>> On Tuesday 13 October 2015 10:22:36 Matthew S Wallace wrote: >>>>> I have the following two lines in my CMakeLists.txt >>>>> >>>>> set_property(GLOBAL PROPERTY CXX_STANDARD 11) >>>>> set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) >>>>> >>>>> However when compiling some of my source files, the -std=c++11 flag is not >>>>> added. >>>>> >>>>> Just for good measure I added: >>>>> target_compile_features(my_target PRIVATE cxx_strong_enums) to the target >>>>> that was having the problem. >>>>> >>>>> Not sure if it matters, but in this case the compile error I?m getting is >>>>> complaining because I?m referencing a fully scoped enum. If I explicitly >>>>> include -std=c++11 in my compile flags, everything works. >>>>> >>>>> I?m thinking I?m probably just misunderstanding how CXX_STANDARD works, but >>>>> any help would be appreciated. >>>>> >>>>> -Matt >>>> >>>> -- >>>> >>>> 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 > From petr.kmoch at gmail.com Fri Oct 16 03:44:33 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Fri, 16 Oct 2015 09:44:33 +0200 Subject: [CMake] C++11 flag not being added In-Reply-To: References: <65672189.Iur57BMnAA@ersa> <086D546E-6369-47A2-82B1-3830D1F785AC@ccmtrading.com> <1141001C-A186-4837-AC63-97C1E6FF3ECF@ccmtrading.com> Message-ID: Hi Petr. You're using a feature (`CMAKE_CXX_STANDARD`) introduced in CMake version 3.1, so you should require a minimum version >= that. You can learn the version of CMake by running `cmake --version` Petr On Thu, Oct 15, 2015 at 5:45 PM, Petr Bena wrote: > What do you mean by "target" property? I don't see any target > mentioned there. I don't have this line in there. I don't know which > CMake this is, it failed on server we use for unit tests, but I have > required min. version set to 2.8.7 > > > > On Thu, Oct 15, 2015 at 5:41 PM, Matthew S Wallace > wrote: > > What version of CMake are you using? I?m using 3.3.2. The only other > thing I did was: > > > > set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) > > > > I?m guessing this probably does nothing since it is probably a target > property. > > > > -Matt > > > >> On Oct 15, 2015, at 10:34 AM, Petr Bena wrote: > >> > >> Can you elaborate on it a bit? > >> > >> I put set(CMAKE_CXX_STANDARD 11) as first line of my CMakeLists and it > >> still doesn't work, without the hack I used I get errors while > >> compiling. > >> > >> Can you give me example file in which it works? I guess there is more > >> needed for it to work. > >> > >> On Tue, Oct 13, 2015 at 7:12 PM, Matthew S Wallace > >> wrote: > >>> Thanks, setting the global variable solved my issue. > >>> > >>> -Matt > >>> > >>>> On Oct 13, 2015, at 10:46 AM, Johannes Zarl-Zierl < > johannes.zarl-zierl at jku.at> wrote: > >>>> > >>>> Hi, > >>>> > >>>> CXX_STANDARD is a target property, not a global one. You can either > set > >>>> CXX_STANDARD for every target that needs it, or set it globally by > changing > >>>> the default value. > >>>> > >>>> You can do the latter by setting the variable CMAKE_CXX_STANDARD > before > >>>> defining any target that depends on it: > >>>> > >>>> set(CMAKE_CXX_STANDARD 11) > >>>> > >>>> HTH, > >>>> Johannes > >>>> > >>>> On Tuesday 13 October 2015 10:22:36 Matthew S Wallace wrote: > >>>>> I have the following two lines in my CMakeLists.txt > >>>>> > >>>>> set_property(GLOBAL PROPERTY CXX_STANDARD 11) > >>>>> set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) > >>>>> > >>>>> However when compiling some of my source files, the -std=c++11 flag > is not > >>>>> added. > >>>>> > >>>>> Just for good measure I added: > >>>>> target_compile_features(my_target PRIVATE cxx_strong_enums) to the > target > >>>>> that was having the problem. > >>>>> > >>>>> Not sure if it matters, but in this case the compile error I?m > getting is > >>>>> complaining because I?m referencing a fully scoped enum. If I > explicitly > >>>>> include -std=c++11 in my compile flags, everything works. > >>>>> > >>>>> I?m thinking I?m probably just misunderstanding how CXX_STANDARD > works, but > >>>>> any help would be appreciated. > >>>>> > >>>>> -Matt > >>>> > >>>> -- > >>>> > >>>> 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 > > > -- > > 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 benapetr at gmail.com Fri Oct 16 04:58:53 2015 From: benapetr at gmail.com (Petr Bena) Date: Fri, 16 Oct 2015 10:58:53 +0200 Subject: [CMake] C++11 flag not being added In-Reply-To: References: <65672189.Iur57BMnAA@ersa> <086D546E-6369-47A2-82B1-3830D1F785AC@ccmtrading.com> <1141001C-A186-4837-AC63-97C1E6FF3ECF@ccmtrading.com> Message-ID: If I did that nearly nobody would be able to compile my program as cmake >= 3.1 is extremely rare on most distributions. Even ubuntu's PPA builder has some ancient version. On Fri, Oct 16, 2015 at 9:44 AM, Petr Kmoch wrote: > Hi Petr. > > You're using a feature (`CMAKE_CXX_STANDARD`) introduced in CMake version > 3.1, so you should require a minimum version >= that. > > You can learn the version of CMake by running `cmake --version` > > Petr > > On Thu, Oct 15, 2015 at 5:45 PM, Petr Bena wrote: >> >> What do you mean by "target" property? I don't see any target >> mentioned there. I don't have this line in there. I don't know which >> CMake this is, it failed on server we use for unit tests, but I have >> required min. version set to 2.8.7 >> >> >> >> On Thu, Oct 15, 2015 at 5:41 PM, Matthew S Wallace >> wrote: >> > What version of CMake are you using? I?m using 3.3.2. The only other >> > thing I did was: >> > >> > set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) >> > >> > I?m guessing this probably does nothing since it is probably a target >> > property. >> > >> > -Matt >> > >> >> On Oct 15, 2015, at 10:34 AM, Petr Bena wrote: >> >> >> >> Can you elaborate on it a bit? >> >> >> >> I put set(CMAKE_CXX_STANDARD 11) as first line of my CMakeLists and it >> >> still doesn't work, without the hack I used I get errors while >> >> compiling. >> >> >> >> Can you give me example file in which it works? I guess there is more >> >> needed for it to work. >> >> >> >> On Tue, Oct 13, 2015 at 7:12 PM, Matthew S Wallace >> >> wrote: >> >>> Thanks, setting the global variable solved my issue. >> >>> >> >>> -Matt >> >>> >> >>>> On Oct 13, 2015, at 10:46 AM, Johannes Zarl-Zierl >> >>>> wrote: >> >>>> >> >>>> Hi, >> >>>> >> >>>> CXX_STANDARD is a target property, not a global one. You can either >> >>>> set >> >>>> CXX_STANDARD for every target that needs it, or set it globally by >> >>>> changing >> >>>> the default value. >> >>>> >> >>>> You can do the latter by setting the variable CMAKE_CXX_STANDARD >> >>>> before >> >>>> defining any target that depends on it: >> >>>> >> >>>> set(CMAKE_CXX_STANDARD 11) >> >>>> >> >>>> HTH, >> >>>> Johannes >> >>>> >> >>>> On Tuesday 13 October 2015 10:22:36 Matthew S Wallace wrote: >> >>>>> I have the following two lines in my CMakeLists.txt >> >>>>> >> >>>>> set_property(GLOBAL PROPERTY CXX_STANDARD 11) >> >>>>> set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) >> >>>>> >> >>>>> However when compiling some of my source files, the -std=c++11 flag >> >>>>> is not >> >>>>> added. >> >>>>> >> >>>>> Just for good measure I added: >> >>>>> target_compile_features(my_target PRIVATE cxx_strong_enums) to the >> >>>>> target >> >>>>> that was having the problem. >> >>>>> >> >>>>> Not sure if it matters, but in this case the compile error I?m >> >>>>> getting is >> >>>>> complaining because I?m referencing a fully scoped enum. If I >> >>>>> explicitly >> >>>>> include -std=c++11 in my compile flags, everything works. >> >>>>> >> >>>>> I?m thinking I?m probably just misunderstanding how CXX_STANDARD >> >>>>> works, but >> >>>>> any help would be appreciated. >> >>>>> >> >>>>> -Matt >> >>>> >> >>>> -- >> >>>> >> >>>> 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 >> > >> -- >> >> 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 roman.wueger at gmx.at Fri Oct 16 05:22:48 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Fri, 16 Oct 2015 11:22:48 +0200 Subject: [CMake] C++11 flag not being added In-Reply-To: References: <65672189.Iur57BMnAA@ersa> <086D546E-6369-47A2-82B1-3830D1F785AC@ccmtrading.com> <1141001C-A186-4837-AC63-97C1E6FF3ECF@ccmtrading.com> Message-ID: Hi Petr, you can download CMake from https://cmake.org/download/. There are also prebuilt binaries available. We use the *.sh files to install CMake on our linux servers. .) Install CMake to /opt/cmake-3.4.2. .) Create a symlink to /opt/cmake .) Create another symlink from the /opt/cmake/bin/* to /usr/bin With this solution you only need to update the first symlink if you want to upgrade/downgrade a CMake version. Best Regards Roman > Am 16.10.2015 um 10:58 schrieb Petr Bena : > > If I did that nearly nobody would be able to compile my program as > cmake >= 3.1 is extremely rare on most distributions. Even ubuntu's > PPA builder has some ancient version. > >> On Fri, Oct 16, 2015 at 9:44 AM, Petr Kmoch wrote: >> Hi Petr. >> >> You're using a feature (`CMAKE_CXX_STANDARD`) introduced in CMake version >> 3.1, so you should require a minimum version >= that. >> >> You can learn the version of CMake by running `cmake --version` >> >> Petr >> >>> On Thu, Oct 15, 2015 at 5:45 PM, Petr Bena wrote: >>> >>> What do you mean by "target" property? I don't see any target >>> mentioned there. I don't have this line in there. I don't know which >>> CMake this is, it failed on server we use for unit tests, but I have >>> required min. version set to 2.8.7 >>> >>> >>> >>> On Thu, Oct 15, 2015 at 5:41 PM, Matthew S Wallace >>> wrote: >>>> What version of CMake are you using? I?m using 3.3.2. The only other >>>> thing I did was: >>>> >>>> set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) >>>> >>>> I?m guessing this probably does nothing since it is probably a target >>>> property. >>>> >>>> -Matt >>>> >>>>> On Oct 15, 2015, at 10:34 AM, Petr Bena wrote: >>>>> >>>>> Can you elaborate on it a bit? >>>>> >>>>> I put set(CMAKE_CXX_STANDARD 11) as first line of my CMakeLists and it >>>>> still doesn't work, without the hack I used I get errors while >>>>> compiling. >>>>> >>>>> Can you give me example file in which it works? I guess there is more >>>>> needed for it to work. >>>>> >>>>> On Tue, Oct 13, 2015 at 7:12 PM, Matthew S Wallace >>>>> wrote: >>>>>> Thanks, setting the global variable solved my issue. >>>>>> >>>>>> -Matt >>>>>> >>>>>>> On Oct 13, 2015, at 10:46 AM, Johannes Zarl-Zierl >>>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> CXX_STANDARD is a target property, not a global one. You can either >>>>>>> set >>>>>>> CXX_STANDARD for every target that needs it, or set it globally by >>>>>>> changing >>>>>>> the default value. >>>>>>> >>>>>>> You can do the latter by setting the variable CMAKE_CXX_STANDARD >>>>>>> before >>>>>>> defining any target that depends on it: >>>>>>> >>>>>>> set(CMAKE_CXX_STANDARD 11) >>>>>>> >>>>>>> HTH, >>>>>>> Johannes >>>>>>> >>>>>>>> On Tuesday 13 October 2015 10:22:36 Matthew S Wallace wrote: >>>>>>>> I have the following two lines in my CMakeLists.txt >>>>>>>> >>>>>>>> set_property(GLOBAL PROPERTY CXX_STANDARD 11) >>>>>>>> set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) >>>>>>>> >>>>>>>> However when compiling some of my source files, the -std=c++11 flag >>>>>>>> is not >>>>>>>> added. >>>>>>>> >>>>>>>> Just for good measure I added: >>>>>>>> target_compile_features(my_target PRIVATE cxx_strong_enums) to the >>>>>>>> target >>>>>>>> that was having the problem. >>>>>>>> >>>>>>>> Not sure if it matters, but in this case the compile error I?m >>>>>>>> getting is >>>>>>>> complaining because I?m referencing a fully scoped enum. If I >>>>>>>> explicitly >>>>>>>> include -std=c++11 in my compile flags, everything works. >>>>>>>> >>>>>>>> I?m thinking I?m probably just misunderstanding how CXX_STANDARD >>>>>>>> works, but >>>>>>>> any help would be appreciated. >>>>>>>> >>>>>>>> -Matt >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> 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 >>> -- >>> >>> 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 From pgquiles at elpauer.org Fri Oct 16 05:26:00 2015 From: pgquiles at elpauer.org (Pau Garcia i Quiles) Date: Fri, 16 Oct 2015 11:26:00 +0200 Subject: [CMake] C++11 flag not being added In-Reply-To: References: <65672189.Iur57BMnAA@ersa> <086D546E-6369-47A2-82B1-3830D1F785AC@ccmtrading.com> <1141001C-A186-4837-AC63-97C1E6FF3ECF@ccmtrading.com> Message-ID: Hello, CMake 3.3.1 is available from my PPA, in case it helps: https://launchpad.net/~pgquiles/+archive/ubuntu/ppa On Fri, Oct 16, 2015 at 10:58 AM, Petr Bena wrote: > If I did that nearly nobody would be able to compile my program as > cmake >= 3.1 is extremely rare on most distributions. Even ubuntu's > PPA builder has some ancient version. > > On Fri, Oct 16, 2015 at 9:44 AM, Petr Kmoch wrote: > > Hi Petr. > > > > You're using a feature (`CMAKE_CXX_STANDARD`) introduced in CMake version > > 3.1, so you should require a minimum version >= that. > > > > You can learn the version of CMake by running `cmake --version` > > > > Petr > > > > On Thu, Oct 15, 2015 at 5:45 PM, Petr Bena wrote: > >> > >> What do you mean by "target" property? I don't see any target > >> mentioned there. I don't have this line in there. I don't know which > >> CMake this is, it failed on server we use for unit tests, but I have > >> required min. version set to 2.8.7 > >> > >> > >> > >> On Thu, Oct 15, 2015 at 5:41 PM, Matthew S Wallace > >> wrote: > >> > What version of CMake are you using? I?m using 3.3.2. The only other > >> > thing I did was: > >> > > >> > set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) > >> > > >> > I?m guessing this probably does nothing since it is probably a target > >> > property. > >> > > >> > -Matt > >> > > >> >> On Oct 15, 2015, at 10:34 AM, Petr Bena wrote: > >> >> > >> >> Can you elaborate on it a bit? > >> >> > >> >> I put set(CMAKE_CXX_STANDARD 11) as first line of my CMakeLists and > it > >> >> still doesn't work, without the hack I used I get errors while > >> >> compiling. > >> >> > >> >> Can you give me example file in which it works? I guess there is more > >> >> needed for it to work. > >> >> > >> >> On Tue, Oct 13, 2015 at 7:12 PM, Matthew S Wallace > >> >> wrote: > >> >>> Thanks, setting the global variable solved my issue. > >> >>> > >> >>> -Matt > >> >>> > >> >>>> On Oct 13, 2015, at 10:46 AM, Johannes Zarl-Zierl > >> >>>> wrote: > >> >>>> > >> >>>> Hi, > >> >>>> > >> >>>> CXX_STANDARD is a target property, not a global one. You can either > >> >>>> set > >> >>>> CXX_STANDARD for every target that needs it, or set it globally by > >> >>>> changing > >> >>>> the default value. > >> >>>> > >> >>>> You can do the latter by setting the variable CMAKE_CXX_STANDARD > >> >>>> before > >> >>>> defining any target that depends on it: > >> >>>> > >> >>>> set(CMAKE_CXX_STANDARD 11) > >> >>>> > >> >>>> HTH, > >> >>>> Johannes > >> >>>> > >> >>>> On Tuesday 13 October 2015 10:22:36 Matthew S Wallace wrote: > >> >>>>> I have the following two lines in my CMakeLists.txt > >> >>>>> > >> >>>>> set_property(GLOBAL PROPERTY CXX_STANDARD 11) > >> >>>>> set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) > >> >>>>> > >> >>>>> However when compiling some of my source files, the -std=c++11 > flag > >> >>>>> is not > >> >>>>> added. > >> >>>>> > >> >>>>> Just for good measure I added: > >> >>>>> target_compile_features(my_target PRIVATE cxx_strong_enums) to the > >> >>>>> target > >> >>>>> that was having the problem. > >> >>>>> > >> >>>>> Not sure if it matters, but in this case the compile error I?m > >> >>>>> getting is > >> >>>>> complaining because I?m referencing a fully scoped enum. If I > >> >>>>> explicitly > >> >>>>> include -std=c++11 in my compile flags, everything works. > >> >>>>> > >> >>>>> I?m thinking I?m probably just misunderstanding how CXX_STANDARD > >> >>>>> works, but > >> >>>>> any help would be appreciated. > >> >>>>> > >> >>>>> -Matt > >> >>>> > >> >>>> -- > >> >>>> > >> >>>> 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 > >> > > >> -- > >> > >> 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 > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From benapetr at gmail.com Fri Oct 16 05:29:48 2015 From: benapetr at gmail.com (Petr Bena) Date: Fri, 16 Oct 2015 11:29:48 +0200 Subject: [CMake] C++11 flag not being added In-Reply-To: References: <65672189.Iur57BMnAA@ersa> <086D546E-6369-47A2-82B1-3830D1F785AC@ccmtrading.com> <1141001C-A186-4837-AC63-97C1E6FF3ECF@ccmtrading.com> Message-ID: I think you completely misunderstood me. I know I can install it on my machine, but I can hardly install it on PC's or servers of users who use my program. I want to make it as easy as possible to let users compile my program. Having to install anything by hand instead of system package manager is a big overhead to majority of users. CMake 3x is too new, it's available by default almost nowhere, meaning this option is not available to me at this time. Maybe in few years the situation will change, but for now I will resort to that hack which works on older versions that are generally available everywhere. On Fri, Oct 16, 2015 at 11:26 AM, Pau Garcia i Quiles wrote: > Hello, > > CMake 3.3.1 is available from my PPA, in case it helps: > > https://launchpad.net/~pgquiles/+archive/ubuntu/ppa > > > > On Fri, Oct 16, 2015 at 10:58 AM, Petr Bena wrote: >> >> If I did that nearly nobody would be able to compile my program as >> cmake >= 3.1 is extremely rare on most distributions. Even ubuntu's >> PPA builder has some ancient version. >> >> On Fri, Oct 16, 2015 at 9:44 AM, Petr Kmoch wrote: >> > Hi Petr. >> > >> > You're using a feature (`CMAKE_CXX_STANDARD`) introduced in CMake >> > version >> > 3.1, so you should require a minimum version >= that. >> > >> > You can learn the version of CMake by running `cmake --version` >> > >> > Petr >> > >> > On Thu, Oct 15, 2015 at 5:45 PM, Petr Bena wrote: >> >> >> >> What do you mean by "target" property? I don't see any target >> >> mentioned there. I don't have this line in there. I don't know which >> >> CMake this is, it failed on server we use for unit tests, but I have >> >> required min. version set to 2.8.7 >> >> >> >> >> >> >> >> On Thu, Oct 15, 2015 at 5:41 PM, Matthew S Wallace >> >> wrote: >> >> > What version of CMake are you using? I?m using 3.3.2. The only >> >> > other >> >> > thing I did was: >> >> > >> >> > set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) >> >> > >> >> > I?m guessing this probably does nothing since it is probably a target >> >> > property. >> >> > >> >> > -Matt >> >> > >> >> >> On Oct 15, 2015, at 10:34 AM, Petr Bena wrote: >> >> >> >> >> >> Can you elaborate on it a bit? >> >> >> >> >> >> I put set(CMAKE_CXX_STANDARD 11) as first line of my CMakeLists and >> >> >> it >> >> >> still doesn't work, without the hack I used I get errors while >> >> >> compiling. >> >> >> >> >> >> Can you give me example file in which it works? I guess there is >> >> >> more >> >> >> needed for it to work. >> >> >> >> >> >> On Tue, Oct 13, 2015 at 7:12 PM, Matthew S Wallace >> >> >> wrote: >> >> >>> Thanks, setting the global variable solved my issue. >> >> >>> >> >> >>> -Matt >> >> >>> >> >> >>>> On Oct 13, 2015, at 10:46 AM, Johannes Zarl-Zierl >> >> >>>> wrote: >> >> >>>> >> >> >>>> Hi, >> >> >>>> >> >> >>>> CXX_STANDARD is a target property, not a global one. You can >> >> >>>> either >> >> >>>> set >> >> >>>> CXX_STANDARD for every target that needs it, or set it globally by >> >> >>>> changing >> >> >>>> the default value. >> >> >>>> >> >> >>>> You can do the latter by setting the variable CMAKE_CXX_STANDARD >> >> >>>> before >> >> >>>> defining any target that depends on it: >> >> >>>> >> >> >>>> set(CMAKE_CXX_STANDARD 11) >> >> >>>> >> >> >>>> HTH, >> >> >>>> Johannes >> >> >>>> >> >> >>>> On Tuesday 13 October 2015 10:22:36 Matthew S Wallace wrote: >> >> >>>>> I have the following two lines in my CMakeLists.txt >> >> >>>>> >> >> >>>>> set_property(GLOBAL PROPERTY CXX_STANDARD 11) >> >> >>>>> set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) >> >> >>>>> >> >> >>>>> However when compiling some of my source files, the -std=c++11 >> >> >>>>> flag >> >> >>>>> is not >> >> >>>>> added. >> >> >>>>> >> >> >>>>> Just for good measure I added: >> >> >>>>> target_compile_features(my_target PRIVATE cxx_strong_enums) to >> >> >>>>> the >> >> >>>>> target >> >> >>>>> that was having the problem. >> >> >>>>> >> >> >>>>> Not sure if it matters, but in this case the compile error I?m >> >> >>>>> getting is >> >> >>>>> complaining because I?m referencing a fully scoped enum. If I >> >> >>>>> explicitly >> >> >>>>> include -std=c++11 in my compile flags, everything works. >> >> >>>>> >> >> >>>>> I?m thinking I?m probably just misunderstanding how CXX_STANDARD >> >> >>>>> works, but >> >> >>>>> any help would be appreciated. >> >> >>>>> >> >> >>>>> -Matt >> >> >>>> >> >> >>>> -- >> >> >>>> >> >> >>>> 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 >> >> > >> >> -- >> >> >> >> 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 > > > > > -- > Pau Garcia i Quiles > http://www.elpauer.org > (Due to my workload, I may need 10 days to answer) From post at hendrik-sattler.de Fri Oct 16 05:56:12 2015 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Fri, 16 Oct 2015 11:56:12 +0200 Subject: [CMake] C++11 flag not being added In-Reply-To: References: <65672189.Iur57BMnAA@ersa> <086D546E-6369-47A2-82B1-3830D1F785AC@ccmtrading.com> <1141001C-A186-4837-AC63-97C1E6FF3ECF@ccmtrading.com> Message-ID: <25FB9206-F66F-4FAA-B6AF-4C40FD6235AB@hendrik-sattler.de> Am 16. Oktober 2015 11:29:48 MESZ, schrieb Petr Bena : >I think you completely misunderstood me. I know I can install it on my >machine, but I can hardly install it on PC's or servers of users who >use my program. > >I want to make it as easy as possible to let users compile my program. >Having to install anything by hand instead of system package manager >is a big overhead to majority of users. CMake 3x is too new, it's Hey, 3.0.2 is even available in Debian stable, and that really says something about older versions! >available by default almost nowhere, meaning this option is not >available to me at this time. Maybe in few years the situation will >change, but for now I will resort to that hack which works on older >versions that are generally available everywhere. > >On Fri, Oct 16, 2015 at 11:26 AM, Pau Garcia i Quiles > wrote: >> Hello, >> >> CMake 3.3.1 is available from my PPA, in case it helps: >> >> https://launchpad.net/~pgquiles/+archive/ubuntu/ppa >> >> >> >> On Fri, Oct 16, 2015 at 10:58 AM, Petr Bena >wrote: >>> >>> If I did that nearly nobody would be able to compile my program as >>> cmake >= 3.1 is extremely rare on most distributions. Even ubuntu's >>> PPA builder has some ancient version. >>> >>> On Fri, Oct 16, 2015 at 9:44 AM, Petr Kmoch >wrote: >>> > Hi Petr. >>> > >>> > You're using a feature (`CMAKE_CXX_STANDARD`) introduced in CMake >>> > version >>> > 3.1, so you should require a minimum version >= that. >>> > >>> > You can learn the version of CMake by running `cmake --version` >>> > >>> > Petr >>> > >>> > On Thu, Oct 15, 2015 at 5:45 PM, Petr Bena >wrote: >>> >> >>> >> What do you mean by "target" property? I don't see any target >>> >> mentioned there. I don't have this line in there. I don't know >which >>> >> CMake this is, it failed on server we use for unit tests, but I >have >>> >> required min. version set to 2.8.7 >>> >> >>> >> >>> >> >>> >> On Thu, Oct 15, 2015 at 5:41 PM, Matthew S Wallace >>> >> wrote: >>> >> > What version of CMake are you using? I?m using 3.3.2. The >only >>> >> > other >>> >> > thing I did was: >>> >> > >>> >> > set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) >>> >> > >>> >> > I?m guessing this probably does nothing since it is probably a >target >>> >> > property. >>> >> > >>> >> > -Matt >>> >> > >>> >> >> On Oct 15, 2015, at 10:34 AM, Petr Bena >wrote: >>> >> >> >>> >> >> Can you elaborate on it a bit? >>> >> >> >>> >> >> I put set(CMAKE_CXX_STANDARD 11) as first line of my >CMakeLists and >>> >> >> it >>> >> >> still doesn't work, without the hack I used I get errors while >>> >> >> compiling. >>> >> >> >>> >> >> Can you give me example file in which it works? I guess there >is >>> >> >> more >>> >> >> needed for it to work. >>> >> >> >>> >> >> On Tue, Oct 13, 2015 at 7:12 PM, Matthew S Wallace >>> >> >> wrote: >>> >> >>> Thanks, setting the global variable solved my issue. >>> >> >>> >>> >> >>> -Matt >>> >> >>> >>> >> >>>> On Oct 13, 2015, at 10:46 AM, Johannes Zarl-Zierl >>> >> >>>> wrote: >>> >> >>>> >>> >> >>>> Hi, >>> >> >>>> >>> >> >>>> CXX_STANDARD is a target property, not a global one. You can >>> >> >>>> either >>> >> >>>> set >>> >> >>>> CXX_STANDARD for every target that needs it, or set it >globally by >>> >> >>>> changing >>> >> >>>> the default value. >>> >> >>>> >>> >> >>>> You can do the latter by setting the variable >CMAKE_CXX_STANDARD >>> >> >>>> before >>> >> >>>> defining any target that depends on it: >>> >> >>>> >>> >> >>>> set(CMAKE_CXX_STANDARD 11) >>> >> >>>> >>> >> >>>> HTH, >>> >> >>>> Johannes >>> >> >>>> >>> >> >>>> On Tuesday 13 October 2015 10:22:36 Matthew S Wallace wrote: >>> >> >>>>> I have the following two lines in my CMakeLists.txt >>> >> >>>>> >>> >> >>>>> set_property(GLOBAL PROPERTY CXX_STANDARD 11) >>> >> >>>>> set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) >>> >> >>>>> >>> >> >>>>> However when compiling some of my source files, the >-std=c++11 >>> >> >>>>> flag >>> >> >>>>> is not >>> >> >>>>> added. >>> >> >>>>> >>> >> >>>>> Just for good measure I added: >>> >> >>>>> target_compile_features(my_target PRIVATE cxx_strong_enums) >to >>> >> >>>>> the >>> >> >>>>> target >>> >> >>>>> that was having the problem. >>> >> >>>>> >>> >> >>>>> Not sure if it matters, but in this case the compile error >I?m >>> >> >>>>> getting is >>> >> >>>>> complaining because I?m referencing a fully scoped enum. >If I >>> >> >>>>> explicitly >>> >> >>>>> include -std=c++11 in my compile flags, everything works. >>> >> >>>>> >>> >> >>>>> I?m thinking I?m probably just misunderstanding how >CXX_STANDARD >>> >> >>>>> works, but >>> >> >>>>> any help would be appreciated. >>> >> >>>>> >>> >> >>>>> -Matt >>> >> >>>> >>> >> >>>> -- >>> >> >>>> >>> >> >>>> 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 >>> >> > >>> >> -- >>> >> >>> >> 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 >> >> >> >> >> -- >> Pau Garcia i Quiles >> http://www.elpauer.org >> (Due to my workload, I may need 10 days to answer) >-- > >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 post at hendrik-sattler.de Fri Oct 16 06:03:41 2015 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Fri, 16 Oct 2015 12:03:41 +0200 Subject: [CMake] C++11 flag not being added In-Reply-To: References: <65672189.Iur57BMnAA@ersa> <086D546E-6369-47A2-82B1-3830D1F785AC@ccmtrading.com> <1141001C-A186-4837-AC63-97C1E6FF3ECF@ccmtrading.com> Message-ID: Am 16. Oktober 2015 11:29:48 MESZ, schrieb Petr Bena : >I think you completely misunderstood me. I know I can install it on my >machine, but I can hardly install it on PC's or servers of users who >use my program. > >I want to make it as easy as possible to let users compile my program. >Having to install anything by hand instead of system package manager >is a big overhead to majority of users. CMake 3x is too new, it's >available by default almost nowhere, meaning this option is not >available to me at this time. Maybe in few years the situation will >change, but for now I will resort to that hack which works on older >versions that are generally available everywhere. And what are those systems that bring an ancient cmake version but real C++11 support? Note that many C++ libraries must be recompiled with c++11 enabled during compilation when you want to use them in your C++11 program. >On Fri, Oct 16, 2015 at 11:26 AM, Pau Garcia i Quiles > wrote: >> Hello, >> >> CMake 3.3.1 is available from my PPA, in case it helps: >> >> https://launchpad.net/~pgquiles/+archive/ubuntu/ppa >> >> >> >> On Fri, Oct 16, 2015 at 10:58 AM, Petr Bena >wrote: >>> >>> If I did that nearly nobody would be able to compile my program as >>> cmake >= 3.1 is extremely rare on most distributions. Even ubuntu's >>> PPA builder has some ancient version. >>> >>> On Fri, Oct 16, 2015 at 9:44 AM, Petr Kmoch >wrote: >>> > Hi Petr. >>> > >>> > You're using a feature (`CMAKE_CXX_STANDARD`) introduced in CMake >>> > version >>> > 3.1, so you should require a minimum version >= that. >>> > >>> > You can learn the version of CMake by running `cmake --version` >>> > >>> > Petr >>> > >>> > On Thu, Oct 15, 2015 at 5:45 PM, Petr Bena >wrote: >>> >> >>> >> What do you mean by "target" property? I don't see any target >>> >> mentioned there. I don't have this line in there. I don't know >which >>> >> CMake this is, it failed on server we use for unit tests, but I >have >>> >> required min. version set to 2.8.7 >>> >> >>> >> >>> >> >>> >> On Thu, Oct 15, 2015 at 5:41 PM, Matthew S Wallace >>> >> wrote: >>> >> > What version of CMake are you using? I?m using 3.3.2. The >only >>> >> > other >>> >> > thing I did was: >>> >> > >>> >> > set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) >>> >> > >>> >> > I?m guessing this probably does nothing since it is probably a >target >>> >> > property. >>> >> > >>> >> > -Matt >>> >> > >>> >> >> On Oct 15, 2015, at 10:34 AM, Petr Bena >wrote: >>> >> >> >>> >> >> Can you elaborate on it a bit? >>> >> >> >>> >> >> I put set(CMAKE_CXX_STANDARD 11) as first line of my >CMakeLists and >>> >> >> it >>> >> >> still doesn't work, without the hack I used I get errors while >>> >> >> compiling. >>> >> >> >>> >> >> Can you give me example file in which it works? I guess there >is >>> >> >> more >>> >> >> needed for it to work. >>> >> >> >>> >> >> On Tue, Oct 13, 2015 at 7:12 PM, Matthew S Wallace >>> >> >> wrote: >>> >> >>> Thanks, setting the global variable solved my issue. >>> >> >>> >>> >> >>> -Matt >>> >> >>> >>> >> >>>> On Oct 13, 2015, at 10:46 AM, Johannes Zarl-Zierl >>> >> >>>> wrote: >>> >> >>>> >>> >> >>>> Hi, >>> >> >>>> >>> >> >>>> CXX_STANDARD is a target property, not a global one. You can >>> >> >>>> either >>> >> >>>> set >>> >> >>>> CXX_STANDARD for every target that needs it, or set it >globally by >>> >> >>>> changing >>> >> >>>> the default value. >>> >> >>>> >>> >> >>>> You can do the latter by setting the variable >CMAKE_CXX_STANDARD >>> >> >>>> before >>> >> >>>> defining any target that depends on it: >>> >> >>>> >>> >> >>>> set(CMAKE_CXX_STANDARD 11) >>> >> >>>> >>> >> >>>> HTH, >>> >> >>>> Johannes >>> >> >>>> >>> >> >>>> On Tuesday 13 October 2015 10:22:36 Matthew S Wallace wrote: >>> >> >>>>> I have the following two lines in my CMakeLists.txt >>> >> >>>>> >>> >> >>>>> set_property(GLOBAL PROPERTY CXX_STANDARD 11) >>> >> >>>>> set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) >>> >> >>>>> >>> >> >>>>> However when compiling some of my source files, the >-std=c++11 >>> >> >>>>> flag >>> >> >>>>> is not >>> >> >>>>> added. >>> >> >>>>> >>> >> >>>>> Just for good measure I added: >>> >> >>>>> target_compile_features(my_target PRIVATE cxx_strong_enums) >to >>> >> >>>>> the >>> >> >>>>> target >>> >> >>>>> that was having the problem. >>> >> >>>>> >>> >> >>>>> Not sure if it matters, but in this case the compile error >I?m >>> >> >>>>> getting is >>> >> >>>>> complaining because I?m referencing a fully scoped enum. >If I >>> >> >>>>> explicitly >>> >> >>>>> include -std=c++11 in my compile flags, everything works. >>> >> >>>>> >>> >> >>>>> I?m thinking I?m probably just misunderstanding how >CXX_STANDARD >>> >> >>>>> works, but >>> >> >>>>> any help would be appreciated. >>> >> >>>>> >>> >> >>>>> -Matt >>> >> >>>> >>> >> >>>> -- >>> >> >>>> >>> >> >>>> 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 >>> >> > >>> >> -- >>> >> >>> >> 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 >> >> >> >> >> -- >> Pau Garcia i Quiles >> http://www.elpauer.org >> (Due to my workload, I may need 10 days to answer) >-- > >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 alex at zelid.com Fri Oct 16 06:12:17 2015 From: alex at zelid.com (Alex Zelid) Date: Fri, 16 Oct 2015 13:12:17 +0300 Subject: [CMake] FindwxWidgets can't find wxWidgets installed by MSYS2 Message-ID: Hello, I'm using mingw-w64 installed by MSYS2 (https://msys2.github.io/) wxWidgets .dlls are installed in C:\msys64\mingw32\bin libs in C:\msys64\mingw32\lib My CMakeList.txt: ------------------------------------------- SET(myapp1_SRCS main.cpp) add_executable(${PROJECT_NAME} ${myapp1_SRCS}) set(BUILD_SHARED_LIBS 0) #Set Linker flags set(CMAKE_EXE_LINKER_FLAGS "-static-libgcc -static-libstdc++ -static") find_package(PNG REQUIRED) include_directories(${PNG_INCLUDE_DIR}) message(STATUS "LibPNG package was found with include dir: '${PNG_INCLUDE_DIRS}'") find_package(Threads REQUIRED) SET(wxWidgets_USE_STATIC ON) SET(wxWidgets_WXCONFIG_OPTS "--static=yes") find_package( wxWidgets REQUIRED html adv core base net aui xrc qa richtext) include(${wxWidgets_USE_FILE}) target_link_libraries(${PROJECT_NAME} ${PNG_LIBRARY} ${CMAKE_THREAD_LIBS_INIT} ${wxWidgets_LIBRARIES}) ------------------------------------------- When I generate "MinGW Makefiles" from windows CMD (not from MSYS2 terminal) CMake finds PNG but doesn't fine wxWidgets: C:\msys64\home\Alex\workspace\_cmake\wxdemo1\build-mingw32>cmake -G "MinGW Makefiles" ..\master -- The C compiler identification is GNU 5.2.0 -- The CXX compiler identification is GNU 5.2.0 -- Check for working C compiler: C:/msys64/mingw32/bin/gcc.exe -- Check for working C compiler: C:/msys64/mingw32/bin/gcc.exe -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: C:/msys64/mingw32/bin/g++.exe -- Check for working CXX compiler: C:/msys64/mingw32/bin/g++.exe -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found ZLIB: C:/msys64/mingw32/lib/libz.dll.a (found version "1.2.8") -- Found PNG: C:/msys64/mingw32/lib/libpng.dll.a (found version "1.6.18") -- LibPNG package was found with include dir: 'C:/msys64/mingw32/include;C:/msys64/mingw32/include' -- Looking for include file pthread.h -- Looking for include file pthread.h - found -- Looking for pthread_create -- Looking for pthread_create - found -- Found Threads: TRUE CMake Error at C:/msys64/mingw32/share/cmake-3.3/Modules/FindPackageHandleStandardArgs.cmake:148 (message): Could NOT find wxWidgets (missing: wxWidgets_FOUND) Call Stack (most recent call first): C:/msys64/mingw32/share/cmake-3.3/Modules/FindPackageHandleStandardArgs.cmake:388 (_FPHSA_FAILURE_MESSAGE) C:/msys64/mingw32/share/cmake-3.3/Modules/FindwxWidgets.cmake:871 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) myapp1/CMakeLists.txt:26 (find_package) -- Configuring incomplete, errors occurred! See also "C:/msys64/home/Alex/workspace/_cmake/wxdemo1/build-mingw32/CMakeFiles/CMakeOutput.log". It happens because wxWidgets are placed in non-standard for mingw version of wxWidgets path. I've also tried cmake -DwxWidgets_ROOT_DIR=C:/msys64/mingw32 -DwxWidgets_LIB_DIR=C:/msys64/mingw32/lib -G "MinGW Makefiles" ..\master it gave the same error How to make FindwxWidgets work in that case? Thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From benapetr at gmail.com Fri Oct 16 07:38:27 2015 From: benapetr at gmail.com (Petr Bena) Date: Fri, 16 Oct 2015 13:38:27 +0200 Subject: [CMake] C++11 flag not being added In-Reply-To: <25FB9206-F66F-4FAA-B6AF-4C40FD6235AB@hendrik-sattler.de> References: <65672189.Iur57BMnAA@ersa> <086D546E-6369-47A2-82B1-3830D1F785AC@ccmtrading.com> <1141001C-A186-4837-AC63-97C1E6FF3ECF@ccmtrading.com> <25FB9206-F66F-4FAA-B6AF-4C40FD6235AB@hendrik-sattler.de> Message-ID: By stable you mean Jessie that was recently released and is almost nowhere in production yet? :) On my debian server: $ cmake --version cmake version 2.8.9 On one of wikimedia's ubuntu servers (the newer ones): $ cmake --version cmake version 2.8.12.2 On travis-ci cmake is about 2.8.7 and on ubuntu PPA builder it's probably same. And we aren't even talking about 3.0, but 3.1 or newer. One would need to be truly naive to expect newer version on some stable production systems, that usually run well established older software (eg. majority of them do). On my dev PC I have last CMake of course, but I need to be able to compile on other systems as well :) This code is meant to be cross-platform and buildable on most of supported OS'es, even on older versions. I sincerely hate programs that requires extremely latest versions of tools or libraries for them to work, because these are usually hard to build. On Fri, Oct 16, 2015 at 11:56 AM, Hendrik Sattler wrote: > > > Am 16. Oktober 2015 11:29:48 MESZ, schrieb Petr Bena : >>I think you completely misunderstood me. I know I can install it on my >>machine, but I can hardly install it on PC's or servers of users who >>use my program. >> >>I want to make it as easy as possible to let users compile my program. >>Having to install anything by hand instead of system package manager >>is a big overhead to majority of users. CMake 3x is too new, it's > > > Hey, 3.0.2 is even available in Debian stable, and that really says something about older versions! > > >>available by default almost nowhere, meaning this option is not >>available to me at this time. Maybe in few years the situation will >>change, but for now I will resort to that hack which works on older >>versions that are generally available everywhere. >> >>On Fri, Oct 16, 2015 at 11:26 AM, Pau Garcia i Quiles >> wrote: >>> Hello, >>> >>> CMake 3.3.1 is available from my PPA, in case it helps: >>> >>> https://launchpad.net/~pgquiles/+archive/ubuntu/ppa >>> >>> >>> >>> On Fri, Oct 16, 2015 at 10:58 AM, Petr Bena >>wrote: >>>> >>>> If I did that nearly nobody would be able to compile my program as >>>> cmake >= 3.1 is extremely rare on most distributions. Even ubuntu's >>>> PPA builder has some ancient version. >>>> >>>> On Fri, Oct 16, 2015 at 9:44 AM, Petr Kmoch >>wrote: >>>> > Hi Petr. >>>> > >>>> > You're using a feature (`CMAKE_CXX_STANDARD`) introduced in CMake >>>> > version >>>> > 3.1, so you should require a minimum version >= that. >>>> > >>>> > You can learn the version of CMake by running `cmake --version` >>>> > >>>> > Petr >>>> > >>>> > On Thu, Oct 15, 2015 at 5:45 PM, Petr Bena >>wrote: >>>> >> >>>> >> What do you mean by "target" property? I don't see any target >>>> >> mentioned there. I don't have this line in there. I don't know >>which >>>> >> CMake this is, it failed on server we use for unit tests, but I >>have >>>> >> required min. version set to 2.8.7 >>>> >> >>>> >> >>>> >> >>>> >> On Thu, Oct 15, 2015 at 5:41 PM, Matthew S Wallace >>>> >> wrote: >>>> >> > What version of CMake are you using? I?m using 3.3.2. The >>only >>>> >> > other >>>> >> > thing I did was: >>>> >> > >>>> >> > set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) >>>> >> > >>>> >> > I?m guessing this probably does nothing since it is probably a >>target >>>> >> > property. >>>> >> > >>>> >> > -Matt >>>> >> > >>>> >> >> On Oct 15, 2015, at 10:34 AM, Petr Bena >>wrote: >>>> >> >> >>>> >> >> Can you elaborate on it a bit? >>>> >> >> >>>> >> >> I put set(CMAKE_CXX_STANDARD 11) as first line of my >>CMakeLists and >>>> >> >> it >>>> >> >> still doesn't work, without the hack I used I get errors while >>>> >> >> compiling. >>>> >> >> >>>> >> >> Can you give me example file in which it works? I guess there >>is >>>> >> >> more >>>> >> >> needed for it to work. >>>> >> >> >>>> >> >> On Tue, Oct 13, 2015 at 7:12 PM, Matthew S Wallace >>>> >> >> wrote: >>>> >> >>> Thanks, setting the global variable solved my issue. >>>> >> >>> >>>> >> >>> -Matt >>>> >> >>> >>>> >> >>>> On Oct 13, 2015, at 10:46 AM, Johannes Zarl-Zierl >>>> >> >>>> wrote: >>>> >> >>>> >>>> >> >>>> Hi, >>>> >> >>>> >>>> >> >>>> CXX_STANDARD is a target property, not a global one. You can >>>> >> >>>> either >>>> >> >>>> set >>>> >> >>>> CXX_STANDARD for every target that needs it, or set it >>globally by >>>> >> >>>> changing >>>> >> >>>> the default value. >>>> >> >>>> >>>> >> >>>> You can do the latter by setting the variable >>CMAKE_CXX_STANDARD >>>> >> >>>> before >>>> >> >>>> defining any target that depends on it: >>>> >> >>>> >>>> >> >>>> set(CMAKE_CXX_STANDARD 11) >>>> >> >>>> >>>> >> >>>> HTH, >>>> >> >>>> Johannes >>>> >> >>>> >>>> >> >>>> On Tuesday 13 October 2015 10:22:36 Matthew S Wallace wrote: >>>> >> >>>>> I have the following two lines in my CMakeLists.txt >>>> >> >>>>> >>>> >> >>>>> set_property(GLOBAL PROPERTY CXX_STANDARD 11) >>>> >> >>>>> set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) >>>> >> >>>>> >>>> >> >>>>> However when compiling some of my source files, the >>-std=c++11 >>>> >> >>>>> flag >>>> >> >>>>> is not >>>> >> >>>>> added. >>>> >> >>>>> >>>> >> >>>>> Just for good measure I added: >>>> >> >>>>> target_compile_features(my_target PRIVATE cxx_strong_enums) >>to >>>> >> >>>>> the >>>> >> >>>>> target >>>> >> >>>>> that was having the problem. >>>> >> >>>>> >>>> >> >>>>> Not sure if it matters, but in this case the compile error >>I?m >>>> >> >>>>> getting is >>>> >> >>>>> complaining because I?m referencing a fully scoped enum. >>If I >>>> >> >>>>> explicitly >>>> >> >>>>> include -std=c++11 in my compile flags, everything works. >>>> >> >>>>> >>>> >> >>>>> I?m thinking I?m probably just misunderstanding how >>CXX_STANDARD >>>> >> >>>>> works, but >>>> >> >>>>> any help would be appreciated. >>>> >> >>>>> >>>> >> >>>>> -Matt >>>> >> >>>> >>>> >> >>>> -- >>>> >> >>>> >>>> >> >>>> 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 >>>> >> > >>>> >> -- >>>> >> >>>> >> 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 >>> >>> >>> >>> >>> -- >>> Pau Garcia i Quiles >>> http://www.elpauer.org >>> (Due to my workload, I may need 10 days to answer) >>-- >> >>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 From post at hendrik-sattler.de Fri Oct 16 08:09:24 2015 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Fri, 16 Oct 2015 14:09:24 +0200 Subject: [CMake] C++11 flag not being added In-Reply-To: References: <65672189.Iur57BMnAA@ersa> <086D546E-6369-47A2-82B1-3830D1F785AC@ccmtrading.com> <1141001C-A186-4837-AC63-97C1E6FF3ECF@ccmtrading.com> <25FB9206-F66F-4FAA-B6AF-4C40FD6235AB@hendrik-sattler.de> Message-ID: <88016538-C0E4-4F4D-BD1A-D4208B6F0EC5@hendrik-sattler.de> Am 16. Oktober 2015 13:38:27 MESZ, schrieb Petr Bena : >By stable you mean Jessie that was recently released and is almost >nowhere in production yet? :) > >On my debian server: > >$ cmake --version >cmake version 2.8.9 > >On one of wikimedia's ubuntu servers (the newer ones): > >$ cmake --version >cmake version 2.8.12.2 > >On travis-ci cmake is about 2.8.7 and on ubuntu PPA builder it's >probably same. > >And we aren't even talking about 3.0, but 3.1 or newer. One would need >to be truly naive to expect newer version on some stable production >systems, that usually run well established older software (eg. >majority of them do). > >On my dev PC I have last CMake of course, but I need to be able to >compile on other systems as well :) > >This code is meant to be cross-platform and buildable on most of >supported OS'es, even on older versions. I sincerely hate programs >that requires extremely latest versions of tools or libraries for them >to work, because these are usually hard to build. They want to self-compile the latest of your software but use several years old versions of everything else? I'd understand the Ubuntu use case but not the Debian oldstable one. If everyone develops like this, the software system grinds to a halt. Recursively, I mean. Just as a reminder for you regarding people of other systems: using C++11 excludes a lot of older compilers, e.g. MS VS6 or 7.1 or 8 or 9 ;-) OTOH, if you have a very specific target audience... >On Fri, Oct 16, 2015 at 11:56 AM, Hendrik Sattler > wrote: >> >> >> Am 16. Oktober 2015 11:29:48 MESZ, schrieb Petr Bena >: >>>I think you completely misunderstood me. I know I can install it on >my >>>machine, but I can hardly install it on PC's or servers of users who >>>use my program. >>> >>>I want to make it as easy as possible to let users compile my >program. >>>Having to install anything by hand instead of system package manager >>>is a big overhead to majority of users. CMake 3x is too new, it's >> >> >> Hey, 3.0.2 is even available in Debian stable, and that really says >something about older versions! >> >> >>>available by default almost nowhere, meaning this option is not >>>available to me at this time. Maybe in few years the situation will >>>change, but for now I will resort to that hack which works on older >>>versions that are generally available everywhere. >>> >>>On Fri, Oct 16, 2015 at 11:26 AM, Pau Garcia i Quiles >>> wrote: >>>> Hello, >>>> >>>> CMake 3.3.1 is available from my PPA, in case it helps: >>>> >>>> https://launchpad.net/~pgquiles/+archive/ubuntu/ppa >>>> >>>> >>>> >>>> On Fri, Oct 16, 2015 at 10:58 AM, Petr Bena >>>wrote: >>>>> >>>>> If I did that nearly nobody would be able to compile my program as >>>>> cmake >= 3.1 is extremely rare on most distributions. Even >ubuntu's >>>>> PPA builder has some ancient version. >>>>> >>>>> On Fri, Oct 16, 2015 at 9:44 AM, Petr Kmoch >>>wrote: >>>>> > Hi Petr. >>>>> > >>>>> > You're using a feature (`CMAKE_CXX_STANDARD`) introduced in >CMake >>>>> > version >>>>> > 3.1, so you should require a minimum version >= that. >>>>> > >>>>> > You can learn the version of CMake by running `cmake --version` >>>>> > >>>>> > Petr >>>>> > >>>>> > On Thu, Oct 15, 2015 at 5:45 PM, Petr Bena >>>wrote: >>>>> >> >>>>> >> What do you mean by "target" property? I don't see any target >>>>> >> mentioned there. I don't have this line in there. I don't know >>>which >>>>> >> CMake this is, it failed on server we use for unit tests, but I >>>have >>>>> >> required min. version set to 2.8.7 >>>>> >> >>>>> >> >>>>> >> >>>>> >> On Thu, Oct 15, 2015 at 5:41 PM, Matthew S Wallace >>>>> >> wrote: >>>>> >> > What version of CMake are you using? I?m using 3.3.2. The >>>only >>>>> >> > other >>>>> >> > thing I did was: >>>>> >> > >>>>> >> > set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) >>>>> >> > >>>>> >> > I?m guessing this probably does nothing since it is probably >a >>>target >>>>> >> > property. >>>>> >> > >>>>> >> > -Matt >>>>> >> > >>>>> >> >> On Oct 15, 2015, at 10:34 AM, Petr Bena >>>wrote: >>>>> >> >> >>>>> >> >> Can you elaborate on it a bit? >>>>> >> >> >>>>> >> >> I put set(CMAKE_CXX_STANDARD 11) as first line of my >>>CMakeLists and >>>>> >> >> it >>>>> >> >> still doesn't work, without the hack I used I get errors >while >>>>> >> >> compiling. >>>>> >> >> >>>>> >> >> Can you give me example file in which it works? I guess >there >>>is >>>>> >> >> more >>>>> >> >> needed for it to work. >>>>> >> >> >>>>> >> >> On Tue, Oct 13, 2015 at 7:12 PM, Matthew S Wallace >>>>> >> >> wrote: >>>>> >> >>> Thanks, setting the global variable solved my issue. >>>>> >> >>> >>>>> >> >>> -Matt >>>>> >> >>> >>>>> >> >>>> On Oct 13, 2015, at 10:46 AM, Johannes Zarl-Zierl >>>>> >> >>>> wrote: >>>>> >> >>>> >>>>> >> >>>> Hi, >>>>> >> >>>> >>>>> >> >>>> CXX_STANDARD is a target property, not a global one. You >can >>>>> >> >>>> either >>>>> >> >>>> set >>>>> >> >>>> CXX_STANDARD for every target that needs it, or set it >>>globally by >>>>> >> >>>> changing >>>>> >> >>>> the default value. >>>>> >> >>>> >>>>> >> >>>> You can do the latter by setting the variable >>>CMAKE_CXX_STANDARD >>>>> >> >>>> before >>>>> >> >>>> defining any target that depends on it: >>>>> >> >>>> >>>>> >> >>>> set(CMAKE_CXX_STANDARD 11) >>>>> >> >>>> >>>>> >> >>>> HTH, >>>>> >> >>>> Johannes >>>>> >> >>>> >>>>> >> >>>> On Tuesday 13 October 2015 10:22:36 Matthew S Wallace >wrote: >>>>> >> >>>>> I have the following two lines in my CMakeLists.txt >>>>> >> >>>>> >>>>> >> >>>>> set_property(GLOBAL PROPERTY CXX_STANDARD 11) >>>>> >> >>>>> set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) >>>>> >> >>>>> >>>>> >> >>>>> However when compiling some of my source files, the >>>-std=c++11 >>>>> >> >>>>> flag >>>>> >> >>>>> is not >>>>> >> >>>>> added. >>>>> >> >>>>> >>>>> >> >>>>> Just for good measure I added: >>>>> >> >>>>> target_compile_features(my_target PRIVATE >cxx_strong_enums) >>>to >>>>> >> >>>>> the >>>>> >> >>>>> target >>>>> >> >>>>> that was having the problem. >>>>> >> >>>>> >>>>> >> >>>>> Not sure if it matters, but in this case the compile >error >>>I?m >>>>> >> >>>>> getting is >>>>> >> >>>>> complaining because I?m referencing a fully scoped enum. >>>If I >>>>> >> >>>>> explicitly >>>>> >> >>>>> include -std=c++11 in my compile flags, everything works. >>>>> >> >>>>> >>>>> >> >>>>> I?m thinking I?m probably just misunderstanding how >>>CXX_STANDARD >>>>> >> >>>>> works, but >>>>> >> >>>>> any help would be appreciated. >>>>> >> >>>>> >>>>> >> >>>>> -Matt >>>>> >> >>>> >>>>> >> >>>> -- >>>>> >> >>>> >>>>> >> >>>> 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 >>>>> >> > >>>>> >> -- >>>>> >> >>>>> >> 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 >>>> >>>> >>>> >>>> >>>> -- >>>> Pau Garcia i Quiles >>>> http://www.elpauer.org >>>> (Due to my workload, I may need 10 days to answer) >>>-- >>> >>>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 >-- > >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 roman.wueger at gmx.at Fri Oct 16 15:21:00 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Fri, 16 Oct 2015 21:21:00 +0200 Subject: [CMake] C++11 flag not being added In-Reply-To: <88016538-C0E4-4F4D-BD1A-D4208B6F0EC5@hendrik-sattler.de> References: <65672189.Iur57BMnAA@ersa> <086D546E-6369-47A2-82B1-3830D1F785AC@ccmtrading.com> <1141001C-A186-4837-AC63-97C1E6FF3ECF@ccmtrading.com> <25FB9206-F66F-4FAA-B6AF-4C40FD6235AB@hendrik-sattler.de> <88016538-C0E4-4F4D-BD1A-D4208B6F0EC5@hendrik-sattler.de> Message-ID: <53694B58-2AED-4DF3-BFF9-9C63596F93EB@gmx.at> You can use CMake 3.x on older systems. Write platform checks for specific C++11 features and implement "old" style code if the C++11 features (e.g. lambdas) are not available. Use https://cmake.org/cmake/help/v3.1/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html and https://cmake.org/cmake/help/v3.1/module/WriteCompilerDetectionHeader.html?highlight=compiler%20detection%20header#module:WriteCompilerDetectionHeader to detect if your compiler supports your implementation. Best Regards > Am 16.10.2015 um 14:09 schrieb Hendrik Sattler : > > > > Am 16. Oktober 2015 13:38:27 MESZ, schrieb Petr Bena : >> By stable you mean Jessie that was recently released and is almost >> nowhere in production yet? :) >> >> On my debian server: >> >> $ cmake --version >> cmake version 2.8.9 >> >> On one of wikimedia's ubuntu servers (the newer ones): >> >> $ cmake --version >> cmake version 2.8.12.2 >> >> On travis-ci cmake is about 2.8.7 and on ubuntu PPA builder it's >> probably same. >> >> And we aren't even talking about 3.0, but 3.1 or newer. One would need >> to be truly naive to expect newer version on some stable production >> systems, that usually run well established older software (eg. >> majority of them do). >> >> On my dev PC I have last CMake of course, but I need to be able to >> compile on other systems as well :) >> >> This code is meant to be cross-platform and buildable on most of >> supported OS'es, even on older versions. I sincerely hate programs >> that requires extremely latest versions of tools or libraries for them >> to work, because these are usually hard to build. > > They want to self-compile the latest of your software but use several years old versions of everything else? > I'd understand the Ubuntu use case but not the Debian oldstable one. > > If everyone develops like this, the software system grinds to a halt. Recursively, I mean. > > Just as a reminder for you regarding people of other systems: using C++11 excludes a lot of older compilers, e.g. MS VS6 or 7.1 or 8 or 9 ;-) > > OTOH, if you have a very specific target audience... > >> On Fri, Oct 16, 2015 at 11:56 AM, Hendrik Sattler >> wrote: >>> >>> >>> Am 16. Oktober 2015 11:29:48 MESZ, schrieb Petr Bena >> : >>>> I think you completely misunderstood me. I know I can install it on >> my >>>> machine, but I can hardly install it on PC's or servers of users who >>>> use my program. >>>> >>>> I want to make it as easy as possible to let users compile my >> program. >>>> Having to install anything by hand instead of system package manager >>>> is a big overhead to majority of users. CMake 3x is too new, it's >>> >>> >>> Hey, 3.0.2 is even available in Debian stable, and that really says >> something about older versions! >>> >>> >>>> available by default almost nowhere, meaning this option is not >>>> available to me at this time. Maybe in few years the situation will >>>> change, but for now I will resort to that hack which works on older >>>> versions that are generally available everywhere. >>>> >>>> On Fri, Oct 16, 2015 at 11:26 AM, Pau Garcia i Quiles >>>> wrote: >>>>> Hello, >>>>> >>>>> CMake 3.3.1 is available from my PPA, in case it helps: >>>>> >>>>> https://launchpad.net/~pgquiles/+archive/ubuntu/ppa >>>>> >>>>> >>>>> >>>>> On Fri, Oct 16, 2015 at 10:58 AM, Petr Bena >>>> wrote: >>>>>> >>>>>> If I did that nearly nobody would be able to compile my program as >>>>>> cmake >= 3.1 is extremely rare on most distributions. Even >> ubuntu's >>>>>> PPA builder has some ancient version. >>>>>> >>>>>> On Fri, Oct 16, 2015 at 9:44 AM, Petr Kmoch >>>> wrote: >>>>>>> Hi Petr. >>>>>>> >>>>>>> You're using a feature (`CMAKE_CXX_STANDARD`) introduced in >> CMake >>>>>>> version >>>>>>> 3.1, so you should require a minimum version >= that. >>>>>>> >>>>>>> You can learn the version of CMake by running `cmake --version` >>>>>>> >>>>>>> Petr >>>>>>> >>>>>>> On Thu, Oct 15, 2015 at 5:45 PM, Petr Bena >>>> wrote: >>>>>>>> >>>>>>>> What do you mean by "target" property? I don't see any target >>>>>>>> mentioned there. I don't have this line in there. I don't know >>>> which >>>>>>>> CMake this is, it failed on server we use for unit tests, but I >>>> have >>>>>>>> required min. version set to 2.8.7 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Oct 15, 2015 at 5:41 PM, Matthew S Wallace >>>>>>>> wrote: >>>>>>>>> What version of CMake are you using? I?m using 3.3.2. The >>>> only >>>>>>>>> other >>>>>>>>> thing I did was: >>>>>>>>> >>>>>>>>> set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) >>>>>>>>> >>>>>>>>> I?m guessing this probably does nothing since it is probably >> a >>>> target >>>>>>>>> property. >>>>>>>>> >>>>>>>>> -Matt >>>>>>>>> >>>>>>>>>> On Oct 15, 2015, at 10:34 AM, Petr Bena >>>> wrote: >>>>>>>>>> >>>>>>>>>> Can you elaborate on it a bit? >>>>>>>>>> >>>>>>>>>> I put set(CMAKE_CXX_STANDARD 11) as first line of my >>>> CMakeLists and >>>>>>>>>> it >>>>>>>>>> still doesn't work, without the hack I used I get errors >> while >>>>>>>>>> compiling. >>>>>>>>>> >>>>>>>>>> Can you give me example file in which it works? I guess >> there >>>> is >>>>>>>>>> more >>>>>>>>>> needed for it to work. >>>>>>>>>> >>>>>>>>>> On Tue, Oct 13, 2015 at 7:12 PM, Matthew S Wallace >>>>>>>>>> wrote: >>>>>>>>>>> Thanks, setting the global variable solved my issue. >>>>>>>>>>> >>>>>>>>>>> -Matt >>>>>>>>>>> >>>>>>>>>>>> On Oct 13, 2015, at 10:46 AM, Johannes Zarl-Zierl >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> CXX_STANDARD is a target property, not a global one. You >> can >>>>>>>>>>>> either >>>>>>>>>>>> set >>>>>>>>>>>> CXX_STANDARD for every target that needs it, or set it >>>> globally by >>>>>>>>>>>> changing >>>>>>>>>>>> the default value. >>>>>>>>>>>> >>>>>>>>>>>> You can do the latter by setting the variable >>>> CMAKE_CXX_STANDARD >>>>>>>>>>>> before >>>>>>>>>>>> defining any target that depends on it: >>>>>>>>>>>> >>>>>>>>>>>> set(CMAKE_CXX_STANDARD 11) >>>>>>>>>>>> >>>>>>>>>>>> HTH, >>>>>>>>>>>> Johannes >>>>>>>>>>>> >>>>>>>>>>>> On Tuesday 13 October 2015 10:22:36 Matthew S Wallace >> wrote: >>>>>>>>>>>>> I have the following two lines in my CMakeLists.txt >>>>>>>>>>>>> >>>>>>>>>>>>> set_property(GLOBAL PROPERTY CXX_STANDARD 11) >>>>>>>>>>>>> set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) >>>>>>>>>>>>> >>>>>>>>>>>>> However when compiling some of my source files, the >>>> -std=c++11 >>>>>>>>>>>>> flag >>>>>>>>>>>>> is not >>>>>>>>>>>>> added. >>>>>>>>>>>>> >>>>>>>>>>>>> Just for good measure I added: >>>>>>>>>>>>> target_compile_features(my_target PRIVATE >> cxx_strong_enums) >>>> to >>>>>>>>>>>>> the >>>>>>>>>>>>> target >>>>>>>>>>>>> that was having the problem. >>>>>>>>>>>>> >>>>>>>>>>>>> Not sure if it matters, but in this case the compile >> error >>>> I?m >>>>>>>>>>>>> getting is >>>>>>>>>>>>> complaining because I?m referencing a fully scoped enum. >>>> If I >>>>>>>>>>>>> explicitly >>>>>>>>>>>>> include -std=c++11 in my compile flags, everything works. >>>>>>>>>>>>> >>>>>>>>>>>>> I?m thinking I?m probably just misunderstanding how >>>> CXX_STANDARD >>>>>>>>>>>>> works, but >>>>>>>>>>>>> any help would be appreciated. >>>>>>>>>>>>> >>>>>>>>>>>>> -Matt >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> 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 >>>>>>>> -- >>>>>>>> >>>>>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Pau Garcia i Quiles >>>>> http://www.elpauer.org >>>>> (Due to my workload, I may need 10 days to answer) >>>> -- >>>> >>>> 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 >> -- >> >> 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 From zbergquist99 at gmail.com Fri Oct 16 16:56:34 2015 From: zbergquist99 at gmail.com (Zac Bergquist) Date: Fri, 16 Oct 2015 16:56:34 -0400 Subject: [CMake] Creating relocatable packages In-Reply-To: References: Message-ID: I've created a sample project to replicate my issue in hopes that it would make it easier to troubleshoot. Thanks for any help, Zac https://github.com/zmb3/cmaketest On Mon, Oct 12, 2015 at 8:53 AM, Zac Bergquist wrote: > Hello, > > I'm trying to fix a project so that its output is relocatable. The > project is a library that itself depends on libpcap. My goal is to be able > to import the library into my CMake application and have CMake > automatically link libpcap with it. > > I'm using a toolchain file that invokes an ARM cross compiler, sets > CMAKE_INSTALL_PREFIX and appends it to CMAKE_FIND_ROOT_PATH. This all > seems to work well. > > What I'm seeing is that the exported files that get installed to > CMAKE_INSTALL_PREFIX contain absolute paths to libpcap on my machine, which > make them useless to other team members. > > The first thing I changed was to use CONFIGURE_PACKAGE_CONFIG_FILE instead > of CONFIGURE_FILE. This got rid of absolute paths in the generated CMake > config file. > > However, I still have absolute paths in the CMake target import file that > gets generated. The IMPORTED_LINK_INTERFACE_LIBRARIES target property has > an absolute path instead of one relative to CMAKE_INSTALL_PREFIX. > > I've read the "Creating Relocatable Packages" [1] section of the CMake > packages documentation. I'm pretty sure this is what I'm running into, but > I don't quite understand how to solve it. The documentation says that I > should be using imported targets, but I'm not sure how to do so. The > library is just using its own FindPCAP.cmake file to locate libpcap. > > Does anyone know of an example of a CMake package that imports other > libraries? I could also try to create a minimal example project with this > setup if it would be helpful. > > Thanks, > Zac > > [1]: > https://cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html#creating-relocatable-packages > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dumont.guillaume at gmail.com Sat Oct 17 08:19:53 2015 From: dumont.guillaume at gmail.com (Guillaume Dumont) Date: Sat, 17 Oct 2015 08:19:53 -0400 Subject: [CMake] Creating relocatable packages In-Reply-To: References: Message-ID: What you are seeing is the expected behavior. You can get a relocatable package if all your dependencies (in your case libcap) have themselves relocatable package config files with exported targets. Then you package should make use of find_dependency macro. On Fri, Oct 16, 2015 at 4:56 PM, Zac Bergquist wrote: > I've created a sample project to replicate my issue in hopes that it would > make it easier to troubleshoot. > > Thanks for any help, > Zac > > https://github.com/zmb3/cmaketest > > On Mon, Oct 12, 2015 at 8:53 AM, Zac Bergquist > wrote: > >> Hello, >> >> I'm trying to fix a project so that its output is relocatable. The >> project is a library that itself depends on libpcap. My goal is to be able >> to import the library into my CMake application and have CMake >> automatically link libpcap with it. >> >> I'm using a toolchain file that invokes an ARM cross compiler, sets >> CMAKE_INSTALL_PREFIX and appends it to CMAKE_FIND_ROOT_PATH. This all >> seems to work well. >> >> What I'm seeing is that the exported files that get installed to >> CMAKE_INSTALL_PREFIX contain absolute paths to libpcap on my machine, which >> make them useless to other team members. >> >> The first thing I changed was to use CONFIGURE_PACKAGE_CONFIG_FILE >> instead of CONFIGURE_FILE. This got rid of absolute paths in the generated >> CMake config file. >> >> However, I still have absolute paths in the CMake target import file that >> gets generated. The IMPORTED_LINK_INTERFACE_LIBRARIES target property has >> an absolute path instead of one relative to CMAKE_INSTALL_PREFIX. >> >> I've read the "Creating Relocatable Packages" [1] section of the CMake >> packages documentation. I'm pretty sure this is what I'm running into, but >> I don't quite understand how to solve it. The documentation says that I >> should be using imported targets, but I'm not sure how to do so. The >> library is just using its own FindPCAP.cmake file to locate libpcap. >> >> Does anyone know of an example of a CMake package that imports other >> libraries? I could also try to create a minimal example project with this >> setup if it would be helpful. >> >> Thanks, >> Zac >> >> [1]: >> https://cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html#creating-relocatable-packages >> >> > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Guillaume Dumont ========================= dumont.guillaume at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.jackson at bluequartz.net Sat Oct 17 12:28:10 2015 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Sat, 17 Oct 2015 12:28:10 -0400 Subject: [CMake] Known issues with Xcode 6.x and CMake Message-ID: Are there any known issues with Xcode 6.4 and CMake 3.3.x? I ask because in our project when we generate the Xcode project we end up with 2 or 3 executables listed in the drop down combo box. We also end up with lots of duplicate targets in the Xcode project. And the first time I open an Xcode project I have to click the ?autocreate schemes? button about 30 times (I counted). We have 127 targets in our project currently. Has anyone seen anything like this or have any comments? This is with Xcode 6.4 on OS X 10.10.5. Thanks -- Mike Jackson [mike.jackson at bluequartz.net] From gurenchan at gmail.com Sun Oct 18 17:58:45 2015 From: gurenchan at gmail.com (Owen Alanzo Hogarth) Date: Mon, 19 Oct 2015 05:58:45 +0800 Subject: [CMake] getting paths of header files Message-ID: I am having some trouble with my cmake build. I recently redesigned the physical layout of my files so that it'll be a bit easier to maintain in the long run. I have my project structure setup like this. MAIN_PROJECT/ project/main.c # this is the executable resources/... # a folder filled with resources source/ source/moduleA/moduleA.h #includes all headers for this module #a user would just import moduleA.h source/moduleA/headers/header1.h header2.h source/moduleA/src/source1.c source2.c source/moduleA/common/common_structs.h #holds common structs for #all src files in this module with my project re-organized like this and try to build my shared libraries I get no output. For example main cmakelists.txt file PROJECT(project) CMAKE_MINIMUM_REQUIRED(VERSION 2.8) 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) ADD_SUBDIRECTORY(source) FILE(COPY ${CMAKE_CURRENT_SOURCE_DIR}/resources/ DESTINATION ${CMAKE_CURRENT_BINARY_DIR}/bin/resources/) this is one module within the source folder, a matrix4 PROJECT(matrix4_scalar) INCLUDE_DIRECTORIES("${CMAKE_CURRENT_SOURCE_DIR}/../common") INCLUDE_DIRECTORIES("${CMAKE_CURRENT_SOURCE_DIR}/../vector3_scalar/headers/vector3_scalar.h") SET(HEADER_FILES "${CMAKE_CURRENT_SOURCE_DIR}/../common/common_structs.h" "${CMAKE_CURRENT_SOURCE_DIR}/../vector3_scalar/headers/vector3_scalar.h") SET(SRC_FILES src/matrix4_scalar.c ${HEADER_FILES}) ADD_LIBRARY(matrix4_scalar SHARED ${SRC_FILES}) TARGET_LINK_LIBRARIES(matrix4_scalar vector3_scalar) The vector3 class is built in a similar way but has no outside dependencies except for the common_struct.h header file. This matrix class depends on the vector3 class so I have it as a target link library. When I build like this I get no output to my lib directories and I am not sure what's going on. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamesbigler at gmail.com Mon Oct 19 00:03:25 2015 From: jamesbigler at gmail.com (James Bigler) Date: Sun, 18 Oct 2015 22:03:25 -0600 Subject: [CMake] cmake_check_build_system is causing a rebuild at "make install" In-Reply-To: <561E52C5.4090400@gmail.com> References: <561D9B6B.9000207@txcorp.com> <561E4E55.8010606@gmail.com> <561E4FC4.10904@txcorp.com> <561E52C5.4090400@gmail.com> Message-ID: This could be caused by CUDA generating dependencies and then needing to load them at the next configure step. For our automated builds, where we don't rely on dependencies during development (e.g. build one main target from scratch then throw it away), we set the CMAKE_SUPPRESS_REGENERATION option to TRUE. This will prevent CMake from configuring during the build. You can still configure manually by running cmake. James On Wed, Oct 14, 2015 at 7:04 AM, Nils Gladitz wrote: > On 14.10.2015 14:51, JR Cary wrote: > >> Thanks for your response. This is a big headache for us, as it slows down >> our builds tremendously. >> >> Is there any way to prevent or control this behavior? >> > > I don't see how. You could modify the module itself I suppose but I'd > expect that to break incremental builds. > > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurenchan at gmail.com Mon Oct 19 02:18:39 2015 From: gurenchan at gmail.com (Owen Alanzo Hogarth) Date: Mon, 19 Oct 2015 14:18:39 +0800 Subject: [CMake] getting paths of header files In-Reply-To: References: Message-ID: Some additional info. Here is my cmakelists.txt for the vector3_scalar module: PROJECT(vector3_scalar) SET(CMAKE_MACOSX_RPATH 1) INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR}/../common) SET(HEADER_FILES ${CMAKE_CURRENT_SOURCE_DIR}/../common/common_structs.h) SET(SRC_FILES ${CMAKE_CURRENT_SOURCE_DIR}/src/vector3_scalar.c ${HEADER_FILES}) ADD_LIBRARY(vector3_scalar SHARED ${SRC_FILES}) now my cmakelists.txt for my matrix4_scalar module. This one depends on vector3_scalar PROJECT(matrix4_scalar) SET(CMAKE_MACOSX_RPATH 1) INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR}/../common ${CMAKE_CURRENT_SOURCE_DIR}/../vector3_scalar ${CMAKE_CURRENT_SOURCE_DIR}/../vector3_scalar/headers) SET(HEADER_FILES ${CMAKE_CURRENT_SOURCE_DIR}/../common/common_structs.h ${CMAKE_CURRENT_SOURCE_DIR}/../vector3_scalar/headers/vector3_scalar.h ${CMAKE_CURRENT_SOURCE_DIR}/headers/matrix4_scalar.h) SET(SRC_FILES ${CMAKE_CURRENT_SOURCE_DIR}/src/matrix4_scalar.c ${HEADER_FILES}) ADD_LIBRARY(matrix4_scalar SHARED ${SRC_FILES}) TARGET_LINK_LIBRARIES(matrix4_scalar vector3_scalar) I am having trouble because when running cmake I get this error that says no rule to make target Scanning dependencies of target vector3_scalar [ 25%] Building C object source/core_math/vector3_scalar/CMakeFiles/vector3_scalar.dir/sr c/vector3_scalar.c.o [ 50%] Linking C shared library $(CMAKE_BINARY_DIR)/lib/libvector3_scalar.dylib [ 50%] Built target vector3_scalar Scanning dependencies of target matrix4_scalar [ 75%] Building C object source/core_math/matrix4_scalar/CMakeFiles/matrix4_scalar.dir/sr c/matrix4_scalar.c.o make[2]: *** No rule to make target `source/core_math/vector3_scalar//Users/blubee/SDL/pr oject/build/lib/libvector3_scalar.dylib', needed by `source/core_math/matrix4_scalar//Use rs/blubee/SDL/project/build/lib/libmatrix4_scalar.dylib'. Stop. make[1]: *** [source/core_math/matrix4_scalar/CMakeFiles/matrix4_scalar.dir/all] Error 2 make: *** [all] Error 2 On Mon, Oct 19, 2015 at 5:58 AM, Owen Alanzo Hogarth wrote: > I am having some trouble with my cmake build. I recently redesigned the > physical layout of my files so that it'll be a bit easier to maintain in > the long run. > > I have my project structure setup like this. > > MAIN_PROJECT/ > project/main.c # this is the executable > resources/... # a folder filled with resources > source/ > source/moduleA/moduleA.h #includes all headers for this module > #a user would just import > moduleA.h > > source/moduleA/headers/header1.h header2.h > source/moduleA/src/source1.c source2.c > source/moduleA/common/common_structs.h #holds common structs for > > #all src files in this module > > > with my project re-organized like this and try to build my shared > libraries I get no output. > > For example main cmakelists.txt file > > PROJECT(project) > CMAKE_MINIMUM_REQUIRED(VERSION 2.8) > > 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) > > ADD_SUBDIRECTORY(source) > > FILE(COPY ${CMAKE_CURRENT_SOURCE_DIR}/resources/ DESTINATION > ${CMAKE_CURRENT_BINARY_DIR}/bin/resources/) > > this is one module within the source folder, a matrix4 > > PROJECT(matrix4_scalar) > > INCLUDE_DIRECTORIES("${CMAKE_CURRENT_SOURCE_DIR}/../common") > > INCLUDE_DIRECTORIES("${CMAKE_CURRENT_SOURCE_DIR}/../vector3_scalar/headers/vector3_scalar.h") > > SET(HEADER_FILES "${CMAKE_CURRENT_SOURCE_DIR}/../common/common_structs.h" > "${CMAKE_CURRENT_SOURCE_DIR}/../vector3_scalar/headers/vector3_scalar.h") > > > SET(SRC_FILES src/matrix4_scalar.c ${HEADER_FILES}) > > ADD_LIBRARY(matrix4_scalar SHARED ${SRC_FILES}) > > TARGET_LINK_LIBRARIES(matrix4_scalar vector3_scalar) > > > > The vector3 class is built in a similar way but has no outside > dependencies except for the common_struct.h header file. > > This matrix class depends on the vector3 class so I have it as a target > link library. > > When I build like this I get no output to my lib directories and I am not > sure what's going on. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsvanbethlehem at gmail.com Mon Oct 19 02:34:27 2015 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Mon, 19 Oct 2015 08:34:27 +0200 Subject: [CMake] getting paths of header files In-Reply-To: References: Message-ID: Hej, A quick glance doesn't show anything out of the ordinary, except that * I'd prevent any use of `..` in your folder references (by using things like $ and $ * I think it is more or less standard practice now to _not_ use 'include_directories', but instead use target_include_directories() * you' On Sun, Oct 18, 2015 at 11:58 PM, Owen Alanzo Hogarth wrote: > I am having some trouble with my cmake build. I recently redesigned the > physical layout of my files so that it'll be a bit easier to maintain in > the long run. > > I have my project structure setup like this. > > MAIN_PROJECT/ > project/main.c # this is the executable > resources/... # a folder filled with resources > source/ > source/moduleA/moduleA.h #includes all headers for this module > #a user would just import > moduleA.h > > source/moduleA/headers/header1.h header2.h > source/moduleA/src/source1.c source2.c > source/moduleA/common/common_structs.h #holds common structs for > > #all src files in this module > > > with my project re-organized like this and try to build my shared > libraries I get no output. > > For example main cmakelists.txt file > > PROJECT(project) > CMAKE_MINIMUM_REQUIRED(VERSION 2.8) > > 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) > > ADD_SUBDIRECTORY(source) > > FILE(COPY ${CMAKE_CURRENT_SOURCE_DIR}/resources/ DESTINATION > ${CMAKE_CURRENT_BINARY_DIR}/bin/resources/) > > this is one module within the source folder, a matrix4 > > PROJECT(matrix4_scalar) > > INCLUDE_DIRECTORIES("${CMAKE_CURRENT_SOURCE_DIR}/../common") > > INCLUDE_DIRECTORIES("${CMAKE_CURRENT_SOURCE_DIR}/../vector3_scalar/headers/vector3_scalar.h") > > SET(HEADER_FILES "${CMAKE_CURRENT_SOURCE_DIR}/../common/common_structs.h" > "${CMAKE_CURRENT_SOURCE_DIR}/../vector3_scalar/headers/vector3_scalar.h") > > > SET(SRC_FILES src/matrix4_scalar.c ${HEADER_FILES}) > > ADD_LIBRARY(matrix4_scalar SHARED ${SRC_FILES}) > > TARGET_LINK_LIBRARIES(matrix4_scalar vector3_scalar) > > > > The vector3 class is built in a similar way but has no outside > dependencies except for the common_struct.h header file. > > This matrix class depends on the vector3 class so I have it as a target > link library. > > When I build like this I get no output to my lib directories and I am not > sure what's going on. > > -- > > 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 Mon Oct 19 02:37:42 2015 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Mon, 19 Oct 2015 08:37:42 +0200 Subject: [CMake] getting paths of header files In-Reply-To: References: Message-ID: Damn..... send the unfinished message, I'll repeat what I had, and type the rest: Hej, A quick glance doesn't show anything out of the ordinary, except that * I'd prevent any use of `..` in your folder references (by using things like $ and $ * I think it is more or less standard practice now to _not_ use 'include_directories', but instead use target_include_directories() * you do add_subdirectory(source), but don't show the lists-file in that folder, which may cause the problem you're seeing The first thing I see that seems really wrong though, is that you type the 'project()' command twice. AFAIK you're supposed to use this command exactly once, to set the properties of the entire project. Using it multiple times causes undefined behaviour, and may very well be the cause for what you're seeing Sincerely, Jakob On Mon, Oct 19, 2015 at 8:34 AM, Jakob van Bethlehem < jsvanbethlehem at gmail.com> wrote: > Hej, > > A quick glance doesn't show anything out of the ordinary, except that > * I'd prevent any use of `..` in your folder references (by using things > like $ and > $ > * I think it is more or less standard practice now to _not_ use > 'include_directories', but instead use target_include_directories() > * you' > > On Sun, Oct 18, 2015 at 11:58 PM, Owen Alanzo Hogarth > wrote: > >> I am having some trouble with my cmake build. I recently redesigned the >> physical layout of my files so that it'll be a bit easier to maintain in >> the long run. >> >> I have my project structure setup like this. >> >> MAIN_PROJECT/ >> project/main.c # this is the executable >> resources/... # a folder filled with resources >> source/ >> source/moduleA/moduleA.h #includes all headers for this module >> #a user would just import >> moduleA.h >> >> source/moduleA/headers/header1.h header2.h >> source/moduleA/src/source1.c source2.c >> source/moduleA/common/common_structs.h #holds common structs for >> >> #all src files in this module >> >> >> with my project re-organized like this and try to build my shared >> libraries I get no output. >> >> For example main cmakelists.txt file >> >> PROJECT(project) >> CMAKE_MINIMUM_REQUIRED(VERSION 2.8) >> >> 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) >> >> ADD_SUBDIRECTORY(source) >> >> FILE(COPY ${CMAKE_CURRENT_SOURCE_DIR}/resources/ DESTINATION >> ${CMAKE_CURRENT_BINARY_DIR}/bin/resources/) >> >> this is one module within the source folder, a matrix4 >> >> PROJECT(matrix4_scalar) >> >> INCLUDE_DIRECTORIES("${CMAKE_CURRENT_SOURCE_DIR}/../common") >> >> INCLUDE_DIRECTORIES("${CMAKE_CURRENT_SOURCE_DIR}/../vector3_scalar/headers/vector3_scalar.h") >> >> SET(HEADER_FILES "${CMAKE_CURRENT_SOURCE_DIR}/../common/common_structs.h" >> "${CMAKE_CURRENT_SOURCE_DIR}/../vector3_scalar/headers/vector3_scalar.h") >> >> >> SET(SRC_FILES src/matrix4_scalar.c ${HEADER_FILES}) >> >> ADD_LIBRARY(matrix4_scalar SHARED ${SRC_FILES}) >> >> TARGET_LINK_LIBRARIES(matrix4_scalar vector3_scalar) >> >> >> >> The vector3 class is built in a similar way but has no outside >> dependencies except for the common_struct.h header file. >> >> This matrix class depends on the vector3 class so I have it as a target >> link library. >> >> When I build like this I get no output to my lib directories and I am not >> sure what's going on. >> >> -- >> >> 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 gurenchan at gmail.com Mon Oct 19 05:43:51 2015 From: gurenchan at gmail.com (Owen Alanzo Hogarth) Date: Mon, 19 Oct 2015 17:43:51 +0800 Subject: [CMake] linking hared libraries Message-ID: Hi guys Can I get some help with this question I have. I did a really thorough writeup here on SO: http://stackoverflow.com/questions/33209659/cmake-no-rule-to-make-target-for-internal-shared-library?noredirect=1#comment54224377_33209659 -------------- next part -------------- An HTML attachment was scrubbed... URL: From peterhull90 at gmail.com Mon Oct 19 06:01:53 2015 From: peterhull90 at gmail.com (Peter Hull) Date: Mon, 19 Oct 2015 10:01:53 +0000 Subject: [CMake] CMake on 64-bit Visual Studio Message-ID: I have been trying to compile the Allegro library (http://liballeg.org/) on Windows 64-bit using Visual Studio 2015. I am running into a problem where CMake 3.3.2 doesn't correctly locate the 64-bit version of gdiplus.lib. I've got a minimal example: ==== cmake_minimum_required(VERSION 3.3) find_library(GDIP gdiplus) ---- I am using the -A x64 flag to CMake to select a 64 bit build, but CMake still finds the 32-bit library in C:/Program Files (x86)/Windows Kits/8.1/Lib/winv6.3/um/x86/gdiplus.lib rather than the 64 bit version in C:/Program Files (x86)/Windows Kits/8.1/Lib/winv6.3/um/x64/gdiplus.lib I believe the path patterns that find_library uses do not match the paths that Microsoft has chosen to put the files into - for example if it was C:/Program Files (x86)/Windows Kits/8.1/winv6.3/um/Lib/x64/gdiplus.lib it could be made to work. Is there a way to get around this? Thanks, Peter (also posted on stackoverflow, http://stackoverflow.com/questions/33124745/cmake-finding-32bit-gdi-on-64-bit-platform) -------------- next part -------------- An HTML attachment was scrubbed... URL: From gjasny at googlemail.com Mon Oct 19 07:01:35 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Mon, 19 Oct 2015 13:01:35 +0200 Subject: [CMake] Known issues with Xcode 6.x and CMake In-Reply-To: References: Message-ID: <5624CD8F.60709@googlemail.com> Hello, On 17/10/15 18:28, Michael Jackson wrote: > Are there any known issues with Xcode 6.4 and CMake 3.3.x? I ask because in our project when we generate the Xcode project we end up with 2 or 3 executables listed in the drop down combo box. We also end up with lots of duplicate targets in the Xcode project. And the first time I open an Xcode project I have to click the ?autocreate schemes? button about 30 times (I counted). We have 127 targets in our project currently. > > Has anyone seen anything like this or have any comments? This is with Xcode 6.4 on OS X 10.10.5. We also have projects which trigger the "Autocreate?" dialog but so far I did not notice the behavior you described. Does this also happen after a complete re-configure with deleted build directory? Thanks, Gregor From sergey.nikulov at gmail.com Mon Oct 19 07:37:32 2015 From: sergey.nikulov at gmail.com (Sergei Nikulov) Date: Mon, 19 Oct 2015 14:37:32 +0300 Subject: [CMake] CMake on 64-bit Visual Studio In-Reply-To: References: Message-ID: 2015-10-19 13:01 GMT+03:00 Peter Hull : > > I have been trying to compile the Allegro library (http://liballeg.org/) on > Windows 64-bit using Visual Studio 2015. > I am running into a problem where CMake 3.3.2 doesn't correctly locate the > 64-bit version of gdiplus.lib. > > I've got a minimal example: > ==== > cmake_minimum_required(VERSION 3.3) > find_library(GDIP gdiplus) > ---- > I am using the -A x64 flag to CMake to select a 64 bit build, but CMake > still finds the 32-bit library in C:/Program Files (x86)/Windows > Kits/8.1/Lib/winv6.3/um/x86/gdiplus.lib rather than the 64 bit version in > C:/Program Files (x86)/Windows Kits/8.1/Lib/winv6.3/um/x64/gdiplus.lib > > I believe the path patterns that find_library uses do not match the paths > that Microsoft has chosen to put the files into - for example if it was > C:/Program Files (x86)/Windows Kits/8.1/winv6.3/um/Lib/x64/gdiplus.lib it > could be made to work. > > Is there a way to get around this? One idea, how I've created workaround it for odbc lib: Remove find_library(GDIPLUS_LIBRARY NAMES libgdiplus gdiplus) from here https://github.com/liballeg/allegro5/blob/5.1/cmake/FindGDIPLUS.cmake#L20 And set(GDIPLUS_LIBRARY gdiplus) or another proper name. Visual studio will pick it from proper path depending on target x86 or x86_64. > > Thanks, > Peter > > > (also posted on stackoverflow, > http://stackoverflow.com/questions/33124745/cmake-finding-32bit-gdi-on-64-bit-platform) > > -- > > 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 -- Best Regards, Sergei Nikulov From gurenchan at gmail.com Mon Oct 19 08:43:54 2015 From: gurenchan at gmail.com (Owen Alanzo Hogarth) Date: Mon, 19 Oct 2015 20:43:54 +0800 Subject: [CMake] linking hared libraries In-Reply-To: References: Message-ID: You made a few points that I have not seen before specifically using $ and $ Where are these commands, I just did a search and found a mailing list that said they will override include_directories but I haven't seen them before, especially in any of the tutorials that i've read on the cmake site. Also you said the PROJECT() should only be defined once, but shouldn't each cmakelists.txt contain a project() or else cmake complains at me. Hej, A quick glance doesn't show anything out of the ordinary, except that * I'd prevent any use of `..` in your folder references (by using things like $ and $ * I think it is more or less standard practice now to _not_ use 'include_directories', but instead use target_include_directories() * you do add_subdirectory(source), but don't show the lists-file in that folder, which may cause the problem you're seeing The first thing I see that seems really wrong though, is that you type the 'project()' command twice. AFAIK you're supposed to use this command exactly once, to set the properties of the entire project. Using it multiple times causes undefined behaviour, and may very well be the cause for what you're seeing Sincerely, Jakob On Mon, Oct 19, 2015 at 5:43 PM, Owen Alanzo Hogarth wrote: > Hi guys > > Can I get some help with this question I have. I did a really thorough > writeup here on SO: > http://stackoverflow.com/questions/33209659/cmake-no-rule-to-make-target-for-internal-shared-library?noredirect=1#comment54224377_33209659 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurenchan at gmail.com Mon Oct 19 09:05:57 2015 From: gurenchan at gmail.com (Owen Alanzo Hogarth) Date: Mon, 19 Oct 2015 21:05:57 +0800 Subject: [CMake] linking hared libraries In-Reply-To: References: Message-ID: also one more question. I have a few header only files one in common/common_structs.h and core_math/core_math.h These files aren't compiled anywhere, they are just used as header only files that I will eventually use to link in different versions of the matrix and vector classes. For example I can have scalar math modules, sse math modules or neon math modules. Depending on compiler flags those header files will compile and include different versions, without changing the public interface. How can I handle that? I still cannot find much information on using these constructs in my cmake files. $ On Mon, Oct 19, 2015 at 8:43 PM, Owen Alanzo Hogarth wrote: > You made a few points that I have not seen before specifically using $ and > > $ > > > Where are these commands, I just did a search and found a mailing list that said they will override include_directories but I haven't seen them before, especially in any of the tutorials that i've read on the cmake site. > > > Also you said the PROJECT() should only be defined once, but shouldn't each cmakelists.txt contain a project() or else cmake complains at me. > > > Hej, > > A quick glance doesn't show anything out of the ordinary, except that > * I'd prevent any use of `..` in your folder references (by using things > like $ and > $ > * I think it is more or less standard practice now to _not_ use > 'include_directories', but instead use target_include_directories() > * you do add_subdirectory(source), but don't show the lists-file in that > folder, which may cause the problem you're seeing > > The first thing I see that seems really wrong though, is that you type the > 'project()' command twice. AFAIK you're supposed to use this command > exactly once, to set the properties of the entire project. Using it > multiple times causes undefined behaviour, and may very well be the cause > for what you're seeing > > Sincerely, > Jakob > > > On Mon, Oct 19, 2015 at 5:43 PM, Owen Alanzo Hogarth > wrote: > >> Hi guys >> >> Can I get some help with this question I have. I did a really thorough >> writeup here on SO: >> http://stackoverflow.com/questions/33209659/cmake-no-rule-to-make-target-for-internal-shared-library?noredirect=1#comment54224377_33209659 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwan.work at gmail.com Mon Oct 19 09:48:38 2015 From: rwan.work at gmail.com (Raymond Wan) Date: Mon, 19 Oct 2015 21:48:38 +0800 Subject: [CMake] linking hared libraries In-Reply-To: References: Message-ID: Hi Owen, On Mon, Oct 19, 2015 at 8:43 PM, Owen Alanzo Hogarth wrote: > Also you said the PROJECT() should only be defined once, but shouldn't each > cmakelists.txt contain a project() or else cmake complains at me. According to the last paragraph of: https://cmake.org/cmake/help/v3.0/command/project.html you only need a PROJECT () in the top-level CMakeLists.txt... Ray From gurenchan at gmail.com Mon Oct 19 10:02:16 2015 From: gurenchan at gmail.com (Owen Alanzo Hogarth) Date: Mon, 19 Oct 2015 22:02:16 +0800 Subject: [CMake] linking hared libraries In-Reply-To: References: Message-ID: Ray Thanks, removing them from the sub projects didn't cause any issues, although I am still having the issue with either a no rule to make target error or if I remove the header I get a linking error: http://stackoverflow.com/questions/33209659/cmake-no-rule-to-make-target-for-internal-shared-library?noredirect=1#comment54229598_33209659 On Mon, Oct 19, 2015 at 9:48 PM, Raymond Wan wrote: > Hi Owen, > > > On Mon, Oct 19, 2015 at 8:43 PM, Owen Alanzo Hogarth > wrote: > > Also you said the PROJECT() should only be defined once, but shouldn't > each > > cmakelists.txt contain a project() or else cmake complains at me. > > > According to the last paragraph of: > > https://cmake.org/cmake/help/v3.0/command/project.html > > you only need a PROJECT () in the top-level CMakeLists.txt... > > Ray > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pascal.bach at siemens.com Mon Oct 19 10:11:57 2015 From: pascal.bach at siemens.com (Pascal Bach) Date: Mon, 19 Oct 2015 16:11:57 +0200 Subject: [CMake] providing host binary and target library cmake-package when cross compiling Message-ID: <5624FA2D.2070105@siemens.com> Hello I'm working on CMake support for Apache Thrift [1]. It is currently already buildable using CMake. However while trying to add support for generating a ThriftConfig.cmake I ran into some issues related to cross compilation. Thrift has the following components relevant to the problem: C++ library (.so library) Thrift compiler (binary) End users/developers usually us thrift in the following way: Thrift IDL ==[Thrift compiler]==> C++ files ==[GCC + Link with thrift.so]==> final.so My idea for the resulting ThriftConfig.cmake was to provide two imported targets Thrift::libthrift and Thrift::compiler. Thrift::compiler can be used to generate C++ files from Thrift IDLs and Thrift::libthrift is what the resulting binary should link against. This works well if no cross compilation is involved. Now for the cross compilation case. I'm using OpenEmbedded [2] which provides two sysroot directories: 1. sysroot_x86 containing binaries and libraries for the host: libthrift.so (x86 library), thrift (x86 executable) 2. sysroot_arm containing binaries and libraries for the target: libthrift.so (arm library), thrift (arm executable) In the cross compiling case the Thrift::compiler target must be executable on the HOST and Thrift::libthrift must be a target library. This means the library should be from sysroot_arm but the binary from sysroot_x86. I'm not able express this an a good way. Does anyone know how to do this? Is there an example how this could be done? Thanks for your help. Regards Pascal [1] http://thrift.apache.org/ [2] http://www.openembedded.org/wiki/Main_Page From gurenchan at gmail.com Mon Oct 19 11:33:55 2015 From: gurenchan at gmail.com (Owen Alanzo Hogarth) Date: Mon, 19 Oct 2015 23:33:55 +0800 Subject: [CMake] providing host binary and target library cmake-package when cross compiling In-Reply-To: <5624FA2D.2070105@siemens.com> References: <5624FA2D.2070105@siemens.com> Message-ID: This is the entire project as it stands right now. I have tried changing from using relative to more absolute directory names in my project but I still get the same build errors. This pastebin has all the relevant code: http://pastebin.com/BnVTnegP Anyone can see anything wrong with this? On Mon, Oct 19, 2015 at 10:11 PM, Pascal Bach wrote: > Hello > > I'm working on CMake support for Apache Thrift [1]. > It is currently already buildable using CMake. However while trying to add > support for generating a ThriftConfig.cmake I ran into some issues > related to cross compilation. > > Thrift has the following components relevant to the problem: > > C++ library (.so library) > Thrift compiler (binary) > > End users/developers usually us thrift in the following way: > Thrift IDL ==[Thrift compiler]==> C++ files ==[GCC + Link with > thrift.so]==> final.so > > My idea for the resulting ThriftConfig.cmake was to provide two imported > targets Thrift::libthrift and Thrift::compiler. > Thrift::compiler can be used to generate C++ files from Thrift IDLs and > Thrift::libthrift is what the resulting binary should link against. > This works well if no cross compilation is involved. > > > Now for the cross compilation case. I'm using OpenEmbedded [2] which > provides two sysroot directories: > 1. sysroot_x86 containing binaries and libraries for the host: > libthrift.so (x86 library), thrift (x86 executable) > 2. sysroot_arm containing binaries and libraries for the target: > libthrift.so (arm library), thrift (arm executable) > > In the cross compiling case the Thrift::compiler target must be executable > on the HOST and Thrift::libthrift must be a target library. > This means the library should be from sysroot_arm but the binary from > sysroot_x86. > I'm not able express this an a good way. > > Does anyone know how to do this? Is there an example how this could be > done? > > Thanks for your help. > > Regards > Pascal > > > [1] http://thrift.apache.org/ > [2] http://www.openembedded.org/wiki/Main_Page > -- > > 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 post at hendrik-sattler.de Mon Oct 19 12:33:22 2015 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Mon, 19 Oct 2015 18:33:22 +0200 Subject: [CMake] providing host binary and target library cmake-package when cross compiling In-Reply-To: References: <5624FA2D.2070105@siemens.com> Message-ID: Am 19. Oktober 2015 17:33:55 MESZ, schrieb Owen Alanzo Hogarth : >This is the entire project as it stands right now. I have tried >changing >from using relative to more absolute directory names in my project but >I >still get the same build errors. > >This pastebin has all the relevant code: http://pastebin.com/BnVTnegP a. You user in-source build, don't do that. b. You have the vector3 target defined in the matrix4 folder and vice versa? Why? c. Because of b. the targets are defined in wrong order. That's why he tries to find a library that is not present. >Anyone can see anything wrong with this? > >On Mon, Oct 19, 2015 at 10:11 PM, Pascal Bach >wrote: > >> Hello >> >> I'm working on CMake support for Apache Thrift [1]. >> It is currently already buildable using CMake. However while trying >to add >> support for generating a ThriftConfig.cmake I ran into some issues >> related to cross compilation. >> >> Thrift has the following components relevant to the problem: >> >> C++ library (.so library) >> Thrift compiler (binary) >> >> End users/developers usually us thrift in the following way: >> Thrift IDL ==[Thrift compiler]==> C++ files ==[GCC + Link with >> thrift.so]==> final.so >> >> My idea for the resulting ThriftConfig.cmake was to provide two >imported >> targets Thrift::libthrift and Thrift::compiler. >> Thrift::compiler can be used to generate C++ files from Thrift IDLs >and >> Thrift::libthrift is what the resulting binary should link against. >> This works well if no cross compilation is involved. >> >> >> Now for the cross compilation case. I'm using OpenEmbedded [2] which >> provides two sysroot directories: >> 1. sysroot_x86 containing binaries and libraries for the host: >> libthrift.so (x86 library), thrift (x86 executable) >> 2. sysroot_arm containing binaries and libraries for the target: >> libthrift.so (arm library), thrift (arm executable) >> >> In the cross compiling case the Thrift::compiler target must be >executable >> on the HOST and Thrift::libthrift must be a target library. >> This means the library should be from sysroot_arm but the binary from >> sysroot_x86. >> I'm not able express this an a good way. >> >> Does anyone know how to do this? Is there an example how this could >be >> done? >> >> Thanks for your help. >> >> Regards >> Pascal >> >> >> [1] http://thrift.apache.org/ >> [2] http://www.openembedded.org/wiki/Main_Page >> -- >> >> 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 Mon Oct 19 12:45:25 2015 From: gurenchan at gmail.com (Owen Alanzo Hogarth) Date: Tue, 20 Oct 2015 00:45:25 +0800 Subject: [CMake] providing host binary and target library cmake-package when cross compiling In-Reply-To: References: <5624FA2D.2070105@siemens.com> Message-ID: this is not an in source build. to do matrix vector multiplication matrix module needs to have access to the vector class. I'll add the source code for these modules here: http://pastebin.com/aj01ycRQ I think the structure should be a little clearer with all that I've provided. This is the previous link to the cmake folder structure and cmakelists.txt files: http://pastebin.com/BnVTnegP On Tue, Oct 20, 2015 at 12:33 AM, Hendrik Sattler wrote: > > > Am 19. Oktober 2015 17:33:55 MESZ, schrieb Owen Alanzo Hogarth < > gurenchan at gmail.com>: > >This is the entire project as it stands right now. I have tried > >changing > >from using relative to more absolute directory names in my project but > >I > >still get the same build errors. > > > >This pastebin has all the relevant code: http://pastebin.com/BnVTnegP > > a. > You user in-source build, don't do that. > > b. > You have the vector3 target defined in the matrix4 folder and vice versa? > Why? > > c. > Because of b. the targets are defined in wrong order. That's why he tries > to find a library that is not present. > > >Anyone can see anything wrong with this? > > > >On Mon, Oct 19, 2015 at 10:11 PM, Pascal Bach > >wrote: > > > >> Hello > >> > >> I'm working on CMake support for Apache Thrift [1]. > >> It is currently already buildable using CMake. However while trying > >to add > >> support for generating a ThriftConfig.cmake I ran into some issues > >> related to cross compilation. > >> > >> Thrift has the following components relevant to the problem: > >> > >> C++ library (.so library) > >> Thrift compiler (binary) > >> > >> End users/developers usually us thrift in the following way: > >> Thrift IDL ==[Thrift compiler]==> C++ files ==[GCC + Link with > >> thrift.so]==> final.so > >> > >> My idea for the resulting ThriftConfig.cmake was to provide two > >imported > >> targets Thrift::libthrift and Thrift::compiler. > >> Thrift::compiler can be used to generate C++ files from Thrift IDLs > >and > >> Thrift::libthrift is what the resulting binary should link against. > >> This works well if no cross compilation is involved. > >> > >> > >> Now for the cross compilation case. I'm using OpenEmbedded [2] which > >> provides two sysroot directories: > >> 1. sysroot_x86 containing binaries and libraries for the host: > >> libthrift.so (x86 library), thrift (x86 executable) > >> 2. sysroot_arm containing binaries and libraries for the target: > >> libthrift.so (arm library), thrift (arm executable) > >> > >> In the cross compiling case the Thrift::compiler target must be > >executable > >> on the HOST and Thrift::libthrift must be a target library. > >> This means the library should be from sysroot_arm but the binary from > >> sysroot_x86. > >> I'm not able express this an a good way. > >> > >> Does anyone know how to do this? Is there an example how this could > >be > >> done? > >> > >> Thanks for your help. > >> > >> Regards > >> Pascal > >> > >> > >> [1] http://thrift.apache.org/ > >> [2] http://www.openembedded.org/wiki/Main_Page > >> -- > >> > >> 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 cary at txcorp.com Mon Oct 19 12:55:29 2015 From: cary at txcorp.com (JR Cary) Date: Mon, 19 Oct 2015 10:55:29 -0600 Subject: [CMake] cmake_check_build_system is causing a rebuild at "make install" In-Reply-To: References: <561D9B6B.9000207@txcorp.com> <561E4E55.8010606@gmail.com> <561E4FC4.10904@txcorp.com> <561E52C5.4090400@gmail.com> Message-ID: <56252081.9040307@txcorp.com> Thanks for the response, James. Our workaround finally was to do "make install/fast". A colleague pointed out that there is a bug report, https://cmake.org/Bug/view.php?id=15801, likely related to this. Is there something about CUDA that requires dependency generation at build time? (I am used to the standard of "#include " following that can be done before any build.) It would be nice if the CUDA dependency generation worked like regular cpp file dependency generation so that cmake would be run only upon change of files and that otherwise it did not have to be turned off completely. Thanks! ....John On 10/18/15 10:03 PM, James Bigler wrote: > This could be caused by CUDA generating dependencies and then needing > to load them at the next configure step. > > For our automated builds, where we don't rely on dependencies during > development (e.g. build one main target from scratch then throw it > away), we set the CMAKE_SUPPRESS_REGENERATION option to TRUE. This > will prevent CMake from configuring during the build. You can still > configure manually by running cmake. > > James > > On Wed, Oct 14, 2015 at 7:04 AM, Nils Gladitz > wrote: > > On 14.10.2015 14:51, JR Cary wrote: > > Thanks for your response. This is a big headache for us, as > it slows down > our builds tremendously. > > Is there any way to prevent or control this behavior? > > > I don't see how. You could modify the module itself I suppose but > I'd expect that to break incremental builds. > > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Mon Oct 19 13:31:50 2015 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Mon, 19 Oct 2015 19:31:50 +0200 Subject: [CMake] providing host binary and target library cmake-package when cross compiling In-Reply-To: References: <5624FA2D.2070105@siemens.com> Message-ID: <088EE452-8127-42DE-90BA-7BD2BE805CE9@hendrik-sattler.de> You didn't answer my points b and c, only a. Am 19. Oktober 2015 18:45:25 MESZ, schrieb Owen Alanzo Hogarth : >this is not an in source build. > >to do matrix vector multiplication matrix module needs to have access >to >the vector class. > > >I'll add the source code for these modules here: >http://pastebin.com/aj01ycRQ > >I think the structure should be a little clearer with all that I've >provided. >This is the previous link to the cmake folder structure and >cmakelists.txt >files: http://pastebin.com/BnVTnegP > > >On Tue, Oct 20, 2015 at 12:33 AM, Hendrik Sattler > >wrote: > >> >> >> Am 19. Oktober 2015 17:33:55 MESZ, schrieb Owen Alanzo Hogarth < >> gurenchan at gmail.com>: >> >This is the entire project as it stands right now. I have tried >> >changing >> >from using relative to more absolute directory names in my project >but >> >I >> >still get the same build errors. >> > >> >This pastebin has all the relevant code: >http://pastebin.com/BnVTnegP >> >> a. >> You user in-source build, don't do that. >> >> b. >> You have the vector3 target defined in the matrix4 folder and vice >versa? >> Why? >> >> c. >> Because of b. the targets are defined in wrong order. That's why he >tries >> to find a library that is not present. >> >> >Anyone can see anything wrong with this? >> > >> >On Mon, Oct 19, 2015 at 10:11 PM, Pascal Bach > >> >wrote: >> > >> >> Hello >> >> >> >> I'm working on CMake support for Apache Thrift [1]. >> >> It is currently already buildable using CMake. However while >trying >> >to add >> >> support for generating a ThriftConfig.cmake I ran into some issues >> >> related to cross compilation. >> >> >> >> Thrift has the following components relevant to the problem: >> >> >> >> C++ library (.so library) >> >> Thrift compiler (binary) >> >> >> >> End users/developers usually us thrift in the following way: >> >> Thrift IDL ==[Thrift compiler]==> C++ files ==[GCC + Link with >> >> thrift.so]==> final.so >> >> >> >> My idea for the resulting ThriftConfig.cmake was to provide two >> >imported >> >> targets Thrift::libthrift and Thrift::compiler. >> >> Thrift::compiler can be used to generate C++ files from Thrift >IDLs >> >and >> >> Thrift::libthrift is what the resulting binary should link >against. >> >> This works well if no cross compilation is involved. >> >> >> >> >> >> Now for the cross compilation case. I'm using OpenEmbedded [2] >which >> >> provides two sysroot directories: >> >> 1. sysroot_x86 containing binaries and libraries for the host: >> >> libthrift.so (x86 library), thrift (x86 executable) >> >> 2. sysroot_arm containing binaries and libraries for the target: >> >> libthrift.so (arm library), thrift (arm executable) >> >> >> >> In the cross compiling case the Thrift::compiler target must be >> >executable >> >> on the HOST and Thrift::libthrift must be a target library. >> >> This means the library should be from sysroot_arm but the binary >from >> >> sysroot_x86. >> >> I'm not able express this an a good way. >> >> >> >> Does anyone know how to do this? Is there an example how this >could >> >be >> >> done? >> >> >> >> Thanks for your help. >> >> >> >> Regards >> >> Pascal >> >> >> >> >> >> [1] http://thrift.apache.org/ >> >> [2] http://www.openembedded.org/wiki/Main_Page >> >> -- >> >> >> >> 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 >> > > >------------------------------------------------------------------------ > >-- > >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 pascal.bach at gmx.ch Mon Oct 19 16:21:19 2015 From: pascal.bach at gmx.ch (Pascal Bach) Date: Mon, 19 Oct 2015 22:21:19 +0200 Subject: [CMake] providing host binary and target library cmake-package when cross compiling In-Reply-To: References: <5624FA2D.2070105@siemens.com> Message-ID: Sorry I don't see how this relates to my question? On Mon, Oct 19, 2015 at 5:33 PM, Owen Alanzo Hogarth wrote: > This is the entire project as it stands right now. I have tried changing > from using relative to more absolute directory names in my project but I > still get the same build errors. > > This pastebin has all the relevant code: http://pastebin.com/BnVTnegP > > Anyone can see anything wrong with this? > > On Mon, Oct 19, 2015 at 10:11 PM, Pascal Bach > wrote: >> >> Hello >> >> I'm working on CMake support for Apache Thrift [1]. >> It is currently already buildable using CMake. However while trying to add >> support for generating a ThriftConfig.cmake I ran into some issues >> related to cross compilation. >> >> Thrift has the following components relevant to the problem: >> >> C++ library (.so library) >> Thrift compiler (binary) >> >> End users/developers usually us thrift in the following way: >> Thrift IDL ==[Thrift compiler]==> C++ files ==[GCC + Link with >> thrift.so]==> final.so >> >> My idea for the resulting ThriftConfig.cmake was to provide two imported >> targets Thrift::libthrift and Thrift::compiler. >> Thrift::compiler can be used to generate C++ files from Thrift IDLs and >> Thrift::libthrift is what the resulting binary should link against. >> This works well if no cross compilation is involved. >> >> >> Now for the cross compilation case. I'm using OpenEmbedded [2] which >> provides two sysroot directories: >> 1. sysroot_x86 containing binaries and libraries for the host: >> libthrift.so (x86 library), thrift (x86 executable) >> 2. sysroot_arm containing binaries and libraries for the target: >> libthrift.so (arm library), thrift (arm executable) >> >> In the cross compiling case the Thrift::compiler target must be executable >> on the HOST and Thrift::libthrift must be a target library. >> This means the library should be from sysroot_arm but the binary from >> sysroot_x86. >> I'm not able express this an a good way. >> >> Does anyone know how to do this? Is there an example how this could be >> done? >> >> Thanks for your help. >> >> Regards >> Pascal >> >> >> [1] http://thrift.apache.org/ >> [2] http://www.openembedded.org/wiki/Main_Page >> -- >> >> 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 From zbergquist99 at gmail.com Mon Oct 19 16:37:02 2015 From: zbergquist99 at gmail.com (Zac Bergquist) Date: Mon, 19 Oct 2015 16:37:02 -0400 Subject: [CMake] Creating relocatable packages In-Reply-To: References: Message-ID: Thank you for your reply, Guillaume. I understand that this is the expected behavior. I even linked to the documentation that says this is the expected behavior. What I don't understand is how to resolve it. Are you saying it is not possible to create a relocatable package unless all dependencies are also using CMake? That doesn't seem right. Should I be trying to write a package config file for libpcap, or is there a better way to approach this? On Sat, Oct 17, 2015 at 8:19 AM, Guillaume Dumont < dumont.guillaume at gmail.com> wrote: > What you are seeing is the expected behavior. You can get a relocatable > package if all your dependencies (in your case libcap) have themselves > relocatable package config files with exported targets. Then you package > should make use of find_dependency macro. > > On Fri, Oct 16, 2015 at 4:56 PM, Zac Bergquist > wrote: > >> I've created a sample project to replicate my issue in hopes that it >> would make it easier to troubleshoot. >> >> Thanks for any help, >> Zac >> >> https://github.com/zmb3/cmaketest >> >> On Mon, Oct 12, 2015 at 8:53 AM, Zac Bergquist >> wrote: >> >>> Hello, >>> >>> I'm trying to fix a project so that its output is relocatable. The >>> project is a library that itself depends on libpcap. My goal is to be able >>> to import the library into my CMake application and have CMake >>> automatically link libpcap with it. >>> >>> I'm using a toolchain file that invokes an ARM cross compiler, sets >>> CMAKE_INSTALL_PREFIX and appends it to CMAKE_FIND_ROOT_PATH. This all >>> seems to work well. >>> >>> What I'm seeing is that the exported files that get installed to >>> CMAKE_INSTALL_PREFIX contain absolute paths to libpcap on my machine, which >>> make them useless to other team members. >>> >>> The first thing I changed was to use CONFIGURE_PACKAGE_CONFIG_FILE >>> instead of CONFIGURE_FILE. This got rid of absolute paths in the generated >>> CMake config file. >>> >>> However, I still have absolute paths in the CMake target import file >>> that gets generated. The IMPORTED_LINK_INTERFACE_LIBRARIES target property >>> has an absolute path instead of one relative to CMAKE_INSTALL_PREFIX. >>> >>> I've read the "Creating Relocatable Packages" [1] section of the CMake >>> packages documentation. I'm pretty sure this is what I'm running into, but >>> I don't quite understand how to solve it. The documentation says that I >>> should be using imported targets, but I'm not sure how to do so. The >>> library is just using its own FindPCAP.cmake file to locate libpcap. >>> >>> Does anyone know of an example of a CMake package that imports other >>> libraries? I could also try to create a minimal example project with this >>> setup if it would be helpful. >>> >>> Thanks, >>> Zac >>> >>> [1]: >>> https://cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html#creating-relocatable-packages >>> >>> >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> > > > > -- > Guillaume Dumont > ========================= > dumont.guillaume at gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pgquiles at elpauer.org Mon Oct 19 17:04:51 2015 From: pgquiles at elpauer.org (Pau Garcia i Quiles) Date: Mon, 19 Oct 2015 23:04:51 +0200 Subject: [CMake] Creating relocatable packages In-Reply-To: References: Message-ID: Hello, Use ExternalProject to build libpcap as part of your project. Make sure you use $ORIGIN in rpath everywhere. Install your application (and your bundled libpcap) to /opt to avoid polluting the system. On Mon, Oct 19, 2015 at 10:37 PM, Zac Bergquist wrote: > Thank you for your reply, Guillaume. > > I understand that this is the expected behavior. I even linked to the > documentation that says this is the expected behavior. What I don't > understand is how to resolve it. Are you saying it is not possible to > create a relocatable package unless all dependencies are also using CMake? > That doesn't seem right. > > Should I be trying to write a package config file for libpcap, or is there > a better way to approach this? > > On Sat, Oct 17, 2015 at 8:19 AM, Guillaume Dumont < > dumont.guillaume at gmail.com> wrote: > >> What you are seeing is the expected behavior. You can get a relocatable >> package if all your dependencies (in your case libcap) have themselves >> relocatable package config files with exported targets. Then you package >> should make use of find_dependency macro. >> >> On Fri, Oct 16, 2015 at 4:56 PM, Zac Bergquist >> wrote: >> >>> I've created a sample project to replicate my issue in hopes that it >>> would make it easier to troubleshoot. >>> >>> Thanks for any help, >>> Zac >>> >>> https://github.com/zmb3/cmaketest >>> >>> On Mon, Oct 12, 2015 at 8:53 AM, Zac Bergquist >>> wrote: >>> >>>> Hello, >>>> >>>> I'm trying to fix a project so that its output is relocatable. The >>>> project is a library that itself depends on libpcap. My goal is to be able >>>> to import the library into my CMake application and have CMake >>>> automatically link libpcap with it. >>>> >>>> I'm using a toolchain file that invokes an ARM cross compiler, sets >>>> CMAKE_INSTALL_PREFIX and appends it to CMAKE_FIND_ROOT_PATH. This all >>>> seems to work well. >>>> >>>> What I'm seeing is that the exported files that get installed to >>>> CMAKE_INSTALL_PREFIX contain absolute paths to libpcap on my machine, which >>>> make them useless to other team members. >>>> >>>> The first thing I changed was to use CONFIGURE_PACKAGE_CONFIG_FILE >>>> instead of CONFIGURE_FILE. This got rid of absolute paths in the generated >>>> CMake config file. >>>> >>>> However, I still have absolute paths in the CMake target import file >>>> that gets generated. The IMPORTED_LINK_INTERFACE_LIBRARIES target property >>>> has an absolute path instead of one relative to CMAKE_INSTALL_PREFIX. >>>> >>>> I've read the "Creating Relocatable Packages" [1] section of the CMake >>>> packages documentation. I'm pretty sure this is what I'm running into, but >>>> I don't quite understand how to solve it. The documentation says that I >>>> should be using imported targets, but I'm not sure how to do so. The >>>> library is just using its own FindPCAP.cmake file to locate libpcap. >>>> >>>> Does anyone know of an example of a CMake package that imports other >>>> libraries? I could also try to create a minimal example project with this >>>> setup if it would be helpful. >>>> >>>> Thanks, >>>> Zac >>>> >>>> [1]: >>>> https://cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html#creating-relocatable-packages >>>> >>>> >>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake >>> >> >> >> >> -- >> 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 > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dank at kegel.com Mon Oct 19 17:15:39 2015 From: dank at kegel.com (Dan Kegel) Date: Mon, 19 Oct 2015 14:15:39 -0700 Subject: [CMake] Creating relocatable packages In-Reply-To: References: Message-ID: Well, that's one answer. But if you want to use system libpcap, it's not a very satisfying one. It's odd that pcap doesn't ship with a .pc file. I guess the pcap folks are hostile to pkgconfig because it's LGPL; see https://github.com/the-tcpdump-group/libpcap/issues/374 - Dan On Mon, Oct 19, 2015 at 2:04 PM, Pau Garcia i Quiles wrote: > Hello, > > Use ExternalProject to build libpcap as part of your project. Make sure > you use $ORIGIN in rpath everywhere. Install your application (and your > bundled libpcap) to /opt to avoid polluting the system. > > On Mon, Oct 19, 2015 at 10:37 PM, Zac Bergquist > wrote: > >> Thank you for your reply, Guillaume. >> >> I understand that this is the expected behavior. I even linked to the >> documentation that says this is the expected behavior. What I don't >> understand is how to resolve it. Are you saying it is not possible to >> create a relocatable package unless all dependencies are also using CMake? >> That doesn't seem right. >> >> Should I be trying to write a package config file for libpcap, or is >> there a better way to approach this? >> >> On Sat, Oct 17, 2015 at 8:19 AM, Guillaume Dumont < >> dumont.guillaume at gmail.com> wrote: >> >>> What you are seeing is the expected behavior. You can get a relocatable >>> package if all your dependencies (in your case libcap) have themselves >>> relocatable package config files with exported targets. Then you package >>> should make use of find_dependency macro. >>> >>> On Fri, Oct 16, 2015 at 4:56 PM, Zac Bergquist >>> wrote: >>> >>>> I've created a sample project to replicate my issue in hopes that it >>>> would make it easier to troubleshoot. >>>> >>>> Thanks for any help, >>>> Zac >>>> >>>> https://github.com/zmb3/cmaketest >>>> >>>> On Mon, Oct 12, 2015 at 8:53 AM, Zac Bergquist >>>> wrote: >>>> >>>>> Hello, >>>>> >>>>> I'm trying to fix a project so that its output is relocatable. The >>>>> project is a library that itself depends on libpcap. My goal is to be able >>>>> to import the library into my CMake application and have CMake >>>>> automatically link libpcap with it. >>>>> >>>>> I'm using a toolchain file that invokes an ARM cross compiler, sets >>>>> CMAKE_INSTALL_PREFIX and appends it to CMAKE_FIND_ROOT_PATH. This all >>>>> seems to work well. >>>>> >>>>> What I'm seeing is that the exported files that get installed to >>>>> CMAKE_INSTALL_PREFIX contain absolute paths to libpcap on my machine, which >>>>> make them useless to other team members. >>>>> >>>>> The first thing I changed was to use CONFIGURE_PACKAGE_CONFIG_FILE >>>>> instead of CONFIGURE_FILE. This got rid of absolute paths in the generated >>>>> CMake config file. >>>>> >>>>> However, I still have absolute paths in the CMake target import file >>>>> that gets generated. The IMPORTED_LINK_INTERFACE_LIBRARIES target property >>>>> has an absolute path instead of one relative to CMAKE_INSTALL_PREFIX. >>>>> >>>>> I've read the "Creating Relocatable Packages" [1] section of the CMake >>>>> packages documentation. I'm pretty sure this is what I'm running into, but >>>>> I don't quite understand how to solve it. The documentation says that I >>>>> should be using imported targets, but I'm not sure how to do so. The >>>>> library is just using its own FindPCAP.cmake file to locate libpcap. >>>>> >>>>> Does anyone know of an example of a CMake package that imports other >>>>> libraries? I could also try to create a minimal example project with this >>>>> setup if it would be helpful. >>>>> >>>>> Thanks, >>>>> Zac >>>>> >>>>> [1]: >>>>> https://cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html#creating-relocatable-packages >>>>> >>>>> >>>> >>>> -- >>>> >>>> Powered by www.kitware.com >>>> >>>> Please keep messages on-topic and check the CMake FAQ at: >>>> http://www.cmake.org/Wiki/CMake_FAQ >>>> >>>> Kitware offers various services to support the CMake community. For >>>> more information on each offering, please visit: >>>> >>>> CMake Support: http://cmake.org/cmake/help/support.html >>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/cmake >>>> >>> >>> >>> >>> -- >>> 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 >> > > > > -- > Pau Garcia i Quiles > http://www.elpauer.org > (Due to my workload, I may need 10 days to answer) > > -- > > 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 pgquiles at elpauer.org Mon Oct 19 17:35:45 2015 From: pgquiles at elpauer.org (Pau Garcia i Quiles) Date: Mon, 19 Oct 2015 23:35:45 +0200 Subject: [CMake] Creating relocatable packages In-Reply-To: References: Message-ID: Hi Dan, On a second read, it seems Zac's problem was actually finding the dependency (libpcap) of a dependency. Or rather, making if findable, because the second depenency contains an absolute path which is broken due to cross-compilation. I have never used it but this page contains information on how to fix the paths in the config file to be relative instead of absolute. That should fix the problem: https://cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file On Mon, Oct 19, 2015 at 11:15 PM, Dan Kegel wrote: > Well, that's one answer. But if you want to use system libpcap, it's not > a very satisfying one. > > It's odd that pcap doesn't ship with a .pc file. > I guess the pcap folks are hostile to pkgconfig because it's LGPL; see > https://github.com/the-tcpdump-group/libpcap/issues/374 > - Dan > > > > On Mon, Oct 19, 2015 at 2:04 PM, Pau Garcia i Quiles > wrote: > >> Hello, >> >> Use ExternalProject to build libpcap as part of your project. Make sure >> you use $ORIGIN in rpath everywhere. Install your application (and your >> bundled libpcap) to /opt to avoid polluting the system. >> >> On Mon, Oct 19, 2015 at 10:37 PM, Zac Bergquist >> wrote: >> >>> Thank you for your reply, Guillaume. >>> >>> I understand that this is the expected behavior. I even linked to the >>> documentation that says this is the expected behavior. What I don't >>> understand is how to resolve it. Are you saying it is not possible to >>> create a relocatable package unless all dependencies are also using CMake? >>> That doesn't seem right. >>> >>> Should I be trying to write a package config file for libpcap, or is >>> there a better way to approach this? >>> >>> On Sat, Oct 17, 2015 at 8:19 AM, Guillaume Dumont < >>> dumont.guillaume at gmail.com> wrote: >>> >>>> What you are seeing is the expected behavior. You can get a relocatable >>>> package if all your dependencies (in your case libcap) have themselves >>>> relocatable package config files with exported targets. Then you package >>>> should make use of find_dependency macro. >>>> >>>> On Fri, Oct 16, 2015 at 4:56 PM, Zac Bergquist >>>> wrote: >>>> >>>>> I've created a sample project to replicate my issue in hopes that it >>>>> would make it easier to troubleshoot. >>>>> >>>>> Thanks for any help, >>>>> Zac >>>>> >>>>> https://github.com/zmb3/cmaketest >>>>> >>>>> On Mon, Oct 12, 2015 at 8:53 AM, Zac Bergquist >>>> > wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> I'm trying to fix a project so that its output is relocatable. The >>>>>> project is a library that itself depends on libpcap. My goal is to be able >>>>>> to import the library into my CMake application and have CMake >>>>>> automatically link libpcap with it. >>>>>> >>>>>> I'm using a toolchain file that invokes an ARM cross compiler, sets >>>>>> CMAKE_INSTALL_PREFIX and appends it to CMAKE_FIND_ROOT_PATH. This all >>>>>> seems to work well. >>>>>> >>>>>> What I'm seeing is that the exported files that get installed to >>>>>> CMAKE_INSTALL_PREFIX contain absolute paths to libpcap on my machine, which >>>>>> make them useless to other team members. >>>>>> >>>>>> The first thing I changed was to use CONFIGURE_PACKAGE_CONFIG_FILE >>>>>> instead of CONFIGURE_FILE. This got rid of absolute paths in the generated >>>>>> CMake config file. >>>>>> >>>>>> However, I still have absolute paths in the CMake target import file >>>>>> that gets generated. The IMPORTED_LINK_INTERFACE_LIBRARIES target property >>>>>> has an absolute path instead of one relative to CMAKE_INSTALL_PREFIX. >>>>>> >>>>>> I've read the "Creating Relocatable Packages" [1] section of the >>>>>> CMake packages documentation. I'm pretty sure this is what I'm running >>>>>> into, but I don't quite understand how to solve it. The documentation says >>>>>> that I should be using imported targets, but I'm not sure how to do so. >>>>>> The library is just using its own FindPCAP.cmake file to locate libpcap. >>>>>> >>>>>> Does anyone know of an example of a CMake package that imports other >>>>>> libraries? I could also try to create a minimal example project with this >>>>>> setup if it would be helpful. >>>>>> >>>>>> Thanks, >>>>>> Zac >>>>>> >>>>>> [1]: >>>>>> https://cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html#creating-relocatable-packages >>>>>> >>>>>> >>>>> >>>>> -- >>>>> >>>>> Powered by www.kitware.com >>>>> >>>>> Please keep messages on-topic and check the CMake FAQ at: >>>>> http://www.cmake.org/Wiki/CMake_FAQ >>>>> >>>>> Kitware offers various services to support the CMake community. For >>>>> more information on each offering, please visit: >>>>> >>>>> CMake Support: http://cmake.org/cmake/help/support.html >>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>>> >>>>> Visit other Kitware open-source projects at >>>>> http://www.kitware.com/opensource/opensource.html >>>>> >>>>> Follow this link to subscribe/unsubscribe: >>>>> http://public.kitware.com/mailman/listinfo/cmake >>>>> >>>> >>>> >>>> >>>> -- >>>> 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 >>> >> >> >> >> -- >> Pau Garcia i Quiles >> http://www.elpauer.org >> (Due to my workload, I may need 10 days to answer) >> >> -- >> >> 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 >> > > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dank at kegel.com Mon Oct 19 17:56:53 2015 From: dank at kegel.com (Dan Kegel) Date: Mon, 19 Oct 2015 14:56:53 -0700 Subject: [CMake] Creating relocatable packages In-Reply-To: References: Message-ID: I had a look at his example, but stopped at the 'export' line. That's just black magic to me :-) CMake user package registry? Yikes. I stopped trying to use cmake for uberbuilds several years ago. - Dan On Mon, Oct 19, 2015 at 2:35 PM, Pau Garcia i Quiles wrote: > Hi Dan, > > On a second read, it seems Zac's problem was actually finding the dependency > (libpcap) of a dependency. Or rather, making if findable, because the second > depenency contains an absolute path which is broken due to > cross-compilation. > > I have never used it but this page contains information on how to fix the > paths in the config file to be relative instead of absolute. That should fix > the problem: > > https://cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file > > > > On Mon, Oct 19, 2015 at 11:15 PM, Dan Kegel wrote: >> >> Well, that's one answer. But if you want to use system libpcap, it's not >> a very satisfying one. >> >> It's odd that pcap doesn't ship with a .pc file. >> I guess the pcap folks are hostile to pkgconfig because it's LGPL; see >> https://github.com/the-tcpdump-group/libpcap/issues/374 >> - Dan >> >> >> >> On Mon, Oct 19, 2015 at 2:04 PM, Pau Garcia i Quiles >> wrote: >>> >>> Hello, >>> >>> Use ExternalProject to build libpcap as part of your project. Make sure >>> you use $ORIGIN in rpath everywhere. Install your application (and your >>> bundled libpcap) to /opt to avoid polluting the system. >>> >>> On Mon, Oct 19, 2015 at 10:37 PM, Zac Bergquist >>> wrote: >>>> >>>> Thank you for your reply, Guillaume. >>>> >>>> I understand that this is the expected behavior. I even linked to the >>>> documentation that says this is the expected behavior. What I don't >>>> understand is how to resolve it. Are you saying it is not possible to >>>> create a relocatable package unless all dependencies are also using CMake? >>>> That doesn't seem right. >>>> >>>> Should I be trying to write a package config file for libpcap, or is >>>> there a better way to approach this? >>>> >>>> On Sat, Oct 17, 2015 at 8:19 AM, Guillaume Dumont >>>> wrote: >>>>> >>>>> What you are seeing is the expected behavior. You can get a relocatable >>>>> package if all your dependencies (in your case libcap) have themselves >>>>> relocatable package config files with exported targets. Then you package >>>>> should make use of find_dependency macro. >>>>> >>>>> On Fri, Oct 16, 2015 at 4:56 PM, Zac Bergquist >>>>> wrote: >>>>>> >>>>>> I've created a sample project to replicate my issue in hopes that it >>>>>> would make it easier to troubleshoot. >>>>>> >>>>>> Thanks for any help, >>>>>> Zac >>>>>> >>>>>> https://github.com/zmb3/cmaketest >>>>>> >>>>>> On Mon, Oct 12, 2015 at 8:53 AM, Zac Bergquist >>>>>> wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I'm trying to fix a project so that its output is relocatable. The >>>>>>> project is a library that itself depends on libpcap. My goal is to be able >>>>>>> to import the library into my CMake application and have CMake automatically >>>>>>> link libpcap with it. >>>>>>> >>>>>>> I'm using a toolchain file that invokes an ARM cross compiler, sets >>>>>>> CMAKE_INSTALL_PREFIX and appends it to CMAKE_FIND_ROOT_PATH. This all seems >>>>>>> to work well. >>>>>>> >>>>>>> What I'm seeing is that the exported files that get installed to >>>>>>> CMAKE_INSTALL_PREFIX contain absolute paths to libpcap on my machine, which >>>>>>> make them useless to other team members. >>>>>>> >>>>>>> The first thing I changed was to use CONFIGURE_PACKAGE_CONFIG_FILE >>>>>>> instead of CONFIGURE_FILE. This got rid of absolute paths in the generated >>>>>>> CMake config file. >>>>>>> >>>>>>> However, I still have absolute paths in the CMake target import file >>>>>>> that gets generated. The IMPORTED_LINK_INTERFACE_LIBRARIES target property >>>>>>> has an absolute path instead of one relative to CMAKE_INSTALL_PREFIX. >>>>>>> >>>>>>> I've read the "Creating Relocatable Packages" [1] section of the >>>>>>> CMake packages documentation. I'm pretty sure this is what I'm running into, >>>>>>> but I don't quite understand how to solve it. The documentation says that I >>>>>>> should be using imported targets, but I'm not sure how to do so. The >>>>>>> library is just using its own FindPCAP.cmake file to locate libpcap. >>>>>>> >>>>>>> Does anyone know of an example of a CMake package that imports other >>>>>>> libraries? I could also try to create a minimal example project with this >>>>>>> setup if it would be helpful. >>>>>>> >>>>>>> Thanks, >>>>>>> Zac >>>>>>> >>>>>>> [1]: >>>>>>> https://cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html#creating-relocatable-packages >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Powered by www.kitware.com >>>>>> >>>>>> Please keep messages on-topic and check the CMake FAQ at: >>>>>> http://www.cmake.org/Wiki/CMake_FAQ >>>>>> >>>>>> Kitware offers various services to support the CMake community. For >>>>>> more information on each offering, please visit: >>>>>> >>>>>> CMake Support: http://cmake.org/cmake/help/support.html >>>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>>>> >>>>>> Visit other Kitware open-source projects at >>>>>> http://www.kitware.com/opensource/opensource.html >>>>>> >>>>>> Follow this link to subscribe/unsubscribe: >>>>>> http://public.kitware.com/mailman/listinfo/cmake >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >>> >>> >>> >>> >>> -- >>> Pau Garcia i Quiles >>> http://www.elpauer.org >>> (Due to my workload, I may need 10 days to answer) >>> >>> -- >>> >>> 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 >> >> > > > > -- > Pau Garcia i Quiles > http://www.elpauer.org > (Due to my workload, I may need 10 days to answer) From zbergquist99 at gmail.com Mon Oct 19 19:02:23 2015 From: zbergquist99 at gmail.com (Zac Bergquist) Date: Mon, 19 Oct 2015 19:02:23 -0400 Subject: [CMake] Creating relocatable packages In-Reply-To: References: Message-ID: Yes, Pau, this is exactly my problem. Or more specifically, as the author of a library that uses CMake and depends on libpcap, how can I best structure and distribute the library to make it easy to use (and cross compile)? I would say using the system libpcap is strongly preferred over distributing a copy of it. That tutorial is very interesting. I'll have to take a closer look at it because the solution isn't jumping out at me. The tutorial shows a project that contains both a library and a program that links to that library in the same list file. In my case that would not be possible. Also, the library in the example has no dependencies so it wouldn't suffer from the absolute path issue I'm encountering. On Oct 19, 2015 5:36 PM, "Pau Garcia i Quiles" wrote: > Hi Dan, > > On a second read, it seems Zac's problem was actually finding the > dependency (libpcap) of a dependency. Or rather, making if findable, > because the second depenency contains an absolute path which is broken due > to cross-compilation. > > I have never used it but this page contains information on how to fix the > paths in the config file to be relative instead of absolute. That should > fix the problem: > > > https://cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file > > > > On Mon, Oct 19, 2015 at 11:15 PM, Dan Kegel wrote: > >> Well, that's one answer. But if you want to use system libpcap, it's not >> a very satisfying one. >> >> It's odd that pcap doesn't ship with a .pc file. >> I guess the pcap folks are hostile to pkgconfig because it's LGPL; see >> https://github.com/the-tcpdump-group/libpcap/issues/374 >> - Dan >> >> >> >> On Mon, Oct 19, 2015 at 2:04 PM, Pau Garcia i Quiles < >> pgquiles at elpauer.org> wrote: >> >>> Hello, >>> >>> Use ExternalProject to build libpcap as part of your project. Make sure >>> you use $ORIGIN in rpath everywhere. Install your application (and your >>> bundled libpcap) to /opt to avoid polluting the system. >>> >>> On Mon, Oct 19, 2015 at 10:37 PM, Zac Bergquist >>> wrote: >>> >>>> Thank you for your reply, Guillaume. >>>> >>>> I understand that this is the expected behavior. I even linked to the >>>> documentation that says this is the expected behavior. What I don't >>>> understand is how to resolve it. Are you saying it is not possible to >>>> create a relocatable package unless all dependencies are also using CMake? >>>> That doesn't seem right. >>>> >>>> Should I be trying to write a package config file for libpcap, or is >>>> there a better way to approach this? >>>> >>>> On Sat, Oct 17, 2015 at 8:19 AM, Guillaume Dumont < >>>> dumont.guillaume at gmail.com> wrote: >>>> >>>>> What you are seeing is the expected behavior. You can get a >>>>> relocatable package if all your dependencies (in your case libcap) have >>>>> themselves relocatable package config files with exported targets. Then you >>>>> package should make use of find_dependency macro. >>>>> >>>>> On Fri, Oct 16, 2015 at 4:56 PM, Zac Bergquist >>>> > wrote: >>>>> >>>>>> I've created a sample project to replicate my issue in hopes that it >>>>>> would make it easier to troubleshoot. >>>>>> >>>>>> Thanks for any help, >>>>>> Zac >>>>>> >>>>>> https://github.com/zmb3/cmaketest >>>>>> >>>>>> On Mon, Oct 12, 2015 at 8:53 AM, Zac Bergquist < >>>>>> zbergquist99 at gmail.com> wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I'm trying to fix a project so that its output is relocatable. The >>>>>>> project is a library that itself depends on libpcap. My goal is to be able >>>>>>> to import the library into my CMake application and have CMake >>>>>>> automatically link libpcap with it. >>>>>>> >>>>>>> I'm using a toolchain file that invokes an ARM cross compiler, sets >>>>>>> CMAKE_INSTALL_PREFIX and appends it to CMAKE_FIND_ROOT_PATH. This all >>>>>>> seems to work well. >>>>>>> >>>>>>> What I'm seeing is that the exported files that get installed to >>>>>>> CMAKE_INSTALL_PREFIX contain absolute paths to libpcap on my machine, which >>>>>>> make them useless to other team members. >>>>>>> >>>>>>> The first thing I changed was to use CONFIGURE_PACKAGE_CONFIG_FILE >>>>>>> instead of CONFIGURE_FILE. This got rid of absolute paths in the generated >>>>>>> CMake config file. >>>>>>> >>>>>>> However, I still have absolute paths in the CMake target import file >>>>>>> that gets generated. The IMPORTED_LINK_INTERFACE_LIBRARIES target property >>>>>>> has an absolute path instead of one relative to CMAKE_INSTALL_PREFIX. >>>>>>> >>>>>>> I've read the "Creating Relocatable Packages" [1] section of the >>>>>>> CMake packages documentation. I'm pretty sure this is what I'm running >>>>>>> into, but I don't quite understand how to solve it. The documentation says >>>>>>> that I should be using imported targets, but I'm not sure how to do so. >>>>>>> The library is just using its own FindPCAP.cmake file to locate libpcap. >>>>>>> >>>>>>> Does anyone know of an example of a CMake package that imports other >>>>>>> libraries? I could also try to create a minimal example project with this >>>>>>> setup if it would be helpful. >>>>>>> >>>>>>> Thanks, >>>>>>> Zac >>>>>>> >>>>>>> [1]: >>>>>>> https://cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html#creating-relocatable-packages >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Powered by www.kitware.com >>>>>> >>>>>> Please keep messages on-topic and check the CMake FAQ at: >>>>>> http://www.cmake.org/Wiki/CMake_FAQ >>>>>> >>>>>> Kitware offers various services to support the CMake community. For >>>>>> more information on each offering, please visit: >>>>>> >>>>>> CMake Support: http://cmake.org/cmake/help/support.html >>>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>>>> >>>>>> Visit other Kitware open-source projects at >>>>>> http://www.kitware.com/opensource/opensource.html >>>>>> >>>>>> Follow this link to subscribe/unsubscribe: >>>>>> http://public.kitware.com/mailman/listinfo/cmake >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >>>> >>> >>> >>> >>> -- >>> Pau Garcia i Quiles >>> http://www.elpauer.org >>> (Due to my workload, I may need 10 days to answer) >>> >>> -- >>> >>> 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 >>> >> >> > > > -- > Pau Garcia i Quiles > http://www.elpauer.org > (Due to my workload, I may need 10 days to answer) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pgquiles at elpauer.org Mon Oct 19 19:06:10 2015 From: pgquiles at elpauer.org (Pau Garcia i Quiles) Date: Tue, 20 Oct 2015 01:06:10 +0200 Subject: [CMake] Creating relocatable packages In-Reply-To: References: Message-ID: Hello, In your case, what you need to do is to modify the config file generation in the library (i. e. you will need to patch the third-party library) so that the generated config file is relative. As an alternative, if you do not want to patch the third-party library, try modifying the generated config file by replacing absolute prefixes with a variable (to the cross-compilation sysroot) or relative paths. On Tue, Oct 20, 2015 at 1:02 AM, Zac Bergquist wrote: > Yes, Pau, this is exactly my problem. Or more specifically, as the author > of a library that uses CMake and depends on libpcap, how can I best > structure and distribute the library to make it easy to use (and cross > compile)? I would say using the system libpcap is strongly preferred over > distributing a copy of it. > > That tutorial is very interesting. I'll have to take a closer look at it > because the solution isn't jumping out at me. The tutorial shows a project > that contains both a library and a program that links to that library in > the same list file. In my case that would not be possible. Also, the > library in the example has no dependencies so it wouldn't suffer from the > absolute path issue I'm encountering. > On Oct 19, 2015 5:36 PM, "Pau Garcia i Quiles" > wrote: > >> Hi Dan, >> >> On a second read, it seems Zac's problem was actually finding the >> dependency (libpcap) of a dependency. Or rather, making if findable, >> because the second depenency contains an absolute path which is broken due >> to cross-compilation. >> >> I have never used it but this page contains information on how to fix the >> paths in the config file to be relative instead of absolute. That should >> fix the problem: >> >> >> https://cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file >> >> >> >> On Mon, Oct 19, 2015 at 11:15 PM, Dan Kegel wrote: >> >>> Well, that's one answer. But if you want to use system libpcap, it's >>> not a very satisfying one. >>> >>> It's odd that pcap doesn't ship with a .pc file. >>> I guess the pcap folks are hostile to pkgconfig because it's LGPL; see >>> https://github.com/the-tcpdump-group/libpcap/issues/374 >>> - Dan >>> >>> >>> >>> On Mon, Oct 19, 2015 at 2:04 PM, Pau Garcia i Quiles < >>> pgquiles at elpauer.org> wrote: >>> >>>> Hello, >>>> >>>> Use ExternalProject to build libpcap as part of your project. Make sure >>>> you use $ORIGIN in rpath everywhere. Install your application (and your >>>> bundled libpcap) to /opt to avoid polluting the system. >>>> >>>> On Mon, Oct 19, 2015 at 10:37 PM, Zac Bergquist >>> > wrote: >>>> >>>>> Thank you for your reply, Guillaume. >>>>> >>>>> I understand that this is the expected behavior. I even linked to the >>>>> documentation that says this is the expected behavior. What I don't >>>>> understand is how to resolve it. Are you saying it is not possible to >>>>> create a relocatable package unless all dependencies are also using CMake? >>>>> That doesn't seem right. >>>>> >>>>> Should I be trying to write a package config file for libpcap, or is >>>>> there a better way to approach this? >>>>> >>>>> On Sat, Oct 17, 2015 at 8:19 AM, Guillaume Dumont < >>>>> dumont.guillaume at gmail.com> wrote: >>>>> >>>>>> What you are seeing is the expected behavior. You can get a >>>>>> relocatable package if all your dependencies (in your case libcap) have >>>>>> themselves relocatable package config files with exported targets. Then you >>>>>> package should make use of find_dependency macro. >>>>>> >>>>>> On Fri, Oct 16, 2015 at 4:56 PM, Zac Bergquist < >>>>>> zbergquist99 at gmail.com> wrote: >>>>>> >>>>>>> I've created a sample project to replicate my issue in hopes that it >>>>>>> would make it easier to troubleshoot. >>>>>>> >>>>>>> Thanks for any help, >>>>>>> Zac >>>>>>> >>>>>>> https://github.com/zmb3/cmaketest >>>>>>> >>>>>>> On Mon, Oct 12, 2015 at 8:53 AM, Zac Bergquist < >>>>>>> zbergquist99 at gmail.com> wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I'm trying to fix a project so that its output is relocatable. The >>>>>>>> project is a library that itself depends on libpcap. My goal is to be able >>>>>>>> to import the library into my CMake application and have CMake >>>>>>>> automatically link libpcap with it. >>>>>>>> >>>>>>>> I'm using a toolchain file that invokes an ARM cross compiler, sets >>>>>>>> CMAKE_INSTALL_PREFIX and appends it to CMAKE_FIND_ROOT_PATH. This all >>>>>>>> seems to work well. >>>>>>>> >>>>>>>> What I'm seeing is that the exported files that get installed to >>>>>>>> CMAKE_INSTALL_PREFIX contain absolute paths to libpcap on my machine, which >>>>>>>> make them useless to other team members. >>>>>>>> >>>>>>>> The first thing I changed was to use CONFIGURE_PACKAGE_CONFIG_FILE >>>>>>>> instead of CONFIGURE_FILE. This got rid of absolute paths in the generated >>>>>>>> CMake config file. >>>>>>>> >>>>>>>> However, I still have absolute paths in the CMake target import >>>>>>>> file that gets generated. The IMPORTED_LINK_INTERFACE_LIBRARIES target >>>>>>>> property has an absolute path instead of one relative to >>>>>>>> CMAKE_INSTALL_PREFIX. >>>>>>>> >>>>>>>> I've read the "Creating Relocatable Packages" [1] section of the >>>>>>>> CMake packages documentation. I'm pretty sure this is what I'm running >>>>>>>> into, but I don't quite understand how to solve it. The documentation says >>>>>>>> that I should be using imported targets, but I'm not sure how to do so. >>>>>>>> The library is just using its own FindPCAP.cmake file to locate libpcap. >>>>>>>> >>>>>>>> Does anyone know of an example of a CMake package that imports >>>>>>>> other libraries? I could also try to create a minimal example project with >>>>>>>> this setup if it would be helpful. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Zac >>>>>>>> >>>>>>>> [1]: >>>>>>>> https://cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html#creating-relocatable-packages >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Powered by www.kitware.com >>>>>>> >>>>>>> Please keep messages on-topic and check the CMake FAQ at: >>>>>>> http://www.cmake.org/Wiki/CMake_FAQ >>>>>>> >>>>>>> Kitware offers various services to support the CMake community. For >>>>>>> more information on each offering, please visit: >>>>>>> >>>>>>> CMake Support: http://cmake.org/cmake/help/support.html >>>>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>>>>> >>>>>>> Visit other Kitware open-source projects at >>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>> >>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>> http://public.kitware.com/mailman/listinfo/cmake >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> Pau Garcia i Quiles >>>> http://www.elpauer.org >>>> (Due to my workload, I may need 10 days to answer) >>>> >>>> -- >>>> >>>> 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 >>>> >>> >>> >> >> >> -- >> Pau Garcia i Quiles >> http://www.elpauer.org >> (Due to my workload, I may need 10 days to answer) >> > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dumont.guillaume at gmail.com Mon Oct 19 21:54:23 2015 From: dumont.guillaume at gmail.com (Guillaume Dumont) Date: Mon, 19 Oct 2015 21:54:23 -0400 Subject: [CMake] Creating relocatable packages In-Reply-To: References: Message-ID: Hi Zac, Sorry I read your post very quickly the first time... If your library uses its own FindPCAP.cmake then you can define an imported target for the PCAP libraries like so: # FindPCAP.cmake find_path(PCAP_INCLUDE_DIR pcap.h ... ) find_library(PCAP_LIBRARY pcap ... ) include(FindPackageHandleStandardArgs) find_package_handle_standard_args(PCAP DEFAULT_MSG PCAP_LIBRARY PCAP_INCLUDE_DIR) if(PCAP_FOUND AND NOT TARGET PCAP) add_library(PCAP IMPORTED) # you can(or should) also specify if it's a shared or static library set_target_properties(PCAP PROPERTIES IMPORTED_LOCATION ${PCAP_LIBRARY}) # also add the interface include directories here via set_target_properties set(PCAP_LIBRARIES PCAP) endif() then in your CMakeLists.txt: find_package(PCAP) target_link_libraries(mylib ${PCAP_LIBRARIES}) Install your FindPCAP.cmake with your exported targets so that you can use the FindDependencyMacro to resolve the dependency when a consuming project finds your library. Would that work for you? HTH Guillaume On Mon, Oct 19, 2015 at 7:06 PM, Pau Garcia i Quiles wrote: > Hello, > > In your case, what you need to do is to modify the config file generation > in the library (i. e. you will need to patch the third-party library) so > that the generated config file is relative. > > As an alternative, if you do not want to patch the third-party library, > try modifying the generated config file by replacing absolute prefixes with > a variable (to the cross-compilation sysroot) or relative paths. > > On Tue, Oct 20, 2015 at 1:02 AM, Zac Bergquist > wrote: > >> Yes, Pau, this is exactly my problem. Or more specifically, as the author >> of a library that uses CMake and depends on libpcap, how can I best >> structure and distribute the library to make it easy to use (and cross >> compile)? I would say using the system libpcap is strongly preferred over >> distributing a copy of it. >> >> That tutorial is very interesting. I'll have to take a closer look at it >> because the solution isn't jumping out at me. The tutorial shows a project >> that contains both a library and a program that links to that library in >> the same list file. In my case that would not be possible. Also, the >> library in the example has no dependencies so it wouldn't suffer from the >> absolute path issue I'm encountering. >> On Oct 19, 2015 5:36 PM, "Pau Garcia i Quiles" >> wrote: >> >>> Hi Dan, >>> >>> On a second read, it seems Zac's problem was actually finding the >>> dependency (libpcap) of a dependency. Or rather, making if findable, >>> because the second depenency contains an absolute path which is broken due >>> to cross-compilation. >>> >>> I have never used it but this page contains information on how to fix >>> the paths in the config file to be relative instead of absolute. That >>> should fix the problem: >>> >>> >>> https://cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file >>> >>> >>> >>> On Mon, Oct 19, 2015 at 11:15 PM, Dan Kegel wrote: >>> >>>> Well, that's one answer. But if you want to use system libpcap, it's >>>> not a very satisfying one. >>>> >>>> It's odd that pcap doesn't ship with a .pc file. >>>> I guess the pcap folks are hostile to pkgconfig because it's LGPL; see >>>> https://github.com/the-tcpdump-group/libpcap/issues/374 >>>> - Dan >>>> >>>> >>>> >>>> On Mon, Oct 19, 2015 at 2:04 PM, Pau Garcia i Quiles < >>>> pgquiles at elpauer.org> wrote: >>>> >>>>> Hello, >>>>> >>>>> Use ExternalProject to build libpcap as part of your project. Make >>>>> sure you use $ORIGIN in rpath everywhere. Install your application (and >>>>> your bundled libpcap) to /opt to avoid polluting the system. >>>>> >>>>> On Mon, Oct 19, 2015 at 10:37 PM, Zac Bergquist < >>>>> zbergquist99 at gmail.com> wrote: >>>>> >>>>>> Thank you for your reply, Guillaume. >>>>>> >>>>>> I understand that this is the expected behavior. I even linked to >>>>>> the documentation that says this is the expected behavior. What I don't >>>>>> understand is how to resolve it. Are you saying it is not possible to >>>>>> create a relocatable package unless all dependencies are also using CMake? >>>>>> That doesn't seem right. >>>>>> >>>>>> Should I be trying to write a package config file for libpcap, or is >>>>>> there a better way to approach this? >>>>>> >>>>>> On Sat, Oct 17, 2015 at 8:19 AM, Guillaume Dumont < >>>>>> dumont.guillaume at gmail.com> wrote: >>>>>> >>>>>>> What you are seeing is the expected behavior. You can get a >>>>>>> relocatable package if all your dependencies (in your case libcap) have >>>>>>> themselves relocatable package config files with exported targets. Then you >>>>>>> package should make use of find_dependency macro. >>>>>>> >>>>>>> On Fri, Oct 16, 2015 at 4:56 PM, Zac Bergquist < >>>>>>> zbergquist99 at gmail.com> wrote: >>>>>>> >>>>>>>> I've created a sample project to replicate my issue in hopes that >>>>>>>> it would make it easier to troubleshoot. >>>>>>>> >>>>>>>> Thanks for any help, >>>>>>>> Zac >>>>>>>> >>>>>>>> https://github.com/zmb3/cmaketest >>>>>>>> >>>>>>>> On Mon, Oct 12, 2015 at 8:53 AM, Zac Bergquist < >>>>>>>> zbergquist99 at gmail.com> wrote: >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I'm trying to fix a project so that its output is relocatable. >>>>>>>>> The project is a library that itself depends on libpcap. My goal is to be >>>>>>>>> able to import the library into my CMake application and have CMake >>>>>>>>> automatically link libpcap with it. >>>>>>>>> >>>>>>>>> I'm using a toolchain file that invokes an ARM cross compiler, >>>>>>>>> sets CMAKE_INSTALL_PREFIX and appends it to CMAKE_FIND_ROOT_PATH. This all >>>>>>>>> seems to work well. >>>>>>>>> >>>>>>>>> What I'm seeing is that the exported files that get installed to >>>>>>>>> CMAKE_INSTALL_PREFIX contain absolute paths to libpcap on my machine, which >>>>>>>>> make them useless to other team members. >>>>>>>>> >>>>>>>>> The first thing I changed was to use CONFIGURE_PACKAGE_CONFIG_FILE >>>>>>>>> instead of CONFIGURE_FILE. This got rid of absolute paths in the generated >>>>>>>>> CMake config file. >>>>>>>>> >>>>>>>>> However, I still have absolute paths in the CMake target import >>>>>>>>> file that gets generated. The IMPORTED_LINK_INTERFACE_LIBRARIES target >>>>>>>>> property has an absolute path instead of one relative to >>>>>>>>> CMAKE_INSTALL_PREFIX. >>>>>>>>> >>>>>>>>> I've read the "Creating Relocatable Packages" [1] section of the >>>>>>>>> CMake packages documentation. I'm pretty sure this is what I'm running >>>>>>>>> into, but I don't quite understand how to solve it. The documentation says >>>>>>>>> that I should be using imported targets, but I'm not sure how to do so. >>>>>>>>> The library is just using its own FindPCAP.cmake file to locate libpcap. >>>>>>>>> >>>>>>>>> Does anyone know of an example of a CMake package that imports >>>>>>>>> other libraries? I could also try to create a minimal example project with >>>>>>>>> this setup if it would be helpful. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Zac >>>>>>>>> >>>>>>>>> [1]: >>>>>>>>> https://cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html#creating-relocatable-packages >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Powered by www.kitware.com >>>>>>>> >>>>>>>> Please keep messages on-topic and check the CMake FAQ at: >>>>>>>> http://www.cmake.org/Wiki/CMake_FAQ >>>>>>>> >>>>>>>> Kitware offers various services to support the CMake community. For >>>>>>>> more information on each offering, please visit: >>>>>>>> >>>>>>>> CMake Support: http://cmake.org/cmake/help/support.html >>>>>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>>>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>>>>>> >>>>>>>> Visit other Kitware open-source projects at >>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>> >>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>> http://public.kitware.com/mailman/listinfo/cmake >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Pau Garcia i Quiles >>>>> http://www.elpauer.org >>>>> (Due to my workload, I may need 10 days to answer) >>>>> >>>>> -- >>>>> >>>>> 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 >>>>> >>>> >>>> >>> >>> >>> -- >>> Pau Garcia i Quiles >>> http://www.elpauer.org >>> (Due to my workload, I may need 10 days to answer) >>> >> > > > -- > Pau Garcia i Quiles > http://www.elpauer.org > (Due to my workload, I may need 10 days to answer) > > -- > > 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 > -- Guillaume Dumont ========================= dumont.guillaume at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.trenkin at gmail.com Tue Oct 20 07:49:15 2015 From: oleg.trenkin at gmail.com (Oleg Trenkin) Date: Tue, 20 Oct 2015 14:49:15 +0300 Subject: [CMake] CMake string REGEX REPLACE and environment variables Message-ID: Hi all, Does anybody know why I can't evaluate environment variable inside "REGEX REPLACE"? Example, I have a value: set(value "LD_LIBRARY_PATH=my_path:$LD_LIBRARY_PATH") I expect: value = "LD_LIBRARY_PATH=my_path:some_system_path_from_env" What I'm doing: string(REGEX REPLACE "\\$\\{([a-zA-Z0-9_]+)\\}" "$ENV{\\1}" value ${value}) Regexp works, CMAKE_MATCH_1 and \\1 both have "LD_LIBRARY_PATH" string string(REGEX REPLACE "\\$\\{([a-zA-Z0-9_]+)\\}" "\\1" value ${value}) will return "LD_LIBRARY_PATH=my_path:LD_LIBRARY_PATH" but why can't I use $ENV{\\1}, or maybe I'm doing something wrong? Thanks, Oleg -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Tue Oct 20 08:07:57 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 20 Oct 2015 14:07:57 +0200 Subject: [CMake] CMake string REGEX REPLACE and environment variables In-Reply-To: References: Message-ID: <56262E9D.6090708@gmail.com> On 10/20/2015 01:49 PM, Oleg Trenkin wrote: > Hi all, > > Does anybody know why I can't evaluate environment variable inside > "REGEX REPLACE"? > > Example, > I have a value: > set(value "LD_LIBRARY_PATH=my_path:$LD_LIBRARY_PATH") > > I expect: > value = "LD_LIBRARY_PATH=my_path:some_system_path_from_env" > > What I'm doing: > string(REGEX REPLACE "\\$\\{([a-zA-Z0-9_]+)\\}" "$ENV{\\1}" value ${value}) > > Regexp works, > CMAKE_MATCH_1 and \\1 both have "LD_LIBRARY_PATH" string > > string(REGEX REPLACE "\\$\\{([a-zA-Z0-9_]+)\\}" "\\1" value ${value}) > will return "LD_LIBRARY_PATH=my_path:LD_LIBRARY_PATH" > but why can't I use $ENV{\\1}, or maybe I'm doing something wrong? $ENV{} is evaluated before string() gets called so \\1 is evaluated as the literal name of the variable. This works for me somewhat: set(value "LD_LIBRARY_PATH=my_path:$LD_LIBRARY_PATH") string(REGEX MATCHALL "\\$[a-zA-Z0-9_]+" MY_MATCHES "${value}") foreach(MATCH ${MY_MATCHES}) string(SUBSTRING "${MATCH}" 1 -1 MY_NAME) string(REPLACE "${MATCH}" "$ENV{${MY_NAME}}" value "${value}") endforeach() message("${value}") Nils From zbergquist99 at gmail.com Tue Oct 20 08:24:44 2015 From: zbergquist99 at gmail.com (Zac Bergquist) Date: Tue, 20 Oct 2015 08:24:44 -0400 Subject: [CMake] Creating relocatable packages In-Reply-To: References: Message-ID: I think I'm on the right track now. I was definitely missing the add_library(PCAP IMPORTED) section. Could you elaborate on the last part? I thought target_link_libraries() is the reason I'm getting absolute paths. Should I be using the FindDependency macro instead of target_link_libraries()? On Mon, Oct 19, 2015 at 9:54 PM, Guillaume Dumont < dumont.guillaume at gmail.com> wrote: > Hi Zac, > > Sorry I read your post very quickly the first time... If your library uses > its own FindPCAP.cmake then you can define an imported target for the PCAP > libraries like so: > > # FindPCAP.cmake > > find_path(PCAP_INCLUDE_DIR pcap.h ... ) > find_library(PCAP_LIBRARY pcap ... ) > > include(FindPackageHandleStandardArgs) > find_package_handle_standard_args(PCAP DEFAULT_MSG PCAP_LIBRARY > PCAP_INCLUDE_DIR) > > if(PCAP_FOUND AND NOT TARGET PCAP) > add_library(PCAP IMPORTED) # you can(or should) also specify if it's a > shared or static library > set_target_properties(PCAP PROPERTIES IMPORTED_LOCATION ${PCAP_LIBRARY}) > # also add the interface include directories here via > set_target_properties > set(PCAP_LIBRARIES PCAP) > endif() > > then in your CMakeLists.txt: > > find_package(PCAP) > > target_link_libraries(mylib ${PCAP_LIBRARIES}) > > Install your FindPCAP.cmake with your exported targets so that you can use > the FindDependencyMacro to resolve the dependency when a consuming project > finds your library. > > Would that work for you? > > HTH > > Guillaume > > > > On Mon, Oct 19, 2015 at 7:06 PM, Pau Garcia i Quiles > wrote: > >> Hello, >> >> In your case, what you need to do is to modify the config file generation >> in the library (i. e. you will need to patch the third-party library) so >> that the generated config file is relative. >> >> As an alternative, if you do not want to patch the third-party library, >> try modifying the generated config file by replacing absolute prefixes with >> a variable (to the cross-compilation sysroot) or relative paths. >> >> On Tue, Oct 20, 2015 at 1:02 AM, Zac Bergquist >> wrote: >> >>> Yes, Pau, this is exactly my problem. Or more specifically, as the >>> author of a library that uses CMake and depends on libpcap, how can I best >>> structure and distribute the library to make it easy to use (and cross >>> compile)? I would say using the system libpcap is strongly preferred over >>> distributing a copy of it. >>> >>> That tutorial is very interesting. I'll have to take a closer look at >>> it because the solution isn't jumping out at me. The tutorial shows a >>> project that contains both a library and a program that links to that >>> library in the same list file. In my case that would not be possible. >>> Also, the library in the example has no dependencies so it wouldn't suffer >>> from the absolute path issue I'm encountering. >>> On Oct 19, 2015 5:36 PM, "Pau Garcia i Quiles" >>> wrote: >>> >>>> Hi Dan, >>>> >>>> On a second read, it seems Zac's problem was actually finding the >>>> dependency (libpcap) of a dependency. Or rather, making if findable, >>>> because the second depenency contains an absolute path which is broken due >>>> to cross-compilation. >>>> >>>> I have never used it but this page contains information on how to fix >>>> the paths in the config file to be relative instead of absolute. That >>>> should fix the problem: >>>> >>>> >>>> https://cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file >>>> >>>> >>>> >>>> On Mon, Oct 19, 2015 at 11:15 PM, Dan Kegel wrote: >>>> >>>>> Well, that's one answer. But if you want to use system libpcap, it's >>>>> not a very satisfying one. >>>>> >>>>> It's odd that pcap doesn't ship with a .pc file. >>>>> I guess the pcap folks are hostile to pkgconfig because it's LGPL; see >>>>> https://github.com/the-tcpdump-group/libpcap/issues/374 >>>>> - Dan >>>>> >>>>> >>>>> >>>>> On Mon, Oct 19, 2015 at 2:04 PM, Pau Garcia i Quiles < >>>>> pgquiles at elpauer.org> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> Use ExternalProject to build libpcap as part of your project. Make >>>>>> sure you use $ORIGIN in rpath everywhere. Install your application (and >>>>>> your bundled libpcap) to /opt to avoid polluting the system. >>>>>> >>>>>> On Mon, Oct 19, 2015 at 10:37 PM, Zac Bergquist < >>>>>> zbergquist99 at gmail.com> wrote: >>>>>> >>>>>>> Thank you for your reply, Guillaume. >>>>>>> >>>>>>> I understand that this is the expected behavior. I even linked to >>>>>>> the documentation that says this is the expected behavior. What I don't >>>>>>> understand is how to resolve it. Are you saying it is not possible to >>>>>>> create a relocatable package unless all dependencies are also using CMake? >>>>>>> That doesn't seem right. >>>>>>> >>>>>>> Should I be trying to write a package config file for libpcap, or is >>>>>>> there a better way to approach this? >>>>>>> >>>>>>> On Sat, Oct 17, 2015 at 8:19 AM, Guillaume Dumont < >>>>>>> dumont.guillaume at gmail.com> wrote: >>>>>>> >>>>>>>> What you are seeing is the expected behavior. You can get a >>>>>>>> relocatable package if all your dependencies (in your case libcap) have >>>>>>>> themselves relocatable package config files with exported targets. Then you >>>>>>>> package should make use of find_dependency macro. >>>>>>>> >>>>>>>> On Fri, Oct 16, 2015 at 4:56 PM, Zac Bergquist < >>>>>>>> zbergquist99 at gmail.com> wrote: >>>>>>>> >>>>>>>>> I've created a sample project to replicate my issue in hopes that >>>>>>>>> it would make it easier to troubleshoot. >>>>>>>>> >>>>>>>>> Thanks for any help, >>>>>>>>> Zac >>>>>>>>> >>>>>>>>> https://github.com/zmb3/cmaketest >>>>>>>>> >>>>>>>>> On Mon, Oct 12, 2015 at 8:53 AM, Zac Bergquist < >>>>>>>>> zbergquist99 at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> I'm trying to fix a project so that its output is relocatable. >>>>>>>>>> The project is a library that itself depends on libpcap. My goal is to be >>>>>>>>>> able to import the library into my CMake application and have CMake >>>>>>>>>> automatically link libpcap with it. >>>>>>>>>> >>>>>>>>>> I'm using a toolchain file that invokes an ARM cross compiler, >>>>>>>>>> sets CMAKE_INSTALL_PREFIX and appends it to CMAKE_FIND_ROOT_PATH. This all >>>>>>>>>> seems to work well. >>>>>>>>>> >>>>>>>>>> What I'm seeing is that the exported files that get installed to >>>>>>>>>> CMAKE_INSTALL_PREFIX contain absolute paths to libpcap on my machine, which >>>>>>>>>> make them useless to other team members. >>>>>>>>>> >>>>>>>>>> The first thing I changed was to use >>>>>>>>>> CONFIGURE_PACKAGE_CONFIG_FILE instead of CONFIGURE_FILE. This got rid of >>>>>>>>>> absolute paths in the generated CMake config file. >>>>>>>>>> >>>>>>>>>> However, I still have absolute paths in the CMake target import >>>>>>>>>> file that gets generated. The IMPORTED_LINK_INTERFACE_LIBRARIES target >>>>>>>>>> property has an absolute path instead of one relative to >>>>>>>>>> CMAKE_INSTALL_PREFIX. >>>>>>>>>> >>>>>>>>>> I've read the "Creating Relocatable Packages" [1] section of the >>>>>>>>>> CMake packages documentation. I'm pretty sure this is what I'm running >>>>>>>>>> into, but I don't quite understand how to solve it. The documentation says >>>>>>>>>> that I should be using imported targets, but I'm not sure how to do so. >>>>>>>>>> The library is just using its own FindPCAP.cmake file to locate libpcap. >>>>>>>>>> >>>>>>>>>> Does anyone know of an example of a CMake package that imports >>>>>>>>>> other libraries? I could also try to create a minimal example project with >>>>>>>>>> this setup if it would be helpful. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Zac >>>>>>>>>> >>>>>>>>>> [1]: >>>>>>>>>> https://cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html#creating-relocatable-packages >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> Powered by www.kitware.com >>>>>>>>> >>>>>>>>> Please keep messages on-topic and check the CMake FAQ at: >>>>>>>>> http://www.cmake.org/Wiki/CMake_FAQ >>>>>>>>> >>>>>>>>> Kitware offers various services to support the CMake community. >>>>>>>>> For more information on each offering, please visit: >>>>>>>>> >>>>>>>>> CMake Support: http://cmake.org/cmake/help/support.html >>>>>>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>>>>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>>>>>>> >>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>>> >>>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>>> http://public.kitware.com/mailman/listinfo/cmake >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> 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 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Pau Garcia i Quiles >>>>>> http://www.elpauer.org >>>>>> (Due to my workload, I may need 10 days to answer) >>>>>> >>>>>> -- >>>>>> >>>>>> 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 >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Pau Garcia i Quiles >>>> http://www.elpauer.org >>>> (Due to my workload, I may need 10 days to answer) >>>> >>> >> >> >> -- >> Pau Garcia i Quiles >> http://www.elpauer.org >> (Due to my workload, I may need 10 days to answer) >> >> -- >> >> 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 >> > > > > -- > Guillaume Dumont > ========================= > dumont.guillaume at gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dumont.guillaume at gmail.com Tue Oct 20 09:25:31 2015 From: dumont.guillaume at gmail.com (Guillaume Dumont) Date: Tue, 20 Oct 2015 09:25:31 -0400 Subject: [CMake] Creating relocatable packages In-Reply-To: References: Message-ID: Hi Zac, target_link_libraries will work with either full library paths or target names including imported targets. You need to use target_link_libraries in your CMakeLists.txt and find_dependency in your PackageConfig.cmake. Like so: in CMakeLists.txt: target_link_libraries(mylib ${PCAP_LIBRARIES}) in PackageConfig.cmake include(CMakeFindDependencyMacro) find_depdency(PCAP) this way your exported targets will carry a link dependency to an imported target called PCAP and your PackageConfig.cmake will resolve that dependency for consuming projects. (Provided you install your FindPCAP.cmake and add the path to this file to CMAKE_MODULE_PATH) Clearer now? On Tue, Oct 20, 2015 at 8:24 AM, Zac Bergquist wrote: > I think I'm on the right track now. I was definitely missing the > add_library(PCAP IMPORTED) section. > > Could you elaborate on the last part? I thought target_link_libraries() > is the reason I'm getting absolute paths. Should I be using the > FindDependency macro instead of target_link_libraries()? > > > On Mon, Oct 19, 2015 at 9:54 PM, Guillaume Dumont < > dumont.guillaume at gmail.com> wrote: > >> Hi Zac, >> >> Sorry I read your post very quickly the first time... If your library >> uses its own FindPCAP.cmake then you can define an imported target for the >> PCAP libraries like so: >> >> # FindPCAP.cmake >> >> find_path(PCAP_INCLUDE_DIR pcap.h ... ) >> find_library(PCAP_LIBRARY pcap ... ) >> >> include(FindPackageHandleStandardArgs) >> find_package_handle_standard_args(PCAP DEFAULT_MSG PCAP_LIBRARY >> PCAP_INCLUDE_DIR) >> >> if(PCAP_FOUND AND NOT TARGET PCAP) >> add_library(PCAP IMPORTED) # you can(or should) also specify if it's a >> shared or static library >> set_target_properties(PCAP PROPERTIES IMPORTED_LOCATION ${PCAP_LIBRARY}) >> # also add the interface include directories here via >> set_target_properties >> set(PCAP_LIBRARIES PCAP) >> endif() >> >> then in your CMakeLists.txt: >> >> find_package(PCAP) >> >> target_link_libraries(mylib ${PCAP_LIBRARIES}) >> >> Install your FindPCAP.cmake with your exported targets so that you can >> use the FindDependencyMacro to resolve the dependency when a consuming >> project finds your library. >> >> Would that work for you? >> >> HTH >> >> Guillaume >> >> >> >> On Mon, Oct 19, 2015 at 7:06 PM, Pau Garcia i Quiles < >> pgquiles at elpauer.org> wrote: >> >>> Hello, >>> >>> In your case, what you need to do is to modify the config file >>> generation in the library (i. e. you will need to patch the third-party >>> library) so that the generated config file is relative. >>> >>> As an alternative, if you do not want to patch the third-party library, >>> try modifying the generated config file by replacing absolute prefixes with >>> a variable (to the cross-compilation sysroot) or relative paths. >>> >>> On Tue, Oct 20, 2015 at 1:02 AM, Zac Bergquist >>> wrote: >>> >>>> Yes, Pau, this is exactly my problem. Or more specifically, as the >>>> author of a library that uses CMake and depends on libpcap, how can I best >>>> structure and distribute the library to make it easy to use (and cross >>>> compile)? I would say using the system libpcap is strongly preferred over >>>> distributing a copy of it. >>>> >>>> That tutorial is very interesting. I'll have to take a closer look at >>>> it because the solution isn't jumping out at me. The tutorial shows a >>>> project that contains both a library and a program that links to that >>>> library in the same list file. In my case that would not be possible. >>>> Also, the library in the example has no dependencies so it wouldn't suffer >>>> from the absolute path issue I'm encountering. >>>> On Oct 19, 2015 5:36 PM, "Pau Garcia i Quiles" >>>> wrote: >>>> >>>>> Hi Dan, >>>>> >>>>> On a second read, it seems Zac's problem was actually finding the >>>>> dependency (libpcap) of a dependency. Or rather, making if findable, >>>>> because the second depenency contains an absolute path which is broken due >>>>> to cross-compilation. >>>>> >>>>> I have never used it but this page contains information on how to fix >>>>> the paths in the config file to be relative instead of absolute. That >>>>> should fix the problem: >>>>> >>>>> >>>>> https://cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file >>>>> >>>>> >>>>> >>>>> On Mon, Oct 19, 2015 at 11:15 PM, Dan Kegel wrote: >>>>> >>>>>> Well, that's one answer. But if you want to use system libpcap, it's >>>>>> not a very satisfying one. >>>>>> >>>>>> It's odd that pcap doesn't ship with a .pc file. >>>>>> I guess the pcap folks are hostile to pkgconfig because it's LGPL; see >>>>>> https://github.com/the-tcpdump-group/libpcap/issues/374 >>>>>> - Dan >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Oct 19, 2015 at 2:04 PM, Pau Garcia i Quiles < >>>>>> pgquiles at elpauer.org> wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Use ExternalProject to build libpcap as part of your project. Make >>>>>>> sure you use $ORIGIN in rpath everywhere. Install your application (and >>>>>>> your bundled libpcap) to /opt to avoid polluting the system. >>>>>>> >>>>>>> On Mon, Oct 19, 2015 at 10:37 PM, Zac Bergquist < >>>>>>> zbergquist99 at gmail.com> wrote: >>>>>>> >>>>>>>> Thank you for your reply, Guillaume. >>>>>>>> >>>>>>>> I understand that this is the expected behavior. I even linked to >>>>>>>> the documentation that says this is the expected behavior. What I don't >>>>>>>> understand is how to resolve it. Are you saying it is not possible to >>>>>>>> create a relocatable package unless all dependencies are also using CMake? >>>>>>>> That doesn't seem right. >>>>>>>> >>>>>>>> Should I be trying to write a package config file for libpcap, or >>>>>>>> is there a better way to approach this? >>>>>>>> >>>>>>>> On Sat, Oct 17, 2015 at 8:19 AM, Guillaume Dumont < >>>>>>>> dumont.guillaume at gmail.com> wrote: >>>>>>>> >>>>>>>>> What you are seeing is the expected behavior. You can get a >>>>>>>>> relocatable package if all your dependencies (in your case libcap) have >>>>>>>>> themselves relocatable package config files with exported targets. Then you >>>>>>>>> package should make use of find_dependency macro. >>>>>>>>> >>>>>>>>> On Fri, Oct 16, 2015 at 4:56 PM, Zac Bergquist < >>>>>>>>> zbergquist99 at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> I've created a sample project to replicate my issue in hopes that >>>>>>>>>> it would make it easier to troubleshoot. >>>>>>>>>> >>>>>>>>>> Thanks for any help, >>>>>>>>>> Zac >>>>>>>>>> >>>>>>>>>> https://github.com/zmb3/cmaketest >>>>>>>>>> >>>>>>>>>> On Mon, Oct 12, 2015 at 8:53 AM, Zac Bergquist < >>>>>>>>>> zbergquist99 at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> I'm trying to fix a project so that its output is relocatable. >>>>>>>>>>> The project is a library that itself depends on libpcap. My goal is to be >>>>>>>>>>> able to import the library into my CMake application and have CMake >>>>>>>>>>> automatically link libpcap with it. >>>>>>>>>>> >>>>>>>>>>> I'm using a toolchain file that invokes an ARM cross compiler, >>>>>>>>>>> sets CMAKE_INSTALL_PREFIX and appends it to CMAKE_FIND_ROOT_PATH. This all >>>>>>>>>>> seems to work well. >>>>>>>>>>> >>>>>>>>>>> What I'm seeing is that the exported files that get installed to >>>>>>>>>>> CMAKE_INSTALL_PREFIX contain absolute paths to libpcap on my machine, which >>>>>>>>>>> make them useless to other team members. >>>>>>>>>>> >>>>>>>>>>> The first thing I changed was to use >>>>>>>>>>> CONFIGURE_PACKAGE_CONFIG_FILE instead of CONFIGURE_FILE. This got rid of >>>>>>>>>>> absolute paths in the generated CMake config file. >>>>>>>>>>> >>>>>>>>>>> However, I still have absolute paths in the CMake target import >>>>>>>>>>> file that gets generated. The IMPORTED_LINK_INTERFACE_LIBRARIES target >>>>>>>>>>> property has an absolute path instead of one relative to >>>>>>>>>>> CMAKE_INSTALL_PREFIX. >>>>>>>>>>> >>>>>>>>>>> I've read the "Creating Relocatable Packages" [1] section of the >>>>>>>>>>> CMake packages documentation. I'm pretty sure this is what I'm running >>>>>>>>>>> into, but I don't quite understand how to solve it. The documentation says >>>>>>>>>>> that I should be using imported targets, but I'm not sure how to do so. >>>>>>>>>>> The library is just using its own FindPCAP.cmake file to locate libpcap. >>>>>>>>>>> >>>>>>>>>>> Does anyone know of an example of a CMake package that imports >>>>>>>>>>> other libraries? I could also try to create a minimal example project with >>>>>>>>>>> this setup if it would be helpful. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Zac >>>>>>>>>>> >>>>>>>>>>> [1]: >>>>>>>>>>> https://cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html#creating-relocatable-packages >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> Powered by www.kitware.com >>>>>>>>>> >>>>>>>>>> Please keep messages on-topic and check the CMake FAQ at: >>>>>>>>>> http://www.cmake.org/Wiki/CMake_FAQ >>>>>>>>>> >>>>>>>>>> Kitware offers various services to support the CMake community. >>>>>>>>>> For more information on each offering, please visit: >>>>>>>>>> >>>>>>>>>> CMake Support: http://cmake.org/cmake/help/support.html >>>>>>>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>>>>>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>>>>>>>> >>>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>>>> >>>>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>>>> http://public.kitware.com/mailman/listinfo/cmake >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Pau Garcia i Quiles >>>>>>> http://www.elpauer.org >>>>>>> (Due to my workload, I may need 10 days to answer) >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> 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 >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Pau Garcia i Quiles >>>>> http://www.elpauer.org >>>>> (Due to my workload, I may need 10 days to answer) >>>>> >>>> >>> >>> >>> -- >>> Pau Garcia i Quiles >>> http://www.elpauer.org >>> (Due to my workload, I may need 10 days to answer) >>> >>> -- >>> >>> 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 >>> >> >> >> >> -- >> Guillaume Dumont >> ========================= >> dumont.guillaume at gmail.com >> > > -- Guillaume Dumont ========================= dumont.guillaume at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From zbergquist99 at gmail.com Tue Oct 20 09:58:58 2015 From: zbergquist99 at gmail.com (Zac Bergquist) Date: Tue, 20 Oct 2015 09:58:58 -0400 Subject: [CMake] Creating relocatable packages In-Reply-To: References: Message-ID: Yes, that was exactly what I needed. Now my installed targets file has IMPORTED_LINK_INTERFACE_LIBRARIES "PCAP" instead of an absolute path, and the FindPCAP.cmake module kicks in and does what I would expect. Thanks again for your time - much appreciated. Zac On Tue, Oct 20, 2015 at 9:25 AM, Guillaume Dumont < dumont.guillaume at gmail.com> wrote: > Hi Zac, > > target_link_libraries will work with either full library paths or target > names including imported targets. > > You need to use target_link_libraries in your CMakeLists.txt and > find_dependency in your PackageConfig.cmake. Like so: > > in CMakeLists.txt: > > target_link_libraries(mylib ${PCAP_LIBRARIES}) > > in PackageConfig.cmake > > include(CMakeFindDependencyMacro) > find_depdency(PCAP) > > this way your exported targets will carry a link dependency to an imported > target called PCAP and your PackageConfig.cmake will resolve that > dependency for consuming projects. (Provided you install your > FindPCAP.cmake and add the path to this file to CMAKE_MODULE_PATH) > > Clearer now? > > > > > On Tue, Oct 20, 2015 at 8:24 AM, Zac Bergquist > wrote: > >> I think I'm on the right track now. I was definitely missing the >> add_library(PCAP IMPORTED) section. >> >> Could you elaborate on the last part? I thought target_link_libraries() >> is the reason I'm getting absolute paths. Should I be using the >> FindDependency macro instead of target_link_libraries()? >> >> >> On Mon, Oct 19, 2015 at 9:54 PM, Guillaume Dumont < >> dumont.guillaume at gmail.com> wrote: >> >>> Hi Zac, >>> >>> Sorry I read your post very quickly the first time... If your library >>> uses its own FindPCAP.cmake then you can define an imported target for the >>> PCAP libraries like so: >>> >>> # FindPCAP.cmake >>> >>> find_path(PCAP_INCLUDE_DIR pcap.h ... ) >>> find_library(PCAP_LIBRARY pcap ... ) >>> >>> include(FindPackageHandleStandardArgs) >>> find_package_handle_standard_args(PCAP DEFAULT_MSG PCAP_LIBRARY >>> PCAP_INCLUDE_DIR) >>> >>> if(PCAP_FOUND AND NOT TARGET PCAP) >>> add_library(PCAP IMPORTED) # you can(or should) also specify if it's a >>> shared or static library >>> set_target_properties(PCAP PROPERTIES IMPORTED_LOCATION >>> ${PCAP_LIBRARY}) >>> # also add the interface include directories here via >>> set_target_properties >>> set(PCAP_LIBRARIES PCAP) >>> endif() >>> >>> then in your CMakeLists.txt: >>> >>> find_package(PCAP) >>> >>> target_link_libraries(mylib ${PCAP_LIBRARIES}) >>> >>> Install your FindPCAP.cmake with your exported targets so that you can >>> use the FindDependencyMacro to resolve the dependency when a consuming >>> project finds your library. >>> >>> Would that work for you? >>> >>> HTH >>> >>> Guillaume >>> >>> >>> >>> On Mon, Oct 19, 2015 at 7:06 PM, Pau Garcia i Quiles < >>> pgquiles at elpauer.org> wrote: >>> >>>> Hello, >>>> >>>> In your case, what you need to do is to modify the config file >>>> generation in the library (i. e. you will need to patch the third-party >>>> library) so that the generated config file is relative. >>>> >>>> As an alternative, if you do not want to patch the third-party library, >>>> try modifying the generated config file by replacing absolute prefixes with >>>> a variable (to the cross-compilation sysroot) or relative paths. >>>> >>>> On Tue, Oct 20, 2015 at 1:02 AM, Zac Bergquist >>>> wrote: >>>> >>>>> Yes, Pau, this is exactly my problem. Or more specifically, as the >>>>> author of a library that uses CMake and depends on libpcap, how can I best >>>>> structure and distribute the library to make it easy to use (and cross >>>>> compile)? I would say using the system libpcap is strongly preferred over >>>>> distributing a copy of it. >>>>> >>>>> That tutorial is very interesting. I'll have to take a closer look at >>>>> it because the solution isn't jumping out at me. The tutorial shows a >>>>> project that contains both a library and a program that links to that >>>>> library in the same list file. In my case that would not be possible. >>>>> Also, the library in the example has no dependencies so it wouldn't suffer >>>>> from the absolute path issue I'm encountering. >>>>> On Oct 19, 2015 5:36 PM, "Pau Garcia i Quiles" >>>>> wrote: >>>>> >>>>>> Hi Dan, >>>>>> >>>>>> On a second read, it seems Zac's problem was actually finding the >>>>>> dependency (libpcap) of a dependency. Or rather, making if findable, >>>>>> because the second depenency contains an absolute path which is broken due >>>>>> to cross-compilation. >>>>>> >>>>>> I have never used it but this page contains information on how to fix >>>>>> the paths in the config file to be relative instead of absolute. That >>>>>> should fix the problem: >>>>>> >>>>>> >>>>>> https://cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Oct 19, 2015 at 11:15 PM, Dan Kegel wrote: >>>>>> >>>>>>> Well, that's one answer. But if you want to use system libpcap, >>>>>>> it's not a very satisfying one. >>>>>>> >>>>>>> It's odd that pcap doesn't ship with a .pc file. >>>>>>> I guess the pcap folks are hostile to pkgconfig because it's LGPL; >>>>>>> see >>>>>>> https://github.com/the-tcpdump-group/libpcap/issues/374 >>>>>>> - Dan >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Oct 19, 2015 at 2:04 PM, Pau Garcia i Quiles < >>>>>>> pgquiles at elpauer.org> wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Use ExternalProject to build libpcap as part of your project. Make >>>>>>>> sure you use $ORIGIN in rpath everywhere. Install your application (and >>>>>>>> your bundled libpcap) to /opt to avoid polluting the system. >>>>>>>> >>>>>>>> On Mon, Oct 19, 2015 at 10:37 PM, Zac Bergquist < >>>>>>>> zbergquist99 at gmail.com> wrote: >>>>>>>> >>>>>>>>> Thank you for your reply, Guillaume. >>>>>>>>> >>>>>>>>> I understand that this is the expected behavior. I even linked to >>>>>>>>> the documentation that says this is the expected behavior. What I don't >>>>>>>>> understand is how to resolve it. Are you saying it is not possible to >>>>>>>>> create a relocatable package unless all dependencies are also using CMake? >>>>>>>>> That doesn't seem right. >>>>>>>>> >>>>>>>>> Should I be trying to write a package config file for libpcap, or >>>>>>>>> is there a better way to approach this? >>>>>>>>> >>>>>>>>> On Sat, Oct 17, 2015 at 8:19 AM, Guillaume Dumont < >>>>>>>>> dumont.guillaume at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> What you are seeing is the expected behavior. You can get a >>>>>>>>>> relocatable package if all your dependencies (in your case libcap) have >>>>>>>>>> themselves relocatable package config files with exported targets. Then you >>>>>>>>>> package should make use of find_dependency macro. >>>>>>>>>> >>>>>>>>>> On Fri, Oct 16, 2015 at 4:56 PM, Zac Bergquist < >>>>>>>>>> zbergquist99 at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> I've created a sample project to replicate my issue in hopes >>>>>>>>>>> that it would make it easier to troubleshoot. >>>>>>>>>>> >>>>>>>>>>> Thanks for any help, >>>>>>>>>>> Zac >>>>>>>>>>> >>>>>>>>>>> https://github.com/zmb3/cmaketest >>>>>>>>>>> >>>>>>>>>>> On Mon, Oct 12, 2015 at 8:53 AM, Zac Bergquist < >>>>>>>>>>> zbergquist99 at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> I'm trying to fix a project so that its output is relocatable. >>>>>>>>>>>> The project is a library that itself depends on libpcap. My goal is to be >>>>>>>>>>>> able to import the library into my CMake application and have CMake >>>>>>>>>>>> automatically link libpcap with it. >>>>>>>>>>>> >>>>>>>>>>>> I'm using a toolchain file that invokes an ARM cross compiler, >>>>>>>>>>>> sets CMAKE_INSTALL_PREFIX and appends it to CMAKE_FIND_ROOT_PATH. This all >>>>>>>>>>>> seems to work well. >>>>>>>>>>>> >>>>>>>>>>>> What I'm seeing is that the exported files that get installed >>>>>>>>>>>> to CMAKE_INSTALL_PREFIX contain absolute paths to libpcap on my machine, >>>>>>>>>>>> which make them useless to other team members. >>>>>>>>>>>> >>>>>>>>>>>> The first thing I changed was to use >>>>>>>>>>>> CONFIGURE_PACKAGE_CONFIG_FILE instead of CONFIGURE_FILE. This got rid of >>>>>>>>>>>> absolute paths in the generated CMake config file. >>>>>>>>>>>> >>>>>>>>>>>> However, I still have absolute paths in the CMake target import >>>>>>>>>>>> file that gets generated. The IMPORTED_LINK_INTERFACE_LIBRARIES target >>>>>>>>>>>> property has an absolute path instead of one relative to >>>>>>>>>>>> CMAKE_INSTALL_PREFIX. >>>>>>>>>>>> >>>>>>>>>>>> I've read the "Creating Relocatable Packages" [1] section of >>>>>>>>>>>> the CMake packages documentation. I'm pretty sure this is what I'm running >>>>>>>>>>>> into, but I don't quite understand how to solve it. The documentation says >>>>>>>>>>>> that I should be using imported targets, but I'm not sure how to do so. >>>>>>>>>>>> The library is just using its own FindPCAP.cmake file to locate libpcap. >>>>>>>>>>>> >>>>>>>>>>>> Does anyone know of an example of a CMake package that imports >>>>>>>>>>>> other libraries? I could also try to create a minimal example project with >>>>>>>>>>>> this setup if it would be helpful. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Zac >>>>>>>>>>>> >>>>>>>>>>>> [1]: >>>>>>>>>>>> https://cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html#creating-relocatable-packages >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> Powered by www.kitware.com >>>>>>>>>>> >>>>>>>>>>> Please keep messages on-topic and check the CMake FAQ at: >>>>>>>>>>> http://www.cmake.org/Wiki/CMake_FAQ >>>>>>>>>>> >>>>>>>>>>> Kitware offers various services to support the CMake community. >>>>>>>>>>> For more information on each offering, please visit: >>>>>>>>>>> >>>>>>>>>>> CMake Support: http://cmake.org/cmake/help/support.html >>>>>>>>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>>>>>>>>> CMake Training Courses: >>>>>>>>>>> http://cmake.org/cmake/help/training.html >>>>>>>>>>> >>>>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>>>>> >>>>>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>>>>> http://public.kitware.com/mailman/listinfo/cmake >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Pau Garcia i Quiles >>>>>>>> http://www.elpauer.org >>>>>>>> (Due to my workload, I may need 10 days to answer) >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> 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 >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Pau Garcia i Quiles >>>>>> http://www.elpauer.org >>>>>> (Due to my workload, I may need 10 days to answer) >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Pau Garcia i Quiles >>>> http://www.elpauer.org >>>> (Due to my workload, I may need 10 days to answer) >>>> >>>> -- >>>> >>>> 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 >>>> >>> >>> >>> >>> -- >>> Guillaume Dumont >>> ========================= >>> dumont.guillaume at gmail.com >>> >> >> > > > -- > Guillaume Dumont > ========================= > dumont.guillaume at gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.atkins at kitware.com Tue Oct 20 11:21:22 2015 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Tue, 20 Oct 2015 11:21:22 -0400 Subject: [CMake] linking hared libraries In-Reply-To: References: Message-ID: > > On Mon, Oct 19, 2015 at 8:43 PM, Owen Alanzo Hogarth > wrote: > > Also you said the PROJECT() should only be defined once, but shouldn't > each > > cmakelists.txt contain a project() or else cmake complains at me. > > > According to the last paragraph of: > > https://cmake.org/cmake/help/v3.0/command/project.html > > you only need a PROJECT () in the top-level CMakeLists.txt... > While this is true, you only need it called once at the top level, there are use cases where you see multiple calls to project() in aa given tree. Usually this is in the case of adding independent third party libraries. For example, imagine a source tree like: /CMakeLists.txt /src/CMakeLists.txt /src/file1.cxx /src/file2.cxx /thirdparty/CMakeLists.txt /thirdparty/libfoo/CMakeLists.txt /thirdparty/libfoo/foo.h /thirdparty/libfoo/foo.cxx /thirdparty/libbar/CMakeLists.txt /thirdparty/libbar/bar.h /thirdparty/libbar/bar.cxx Here, you may have project() called in /CMakeLists.txt, /thirdparty/libfoo/CMakeLists.txt, and /thirdparty/libbar/CMakeLists.txt. This would mean that libfoo and libbar are are independent projects that can be built on their own, outside of the top level project. This is generally discouraged nowadays and is replaced by using ExternalProject but prior to that module it was a common way to create a "superbuild" of many CMake-based dependencies. You still see it's use in many projects that have been around a long time, i.e. VTK, ITK, etc. It's even how CMake itself manages building it's own version of it's dependencies (liblzma, libcurl, libarchive, etc.). -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamesbigler at gmail.com Tue Oct 20 11:36:55 2015 From: jamesbigler at gmail.com (James Bigler) Date: Tue, 20 Oct 2015 15:36:55 +0000 Subject: [CMake] cmake_check_build_system is causing a rebuild at "make install" In-Reply-To: <56252081.9040307@txcorp.com> References: <561D9B6B.9000207@txcorp.com> <561E4E55.8010606@gmail.com> <561E4FC4.10904@txcorp.com> <561E52C5.4090400@gmail.com> <56252081.9040307@txcorp.com> Message-ID: The cpp file dependency is generator specific. CMake supports cpp file dependency for Makefiles only. The solution we have works for any generator. The dependencies could be generated at configure time, and I have a local version used internally where I work that does this, but it's not a cure-all. This is a complex issue that I've gone into in the past on the list. I hope at some future point this can be made better. On Mon, Oct 19, 2015 at 10:55 AM JR Cary wrote: > Thanks for the response, James. Our workaround finally > was to do "make install/fast". > > A colleague pointed out that there is a bug report, > https://cmake.org/Bug/view.php?id=15801, > likely related to this. > > Is there something about CUDA that requires dependency generation > at build time? (I am used to the standard of "#include " following > that can be done before any build.) > > It would be nice if the CUDA dependency generation worked like regular > cpp file dependency generation so that cmake would be run only upon > change of files and that otherwise it did not have to be turned off > completely. > > Thanks! > > ....John > > On 10/18/15 10:03 PM, James Bigler wrote: > > This could be caused by CUDA generating dependencies and then needing to > load them at the next configure step. > > For our automated builds, where we don't rely on dependencies during > development (e.g. build one main target from scratch then throw it away), > we set the CMAKE_SUPPRESS_REGENERATION option to TRUE. This will prevent > CMake from configuring during the build. You can still configure manually > by running cmake. > > James > > On Wed, Oct 14, 2015 at 7:04 AM, Nils Gladitz > wrote: > >> On 14.10.2015 14:51, JR Cary wrote: >> >>> Thanks for your response. This is a big headache for us, as it slows >>> down >>> our builds tremendously. >>> >>> Is there any way to prevent or control this behavior? >>> >> >> I don't see how. You could modify the module itself I suppose but I'd >> expect that to break incremental builds. >> >> >> 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 >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hotsmileband at gmail.com Wed Oct 21 06:07:48 2015 From: hotsmileband at gmail.com (Andrew Zhilka) Date: Wed, 21 Oct 2015 13:07:48 +0300 Subject: [CMake] CMake add_definitions string definitions fails on OS X Message-ID: Hi all! I am using CMake and g++ on OS X 10.10. My problem is following: in CMakeLists.txt I add line: add_definitions(-DPROJECT_ROOT="${CMAKE_CURRENT_SOURCE_DIR}/../..") When I try to use PROJECT_ROOT in source code I can not build it. It says error: expected expression std::cout << PROJECT_ROOT; ^ expanded from here #define PROJECT_ROOT "...." I have tried the very same thing on Linux and it worked well. Could anyone, please, suggest anything? Regards, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From laasunde at hotmail.com Wed Oct 21 07:56:07 2015 From: laasunde at hotmail.com (Lars) Date: Wed, 21 Oct 2015 13:56:07 +0200 Subject: [CMake] cmake.exe build type from cmd Message-ID: Hello, Using CMake 3.3 on Windows 7 platform with VS2012. To build software I run; cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -G "Visual Studio 11" /path/to/source msbuild /m /p:Configuration=RelWithDebInfo INSTALL.wcxproj To help developers I would like to create a couple of scripts. Does cmake.exe provide any means to return the value of an cache entry? I would like to know the value of CMAKE_BUILD_TYPE. Do not want to parse the CMakeCache.txt file. Appreciate any input. kind regards, LarsA -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedric.doucet at inria.fr Wed Oct 21 08:58:50 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Wed, 21 Oct 2015 14:58:50 +0200 (CEST) Subject: [CMake] ExternalProject_Add and proxy In-Reply-To: <441454100.10862931.1445431751297.JavaMail.zimbra@inria.fr> Message-ID: <1490625109.10868163.1445432330435.JavaMail.zimbra@inria.fr> Hello, I try to download a library with ExternalProject_Add. The URL is correct and the CMake script works well, except when there is a proxy to define. The URL is : http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz After having set http_proxy=http://proxy.name.fr:1234 https_proxy=https://proxy.name.fr:1234 I can download the archive with: wget http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz But when I type 'make' to use the ExternalProject_Add command, I get (after some minutes): =========================================================================== [ 44%] Performing download step (download, verify and extract) for 'eigen' -- downloading... src='http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' dst='/home/cdoucet/Documents/soutien/matherials/simol/build/third-party/eigen/download/3.2.4.tar.gz' timeout='none' CMake Error at stamp/download-eigen.cmake:19 (message): error: downloading 'http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' failed status_code: 7 status_string: "Couldn't connect to server" log: About to connect() to bitbucket.org port 80 (#0) Trying 131.103.20.167... Connection timed out Trying 131.103.20.168... Connection timed out couldn't connect to host Closing connection #0 Couldn't connect to server =========================================================================== Do you know how to solve this problem? Thank you very much! C?dric Doucet -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.jackson at bluequartz.net Wed Oct 21 09:58:19 2015 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Wed, 21 Oct 2015 09:58:19 -0400 Subject: [CMake] Known issues with Xcode 6.x and CMake In-Reply-To: <5624CD8F.60709@googlemail.com> References: <5624CD8F.60709@googlemail.com> Message-ID: <84973ECA-3305-4057-8C88-C8DAFCEE2F93@bluequartz.net> > On Oct 19, 2015, at 7:01 AM, Gregor Jasny via CMake wrote: > > Hello, > > On 17/10/15 18:28, Michael Jackson wrote: >> Are there any known issues with Xcode 6.4 and CMake 3.3.x? I ask because in our project when we generate the Xcode project we end up with 2 or 3 executables listed in the drop down combo box. We also end up with lots of duplicate targets in the Xcode project. And the first time I open an Xcode project I have to click the ?autocreate schemes? button about 30 times (I counted). We have 127 targets in our project currently. >> >> Has anyone seen anything like this or have any comments? This is with Xcode 6.4 on OS X 10.10.5. > > We also have projects which trigger the "Autocreate?" dialog but so far I did not notice the behavior you described. > > Does this also happen after a complete re-configure with deleted build directory? > > Thanks, > Gregor > Yes, it happens each time I do a completely clean re-configure. I am still trying to figure out why we have multiple executables listed for some projects but not others. We build some ?MODULES? and we build actual dylibs. For the dylib targets there are only a single executable. For the MODULES however is where we get multiple executable targets for the same executable. It makes a long list even longer. i have spent some time trying to figure out the issues? We have lots of ?project()? commands in our CMakeLists.txt files spread out over the project and I am trying to figure out if this is part of the problem? We also setup dependencies between the plugins and the main application to ensure they are all built when ?ALL_BUILD? is used (Both on Xcode and Visual Studio). The Visual Studio 2013 generated solutions do not seem to have any issues so I think this is purely with the Xcode generators. ? Mike Jackson BlueQuartz Software. From srinivas.boppu at gmail.com Wed Oct 21 11:28:16 2015 From: srinivas.boppu at gmail.com (srinivas boppu) Date: Wed, 21 Oct 2015 17:28:16 +0200 Subject: [CMake] Python project using Cmake Message-ID: Hello All, I am new to cmake and its build and ctest system. I read some where that cmake default look for c++ compiler and we need to modify/configure the cmake to recongize the python files. I googled for the same but I couldn't find any concrete and complete example. Any pointers in this regard would be useful. Thanks in advance. -- Apologizing doesn't mean U r wrong & the other is right,It means that U value the relationship more than Ur ego... -------------- next part -------------- An HTML attachment was scrubbed... URL: From bouzim at gmail.com Wed Oct 21 11:35:47 2015 From: bouzim at gmail.com (D. Barbier) Date: Wed, 21 Oct 2015 17:35:47 +0200 Subject: [CMake] ExternalProject_Add and proxy In-Reply-To: <1490625109.10868163.1445432330435.JavaMail.zimbra@inria.fr> References: <441454100.10862931.1445431751297.JavaMail.zimbra@inria.fr> <1490625109.10868163.1445432330435.JavaMail.zimbra@inria.fr> Message-ID: On 2015-10-21 14:58 GMT+02:00 Cedric Doucet wrote: > > Hello, > > I try to download a library with ExternalProject_Add. > The URL is correct and the CMake script works well, except when there is a > proxy to define. > > The URL is : http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > > After having set > > http_proxy=http://proxy.name.fr:1234 > https_proxy=https://proxy.name.fr:1234 > > I can download the archive with: wget > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz Hello, Since you do not provide login/password to your proxy, it is stored elsewhere, either in ~/.netrc or ~/.wgetrc. Delete these files and you will encounter the same problem. > But when I type 'make' to use the ExternalProject_Add command, I get (after > some minutes): > =========================================================================== > [ 44%] Performing download step (download, verify and extract) for 'eigen' > -- downloading... > src='http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > > dst='/home/cdoucet/Documents/soutien/matherials/simol/build/third-party/eigen/download/3.2.4.tar.gz' > timeout='none' > CMake Error at stamp/download-eigen.cmake:19 (message): > error: downloading 'http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > failed [...] Try with http_proxy=http://your_login:your_password at proxy.name.fr:1234 Denis From cedric.doucet at inria.fr Wed Oct 21 12:07:41 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Wed, 21 Oct 2015 18:07:41 +0200 (CEST) Subject: [CMake] ExternalProject_Add and proxy In-Reply-To: References: <441454100.10862931.1445431751297.JavaMail.zimbra@inria.fr> <1490625109.10868163.1445432330435.JavaMail.zimbra@inria.fr> Message-ID: <836126578.10955247.1445443661335.JavaMail.zimbra@inria.fr> Hello Denis! Thank you for your answer. Actually, there is no login and no password. It's an academic proxy. So the initial syntax of http_proxy should to be correct. C?dric ----- Mail original ----- > De: "D. Barbier" > ?: "Cedric Doucet" > Cc: cmake at cmake.org > Envoy?: Mercredi 21 Octobre 2015 17:35:47 > Objet: Re: [CMake] ExternalProject_Add and proxy > > On 2015-10-21 14:58 GMT+02:00 Cedric Doucet wrote: > > > > Hello, > > > > I try to download a library with ExternalProject_Add. > > The URL is correct and the CMake script works well, except when there is a > > proxy to define. > > > > The URL is : http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > > > > After having set > > > > http_proxy=http://proxy.name.fr:1234 > > https_proxy=https://proxy.name.fr:1234 > > > > I can download the archive with: wget > > http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz > > Hello, > > Since you do not provide login/password to your proxy, it is stored > elsewhere, either in ~/.netrc or ~/.wgetrc. > Delete these files and you will encounter the same problem. > > > But when I type 'make' to use the ExternalProject_Add command, I get (after > > some minutes): > > =========================================================================== > > [ 44%] Performing download step (download, verify and extract) for 'eigen' > > -- downloading... > > src='http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > > > > dst='/home/cdoucet/Documents/soutien/matherials/simol/build/third-party/eigen/download/3.2.4.tar.gz' > > timeout='none' > > CMake Error at stamp/download-eigen.cmake:19 (message): > > error: downloading 'http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' > > failed > [...] > > Try with > http_proxy=http://your_login:your_password at proxy.name.fr:1234 > > Denis > From mkeeler at tenable.com Wed Oct 21 12:22:03 2015 From: mkeeler at tenable.com (Matthew Keeler) Date: Wed, 21 Oct 2015 16:22:03 +0000 Subject: [CMake] Python project using Cmake In-Reply-To: References: Message-ID: What are you trying to do? Are you trying to build Python C extensions? If so then the FindPythonLibs module will help you in that regard. It will determine if the Python development files are installed and populate variables with the necessary paths to provide to link_directories and include_directories. https://cmake.org/cmake/help/v3.3/module/FindPythonLibs.html Additionally there is the FindPythonInterp module which will find the Python interpreter for invoking via custom commands or execute_process. https://cmake.org/cmake/help/v3.3/module/FindPythonInterp.html Also if you aren?t actually compiling any C/C++ code it will speed up build system generation if you specify the languages as NONE during the project command invocation. That behavior is documented at: https://cmake.org/cmake/help/v3.3/command/project.html In the past I have used cmake even for pure Python projects to just get the benefits of generic packaging with cpack and to be able to use ctest. If this is the case for you then you may end up defining a bunch of functions/macros to do all the work as I did. -- Matt Keeler On October 21, 2015 at 11:28:28, srinivas boppu (srinivas.boppu at gmail.com) wrote: Hello All, I am new to cmake and its build and ctest system. I read some where that cmake default look for c++ compiler and we need to modify/configure the cmake to recongize the python files. I googled for the same but I couldn't find any concrete and complete example. Any pointers in this regard would be useful. Thanks in advance. -- Apologizing doesn't mean U r wrong & the other is right,It means that U value the relationship more than Ur ego... -- 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 dumont.guillaume at gmail.com Wed Oct 21 13:57:33 2015 From: dumont.guillaume at gmail.com (Guillaume Dumont) Date: Wed, 21 Oct 2015 13:57:33 -0400 Subject: [CMake] Creating relocatable packages In-Reply-To: References: Message-ID: Great! Always happy to help! On Tue, Oct 20, 2015 at 9:58 AM, Zac Bergquist wrote: > Yes, that was exactly what I needed. > > Now my installed targets file has IMPORTED_LINK_INTERFACE_LIBRARIES "PCAP" > instead of an absolute path, and the FindPCAP.cmake module kicks in and > does what I would expect. > > Thanks again for your time - much appreciated. > > Zac > > On Tue, Oct 20, 2015 at 9:25 AM, Guillaume Dumont < > dumont.guillaume at gmail.com> wrote: > >> Hi Zac, >> >> target_link_libraries will work with either full library paths or target >> names including imported targets. >> >> You need to use target_link_libraries in your CMakeLists.txt and >> find_dependency in your PackageConfig.cmake. Like so: >> >> in CMakeLists.txt: >> >> target_link_libraries(mylib ${PCAP_LIBRARIES}) >> >> in PackageConfig.cmake >> >> include(CMakeFindDependencyMacro) >> find_depdency(PCAP) >> >> this way your exported targets will carry a link dependency to an >> imported target called PCAP and your PackageConfig.cmake will resolve that >> dependency for consuming projects. (Provided you install your >> FindPCAP.cmake and add the path to this file to CMAKE_MODULE_PATH) >> >> Clearer now? >> >> >> >> >> On Tue, Oct 20, 2015 at 8:24 AM, Zac Bergquist >> wrote: >> >>> I think I'm on the right track now. I was definitely missing the >>> add_library(PCAP IMPORTED) section. >>> >>> Could you elaborate on the last part? I thought target_link_libraries() >>> is the reason I'm getting absolute paths. Should I be using the >>> FindDependency macro instead of target_link_libraries()? >>> >>> >>> On Mon, Oct 19, 2015 at 9:54 PM, Guillaume Dumont < >>> dumont.guillaume at gmail.com> wrote: >>> >>>> Hi Zac, >>>> >>>> Sorry I read your post very quickly the first time... If your library >>>> uses its own FindPCAP.cmake then you can define an imported target for the >>>> PCAP libraries like so: >>>> >>>> # FindPCAP.cmake >>>> >>>> find_path(PCAP_INCLUDE_DIR pcap.h ... ) >>>> find_library(PCAP_LIBRARY pcap ... ) >>>> >>>> include(FindPackageHandleStandardArgs) >>>> find_package_handle_standard_args(PCAP DEFAULT_MSG PCAP_LIBRARY >>>> PCAP_INCLUDE_DIR) >>>> >>>> if(PCAP_FOUND AND NOT TARGET PCAP) >>>> add_library(PCAP IMPORTED) # you can(or should) also specify if it's >>>> a shared or static library >>>> set_target_properties(PCAP PROPERTIES IMPORTED_LOCATION >>>> ${PCAP_LIBRARY}) >>>> # also add the interface include directories here via >>>> set_target_properties >>>> set(PCAP_LIBRARIES PCAP) >>>> endif() >>>> >>>> then in your CMakeLists.txt: >>>> >>>> find_package(PCAP) >>>> >>>> target_link_libraries(mylib ${PCAP_LIBRARIES}) >>>> >>>> Install your FindPCAP.cmake with your exported targets so that you can >>>> use the FindDependencyMacro to resolve the dependency when a consuming >>>> project finds your library. >>>> >>>> Would that work for you? >>>> >>>> HTH >>>> >>>> Guillaume >>>> >>>> >>>> >>>> On Mon, Oct 19, 2015 at 7:06 PM, Pau Garcia i Quiles < >>>> pgquiles at elpauer.org> wrote: >>>> >>>>> Hello, >>>>> >>>>> In your case, what you need to do is to modify the config file >>>>> generation in the library (i. e. you will need to patch the third-party >>>>> library) so that the generated config file is relative. >>>>> >>>>> As an alternative, if you do not want to patch the third-party >>>>> library, try modifying the generated config file by replacing absolute >>>>> prefixes with a variable (to the cross-compilation sysroot) or relative >>>>> paths. >>>>> >>>>> On Tue, Oct 20, 2015 at 1:02 AM, Zac Bergquist >>>> > wrote: >>>>> >>>>>> Yes, Pau, this is exactly my problem. Or more specifically, as the >>>>>> author of a library that uses CMake and depends on libpcap, how can I best >>>>>> structure and distribute the library to make it easy to use (and cross >>>>>> compile)? I would say using the system libpcap is strongly preferred over >>>>>> distributing a copy of it. >>>>>> >>>>>> That tutorial is very interesting. I'll have to take a closer look >>>>>> at it because the solution isn't jumping out at me. The tutorial shows a >>>>>> project that contains both a library and a program that links to that >>>>>> library in the same list file. In my case that would not be possible. >>>>>> Also, the library in the example has no dependencies so it wouldn't suffer >>>>>> from the absolute path issue I'm encountering. >>>>>> On Oct 19, 2015 5:36 PM, "Pau Garcia i Quiles" >>>>>> wrote: >>>>>> >>>>>>> Hi Dan, >>>>>>> >>>>>>> On a second read, it seems Zac's problem was actually finding the >>>>>>> dependency (libpcap) of a dependency. Or rather, making if findable, >>>>>>> because the second depenency contains an absolute path which is broken due >>>>>>> to cross-compilation. >>>>>>> >>>>>>> I have never used it but this page contains information on how to >>>>>>> fix the paths in the config file to be relative instead of absolute. That >>>>>>> should fix the problem: >>>>>>> >>>>>>> >>>>>>> https://cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Oct 19, 2015 at 11:15 PM, Dan Kegel wrote: >>>>>>> >>>>>>>> Well, that's one answer. But if you want to use system libpcap, >>>>>>>> it's not a very satisfying one. >>>>>>>> >>>>>>>> It's odd that pcap doesn't ship with a .pc file. >>>>>>>> I guess the pcap folks are hostile to pkgconfig because it's LGPL; >>>>>>>> see >>>>>>>> https://github.com/the-tcpdump-group/libpcap/issues/374 >>>>>>>> - Dan >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Oct 19, 2015 at 2:04 PM, Pau Garcia i Quiles < >>>>>>>> pgquiles at elpauer.org> wrote: >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Use ExternalProject to build libpcap as part of your project. Make >>>>>>>>> sure you use $ORIGIN in rpath everywhere. Install your application (and >>>>>>>>> your bundled libpcap) to /opt to avoid polluting the system. >>>>>>>>> >>>>>>>>> On Mon, Oct 19, 2015 at 10:37 PM, Zac Bergquist < >>>>>>>>> zbergquist99 at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Thank you for your reply, Guillaume. >>>>>>>>>> >>>>>>>>>> I understand that this is the expected behavior. I even linked >>>>>>>>>> to the documentation that says this is the expected behavior. What I don't >>>>>>>>>> understand is how to resolve it. Are you saying it is not possible to >>>>>>>>>> create a relocatable package unless all dependencies are also using CMake? >>>>>>>>>> That doesn't seem right. >>>>>>>>>> >>>>>>>>>> Should I be trying to write a package config file for libpcap, or >>>>>>>>>> is there a better way to approach this? >>>>>>>>>> >>>>>>>>>> On Sat, Oct 17, 2015 at 8:19 AM, Guillaume Dumont < >>>>>>>>>> dumont.guillaume at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> What you are seeing is the expected behavior. You can get a >>>>>>>>>>> relocatable package if all your dependencies (in your case libcap) have >>>>>>>>>>> themselves relocatable package config files with exported targets. Then you >>>>>>>>>>> package should make use of find_dependency macro. >>>>>>>>>>> >>>>>>>>>>> On Fri, Oct 16, 2015 at 4:56 PM, Zac Bergquist < >>>>>>>>>>> zbergquist99 at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> I've created a sample project to replicate my issue in hopes >>>>>>>>>>>> that it would make it easier to troubleshoot. >>>>>>>>>>>> >>>>>>>>>>>> Thanks for any help, >>>>>>>>>>>> Zac >>>>>>>>>>>> >>>>>>>>>>>> https://github.com/zmb3/cmaketest >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Oct 12, 2015 at 8:53 AM, Zac Bergquist < >>>>>>>>>>>> zbergquist99 at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> I'm trying to fix a project so that its output is >>>>>>>>>>>>> relocatable. The project is a library that itself depends on libpcap. My >>>>>>>>>>>>> goal is to be able to import the library into my CMake application and have >>>>>>>>>>>>> CMake automatically link libpcap with it. >>>>>>>>>>>>> >>>>>>>>>>>>> I'm using a toolchain file that invokes an ARM cross compiler, >>>>>>>>>>>>> sets CMAKE_INSTALL_PREFIX and appends it to CMAKE_FIND_ROOT_PATH. This all >>>>>>>>>>>>> seems to work well. >>>>>>>>>>>>> >>>>>>>>>>>>> What I'm seeing is that the exported files that get installed >>>>>>>>>>>>> to CMAKE_INSTALL_PREFIX contain absolute paths to libpcap on my machine, >>>>>>>>>>>>> which make them useless to other team members. >>>>>>>>>>>>> >>>>>>>>>>>>> The first thing I changed was to use >>>>>>>>>>>>> CONFIGURE_PACKAGE_CONFIG_FILE instead of CONFIGURE_FILE. This got rid of >>>>>>>>>>>>> absolute paths in the generated CMake config file. >>>>>>>>>>>>> >>>>>>>>>>>>> However, I still have absolute paths in the CMake target >>>>>>>>>>>>> import file that gets generated. The IMPORTED_LINK_INTERFACE_LIBRARIES >>>>>>>>>>>>> target property has an absolute path instead of one relative to >>>>>>>>>>>>> CMAKE_INSTALL_PREFIX. >>>>>>>>>>>>> >>>>>>>>>>>>> I've read the "Creating Relocatable Packages" [1] section of >>>>>>>>>>>>> the CMake packages documentation. I'm pretty sure this is what I'm running >>>>>>>>>>>>> into, but I don't quite understand how to solve it. The documentation says >>>>>>>>>>>>> that I should be using imported targets, but I'm not sure how to do so. >>>>>>>>>>>>> The library is just using its own FindPCAP.cmake file to locate libpcap. >>>>>>>>>>>>> >>>>>>>>>>>>> Does anyone know of an example of a CMake package that imports >>>>>>>>>>>>> other libraries? I could also try to create a minimal example project with >>>>>>>>>>>>> this setup if it would be helpful. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Zac >>>>>>>>>>>>> >>>>>>>>>>>>> [1]: >>>>>>>>>>>>> https://cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html#creating-relocatable-packages >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> Powered by www.kitware.com >>>>>>>>>>>> >>>>>>>>>>>> Please keep messages on-topic and check the CMake FAQ at: >>>>>>>>>>>> http://www.cmake.org/Wiki/CMake_FAQ >>>>>>>>>>>> >>>>>>>>>>>> Kitware offers various services to support the CMake community. >>>>>>>>>>>> For more information on each offering, please visit: >>>>>>>>>>>> >>>>>>>>>>>> CMake Support: http://cmake.org/cmake/help/support.html >>>>>>>>>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>>>>>>>>>> CMake Training Courses: >>>>>>>>>>>> http://cmake.org/cmake/help/training.html >>>>>>>>>>>> >>>>>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>>>>>> >>>>>>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>>>>>> http://public.kitware.com/mailman/listinfo/cmake >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Pau Garcia i Quiles >>>>>>>>> http://www.elpauer.org >>>>>>>>> (Due to my workload, I may need 10 days to answer) >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> 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 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Pau Garcia i Quiles >>>>>>> http://www.elpauer.org >>>>>>> (Due to my workload, I may need 10 days to answer) >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Pau Garcia i Quiles >>>>> http://www.elpauer.org >>>>> (Due to my workload, I may need 10 days to answer) >>>>> >>>>> -- >>>>> >>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> Guillaume Dumont >>>> ========================= >>>> dumont.guillaume at gmail.com >>>> >>> >>> >> >> >> -- >> Guillaume Dumont >> ========================= >> dumont.guillaume at gmail.com >> > > -- Guillaume Dumont ========================= dumont.guillaume at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisstankevitz at gmail.com Wed Oct 21 15:32:11 2015 From: chrisstankevitz at gmail.com (Chris Stankevitz) Date: Wed, 21 Oct 2015 12:32:11 -0700 Subject: [CMake] CMake way to achieve march=native Message-ID: Hi, What is the CMake way to get march=native? By "CMake way" I'm looking for something that is somewhat robust, works, doesnt' confuse CMake itself... perhaps even works if/when anyone is going to cross compile, etc. The cross-compile part isn't a requirement... I'm just trying to get you to understand what I'm after is not just to slop together a command that happens to work today. But if the only way is to slop something together then that's okay too. Thank you, Chris From chrisstankevitz at gmail.com Wed Oct 21 15:43:39 2015 From: chrisstankevitz at gmail.com (Chris Stankevitz) Date: Wed, 21 Oct 2015 12:43:39 -0700 Subject: [CMake] Asking CMake to setup compiler for c++11 Message-ID: Hi, Q: What is the "CMake way" to ask that the compiler be setup for c++11? FYI I could not find the answer at https://cmake.org/cmake/help/v3.4/search.html?q=c%2B%2B11 Thank you, Chris From dank at kegel.com Wed Oct 21 15:54:44 2015 From: dank at kegel.com (Dan Kegel) Date: Wed, 21 Oct 2015 12:54:44 -0700 Subject: [CMake] Asking CMake to setup compiler for c++11 In-Reply-To: References: Message-ID: Something like CMAKE_MINIMUM_REQUIRED(VERSION 3.1) SET(CMAKE_CXX_STANDARD 11) I think. On Wed, Oct 21, 2015 at 12:43 PM, Chris Stankevitz wrote: > Hi, > > Q: What is the "CMake way" to ask that the compiler be setup for c++11? > > FYI I could not find the answer at > https://cmake.org/cmake/help/v3.4/search.html?q=c%2B%2B11 > > Thank you, > > Chris > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From srinivas.boppu at gmail.com Wed Oct 21 16:21:35 2015 From: srinivas.boppu at gmail.com (srinivas boppu) Date: Thu, 22 Oct 2015 01:51:35 +0530 Subject: [CMake] Python project using Cmake In-Reply-To: References: Message-ID: Hi Matthew Keeler, Thanks for your quick reply. My project is a pure python project. I wanted to use cmake and ctest for testing my individual python modules. Later on, I might have some "tcl" scripts and may be some c++ sources in the same project. It would be great, if you could share your pure python project details and the macros or related documents. Thanks and Regards, Srinivas Boppu On Wed, Oct 21, 2015 at 9:52 PM, Matthew Keeler wrote: > What are you trying to do? Are you trying to build Python C extensions? If > so then the FindPythonLibs module will help you in that regard. It will > determine if the Python development files are installed and populate > variables with the necessary paths to provide to link_directories and > include_directories. > https://cmake.org/cmake/help/v3.3/module/FindPythonLibs.html > > Additionally there is the FindPythonInterp module which will find the > Python interpreter for invoking via custom commands or execute_process. > https://cmake.org/cmake/help/v3.3/module/FindPythonInterp.html > > Also if you aren?t actually compiling any C/C++ code it will speed up > build system generation if you specify the languages as NONE during the > project command invocation. That behavior is documented at: > https://cmake.org/cmake/help/v3.3/command/project.html > > In the past I have used cmake even for pure Python projects to just get > the benefits of generic packaging with cpack and to be able to use ctest. > If this is the case for you then you may end up defining a bunch of > functions/macros to do all the work as I did. > > -- > Matt Keeler > > On October 21, 2015 at 11:28:28, srinivas boppu (srinivas.boppu at gmail.com) > wrote: > > Hello All, > > I am new to cmake and its build and ctest system. I read some where that > cmake default look for c++ compiler and we need to modify/configure the > cmake to recongize the python files. > I googled for the same but I couldn't find any concrete and complete > example. > Any pointers in this regard would be useful. > > Thanks in advance. > > -- > Apologizing doesn't mean U r wrong & the other is right,It means that U > value the relationship more than Ur ego... > > -- > > 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 > > -- Apologizing doesn't mean U r wrong & the other is right,It means that U value the relationship more than Ur ego... -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Wed Oct 21 16:39:33 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 21 Oct 2015 16:39:33 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.4.0-rc2 is now ready! Message-ID: I am proud to announce the second CMake 3.4 release candidate. Sources and binaries are available at: https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.4 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.4/release/3.4.html Some of the more significant features of CMake 3.4 are: * The "if()" command learned a new "TEST" operator that evaluates to true if a given test name has been defined by the "add_test()" command. See policy "CMP0064". * The "install(DIRECTORY)" command "DESTINATION" option learned to support "generator expressions". * The "install(FILES)" command "DESTINATION" option learned to support "generator expressions". * CMake learned to honor "*.manifest" source files with MSVC tools. Manifest files named as sources of ".exe" and ".dll" targets will be merged with linker-generated manifests and embedded in the binary. Deprecated and Removed Features: * The "CMakeExpandImportedTargets" module is now documented as deprecated. See module documentation for an explanation. * The "CMAKE_USE_RELATIVE_PATHS" variable no longer has any effect. Previously it was partially implemented and unreliable. CMake 3.4 Release Notes *********************** Changes made since CMake 3.3 include the following. New Features ============ Generators ---------- * The "Visual Studio 14 2015" generator learned to select a Windows 10 SDK based on the value of the "CMAKE_SYSTEM_VERSION" variable and the SDKs available on the host. * CMake learned rudimentary support for the Apple Swift language. When using the "Xcode" generator with Xcode 6.1 or higher, one may enable the "Swift" language with the "enable_language()" command or the "project()" command (this is an error with other generators or when Xcode is too old). Then one may list ".swift" source files in targets for compilation. Commands -------- * The "find_program()" command learned a "NAMES_PER_DIR" option to consider all given "NAMES" in each directory before moving on to the next directory. * The "get_filename_component()" command learned a new "BASE_DIR" subcommand. This is used to specify a base directory when calculating an absolute path from a relative path. * The "if()" command learned a new "TEST" operator that evaluates to true if a given test name has been defined by the "add_test()" command. See policy "CMP0064". * The "install(DIRECTORY)" command "DESTINATION" option learned to support "generator expressions". * The "install(FILES)" command "DESTINATION" option learned to support "generator expressions". * The "string()" command learned a new "APPEND" subcommand. Variables --------- * The Makefile Generators and the "Ninja" generator learned to add compiler launcher tools like distcc and ccache along with the compiler for "C" and "CXX" languages. See the "CMAKE__COMPILER_LAUNCHER" variable and "_COMPILER_LAUNCHER" target property for details. * New "CMAKE_LINK_SEARCH_START_STATIC" and "CMAKE_LINK_SEARCH_END_STATIC" variables were introduced to initialize the "LINK_SEARCH_START_STATIC" and "LINK_SEARCH_END_STATIC" target properties, respectively. Properties ---------- * Visual Studio Generators learned to support additonal target properties to customize projects for NVIDIA Nsight Tegra Visual Studio Edition: * "ANDROID_ANT_ADDITIONAL_OPTIONS" * "ANDROID_ARCH" * "ANDROID_ASSETS_DIRECTORIES" * "ANDROID_JAR_DEPENDENCIES" * "ANDROID_JAR_DIRECTORIES" * "ANDROID_JAVA_SOURCE_DIR" * "ANDROID_NATIVE_LIB_DEPENDENCIES" * "ANDROID_NATIVE_LIB_DIRECTORIES" * "ANDROID_PROCESS_MAX" * "ANDROID_PROGUARD" * "ANDROID_PROGUARD_CONFIG_PATH" * "ANDROID_SECURE_PROPS_PATH" * "ANDROID_SKIP_ANT_STEP" * "ANDROID_STL_TYPE" * The "ARCHIVE_OUTPUT_DIRECTORY", "LIBRARY_OUTPUT_DIRECTORY", and "RUNTIME_OUTPUT_DIRECTORY" target properties learned to support "generator expressions". * The "SOURCE_DIR" and "BINARY_DIR" target properties were introduced to allow project code to query where a target is defined. * The "OUTPUT_NAME" target property and its variants learned to support "generator expressions". * A "TARGET_MESSAGES" global property was added to tell the Makefile Generators whether to generate commands to print output after each target is completed. * On Windows with MS-compatible tools, CMake learned to optionally generate a module definition (".def") file for "SHARED" libraries. See the "WINDOWS_EXPORT_ALL_SYMBOLS" target property. Modules ------- * The "ExternalProject" module "ExternalProject_Add()" function "GIT_SUBMODULES" option now also limits the set of submodules that are initialized in addition to the prior behavior of limiting the set of submodules that are updated. * The "ExternalProject" module learned new "USES_TERMINAL" arguments for giving steps exclusive terminal access. This is useful with the "Ninja" generator to monitor CMake superbuild progress and prevent CPU oversubscription. * The "FindBISON" module "BISON_TARGET" macro learned a new "DEFINES_FILE" option to specify a custom output header to be generated. * The "FindHDF5" module learend a new "HDF5_PREFER_PARALLEL" option allowing users to specify that a parallel HDF5 tool is preferred if both are available. * The "FindIce" module now provides imported targets. * The "FindJava" module learned to optionally find the "idlj" and "jarsigner" tools. * The "FindOpenSSL" module now provides imported targets. * The "FindOpenSSL" module learned a new "OPENSSL_USE_STATIC_LIBS" option to search only for static libraries. * The "FindPkgConfig" learned a new "pkg_get_variable()" command which may be used to query for arbitrary variables from a package (such as for related tools or data and plugin install paths). * The "FindProtobuf" module gained a new "protobuf_generate_python()" function to generate python sources from ".proto" files. * The "FindTIFF" module learned to search separately for debug and release variants. * The "FindwxWidgets" module learned to support version requests. * The "FindXercesC" module learned to search separately for debug and release variants. * The "FindZLIB" module learned to search separately for debug and release variants. * The "GNUInstallDirs" module learned special default values for certain installation prefixes according to the GNU Coding Standards and the Filesystem Hierarchy Standard. * The "UseJava" module "add_jar" function learned to support response files (e.g. "@srcs.txt") for source specification. * The "UseJava" module "install_jar" function learned new "DESTINATION" and "COMPONENT" options to specify the corresponding "install()" command options. * The "UseJava" module gained a new "create_javah" function to create C headers from Java classes. Generator Expressions --------------------- * A new "$" "generator expression" has been added. CTest ----- * CTest learned to optionally measure the CPU load during parallel testing and avoid starting tests that may cause the load to exceed a given threshold. See the "ctest(1)" command "--test-load" option, the "TestLoad" setting of the CTest Test Step, the "CTEST_TEST_LOAD" variable, and the "TEST_LOAD" option of the "ctest_test()" command. * "ctest(1)" learned options "--test-output-size-passed" and "-- test- output-size-failed" to customize the limit on test output size submitted when running as a Dashboard Client. CPack ----- * The "CPackDeb" module learned to set package dependencies per component. See variables: * "CPACK_DEBIAN__PACKAGE_BREAKS" * "CPACK_DEBIAN__PACKAGE_CONFLICTS" * "CPACK_DEBIAN__PACKAGE_ENHANCES" * "CPACK_DEBIAN__PACKAGE_PREDEPENDS" * "CPACK_DEBIAN__PACKAGE_PROVIDES" * "CPACK_DEBIAN__PACKAGE_RECOMMENDS" * "CPACK_DEBIAN__PACKAGE_REPLACES" * "CPACK_DEBIAN__PACKAGE_SUGGESTS" * The "CPack" module learned to package empty directories. * The "CPack" module gained a new setting, "CPACK_VERBATIM_VARIABLES", which can be used to ensure the cpack program receives the settings' values exactly as they were set, even if they contain CMake-special characters. For compatibility, it's off by default. Other ----- * The "Compile Features" functionality is now aware of features supported by GNU C compilers on Windows. * CMake learned to honor "*.manifest" source files with MSVC tools. Manifest files named as sources of ".exe" and ".dll" targets will be merged with linker-generated manifests and embedded in the binary. * The Concurrent Fortran 77 compiler is now supported. Its "compiler id" is "CCur". * "cmake(1)" gained a new "--trace-expand" command line option that is like "--trace" but expands variable references in the output. Deprecated and Removed Features =============================== * The "CMakeExpandImportedTargets" module is now documented as deprecated. See module documentation for an explanation. * The "CMAKE_USE_RELATIVE_PATHS" variable no longer has any effect. Previously it was partially implemented and unreliable. Other Changes ============= * The "CheckFunctionExists", "CheckLibraryExists", "CheckSymbolExists", and "FindThreads" modules learned to work in environments where only CXX is enabled. * The "CPackDeb" module now correctly excludes symlinks during package checksum calculation. * The "CPackDeb" no longer uses fakeroot and system tar program for packaging. * The "CPack" module no longer mangles settings with CMake-special characters when they're used as defaults for other settings. The macro "cpack_set_if_not_set", which was responsible for this, is now deprecated. * CMake no longer links executables with flags to export symbols unless the "ENABLE_EXPORTS" target property is set. See policy "CMP0065". * The "SONAME" field is no longer set for "MODULE" libraries created with the "add_library()" command. "MODULE" libraries are meant for explicit dynamic loading at runtime. They cannot be linked so "SONAME" is not useful. * The internal "CMAKE__COMPILE_OBJECT" rule variable now substitutes compiler include flags in a separate "" placeholder instead of the main "" placeholder. -------------------------------------------------------------------------- Changes made since CMake 3.4.0-rc1: Brad King (6): Revert topic 'compiler-features-solaris' Help: Add release note about compile rule placeholder changes (#15787) ExternalProject: Fix Git version report in error message (#15791) ExternalProject: Always use CMake builtin FindGit (#15791) Help: Document add_test expectations of test command (#15798) CMake 3.4.0-rc2 Derek Bruening (1): CTest: Set Content-Type header for http file upload (#15774) Gregor Jasny (1): Xcode: Adjust deployment target SDK version to host version James Johnston (1): Help: Document that SHARED libraries must export a symbol (#15775) Kevin Burge (1): cmake-mode.el: treat keywords as symbols Kevin Wojniak (1): CPackWIX: fix typos in documentation Ruslan Baratov (1): Help: Document that file(GLOB*) order is undefined Stephen Kelly (1): cmIfCommand: Issue CMP0054 warning with appropriate context. (#15802) Tamar Kranenburg (1): FindPostgreSQL: Search for version 9.5 From srinath.vadlamani at gmail.com Wed Oct 21 16:45:17 2015 From: srinath.vadlamani at gmail.com (Srinath Vadlamani) Date: Wed, 21 Oct 2015 14:45:17 -0600 Subject: [CMake] using source files in build directory Message-ID: Hello All, Is it possible to have CMake use source files in some particular order that are placed in the out-of-source build directory? This is allows for the convenience of having multiple builds in different build directories due to a few file changes while preserving the files themselves? Thanks, <>Srinath ================================= Srinath Vadlamani ================================= -------------- next part -------------- An HTML attachment was scrubbed... URL: From audiofanatic at gmail.com Wed Oct 21 17:18:28 2015 From: audiofanatic at gmail.com (Craig Scott) Date: Thu, 22 Oct 2015 08:18:28 +1100 Subject: [CMake] Asking CMake to setup compiler for c++11 Message-ID: > ---------- Forwarded message ---------- > From: Dan Kegel > To: Chris Stankevitz > Cc: cmake > Date: Wed, 21 Oct 2015 12:54:44 -0700 > Subject: Re: [CMake] Asking CMake to setup compiler for c++11 > Something like > > CMAKE_MINIMUM_REQUIRED(VERSION 3.1) > SET(CMAKE_CXX_STANDARD 11) > > I think. > > On Wed, Oct 21, 2015 at 12:43 PM, Chris Stankevitz > wrote: > > Hi, > > > > Q: What is the "CMake way" to ask that the compiler be setup for c++11? > > > > FYI I could not find the answer at > > https://cmake.org/cmake/help/v3.4/search.html?q=c%2B%2B11 > > > > Dan's answer is heading down the right track. Unfortunately, there is some unexpected behaviour in certain situations, such as when the compiler doesn't actually support C++11. For a full explanation of how to set up for C++11, see this article: http://crascit.com/2015/03/28/enabling-cxx11-in-cmake/ -- Craig Scott Melbourne, Australia http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisstankevitz at gmail.com Wed Oct 21 19:31:44 2015 From: chrisstankevitz at gmail.com (Chris Stankevitz) Date: Wed, 21 Oct 2015 16:31:44 -0700 Subject: [CMake] Asking CMake to setup compiler for c++11 In-Reply-To: References: Message-ID: On Wed, Oct 21, 2015 at 2:18 PM, Craig Scott wrote: >> CMAKE_MINIMUM_REQUIRED(VERSION 3.1) >> SET(CMAKE_CXX_STANDARD 11) > http://crascit.com/2015/03/28/enabling-cxx11-in-cmake/ Dan, Craig: Thanks that's great news, Chris From bouzim at gmail.com Thu Oct 22 05:21:59 2015 From: bouzim at gmail.com (D. Barbier) Date: Thu, 22 Oct 2015 11:21:59 +0200 Subject: [CMake] ExternalProject_Add and proxy In-Reply-To: <836126578.10955247.1445443661335.JavaMail.zimbra@inria.fr> References: <441454100.10862931.1445431751297.JavaMail.zimbra@inria.fr> <1490625109.10868163.1445432330435.JavaMail.zimbra@inria.fr> <836126578.10955247.1445443661335.JavaMail.zimbra@inria.fr> Message-ID: On 2015-10-21 18:07 GMT+02:00 Cedric Doucet wrote: > Hello Denis! > > Thank you for your answer. > Actually, there is no login and no password. > It's an academic proxy. > So the initial syntax of http_proxy should to be correct. Hello, CMake uses libcurl, so check your proxy settings with curl instead of wget. As libcurl does not use any config file, pass -q flag, this should be quite similar to libcurl and thus CMake. For instance, if curl -q -I https://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz works, CMake should work too. Denis From orion at cora.nwra.com Thu Oct 22 11:28:46 2015 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 22 Oct 2015 09:28:46 -0600 Subject: [CMake] [ANNOUNCE] CMake 3.4.0-rc1 is now ready! In-Reply-To: <56154C15.3030806@cora.nwra.com> References: <56148ABA.5070303@cora.nwra.com> <56154C15.3030806@cora.nwra.com> Message-ID: <562900AE.1060704@cora.nwra.com> On 10/07/2015 10:45 AM, Orion Poplawski wrote: > On 10/06/2015 09:00 PM, Orion Poplawski wrote: >> On 10/06/2015 09:42 AM, Robert Maynard wrote: >>> I am proud to announce the first CMake 3.4 release candidate. >> >> This appears to have broken plplot's ada build on Fedora. Previous good (cmake >> 3.3.2): >> >> [ 22%] Building Ada object examples/ada/CMakeFiles/x00a.dir/x00a.o >> cd /builddir/build/BUILD/plplot-5.11.1/fedora/examples/ada && /usr/bin/gnatgcc >> -I/builddir/build/BUILD/plplot-5.11.1/fedora/examples/ada >> -I/builddir/build/BUILD/plplot-5.11.1/bindings/ada -c >> /builddir/build/BUILD/plplot-5.11.1/examples/ada/x00a.adb -o >> CMakeFiles/x00a.dir/x00a.o >> >> New bad: >> >> [ 22%] Building Ada object examples/ada/CMakeFiles/x00a.dir/x00a.o >> cd /builddir/build/BUILD/plplot-5.11.1/fedora/examples/ada && >> /usr/bin/gnatgcc -c >> /builddir/build/BUILD/plplot-5.11.1/examples/ada/x00a.adb -o >> CMakeFiles/x00a.dir/x00a.o >> x00a.adb:28:05: file "plplot_auxiliary.ads" not found >> x00a.adb:29:05: file "plplot_traditional.ads" not found >> examples/ada/CMakeFiles/x00a.dir/build.make:65: recipe for target >> 'examples/ada/CMakeFiles/x00a.dir/x00a.o' failed >> >> So we're now missing the -I include dir options. >> >> That's all I have for now, I'll try to take a closer look later. >> > > There also appears to be a similar issue with building Paraview where the > MPI_INLCUDE_PATH is no longer being passed to the compile line. > FYI - builds still fail with cmake 3.4.0-rc2. Have had time to look at it closer. plplot issue seems to be triggered by a change in Ada_FLAGS: -Ada_FLAGS = -I/home/orion/fedora/plplot/plplot-5.11.1/build-3.3.2/examples/ada -I/home/orion/fedora/plplot/plplot-5.11.1/bindings/ada +Ada_FLAGS = but plplot I believe has custom Ada cmake platform support. I am still concerned about possible regressions here. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From brad.king at kitware.com Thu Oct 22 13:30:32 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 22 Oct 2015 13:30:32 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.4.0-rc1 is now ready! In-Reply-To: <562900AE.1060704@cora.nwra.com> References: <56148ABA.5070303@cora.nwra.com> <56154C15.3030806@cora.nwra.com> <562900AE.1060704@cora.nwra.com> Message-ID: <56291D38.6070409@kitware.com> On 10/22/2015 11:28 AM, Orion Poplawski wrote: >>> This appears to have broken plplot's ada build on Fedora. > > FYI - builds still fail with cmake 3.4.0-rc2. Have had time to look at it > closer. plplot issue seems to be triggered by a change in Ada_FLAGS: > > -Ada_FLAGS = > -I/home/orion/fedora/plplot/plplot-5.11.1/build-3.3.2/examples/ada > -I/home/orion/fedora/plplot/plplot-5.11.1/bindings/ada > +Ada_FLAGS = > > but plplot I believe has custom Ada cmake platform support. I am still > concerned about possible regressions here. Plplot's Ada support uses CMake internal APIs so it is plplot's responsibility to adapt to our changes: https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeAddNewLanguage.txt;hb=v3.4.0-rc2 Maintainers of external language support are responsible for porting it to each version of CMake as upstream changes are made. Our 3.4.0-rc2 release notes point out a change likely causing this problem: https://cmake.org/gitweb?p=cmake.git;a=blob;f=Help/release/3.4.rst;hb=v3.4.0-rc2#l271 * The internal "CMAKE__COMPILE_OBJECT" rule variable now substitutes compiler include flags in a separate "" placeholder instead of the main "" placeholder. Where Plplot currently writes: SET(CMAKE_Ada_COMPILE_OBJECT " -c -o ") try: if(NOT CMAKE_VERSION VERSION_LESS 3.4) set(CMAKE_Ada_COMPILE_OBJECT " -c -o ") else() set(CMAKE_Ada_COMPILE_OBJECT " -c -o ") endif() -Brad From tom.kacvinsky at vectorcast.com Thu Oct 22 13:40:40 2015 From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky) Date: Thu, 22 Oct 2015 13:40:40 -0400 Subject: [CMake] Finding debug Qt libraries without CMAKE_BUILD_TYPE set to None Message-ID: I have need to find the debug version of Qt libraries. From the documentation I read, the libraries found are based on the CMAKE_BUILD_TYPE vale. So it it is set to Release, the release versions are found, and if set to DEBUG, the debug versions are found. Unfortunately, due to use of Ada support from PLPlot, I cannot set it to eitehr of those values as then our Ada support craps out. So, how can I find the debug version of the libraries if CMAKE_BUILD_TYPE is set to NONE? Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkeeler at tenable.com Thu Oct 22 13:45:42 2015 From: mkeeler at tenable.com (Matthew Keeler) Date: Thu, 22 Oct 2015 17:45:42 +0000 Subject: [CMake] Python project using Cmake In-Reply-To: References: Message-ID: Sorry Srinivas, the projects was for a former employer of mine and I no longer have access to it. We were distributing ?scripts? as executable zip files (a lesser known feature of Python). So we had a few things going on. include(FindPythonInterp) configure_file(${CMAKE_CURRENT_SOURCE_DIR}/setup.py.in ${CMAKE_CURRENT_BINARY_DIR}/setup.py @ONLY) add_custom_command(${CMAKE_CURRENT_BINARY_DIR}/ COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_BINARY_DIR}/setup.py bdist -format zip COMMAND ?) For the add_custom_command we ran more commands after invoking python to run the setup.py file. The extra commands were to rename from the normal distutils name to the final name and to prepend a UNIX #!/usr/bin/env python text line to the zip file. In this way you can make a self contained ?executable? that on UNIX at least runs like any other binary. All of the add_custom_command logic to build these zip executables was put into a cmake function: https://cmake.org/cmake/help/v3.3/command/function.html If you do go the function route I would recommend taking a look at the CMakeParseArguments module it was very useful for me. https://cmake.org/cmake/help/v3.3/module/CMakeParseArguments.html Sorry I don?t have more specifics. -- Matt Keeler On October 21, 2015 at 16:21:36, srinivas boppu (srinivas.boppu at gmail.com) wrote: Hi Matthew Keeler, Thanks for your quick reply. My project is a pure python project. I wanted to use cmake and ctest for testing my individual python modules. Later on, I might have some "tcl" scripts and may be some c++ sources in the same project. It would be great, if you could share your pure python project details and the macros or related documents. Thanks and Regards, Srinivas Boppu On Wed, Oct 21, 2015 at 9:52 PM, Matthew Keeler > wrote: What are you trying to do? Are you trying to build Python C extensions? If so then the FindPythonLibs module will help you in that regard. It will determine if the Python development files are installed and populate variables with the necessary paths to provide to link_directories and include_directories. https://cmake.org/cmake/help/v3.3/module/FindPythonLibs.html Additionally there is the FindPythonInterp module which will find the Python interpreter for invoking via custom commands or execute_process. https://cmake.org/cmake/help/v3.3/module/FindPythonInterp.html Also if you aren?t actually compiling any C/C++ code it will speed up build system generation if you specify the languages as NONE during the project command invocation. That behavior is documented at: https://cmake.org/cmake/help/v3.3/command/project.html In the past I have used cmake even for pure Python projects to just get the benefits of generic packaging with cpack and to be able to use ctest. If this is the case for you then you may end up defining a bunch of functions/macros to do all the work as I did. -- Matt Keeler On October 21, 2015 at 11:28:28, srinivas boppu (srinivas.boppu at gmail.com) wrote: Hello All, I am new to cmake and its build and ctest system. I read some where that cmake default look for c++ compiler and we need to modify/configure the cmake to recongize the python files. I googled for the same but I couldn't find any concrete and complete example. Any pointers in this regard would be useful. Thanks in advance. -- Apologizing doesn't mean U r wrong & the other is right,It means that U value the relationship more than Ur ego... -- 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 -- Apologizing doesn't mean U r wrong & the other is right,It means that U value the relationship more than Ur ego... -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggarra13 at gmail.com Thu Oct 22 17:02:29 2015 From: ggarra13 at gmail.com (Gonzalo) Date: Thu, 22 Oct 2015 18:02:29 -0300 Subject: [CMake] using source files in build directory In-Reply-To: References: Message-ID: <56294EE5.5010507@gmail.com> El 21/10/15 a las 17:45, Srinath Vadlamani escribi?: > Hello All, > Is it possible to have CMake use source files in some particular > order that are placed in the out-of-source build directory? This is > allows for the convenience of having multiple builds in different > build directories due to a few file changes while preserving the files > themselves? > You are aware that you can do out of source builds, right? $ mkdir build-linux64 $ cd build-linux64 $ cmake .. # plus any options you want $ make -- Gonzalo Garramu?o ggarra13 at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From srinath.vadlamani at gmail.com Thu Oct 22 17:13:08 2015 From: srinath.vadlamani at gmail.com (Srinath Vadlamani) Date: Thu, 22 Oct 2015 15:13:08 -0600 Subject: [CMake] using source files in build directory In-Reply-To: <56294EE5.5010507@gmail.com> References: <56294EE5.5010507@gmail.com> Message-ID: Hello All, I am aware of out-of-source builds. I want to add modified source files to the out of source build directory and have CMake use these modified files. Below is my example: $pwd $ls CmakeLists.txt CMake README src tests doc ... $mkdir build1 $cd build1 $cp ../src/file1.cpp . $ $ccmake $make -j N $ Now I want to make another build directory that houses a few other modified files: $cd $mkdir build2 $cd build2 $cp ../src/file1.cpp . && cp ../src/file2.cpp . $ $ccmake $make -j N $ ..... and so on. The point is that the build directory allowing for modified source files helps preserve executables and the dependent source files for code management. Some may now chime in with opinions on version control usage, but I'm trying to understand if it is possible to do what I described and is possible with Autotools. Thank you for your time, <>Srinath ================================= Srinath Vadlamani ================================= On Thu, Oct 22, 2015 at 3:02 PM, Gonzalo wrote: > El 21/10/15 a las 17:45, Srinath Vadlamani escribi?: > > Hello All, > Is it possible to have CMake use source files in some particular order > that are placed in the out-of-source build directory? This is allows for > the convenience of having multiple builds in different build directories > due to a few file changes while preserving the files themselves? > > You are aware that you can do out of source builds, right? > > $ mkdir build-linux64 > $ cd build-linux64 > $ cmake .. # plus any options you want > $ make > > -- > Gonzalo Garramu?oggarra13 at gmail.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Thu Oct 22 19:05:48 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 22 Oct 2015 16:05:48 -0700 (PDT) Subject: [CMake] [ANNOUNCE] CMake 3.4.0-rc1 is now ready! In-Reply-To: <56291D38.6070409@kitware.com> References: <56148ABA.5070303@cora.nwra.com> <56154C15.3030806@cora.nwra.com> <562900AE.1060704@cora.nwra.com> <56291D38.6070409@kitware.com> Message-ID: On 2015-10-22 13:30-0400 Brad King wrote: > On 10/22/2015 11:28 AM, Orion Poplawski wrote: >>>> This appears to have broken plplot's ada build on Fedora. >> >> FYI - builds still fail with cmake 3.4.0-rc2. Have had time to look at it >> closer. plplot issue seems to be triggered by a change in Ada_FLAGS: >> >> -Ada_FLAGS = >> -I/home/orion/fedora/plplot/plplot-5.11.1/build-3.3.2/examples/ada >> -I/home/orion/fedora/plplot/plplot-5.11.1/bindings/ada >> +Ada_FLAGS = >> >> but plplot I believe has custom Ada cmake platform support. I am still >> concerned about possible regressions here. > > Plplot's Ada support uses CMake internal APIs so it is plplot's > responsibility to adapt to our changes: > > https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeAddNewLanguage.txt;hb=v3.4.0-rc2 > Maintainers of external language support are responsible for porting > it to each version of CMake as upstream changes are made. > > Our 3.4.0-rc2 release notes point out a change likely causing this problem: > > https://cmake.org/gitweb?p=cmake.git;a=blob;f=Help/release/3.4.rst;hb=v3.4.0-rc2#l271 > * The internal "CMAKE__COMPILE_OBJECT" rule variable now > substitutes compiler include flags in a separate "" > placeholder instead of the main "" placeholder. > > Where Plplot currently writes: > > SET(CMAKE_Ada_COMPILE_OBJECT > " -c -o > ") > > try: > > if(NOT CMAKE_VERSION VERSION_LESS 3.4) > set(CMAKE_Ada_COMPILE_OBJECT > " -c -o ") > else() > set(CMAKE_Ada_COMPILE_OBJECT > " -c -o ") > endif() Hi Brad: I will give your suggestion a try. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From johannes.zarl-zierl at jku.at Fri Oct 23 05:07:05 2015 From: johannes.zarl-zierl at jku.at (Johannes Zarl-Zierl) Date: Fri, 23 Oct 2015 11:07:05 +0200 Subject: [CMake] using source files in build directory In-Reply-To: References: <56294EE5.5010507@gmail.com> Message-ID: <3579886.TgVVy3LYrq@ersa> Hi, For header files, that's quite a normal thing to do - you just need to add the CMAKE_CURRENT_BINARY_DIR to your include directories. For .cpp files, you can write your target so that it is referencing the source file in the binary directory. I.e.: configure_file( ${CMAKE_CURRENT_SOURCE_DIRECTORY}/file1.cpp.in ${CMAKE_CURRENT_BINARY_DIRECTORY}/file1.cpp COPYONLY) add_executable( target1 ${CMAKE_CURRENT_BINARY_DIRECTORY}/file1.cpp) Is that sufficient for your needs? If you rather need a real wildcard way to override arbitrary source files, then you're probably out of luck. You could still write a wrapper around add_executable and add_library that inspects source directory and binary directory, but that might not be worth the effort... Johannes On Thursday 22 October 2015 15:13:08 Srinath Vadlamani wrote: > Hello All, > I am aware of out-of-source builds. I want to add modified source files > to the out of source build directory and have CMake use these modified > files. > > Below is my example: > $pwd > > $ls > CmakeLists.txt CMake README src tests doc ... > $mkdir build1 > $cd build1 > $cp ../src/file1.cpp . > $ > $ccmake > $make -j N > $ > > Now I want to make another build directory that houses a few other modified > files: > > $cd > $mkdir build2 > $cd build2 > $cp ../src/file1.cpp . && cp ../src/file2.cpp . > $ > $ccmake > $make -j N > $ but file2 mods helped> > > > ..... and so on. The point is that the build directory allowing for > modified source files helps preserve executables and the dependent source > files for code management. Some may now chime in with opinions on version > control usage, but I'm trying to understand if it is possible to do what I > described and is possible with Autotools. > > Thank you for your time, > <>Srinath > > ================================= > Srinath Vadlamani > ================================= > > On Thu, Oct 22, 2015 at 3:02 PM, Gonzalo wrote: > > El 21/10/15 a las 17:45, Srinath Vadlamani escribi?: > > > > Hello All, > > > > Is it possible to have CMake use source files in some particular order > > > > that are placed in the out-of-source build directory? This is allows for > > the convenience of having multiple builds in different build directories > > due to a few file changes while preserving the files themselves? > > > > You are aware that you can do out of source builds, right? > > > > $ mkdir build-linux64 > > $ cd build-linux64 > > $ cmake .. # plus any options you want > > $ make > > > > -- > > Gonzalo Garramu?oggarra13 at gmail.com From brad.king at kitware.com Fri Oct 23 09:19:07 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 23 Oct 2015 09:19:07 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.4.0-rc1 is now ready! In-Reply-To: <56154C15.3030806@cora.nwra.com> References: <56148ABA.5070303@cora.nwra.com> <56154C15.3030806@cora.nwra.com> Message-ID: <562A33CB.90207@kitware.com> On 10/07/2015 12:45 PM, Orion Poplawski wrote: > There also appears to be a similar issue with building Paraview where the > MPI_INLCUDE_PATH is no longer being passed to the compile line. Can you provide any more detail on this problem? There was only one change to FindMPI between 3.3.2 and 3.4.0-rc1 and I don't think it could cause this. Also ParaView and VTK are not using the internal CMake interface where the placeholder was added. Thanks, -Brad From tom.kacvinsky at vectorcast.com Fri Oct 23 09:38:19 2015 From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky) Date: Fri, 23 Oct 2015 09:38:19 -0400 Subject: [CMake] Finding debug Qt libraries without CMAKE_BUILD_TYPE set to None In-Reply-To: References: Message-ID: Here is what I tried for Qt4 (that is what I am using), using cmake 3.3.2 on Windows 7 find_package(Qt4 4.8.5 REQUIRED QtCore QtGui QtXml Qt3Support QtWebKit QtSql QtSvg QtNetwork QAxContainer) set_target_properties(Qt4::QtCore PROPERTIES MAP_IMPORTED_CONFIG_COVERAGE "DEBUG") set_target_properties(Qt4::QtGui PROPERTIES MAP_IMPORTED_CONFIG_COVERAGE "DEBUG") set_target_properties(Qt4::QtXml PROPERTIES MAP_IMPORTED_CONFIG_COVERAGE "DEBUG") set_target_properties(Qt4::Qt3Support PROPERTIES MAP_IMPORTED_CONFIG_COVERAGE "DEBUG") set_target_properties(Qt4::QtWebKit PROPERTIES MAP_IMPORTED_CONFIG_COVERAGE "DEBUG") set_target_properties(Qt4::QtSql PROPERTIES MAP_IMPORTED_CONFIG_COVERAGE "DEBUG") set_target_properties(Qt4::QtSvg PROPERTIES MAP_IMPORTED_CONFIG_COVERAGE "DEBUG") set_target_properties(Qt4::QtNetwork PROPERTIES MAP_IMPORTED_CONFIG_COVERAGE "DEBUG") set_target_properties(Qt4::QAxContainer PROPERTIES MAP_IMPORTED_CONFIG_COVERAGE "DEBUG") set(QT_LIBS Qt4::QtCore Qt4::QtGui Qt4::QtXml Qt4::Qt3Support Qt4::QtWebKit Qt4::QtSql Qt4::QtSvg Qt4::QtNetwork Qt4::QAxContainer) But apparently the set_target_properties trick only works with the FindQt5 module, as I am still getting the release version of the libraries. Any idea what I can do? I am guessing MAP_IMPORTED_CONFIG_COVERAGE is not the target property I want to set. Thanks, Tom On Thu, Oct 22, 2015 at 1:40 PM, Tom Kacvinsky wrote: > I have need to find the debug version of Qt libraries. From the > documentation I read, the libraries found are based on the CMAKE_BUILD_TYPE > vale. So it it is set to Release, the release versions are found, and if > set to DEBUG, the debug versions are found. Unfortunately, due to use of > Ada support from PLPlot, I cannot set it to eitehr of those values as then > our Ada support craps out. > > So, how can I find the debug version of the libraries if CMAKE_BUILD_TYPE > is set to NONE? > > Thanks, > > Tom > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.kacvinsky at vectorcast.com Fri Oct 23 10:01:41 2015 From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky) Date: Fri, 23 Oct 2015 10:01:41 -0400 Subject: [CMake] Finding debug Qt libraries without CMAKE_BUILD_TYPE set to None In-Reply-To: References: Message-ID: That was it, I had to replace MAP_IMPORTED_CONFIG_COVERAGE with MAP_IMPORTED_CONFIG_NONE as I have set(CMAKE_BUILD_TYPE NONE) I hope this is useful to others. On Fri, Oct 23, 2015 at 9:38 AM, Tom Kacvinsky wrote: > Here is what I tried for Qt4 (that is what I am using), using cmake 3.3.2 > on Windows 7 > > find_package(Qt4 4.8.5 REQUIRED QtCore QtGui QtXml Qt3Support QtWebKit > QtSql QtSvg QtNetwork QAxContainer) > > set_target_properties(Qt4::QtCore PROPERTIES > MAP_IMPORTED_CONFIG_COVERAGE "DEBUG") > set_target_properties(Qt4::QtGui PROPERTIES > MAP_IMPORTED_CONFIG_COVERAGE "DEBUG") > set_target_properties(Qt4::QtXml PROPERTIES > MAP_IMPORTED_CONFIG_COVERAGE "DEBUG") > set_target_properties(Qt4::Qt3Support PROPERTIES > MAP_IMPORTED_CONFIG_COVERAGE "DEBUG") > set_target_properties(Qt4::QtWebKit PROPERTIES > MAP_IMPORTED_CONFIG_COVERAGE "DEBUG") > set_target_properties(Qt4::QtSql PROPERTIES > MAP_IMPORTED_CONFIG_COVERAGE "DEBUG") > set_target_properties(Qt4::QtSvg PROPERTIES > MAP_IMPORTED_CONFIG_COVERAGE "DEBUG") > set_target_properties(Qt4::QtNetwork PROPERTIES > MAP_IMPORTED_CONFIG_COVERAGE "DEBUG") > set_target_properties(Qt4::QAxContainer PROPERTIES > MAP_IMPORTED_CONFIG_COVERAGE "DEBUG") > > set(QT_LIBS Qt4::QtCore Qt4::QtGui Qt4::QtXml Qt4::Qt3Support > Qt4::QtWebKit Qt4::QtSql Qt4::QtSvg Qt4::QtNetwork Qt4::QAxContainer) > > But apparently the set_target_properties trick only works with the FindQt5 > module, as I am still getting the release version of the libraries. Any > idea what I can do? I am guessing > > MAP_IMPORTED_CONFIG_COVERAGE > > is not the target property I want to set. > > Thanks, > > Tom > > > On Thu, Oct 22, 2015 at 1:40 PM, Tom Kacvinsky < > tom.kacvinsky at vectorcast.com> wrote: > >> I have need to find the debug version of Qt libraries. From the >> documentation I read, the libraries found are based on the CMAKE_BUILD_TYPE >> vale. So it it is set to Release, the release versions are found, and if >> set to DEBUG, the debug versions are found. Unfortunately, due to use of >> Ada support from PLPlot, I cannot set it to eitehr of those values as then >> our Ada support craps out. >> >> So, how can I find the debug version of the libraries if CMAKE_BUILD_TYPE >> is set to NONE? >> >> Thanks, >> >> Tom >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.kacvinsky at vectorcast.com Fri Oct 23 17:45:37 2015 From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky) Date: Fri, 23 Oct 2015 17:45:37 -0400 Subject: [CMake] Obtaining build time stamps Message-ID: Is there a way of tracking the time individual compiles take using cmake? What I am after is a cmake variable to set, or a cmake invocation option that will in the end generate Makefiles that output the time it takes for each compile/link. I am trying to track down a build performance issue and having this timing data to see what compiles are taking abnormally long would be extremely useful. Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.braun at ettus.com Fri Oct 23 20:35:26 2015 From: martin.braun at ettus.com (Martin Braun) Date: Fri, 23 Oct 2015 17:35:26 -0700 Subject: [CMake] add_dependencies being ignored for add_custom_command? Message-ID: <562AD24E.5030908@ettus.com> Hey, I'm at a loss here: I have a command that's run with add_custom_command(). I need to run it before compiling a library that I add with add_library(), because it generates some header files. This was my first try: file1: {{{ add_custom_command( OUTPUT foo.hpp COMMAND bar ) }}} file2: {{{ add_library(baz ${sources}) add_dependencies(baz ${CMAKE_BINARY_DIR}/path/to/foo.hpp) }}} ==> This didn't work. If I run make -j4, it will always try and compile my ${sources} before it ran the command. Maybe I'm specifying targets the wrong way? Next try: file1: {{{ add_custom_command(TARGET baz PRE_BUILD OUTPUT foo.hpp COMMAND bar ) }}} file2: {{{ add_library(baz ${sources}) }}} ==> Same behaviour. I'm using CMake 2.8.2.12. Really, I need something that works with CMake 2.8.0 because that's the minimum we guarantee our customers. Any ideas? Thanks in advance! Cheers, Martin From iosif.neitzke+cmake at gmail.com Fri Oct 23 21:21:17 2015 From: iosif.neitzke+cmake at gmail.com (Iosif Neitzke) Date: Fri, 23 Oct 2015 20:21:17 -0500 Subject: [CMake] add_dependencies being ignored for add_custom_command? In-Reply-To: <562AD24E.5030908@ettus.com> References: <562AD24E.5030908@ettus.com> Message-ID: The command "add_dependencies" [0] only works on targets. See the CMake Tutorial for how to generate files as part of the build that later targets rely on. [1]. [0] https://cmake.org/cmake/help/v2.8.12/cmake.html#command:add_dependencies [1] https://cmake.org/cmake-tutorial/#s5 On Fri, Oct 23, 2015 at 7:35 PM, Martin Braun wrote: > Hey, > > I'm at a loss here: > > I have a command that's run with add_custom_command(). I need to run it > before compiling a library that I add with add_library(), because it > generates some header files. > > This was my first try: > > file1: > {{{ > add_custom_command( > OUTPUT foo.hpp > COMMAND bar > ) > }}} > > file2: > {{{ > add_library(baz ${sources}) > add_dependencies(baz ${CMAKE_BINARY_DIR}/path/to/foo.hpp) > }}} > > ==> This didn't work. If I run make -j4, it will always try and compile > my ${sources} before it ran the command. Maybe I'm specifying targets > the wrong way? > > Next try: > > file1: > {{{ > add_custom_command(TARGET baz > PRE_BUILD > OUTPUT foo.hpp > COMMAND bar > ) > }}} > > file2: > {{{ > add_library(baz ${sources}) > }}} > > > ==> Same behaviour. > > I'm using CMake 2.8.2.12. Really, I need something that works with CMake > 2.8.0 because that's the minimum we guarantee our customers. > > Any ideas? Thanks in advance! > > Cheers, > Martin > -- > > 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 d3ck0r at gmail.com Sat Oct 24 01:09:58 2015 From: d3ck0r at gmail.com (J Decker) Date: Fri, 23 Oct 2015 22:09:58 -0700 Subject: [CMake] using source files in build directory In-Reply-To: <3579886.TgVVy3LYrq@ersa> References: <56294EE5.5010507@gmail.com> <3579886.TgVVy3LYrq@ersa> Message-ID: That's really more of a job for source control.... if you add like if( exists ) for each potential file you want to experiment with it could be done. On Fri, Oct 23, 2015 at 2:07 AM, Johannes Zarl-Zierl wrote: > Hi, > > For header files, that's quite a normal thing to do - you just need to add the > CMAKE_CURRENT_BINARY_DIR to your include directories. > > For .cpp files, you can write your target so that it is referencing the source > file in the binary directory. I.e.: > > configure_file( > ${CMAKE_CURRENT_SOURCE_DIRECTORY}/file1.cpp.in > ${CMAKE_CURRENT_BINARY_DIRECTORY}/file1.cpp COPYONLY) > add_executable( target1 ${CMAKE_CURRENT_BINARY_DIRECTORY}/file1.cpp) > > Is that sufficient for your needs? > > If you rather need a real wildcard way to override arbitrary source files, > then you're probably out of luck. You could still write a wrapper around > add_executable and add_library that inspects source directory and binary > directory, but that might not be worth the effort... > > Johannes > > On Thursday 22 October 2015 15:13:08 Srinath Vadlamani wrote: >> Hello All, >> I am aware of out-of-source builds. I want to add modified source files >> to the out of source build directory and have CMake use these modified >> files. >> >> Below is my example: >> $pwd >> >> $ls >> CmakeLists.txt CMake README src tests doc ... >> $mkdir build1 >> $cd build1 >> $cp ../src/file1.cpp . >> $ >> $ccmake >> $make -j N >> $ >> >> Now I want to make another build directory that houses a few other modified >> files: >> >> $cd >> $mkdir build2 >> $cd build2 >> $cp ../src/file1.cpp . && cp ../src/file2.cpp . >> $ >> $ccmake >> $make -j N >> $> but file2 mods helped> >> >> >> ..... and so on. The point is that the build directory allowing for >> modified source files helps preserve executables and the dependent source >> files for code management. Some may now chime in with opinions on version >> control usage, but I'm trying to understand if it is possible to do what I >> described and is possible with Autotools. >> >> Thank you for your time, >> <>Srinath >> >> ================================= >> Srinath Vadlamani >> ================================= >> >> On Thu, Oct 22, 2015 at 3:02 PM, Gonzalo wrote: >> > El 21/10/15 a las 17:45, Srinath Vadlamani escribi?: >> > >> > Hello All, >> > >> > Is it possible to have CMake use source files in some particular order >> > >> > that are placed in the out-of-source build directory? This is allows for >> > the convenience of having multiple builds in different build directories >> > due to a few file changes while preserving the files themselves? >> > >> > You are aware that you can do out of source builds, right? >> > >> > $ mkdir build-linux64 >> > $ cd build-linux64 >> > $ cmake .. # plus any options you want >> > $ make >> > >> > -- >> > Gonzalo Garramu?oggarra13 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 From peterhull90 at gmail.com Mon Oct 26 10:09:36 2015 From: peterhull90 at gmail.com (Peter Hull) Date: Mon, 26 Oct 2015 14:09:36 +0000 Subject: [CMake] CMake on 64-bit Visual Studio In-Reply-To: References: Message-ID: On Mon, 19 Oct 2015 at 12:37 Sergei Nikulov wrote: > 2015-10-19 13:01 GMT+03:00 Peter Hull : > > I have been trying to compile the Allegro library (http://liballeg.org/) > on > > Windows 64-bit using Visual Studio 2015. > One idea, how I've created workaround it for odbc lib: Thanks, Sergei. I quoted your answer on my StackOverflow question too, hope that's OK. Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.braun at ettus.com Mon Oct 26 13:32:42 2015 From: martin.braun at ettus.com (Martin Braun) Date: Mon, 26 Oct 2015 10:32:42 -0700 Subject: [CMake] add_dependencies being ignored for add_custom_command? In-Reply-To: References: <562AD24E.5030908@ettus.com> Message-ID: <562E63BA.5030906@ettus.com> Iosif, thanks for your answer. I have some follow-up questions, though: On 23.10.2015 18:21, Iosif Neitzke wrote: > The command "add_dependencies" [0] only works on targets. What exactly is a target? I thought if I do add_library(foo ${sources}), then 'foo' is a target? You seem to suggest otherwise, which means I'm misunderstanding some concepts. > See the CMake Tutorial for how to generate files as part of the build > that later targets rely on. [1]. This describes how add_custom_command() *itself* can declare dependencies, which is not my issue. My issue is that I need to run the custom command *before* I build a library (which I thought was a target). I would assume there's a way to declare this kind of dependency, but other than add_dependencies(), I can't seem to find anything. Thanks again, Martin > > [0] https://cmake.org/cmake/help/v2.8.12/cmake.html#command:add_dependencies > > [1] https://cmake.org/cmake-tutorial/#s5 > > On Fri, Oct 23, 2015 at 7:35 PM, Martin Braun wrote: >> Hey, >> >> I'm at a loss here: >> >> I have a command that's run with add_custom_command(). I need to run it >> before compiling a library that I add with add_library(), because it >> generates some header files. >> >> This was my first try: >> >> file1: >> {{{ >> add_custom_command( >> OUTPUT foo.hpp >> COMMAND bar >> ) >> }}} >> >> file2: >> {{{ >> add_library(baz ${sources}) >> add_dependencies(baz ${CMAKE_BINARY_DIR}/path/to/foo.hpp) >> }}} >> >> ==> This didn't work. If I run make -j4, it will always try and compile >> my ${sources} before it ran the command. Maybe I'm specifying targets >> the wrong way? >> >> Next try: >> >> file1: >> {{{ >> add_custom_command(TARGET baz >> PRE_BUILD >> OUTPUT foo.hpp >> COMMAND bar >> ) >> }}} >> >> file2: >> {{{ >> add_library(baz ${sources}) >> }}} >> >> >> ==> Same behaviour. >> >> I'm using CMake 2.8.2.12. Really, I need something that works with CMake >> 2.8.0 because that's the minimum we guarantee our customers. >> >> Any ideas? Thanks in advance! >> >> Cheers, >> Martin >> -- >> >> 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 fmilano at gmail.com Mon Oct 26 14:52:14 2015 From: fmilano at gmail.com (Federico Milano) Date: Mon, 26 Oct 2015 15:52:14 -0300 Subject: [CMake] CMake hangs on Found Git Message-ID: Hi. I've been using CMake for a while, and this is the first time I've found a problem I really cannot solve. I'm running cmake-gui on Windows 7, to build an MITK derived project. If Git is installed on the computer, the first time I run a Git "Configure", it hangs indefinitely in the line: Found Git: C:/Program Files/Git/cmd/git.exe I've tried turning off my AV (Bitdefender), but the only way I have made it work is by uninstalling Git. I've tried with CMake 2.8.12 and 3.3.2 and the way it fails with both versions is the same. I've tried with Git 2.5.2 and 2.6.2 and it hangs the same way. Do you know what command is run when it is printing the line "Found Git:..."? I would really appreciate any hint. Thanks in advance, Federico -------------- next part -------------- An HTML attachment was scrubbed... URL: From greenc at fnal.gov Mon Oct 26 15:29:31 2015 From: greenc at fnal.gov (Chris Green) Date: Mon, 26 Oct 2015 14:29:31 -0500 Subject: [CMake] add_test to support generator expressions? Message-ID: <562E7F1B.7000300@fnal.gov> Hi, I have a function cet_test(), which allows a user to specify the details of a test which will be executed via a wrapper, cet_exec_test. It calls the CMake add_test() macro to set this up. The user may subsequently set the SKIP_RETURN_CODE property on this test, which must be communicated to cet_exec_test() so that it can notify CMake if the test requirements are violated. I attempted to do this with: add_test(NAME ${target} ... COMMAND cet_exec_test ... --skip-return-code $ ...) but this resulted in an error. Am I using generator expressions wrongly in this case, or does add_test() not support them? Is there something else I can do? Thanks for any help, Chris. -- Chris Green , FNAL CS/SCD/ADSS/SSI/TAC; From iosif.neitzke+cmake at gmail.com Mon Oct 26 15:51:33 2015 From: iosif.neitzke+cmake at gmail.com (Iosif Neitzke) Date: Mon, 26 Oct 2015 14:51:33 -0500 Subject: [CMake] add_dependencies being ignored for add_custom_command? In-Reply-To: <562E63BA.5030906@ettus.com> References: <562AD24E.5030908@ettus.com> <562E63BA.5030906@ettus.com> Message-ID: On Mon, Oct 26, 2015 at 12:32 PM, Martin Braun wrote: > What exactly is a target? I thought if I do add_library(foo ${sources}), > then 'foo' is a target? You seem to suggest otherwise, which means I'm > misunderstanding some concepts. You are correct, "foo" is a target, but in one of your previous examples you had listed: add_dependencies(baz ${CMAKE_BINARY_DIR}/path/to/foo.hpp) Which should generate a warning like: "CMake Warning (dev) at CMakeLists.txt: (add_dependencies): Policy CMP0046 is not set: Error on non-existent dependency in add_dependencies. Run "cmake --help-policy CMP0046" for policy details. Use the cmake_policy command to set the policy and suppress this warning. The dependency target "/tmp/path/to/foo.hpp" of target "baz" does not exist. This warning is for project developers. Use -Wno-dev to suppress it." Here is the simplest code I can think of that creates files required by a target: add_custom_command( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/Header.hpp ${CMAKE_CURRENT_BINARY_DIR}/Header.cpp COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_CURRENT_BINARY_DIR}/Header.cpp COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_CURRENT_BINARY_DIR}/Header.hpp COMMENT "Running pre-build step for a target" ) add_library( somelib ${CMAKE_CURRENT_BINARY_DIR}/Header.hpp ${CMAKE_CURRENT_BINARY_DIR}/Header.cpp source.cpp ) target_include_directories( somelib PRIVATE ${CMAKE_CURRENT_BINARY_DIR} ) Which outputs: make -- Configuring done -- Generating done -- Build files have been written to: /home/iosif/tmp/prebuild_header_ex [ 33%] Running pre-build step for a target Scanning dependencies of target somelib [ 66%] Building CXX object CMakeFiles/Headers.dir/Header.cpp.o [100%] Building CXX object CMakeFiles/Headers.dir/source.cpp.o Linking CXX static library libsomelib.a [100%] Built target somelib From greenc at fnal.gov Mon Oct 26 16:10:14 2015 From: greenc at fnal.gov (Chris Green) Date: Mon, 26 Oct 2015 15:10:14 -0500 Subject: [CMake] add_test to support generator expressions? In-Reply-To: <562E7F1B.7000300@fnal.gov> References: <562E7F1B.7000300@fnal.gov> Message-ID: <562E88A6.8050506@fnal.gov> Hi, I should add that I am using CMake 3.3.2. Sorry for the omission, Chris. On 10/26/15 2:29 PM, Chris Green wrote: > Hi, > > I have a function cet_test(), which allows a user to specify the > details of a test which will be executed via a wrapper, cet_exec_test. > It calls the CMake add_test() macro to set this up. The user may > subsequently set the SKIP_RETURN_CODE property on this test, which > must be communicated to cet_exec_test() so that it can notify CMake if > the test requirements are violated. I attempted to do this with: > > add_test(NAME ${target} > ... > COMMAND cet_exec_test ... --skip-return-code > $ > ...) > > but this resulted in an error. Am I using generator expressions > wrongly in this case, or does add_test() not support them? Is there > something else I can do? > > Thanks for any help, > > Chris. -- Chris Green , FNAL CS/SCD/ADSS/SSI/TAC; From nilsgladitz at gmail.com Mon Oct 26 16:20:30 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 26 Oct 2015 21:20:30 +0100 Subject: [CMake] add_test to support generator expressions? In-Reply-To: <562E7F1B.7000300@fnal.gov> References: <562E7F1B.7000300@fnal.gov> Message-ID: <562E8B0E.6070706@gmail.com> On 26.10.2015 20:29, Chris Green wrote: > Hi, > > I have a function cet_test(), which allows a user to specify the > details of a test which will be executed via a wrapper, cet_exec_test. > It calls the CMake add_test() macro to set this up. The user may > subsequently set the SKIP_RETURN_CODE property on this test, which > must be communicated to cet_exec_test() so that it can notify CMake if > the test requirements are violated. I attempted to do this with: > > add_test(NAME ${target} > ... > COMMAND cet_exec_test ... --skip-return-code > $ > ...) > > but this resulted in an error. Am I using generator expressions > wrongly in this case, or does add_test() not support them? Is there > something else I can do? You did not mention what the error actually is but ... add_test() does support generator expressions in the command (as long as you are using the NAME/COMMAND signature; which you are). Tests are not targets; hence TARGET_PROPERTY does not work here unless you also happen to have an actual target with the same name as the test (which is possible but can't be inferred from your snippet) and you set the property of that target rather than the test. Nils From martin.braun at ettus.com Mon Oct 26 18:31:31 2015 From: martin.braun at ettus.com (Martin Braun) Date: Mon, 26 Oct 2015 15:31:31 -0700 Subject: [CMake] add_dependencies being ignored for add_custom_command? In-Reply-To: References: <562AD24E.5030908@ettus.com> <562E63BA.5030906@ettus.com> Message-ID: <562EA9C3.6060704@ettus.com> Gotcha, Iosif, thanks for clearing that up for me. To summarize, I should ... On 26.10.2015 12:51, Iosif Neitzke wrote: > [...] > add_library( somelib ${CMAKE_CURRENT_BINARY_DIR}/Header.hpp > ${CMAKE_CURRENT_BINARY_DIR}/Header.cpp source.cpp ) ...add the generated files as to the target. That leads me to another question, though (hopefully the last): If source.cpp depends on Header.hpp, is it guaranteed that Header.hpp will be generated before the compiler tries to compile source.cpp? Does the list order of the files inside add_library() matter? Cheers, Martin From Axel.Holzinger at alcnetworx.de Tue Oct 27 08:06:02 2015 From: Axel.Holzinger at alcnetworx.de (Holzinger, Axel (ALC NetworX GmbH)) Date: Tue, 27 Oct 2015 12:06:02 +0000 Subject: [CMake] include_external_msproject, add_dependencies and build type (debug/release) Message-ID: <55aeb29c647f428baa6dad210849bc35@exchange3.lawo.de> Hi list, I'm on my wits end with include_external_msproject, add_dependencies and build type. This is the situation: I have a CMake project with an external static library A which is included in the build via include_external_msproject, a static library B and a binary C. B is depemding on A C is depending on B My upper (above the directories for B and C) CMakeLists.txt looks like this: include_external_msproject(A ${CMAKE_SOURCE_DIR}/A.vcxproj) The CMakeLists.txt for B has these (and other) parts: cmake_policy(GET CMP0046 cmp) if (NOT cmp STREQUAL "OLD") cmake_policy(SET CMP0046 OLD) endif () add_dependencies (B A) cmake_policy(SET CMP0046 NEW) target_link_libraries(B ${CMAKE_BINARY_DIR}/Win32/${CMAKE_BUILD_TYPE}/A.lib) The CMakeLists.txt for C has these (and other) parts: target_link_libraries(C B) In reality there are othe libs too. I reduced complexity to make it easier to understand the scenario. The stuff above works fine for CMAKE_BUILD_TYPE=Debug, meaning in Visual Studio 2013 in the project build dependencies for B I see that it's depending on A and so the build order is A first then B. The project build dependencies for C say that the binary is depending on B and A and the build oreder is A first, then B and then C. Perfect. But with CMAKE_BUILD_TYPE=Release I see that B is depending on A, but C is ONLY depending on B, but NOT on A. Can anybody explain what's going on? Any hint would be greatly appreciated. Thank you Axel PS: I know that setting policies to OLD isn't the nice way, but I don't know of any other solution the depend on a external Visual Studio project. From brad.king at kitware.com Tue Oct 27 08:36:23 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 27 Oct 2015 08:36:23 -0400 Subject: [CMake] CMake hangs on Found Git In-Reply-To: References: Message-ID: <562F6FC7.3030502@kitware.com> On 10/26/2015 02:52 PM, Federico Milano wrote: > but the only way I have made it work is by uninstalling Git. [snip] > Do you know what command is run when it is printing the line "Found Git:..."? By the time that prints then most of the Git operations should be finished. Run "cmake" from the command line and add the "--trace" option to get verbose output about what it is doing. That may show what is happening when the hang occurs. -Brad From greenc at fnal.gov Tue Oct 27 09:33:28 2015 From: greenc at fnal.gov (Chris Green) Date: Tue, 27 Oct 2015 08:33:28 -0500 Subject: [CMake] add_test to support generator expressions? In-Reply-To: <562E8B0E.6070706@gmail.com> References: <562E7F1B.7000300@fnal.gov> <562E8B0E.6070706@gmail.com> Message-ID: <562F7D28.4000704@fnal.gov> Ah, I see. It appears I was unclear on the difference between target and test. What I actually want is the *test* property SKIP_RETURN_CODE, which there does not seem to be any way to access via a generator expression. Looks like I'm out of look, unless this is an upcoming feature? Thanks for the clarification, Chris. On 10/26/15 3:20 PM, Nils Gladitz wrote: > On 26.10.2015 20:29, Chris Green wrote: >> Hi, >> >> I have a function cet_test(), which allows a user to specify the >> details of a test which will be executed via a wrapper, >> cet_exec_test. It calls the CMake add_test() macro to set this up. >> The user may subsequently set the SKIP_RETURN_CODE property on this >> test, which must be communicated to cet_exec_test() so that it can >> notify CMake if the test requirements are violated. I attempted to do >> this with: >> >> add_test(NAME ${target} >> ... >> COMMAND cet_exec_test ... --skip-return-code >> $ >> ...) >> >> but this resulted in an error. Am I using generator expressions >> wrongly in this case, or does add_test() not support them? Is there >> something else I can do? > > You did not mention what the error actually is but ... > > add_test() does support generator expressions in the command (as long > as you are using the NAME/COMMAND signature; which you are). > Tests are not targets; hence TARGET_PROPERTY does not work here unless > you also happen to have an actual target with the same name as the > test (which is possible but can't be inferred from your snippet) and > you set the property of that target rather than the test. > > Nils > -- Chris Green , FNAL CS/SCD/ADSS/SSI/TAC; 'phone (630) 840-2167; Skype: chris.h.green; IM: greenc at jabber.fnal.gov, chissgreen (AIM), chris.h.green (Google Talk). From nilsgladitz at gmail.com Tue Oct 27 10:24:24 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 27 Oct 2015 15:24:24 +0100 Subject: [CMake] add_test to support generator expressions? In-Reply-To: <562F7D28.4000704@fnal.gov> References: <562E7F1B.7000300@fnal.gov> <562E8B0E.6070706@gmail.com> <562F7D28.4000704@fnal.gov> Message-ID: <562F8918.4020601@gmail.com> On 10/27/2015 02:33 PM, Chris Green wrote: > Ah, I see. It appears I was unclear on the difference between target > and test. What I actually want is the *test* property > SKIP_RETURN_CODE, which there does not seem to be any way to access > via a generator expression. Looks like I'm out of look, unless this is > an upcoming feature? I haven't heard of anyone working on this and it is certainly too late for 3.4 but if you make it a feature request on the issue tracker you might be lucky and someone might pick it up eventually. Or better yet you could consider contributing it yourself. [1] Nils [1] https://cmake.org/gitweb?p=cmake.git;a=blob;f=CONTRIBUTING.rst From DLRdave at aol.com Tue Oct 27 12:08:19 2015 From: DLRdave at aol.com (David Cole) Date: Tue, 27 Oct 2015 12:08:19 -0400 Subject: [CMake] include_external_msproject, add_dependencies and build type (debug/release) In-Reply-To: <55aeb29c647f428baa6dad210849bc35@exchange3.lawo.de> References: <55aeb29c647f428baa6dad210849bc35@exchange3.lawo.de> Message-ID: CMAKE_BUILD_TYPE is not typically used/useful with the Visual Studio generators. You may want to look into using the CMAKE_CFG_INTDIR variable instead. https://cmake.org/cmake/help/v3.3/variable/CMAKE_CFG_INTDIR.html On Tue, Oct 27, 2015 at 8:06 AM, Holzinger, Axel (ALC NetworX GmbH) wrote: > Hi list, > > I'm on my wits end with include_external_msproject, add_dependencies and build type. > > This is the situation: I have a CMake project with an external static library A which is included in the build via include_external_msproject, a static library B and a binary C. > > B is depemding on A > C is depending on B > > My upper (above the directories for B and C) CMakeLists.txt looks like this: > > include_external_msproject(A ${CMAKE_SOURCE_DIR}/A.vcxproj) > > The CMakeLists.txt for B has these (and other) parts: > > cmake_policy(GET CMP0046 cmp) > if (NOT cmp STREQUAL "OLD") > cmake_policy(SET CMP0046 OLD) > endif () > add_dependencies (B A) > cmake_policy(SET CMP0046 NEW) > target_link_libraries(B ${CMAKE_BINARY_DIR}/Win32/${CMAKE_BUILD_TYPE}/A.lib) > > The CMakeLists.txt for C has these (and other) parts: > > target_link_libraries(C B) > > In reality there are othe libs too. I reduced complexity to make it easier to understand the scenario. > > The stuff above works fine for CMAKE_BUILD_TYPE=Debug, meaning in Visual Studio 2013 in the project build dependencies for B I see that it's depending on A and so the build order is A first then B. The project build dependencies for C say that the binary is depending on B and A and the build oreder is A first, then B and then C. > > Perfect. > > But with CMAKE_BUILD_TYPE=Release I see that B is depending on A, but C is ONLY depending on B, but NOT on A. > > Can anybody explain what's going on? Any hint would be greatly appreciated. > > Thank you > Axel > > PS: I know that setting policies to OLD isn't the nice way, but I don't know of any other solution the depend on a external Visual Studio project. > > -- > > 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 Axel.Holzinger at alcnetworx.de Tue Oct 27 12:15:35 2015 From: Axel.Holzinger at alcnetworx.de (Holzinger, Axel (ALC NetworX GmbH)) Date: Tue, 27 Oct 2015 16:15:35 +0000 Subject: [CMake] include_external_msproject, add_dependencies and build type (debug/release) In-Reply-To: References: <55aeb29c647f428baa6dad210849bc35@exchange3.lawo.de> Message-ID: Hi David, thank you. I'll take a look at it. But it's not a problem finding/linking to the external libs. The problem is the dependencies. If I add the dependencies to every linked binary (in contrast to a lib) it works. What doesn't work is having a lib being dependent on an external lib and having the binary being dependendent from the lib and automatically adding dependendies from the other (external) lib. Regards Axel On Tue, Oct 27, 2015 at 5:08 PM, David Cole wrote: > CMAKE_BUILD_TYPE is not typically used/useful with the Visual > Studio generators. You may want to look into using the > CMAKE_CFG_INTDIR variable instead. > > https://cmake.org/cmake/help/v3.3/variable/CMAKE_CFG_INTDIR.html > > > > On Tue, Oct 27, 2015 at 8:06 AM, Holzinger, Axel (ALC NetworX > GmbH) wrote: > > Hi list, > > > > I'm on my wits end with include_external_msproject, > add_dependencies and build type. > > > > This is the situation: I have a CMake project with an external > static library A which is included in the build via > include_external_msproject, a static library B and a binary C. > > > > B is depemding on A > > C is depending on B > > > > My upper (above the directories for B and C) CMakeLists.txt > looks like this: > > > > include_external_msproject(A ${CMAKE_SOURCE_DIR}/A.vcxproj) > > > > The CMakeLists.txt for B has these (and other) parts: > > > > cmake_policy(GET CMP0046 cmp) > > if (NOT cmp STREQUAL "OLD") > > cmake_policy(SET CMP0046 OLD) > > endif () > > add_dependencies (B A) > > cmake_policy(SET CMP0046 NEW) > > target_link_libraries(B > > ${CMAKE_BINARY_DIR}/Win32/${CMAKE_BUILD_TYPE}/A.lib) > > > > The CMakeLists.txt for C has these (and other) parts: > > > > target_link_libraries(C B) > > > > In reality there are othe libs too. I reduced complexity to > make it easier to understand the scenario. > > > > The stuff above works fine for CMAKE_BUILD_TYPE=Debug, meaning > in Visual Studio 2013 in the project build dependencies for B I > see that it's depending on A and so the build order is A first > then B. The project build dependencies for C say that the binary > is depending on B and A and the build oreder is A first, then B > and then C. > > > > Perfect. > > > > But with CMAKE_BUILD_TYPE=Release I see that B is depending on > A, but C is ONLY depending on B, but NOT on A. > > > > Can anybody explain what's going on? Any hint would be greatly > appreciated. > > > > Thank you > > Axel > > > > PS: I know that setting policies to OLD isn't the nice way, but > I don't know of any other solution the depend on a external > Visual Studio project. > > > > -- > > > > 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 steveire at gmail.com Tue Oct 27 14:58:27 2015 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 27 Oct 2015 19:58:27 +0100 Subject: [CMake] add_test to support generator expressions? References: <562E7F1B.7000300@fnal.gov> <562E8B0E.6070706@gmail.com> <562F7D28.4000704@fnal.gov> Message-ID: Chris Green wrote: > Ah, I see. It appears I was unclear on the difference between target and > test. What I actually want is the *test* property SKIP_RETURN_CODE, > which there does not seem to be any way to access via a generator > expression. Looks like I'm out of look, unless this is an upcoming > feature? Generator expressions are generally only useful for things which are determined at generate-time. Can't you just read the test property at configure-time instead? You're the one setting the property, right? Thanks, Steve. From nilsgladitz at gmail.com Tue Oct 27 15:28:38 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 27 Oct 2015 20:28:38 +0100 Subject: [CMake] add_test to support generator expressions? In-Reply-To: References: <562E7F1B.7000300@fnal.gov> <562E8B0E.6070706@gmail.com> <562F7D28.4000704@fnal.gov> Message-ID: <562FD066.1040006@gmail.com> On 27.10.2015 19:58, Stephen Kelly wrote: > Chris Green wrote: > >> Ah, I see. It appears I was unclear on the difference between target and >> test. What I actually want is the *test* property SKIP_RETURN_CODE, >> which there does not seem to be any way to access via a generator >> expression. Looks like I'm out of look, unless this is an upcoming >> feature? > Generator expressions are generally only useful for things which are > determined at generate-time. > > Can't you just read the test property at configure-time instead? You're the > one setting the property, right? Deferring evaluation to generation time does have the advantage that you can set and change properties at any point after the test has been created and you can still be sure that the test is invoked with the final value. Without the generator expression reading the property at configuration time is not really an option because the test's properties will not exist before add_test() and the test command itself is what was referring to that property. You'd have to reorder logic so that the parameter for --skip-return-code is known before add_test() (and use e.g. variables or (custom) target properties). Nils From steveire at gmail.com Tue Oct 27 15:49:07 2015 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 27 Oct 2015 20:49:07 +0100 Subject: [CMake] add_test to support generator expressions? References: <562E7F1B.7000300@fnal.gov> <562E8B0E.6070706@gmail.com> <562F7D28.4000704@fnal.gov> <562FD066.1040006@gmail.com> Message-ID: Nils Gladitz wrote: > On 27.10.2015 19:58, Stephen Kelly wrote: >> Chris Green wrote: >> >>> Ah, I see. It appears I was unclear on the difference between target and >>> test. What I actually want is the *test* property SKIP_RETURN_CODE, >>> which there does not seem to be any way to access via a generator >>> expression. Looks like I'm out of look, unless this is an upcoming >>> feature? >> Generator expressions are generally only useful for things which are >> determined at generate-time. >> >> Can't you just read the test property at configure-time instead? You're >> the one setting the property, right? > > Deferring evaluation to generation time does have the advantage that you > can set and change properties at any point after the test has been > created and you can still be sure that the test is invoked with the > final value. Right. What I missed is that Chris seems to be making an interface for other unknown downstreams to use (a cet_test function). It would be possible to require the user of cet_test to specify the SKIP_RETURN_CODE in a parameter, but there would be unexpected behavior if someone omitted that parameter and wrote cet_test(mytest ...) set_test_property(mytest PROPERTIES SKIP_RETURN_CODE ...) instead. A lot of effort went into cmake targets to make wrappers like kde4_add_executable/kde4_add_library unnecessary, and generator expressions were a part of that. Perhaps it makes sense to put similar effort into making add_test wrappers unnecessary, and generator expressions for test properties could be part of that. However, I don't have so much experience with doing beyond-basic things with ctest, so I don't know what kinds of issues arise which lead people to create wrappers like that, so I probably can't be of much help. Thanks, Steve. From bill at classdesign.com Tue Oct 27 17:50:42 2015 From: bill at classdesign.com (Bill Somerville) Date: Tue, 27 Oct 2015 21:50:42 +0000 Subject: [CMake] Passing CMake verbosity down to external project Message-ID: <562FF1B2.7050801@classdesign.com> Hi All, I have an ExternalProject_Add() that uses autotools and I want to tell it to do a verbose make when my CMake parent project has been invoked with VERBOSE=1 or CMAKE_VERBOSE_MAKEFILE=ON. The external project requires V=1 as a make argument to do this. How do I detect the request for verbose make in my CMakeLists.txt so I can translate it to V=1 in the BUILD_COMMAND of the ExternalProject_Add() function? Regards Bill Somerville. From rcdailey.lists at gmail.com Wed Oct 28 09:43:28 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Wed, 28 Oct 2015 08:43:28 -0500 Subject: [CMake] Colored diagnostic output for GCC 4.9 through Ninja Message-ID: I'm using CMake + Ninja against GCC 4.9 in the Android NDK. I'm on Windows, invoking 'ninja' through CMD.exe. I do not see colored output for diagnostics (errors, warnings, etc) GCC gives. Is there something in CMake I need to configure to enable colored output? From dank at kegel.com Wed Oct 28 10:11:00 2015 From: dank at kegel.com (Dan Kegel) Date: Wed, 28 Oct 2015 07:11:00 -0700 Subject: [CMake] Colored diagnostic output for GCC 4.9 through Ninja In-Reply-To: References: Message-ID: On Wed, Oct 28, 2015 at 6:43 AM, Robert Dailey wrote: > I'm using CMake + Ninja against GCC 4.9 in the Android NDK. I'm on > Windows, invoking 'ninja' through CMD.exe. > > I do not see colored output for diagnostics (errors, warnings, etc) > GCC gives. Is there something in CMake I need to configure to enable > colored output? Try adding -fdiagnostics-color=always to the compiler options. From MillerHenry at JohnDeere.com Wed Oct 28 10:03:32 2015 From: MillerHenry at JohnDeere.com (Miller Henry) Date: Wed, 28 Oct 2015 14:03:32 +0000 Subject: [CMake] Colored diagnostic output for GCC 4.9 through Ninja In-Reply-To: References: Message-ID: <35F6921410093E4CA40D524BD5C18D4C303D6E91@EDXMB57.jdnet.deere.com> I do something like this, which works for clang and should work for gcc 4.9 though I haven't tested it. I haven't wrote the right way to do this which is to check if the terminal supports color before passing the flag in. I don't know what will happen on our e.g. CI system which doesn't support color. macro(AddCXXFlagIfSupported flag test) CHECK_CXX_COMPILER_FLAG(${flag} ${test}) if( ${${test}} ) message("adding ${flag}") set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${flag}") endif() endmacro() if("Ninja" STREQUAL ${CMAKE_GENERATOR}) AddCXXFlagIfSupported(-fcolor-diagnostics COMPILER_SUPPORTS_fcolor-diagnostics) endif() P.s. AddCXXFlagIfSupported ought to be in the default cmake distribution along with a lot or similar things -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Robert Dailey Sent: Wednesday, October 28, 2015 8:43 AM To: CMake Subject: [CMake] Colored diagnostic output for GCC 4.9 through Ninja I'm using CMake + Ninja against GCC 4.9 in the Android NDK. I'm on Windows, invoking 'ninja' through CMD.exe. I do not see colored output for diagnostics (errors, warnings, etc) GCC gives. Is there something in CMake I need to configure to enable colored output? -- 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 rcdailey.lists at gmail.com Wed Oct 28 12:19:06 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Wed, 28 Oct 2015 11:19:06 -0500 Subject: [CMake] Colored diagnostic output for GCC 4.9 through Ninja In-Reply-To: <35F6921410093E4CA40D524BD5C18D4C303D6E91@EDXMB57.jdnet.deere.com> References: <35F6921410093E4CA40D524BD5C18D4C303D6E91@EDXMB57.jdnet.deere.com> Message-ID: On Wed, Oct 28, 2015 at 9:03 AM, Miller Henry wrote: > > I do something like this, which works for clang and should work for gcc 4.9 though I haven't tested it. I haven't wrote the right way to do this which is to check if the terminal supports color before passing the flag in. I don't know what will happen on our e.g. CI system which doesn't support color. > > macro(AddCXXFlagIfSupported flag test) > CHECK_CXX_COMPILER_FLAG(${flag} ${test}) > if( ${${test}} ) > message("adding ${flag}") > set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${flag}") > endif() > endmacro() > > if("Ninja" STREQUAL ${CMAKE_GENERATOR}) > AddCXXFlagIfSupported(-fcolor-diagnostics COMPILER_SUPPORTS_fcolor-diagnostics) > endif() > > P.s. AddCXXFlagIfSupported ought to be in the default cmake distribution along with a lot or similar things Unfortunately your solution doesn't seem to work. I get the following output: [1/1] Re-running CMake... -- Performing Test COMPILER_SUPPORTS_fcolor-diagnostics -- Performing Test COMPILER_SUPPORTS_fcolor-diagnostics - Failed GCC 4.9 supports this I thought? From rcdailey.lists at gmail.com Wed Oct 28 12:20:56 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Wed, 28 Oct 2015 11:20:56 -0500 Subject: [CMake] Colored diagnostic output for GCC 4.9 through Ninja In-Reply-To: References: <35F6921410093E4CA40D524BD5C18D4C303D6E91@EDXMB57.jdnet.deere.com> Message-ID: On Wed, Oct 28, 2015 at 11:19 AM, Robert Dailey wrote: > On Wed, Oct 28, 2015 at 9:03 AM, Miller Henry wrote: >> >> I do something like this, which works for clang and should work for gcc 4.9 though I haven't tested it. I haven't wrote the right way to do this which is to check if the terminal supports color before passing the flag in. I don't know what will happen on our e.g. CI system which doesn't support color. >> >> macro(AddCXXFlagIfSupported flag test) >> CHECK_CXX_COMPILER_FLAG(${flag} ${test}) >> if( ${${test}} ) >> message("adding ${flag}") >> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${flag}") >> endif() >> endmacro() >> >> if("Ninja" STREQUAL ${CMAKE_GENERATOR}) >> AddCXXFlagIfSupported(-fcolor-diagnostics COMPILER_SUPPORTS_fcolor-diagnostics) >> endif() >> >> P.s. AddCXXFlagIfSupported ought to be in the default cmake distribution along with a lot or similar things > > Unfortunately your solution doesn't seem to work. I get the following output: > > [1/1] Re-running CMake... > -- Performing Test COMPILER_SUPPORTS_fcolor-diagnostics > -- Performing Test COMPILER_SUPPORTS_fcolor-diagnostics - Failed > > GCC 4.9 supports this I thought? I found the issue, the flag is diagnostics-color, not color-diagnostics. From rcdailey.lists at gmail.com Wed Oct 28 12:52:53 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Wed, 28 Oct 2015 11:52:53 -0500 Subject: [CMake] Colored diagnostic output for GCC 4.9 through Ninja In-Reply-To: References: <35F6921410093E4CA40D524BD5C18D4C303D6E91@EDXMB57.jdnet.deere.com> Message-ID: On Wed, Oct 28, 2015 at 11:20 AM, Robert Dailey wrote: > On Wed, Oct 28, 2015 at 11:19 AM, Robert Dailey > wrote: >> On Wed, Oct 28, 2015 at 9:03 AM, Miller Henry wrote: >>> >>> I do something like this, which works for clang and should work for gcc 4.9 though I haven't tested it. I haven't wrote the right way to do this which is to check if the terminal supports color before passing the flag in. I don't know what will happen on our e.g. CI system which doesn't support color. >>> >>> macro(AddCXXFlagIfSupported flag test) >>> CHECK_CXX_COMPILER_FLAG(${flag} ${test}) >>> if( ${${test}} ) >>> message("adding ${flag}") >>> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${flag}") >>> endif() >>> endmacro() >>> >>> if("Ninja" STREQUAL ${CMAKE_GENERATOR}) >>> AddCXXFlagIfSupported(-fcolor-diagnostics COMPILER_SUPPORTS_fcolor-diagnostics) >>> endif() >>> >>> P.s. AddCXXFlagIfSupported ought to be in the default cmake distribution along with a lot or similar things >> >> Unfortunately your solution doesn't seem to work. I get the following output: >> >> [1/1] Re-running CMake... >> -- Performing Test COMPILER_SUPPORTS_fcolor-diagnostics >> -- Performing Test COMPILER_SUPPORTS_fcolor-diagnostics - Failed >> >> GCC 4.9 supports this I thought? > > I found the issue, the flag is diagnostics-color, not color-diagnostics. Actually, even after getting this working, I still get no color output. :-( From jay.custin at hpe.com Wed Oct 28 15:35:11 2015 From: jay.custin at hpe.com (Custin, Jay (CSC Sw Middleware)) Date: Wed, 28 Oct 2015 19:35:11 +0000 Subject: [CMake] CMake on OpenVMS - Apparent roadblock buried within cmake-3.3.2\Tests\CMakeLists.txt Message-ID: I thought I had turned the final corner and only had the ?home stretch? left to get to the finish line? and then a brick wall suddenly appeared to block my way? So the configuration/bootstrap script seems to blissfully get all the way to the end and even displays the following: --------------------------------------------- CMake has bootstrapped. Now run make. Except when I looked? it had not created the Makefile. I ran the same basic process on one of my Linux systems and noticed that in addition to NOT creating the Makefile? it also did not create the bin subdirectory. I tried simply adding the ?trace option on the bootstrap?s cmake command (the last thing it does before posting the text above), but that didn?t seem to reveal any clues. I would love to simply comment out large swaths of the 3000+ lines of cmake-3.3.2\Tests\CMakeLists.txt but at this point I don?t have sufficient understanding of what impact doing this would have and fear that without the understanding doing so would probably do little to help me isolate where things appear to have gone awry. Does anyone know where (specifically) I should investigate to determine where the Makefile itself should get generated? What about what triggers the creation of the bin folder? Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Wed Oct 28 17:50:44 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Wed, 28 Oct 2015 17:50:44 -0400 Subject: [CMake] CMake on OpenVMS - Apparent roadblock buried within cmake-3.3.2\Tests\CMakeLists.txt In-Reply-To: References: Message-ID: <56314334.8020103@kitware.com> Questions inline: On 10/28/2015 3:35 PM, Custin, Jay (CSC Sw Middleware) wrote: > > So the configuration/bootstrap script seems to blissfully get all the > way to the end and even displays the following: > > --------------------------------------------- > > CMake has bootstrapped. Now run make. > > Except when I looked? it had not created the Makefile. I ran the same > basic process on one of my Linux systems and noticed that in addition to > NOT creating the Makefile? it also did not create the bin subdirectory. > I tried simply adding the ?trace option on the bootstrap?s cmake command > (the last thing it does before posting the text above), but that didn?t > seem to reveal any clues. > > I would love to simply comment out large swaths of the 3000+ lines of > cmake-3.3.2\Tests\CMakeLists.txt but at this point I don?t have > sufficient understanding of what impact doing this would have and fear > that without the understanding doing so would probably do little to help > me isolate where things appear to have gone awry. > What makes you think there is a problem in Tests/CMakeLists.txt? > Does anyone know where (specifically) I should investigate to determine > where the Makefile itself should get generated? > What files are generated in the build tree? The toplevel makefile is created here: void cmGlobalUnixMakefileGenerator3::WriteMainCMakefile() But there are lots of other files that get created. One thing you could try is to use the bootstrapped cmake to configure a more simple project. Something like: project(foo) add_library(foo foo.c) foo.c can be an empty file. Does the bootstrapped cmake work on that project? > What about what triggers the creation of the bin folder? I would not worry about that yet. -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoffman at kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 From labroue.aurel at yahoo.fr Wed Oct 28 17:51:02 2015 From: labroue.aurel at yahoo.fr (aurel labroue) Date: Wed, 28 Oct 2015 21:51:02 +0000 (UTC) Subject: [CMake] Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE) References: <430549201.6805403.1446069062840.JavaMail.yahoo@mail.yahoo.com> Message-ID: <430549201.6805403.1446069062840.JavaMail.yahoo@mail.yahoo.com> Hi everyone, ? I'm trying to install rtl-sdr on my Linux, and i have this error during the compilation "Could NOT find PkgConfig (missing:? PKG_CONFIG_EXECUTABLE)", i searched where the problem came from and apparently a function named find_package(PkgConfig) is called in? ?? CMakeLists.txt to find pkg-config, this function search with 2 modes, the first one being the module mode where the function go in the Modules repertory of CMake and catch the file named FindPkgConfig.cmake... I checked in this repertory and found no such file...I found a find with this name here https://github.com/Kitware/CMake/blob/master/Modules/FindPkgConfig.cmake but i put it in the Modules dir. but still the same error... I'm stuck there... Any suggestion ? Cheers Aur?lien -------------- next part -------------- An HTML attachment was scrubbed... URL: From Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de Thu Oct 29 06:22:57 2015 From: Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de (Mueller-Roemer, Johannes Sebastian) Date: Thu, 29 Oct 2015 10:22:57 +0000 Subject: [CMake] Asking CMake to setup compiler for c++11 In-Reply-To: References: Message-ID: <8D981219EEA621479C112DA9BDC39A8E46F27684@EXMBS2.ad.igd.fraunhofer.de> This fails for me when using Visual Studio -- 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 -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Dan Kegel Sent: Wednesday, October 21, 2015 21:55 To: Chris Stankevitz Cc: cmake Subject: Re: [CMake] Asking CMake to setup compiler for c++11 Something like CMAKE_MINIMUM_REQUIRED(VERSION 3.1) SET(CMAKE_CXX_STANDARD 11) I think. On Wed, Oct 21, 2015 at 12:43 PM, Chris Stankevitz wrote: > Hi, > > Q: What is the "CMake way" to ask that the compiler be setup for c++11? > > FYI I could not find the answer at > https://cmake.org/cmake/help/v3.4/search.html?q=c%2B%2B11 > > Thank you, > > Chris > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- 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 Thu Oct 29 06:45:14 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Thu, 29 Oct 2015 11:45:14 +0100 Subject: [CMake] Asking CMake to setup compiler for c++11 In-Reply-To: <8D981219EEA621479C112DA9BDC39A8E46F27684@EXMBS2.ad.igd.fraunhofer.de> References: <8D981219EEA621479C112DA9BDC39A8E46F27684@EXMBS2.ad.igd.fraunhofer.de> Message-ID: this is what I do: if(NOT MSVC) if(CMAKE_VERSION VERSION_LESS 3.1) set(CMAKE_CXX_FLAGS "-std=c++11 ${CMAKE_CXX_FLAGS}") else() if(NOT DEFINED CMAKE_CXX_STANDARD OR CMAKE_CXX_STANDARD STREQUAL "98") set(CMAKE_CXX_STANDARD 11) endif() set(CMAKE_CXX_STANDARD_REQUIRED ON) endif() endif() On Thu, Oct 29, 2015 at 11:22 AM, Mueller-Roemer, Johannes Sebastian < Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote: > This fails for me when using Visual Studio > > -- > 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 > > > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Dan Kegel > Sent: Wednesday, October 21, 2015 21:55 > To: Chris Stankevitz > Cc: cmake > Subject: Re: [CMake] Asking CMake to setup compiler for c++11 > > Something like > > CMAKE_MINIMUM_REQUIRED(VERSION 3.1) > SET(CMAKE_CXX_STANDARD 11) > > I think. > > On Wed, Oct 21, 2015 at 12:43 PM, Chris Stankevitz < > chrisstankevitz at gmail.com> wrote: > > Hi, > > > > Q: What is the "CMake way" to ask that the compiler be setup for c++11? > > > > FYI I could not find the answer at > > https://cmake.org/cmake/help/v3.4/search.html?q=c%2B%2B11 > > > > Thank you, > > > > Chris > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > -- > > 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 dolfimeth at gmail.com Thu Oct 29 08:50:57 2015 From: dolfimeth at gmail.com (Michele Dolfi) Date: Thu, 29 Oct 2015 13:50:57 +0100 Subject: [CMake] Extract list of libraries with full path from link command line Message-ID: Hi, Here is my problem. Having a string like "-L/mydir/lib -lfoo -lbar", is there a 'nice' automated way to turn it into a proper list of libraries like "/mydir/lib/libfoo.dylib;/mydir/lib/libbar.dylib"? Or, is there a way for cmake to make this magic happen when I pass the above string to target_link_libraries()? E.g. target_link_libraries(app "-L/mydir/lib -lfoo -lbar") turning to full path while linking. I know that I could come up with regex and do the magic myself like it is the case in the FindMPI.cmake module, but this looks to me like a standard procedure that maybe there is a better way then copying almost 100 lines in every package file. Thanks a lot, Michele -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.jaentsch at in.tum.de Thu Oct 29 10:21:41 2015 From: michael.jaentsch at in.tum.de (Michael Jaentsch) Date: Thu, 29 Oct 2015 15:21:41 +0100 Subject: [CMake] Visual Studio Cross Compile Message-ID: <44e308e464e4495c8ff063b9f7de58f3@in.tum.de> Hi all, I have a question concerning Cross Compiling with CMake on Windows. I would like to use Visual Studio but this is not a must. What I do is, I setup a project for Cross Compiling on Linux and it works fine. Now I want to transfer to Windows, so I set up a toolchain file which sets the following variables: CMAKE_SYSTEM_NAME CMAKE_SYSTEM_PROCESSOR CMAKE_FIND_ROOT_PATH CMAKE_C_COMPILER CMAKE_CXX_COMPILER and some more stuff. Then I run my cmake gui (I tried 3.2 and 3.4rc2) on Windows and tell it to generate a project for Visual Studio 10 and to use the toolchain file. However, the output shows that it is trying to use the Visual Studio compiler and then subsequently the build fails because of some unkown compiler flags. So my question is: Is it even possible to do what I'm trying to do? Can I cross compile with Visual Studio or do I have to use a different generator? All I found in the documentation is that it is possible to cross compile with a toolchain file... Cheers Michael -- Technische Universit?t M?nchen Michael J?ntsch Fakult?t f?r Informatik Robotics and Embedded Systems Parkring 13 85748 Garching bei M?nchen michael.jaentsch at in.tum.de www6.in.tum.de From joubert.sy at gmail.com Thu Oct 29 10:33:42 2015 From: joubert.sy at gmail.com (Sylvain Joubert) Date: Thu, 29 Oct 2015 15:33:42 +0100 Subject: [CMake] CMP0058 warning on configure-time generated source files Message-ID: Hi, In my project I have some source files that are generated at configure time. Much like configure_file but using one execute_process call with an external executable, then a second execute_process with cmake -E copy_if_different to avoid unnecessary rebuild. The generated files (from the build folder) are then used as source file for some targets. I recently upgraded to CMake >= 3.3 and I get a CMP0058 warning on some of the generated files. What I don't understand is that: - These files are not generated at build time but at configure time, why can't they just be seen as regular source files? - I generate lots of these files, but only some (only a few proportionally) are listed in the warning. I haven't been able to see a pattern yet and the build.ninja seems to contain equivalent rules both for the warned and the not warned files. What am I missing here? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From mixagd777 at gmail.com Thu Oct 29 11:00:26 2015 From: mixagd777 at gmail.com (Michaila Goula-Dimitriou) Date: Thu, 29 Oct 2015 17:00:26 +0200 Subject: [CMake] connect libraries to project with cmakelists Message-ID: I am using the cmakelists.txt below, that exists in the top folder of my project, and I am trying to connect mpg123 and ao to my project. In one .cpp file of the source folder I added a code with mpg123 and ao to play a song. This code can be compiled with this line: *g++ mpg.cpp -lmpg123 -lao -o mpg* I also added this line: target_link_libraries(emotime ${LIBAO_LIBRARIES} ${MPG123_LIBRARIES}) in the cmakelists that exists in my source folder. When I am running make I get errors like "undefined reference to `ao_initialize'" and "undefined reference to `mpg123_init'". Am I doing something wrong? cmake_minimum_required(VERSION 2.8) project(emotime) find_package(OpenCV REQUIRED) include_directories(${OpenCV_INCLUDE_DIRS}) FIND_PATH( MPG123_INCLUDE_DIR1 NAMES mpg123.h PATH_SUFFIXES include PATHS ~/Library/Frameworks /Library/Frameworks /usr/local /usr /sw # Fink /opt/local # DarwinPorts /opt/csw # Blastwave /opt extern/mpg123/ports/MSVC++ extern/mpg123/ports/Xcode ) IF( MPG123_INCLUDE_DIR1 ) SET( MPG123_INCLUDE_DIRS ${MPG123_INCLUDE_DIRS} ${MPG123_INCLUDE_DIR1} ) ENDIF( MPG123_INCLUDE_DIR1 ) # Include dir (May not be necessary on all platforms) FIND_PATH( MPG123_INCLUDE_DIR2 NAMES mpg123.h.in PATHS ~/Library/Frameworks /Library/Frameworks /usr/local /usr /sw # Fink /opt/local # DarwinPorts /opt/csw # Blastwave /opt extern/mpg123/src/libmpg123 ) IF( MPG123_INCLUDE_DIR2 ) SET( MPG123_INCLUDE_DIRS ${MPG123_INCLUDE_DIRS} ${MPG123_INCLUDE_DIR2} ) ENDIF( MPG123_INCLUDE_DIR2 ) #MESSAGE( "MPG123_INCLUDE_DIR1: " ${MPG123_INCLUDE_DIR1} ) #MESSAGE( "MPG123_INCLUDE_DIR2: " ${MPG123_INCLUDE_DIR2} ) #MESSAGE( "MPG123_INCLUDE_DIRS: " ${MPG123_INCLUDE_DIRS} ) FIND_LIBRARY( MPG123_LIBRARIES NAMES mpg123 libmpg123.lib HINTS PATH_SUFFIXES lib64 lib libs64 libs libs/Win32 libs/Win64 Release Debug PATHS ~/Library/Frameworks /Library/Frameworks /usr/local /usr /sw /opt/local /opt/csw /opt extern/mpg123/ports/MSVC++/2005 extern/mpg123/ports/MSVC++/2008 extern/mpg123/ports/MSVC++/2008clr extern/mpg123/ports/MSVC++/2010 ) SET( MPG123_FOUND 0 ) IF( MPG123_LIBRARIES AND MPG123_INCLUDE_DIRS ) SET( MPG123_FOUND 1 ) MESSAGE( STATUS "mpg123 found!" ) ELSE( MPG123_LIBRARIES AND MPG123_INCLUDE_DIRS ) MESSAGE( STATUS "mpg123 not found..." ) ENDIF( MPG123_LIBRARIES AND MPG123_INCLUDE_DIRS ) FIND_PATH(LIBAO_INCLUDE_DIR ao.h /usr/include/ao /usr/local/include/ao) FIND_LIBRARY(LIBAO_LIBRARIES NAMES ao PATH /usr/lib /usr/local/lib) IF (LIBAO_INCLUDE_DIR AND LIBAO_LIBRARIES) SET(LIBAO_FOUND TRUE) ENDIF (LIBAO_INCLUDE_DIR AND LIBAO_LIBRARIES) IF (LIBAO_FOUND) IF (NOT LIBAO_FIND_QUIETLY) MESSAGE(STATUS "Found libao: ${LIBAO_LIBRARIES}") ENDIF (NOT LIBAO_FIND_QUIETLY) ELSE (LIBAO_FOUND) IF (LIBAO_FIND_REQUIRED) MESSAGE(FATAL_ERROR "Could not find libao") ENDIF (LIBAO_FIND_REQUIRED) ENDIF (LIBAO_FOUND) include_directories(${LIBAO_INCLUDE_DIR} ${MPG123_INCLUDE_DIRS}) set(ASSETDIR "${emotime_SOURCE_DIR}/assets" ) set(HEADERDIR "${emotime_SOURCE_DIR}/include" ) set(SRCDIR "${emotime_SOURCE_DIR}/src" ) SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}") add_subdirectory(src) -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Oct 29 11:13:03 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 29 Oct 2015 11:13:03 -0400 Subject: [CMake] CMP0058 warning on configure-time generated source files In-Reply-To: References: Message-ID: <5632377F.4010800@kitware.com> On 10/29/2015 10:33 AM, Sylvain Joubert wrote: > I recently upgraded to CMake >= 3.3 and I get a CMP0058 warning on some > of the generated files. What I don't understand is that: > - These files are not generated at build time but at configure time, > why can't they just be seen as regular source files? They can, but CMake does not know that for sure so it warns about the policy's behavior change just in case. In your case you know everything is okay so you can go ahead and tell CMake to use its new preferred behavior because it won't break anything. All you have to do is add the code: if(POLICY CMP0058) cmake_policy(SET CMP0058 NEW) endif() You can drop that in the future when you use cmake_minimum_required(VERSION 3.3) which will set the policy to NEW automatically. See further details in the policy docs: https://cmake.org/cmake/help/v3.3/policy/CMP0058.html https://cmake.org/cmake/help/v3.3/manual/cmake-policies.7.html https://cmake.org/cmake/help/v3.3/command/cmake_policy.html -Brad From attila.krasznahorkay at gmail.com Thu Oct 29 11:53:32 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Thu, 29 Oct 2015 16:53:32 +0100 Subject: [CMake] How to figure out the "type" of an imported library Message-ID: <545D4B32-9076-488B-BBB9-117837CD7B2D@gmail.com> Dear All, In my code I'm trying to do something slightly tricky. I include packages that provide imported libraries (amongst other things). Then, because of how my project is structured, I don't make use of the imported libraries directly, but first make "copies" of them, and then make use of these copies in my build. (The reason is that I allow the project to override libraries that are available from the base packages as well. In which case components using this overridden library need to use this instance instead of the imported one. But if no such override is in place, I need to give the library a name that the components in the project expect to find it with.) If there would be a way in CMake to "clone" an imported library with a new name, that would be perfect for my use case. Since as far as I know there's no such thing, I use code like: ... add_library( ${libName} SHARED IMPORTED GLOBAL ) # Check which builds it is available for: get_property( _builds TARGET ${prefix}_${libName} PROPERTY IMPORTED_CONFIGURATIONS ) set_property( TARGET ${libName} PROPERTY IMPORTED_CONFIGURATIONS ${_builds} ) ... Now, I recently started producing MODULE and INTERFACE libraries as well. So the first line in this code is no longer correct for all the imported libraries. Plus, for INTERFACE libraries the get_property call on IMPORTED_CONFIGURATIONS just fails with an error message. So now I wonder: Is there a target property on INTERFACE libraries that I could use to identify them? Like how there is the target property IMPORTED on the imported libraries. Cheers, Attila From mcotter222 at gmail.com Thu Oct 29 15:31:05 2015 From: mcotter222 at gmail.com (Matt Cotter) Date: Thu, 29 Oct 2015 19:31:05 +0000 Subject: [CMake] Undef GENERATE_EXPORT_HEADER macros? Message-ID: Hello! Is there a way to have cmake generate #undef's for all of the macros it creates in the GENERATE_EXPORT_HEADER command? I am trying not to leak these macros to users including the library, but I can't seem to find any way to generate this. As a reference, for other macros that I am defining myself, I'm using #pragma push_macro() and #undef before defining them and then #undef and #pragma pop_macro() after I'm done with them. Thanks for any help! -Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From tamas.kenez at gmail.com Thu Oct 29 15:42:50 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Thu, 29 Oct 2015 20:42:50 +0100 Subject: [CMake] How to figure out the "type" of an imported library In-Reply-To: <545D4B32-9076-488B-BBB9-117837CD7B2D@gmail.com> References: <545D4B32-9076-488B-BBB9-117837CD7B2D@gmail.com> Message-ID: There's a TYPE property which should contain what you need: https://cmake.org/cmake/help/latest/prop_tgt/TYPE.html On Thu, Oct 29, 2015 at 4:53 PM, Attila Krasznahorkay < attila.krasznahorkay at gmail.com> wrote: > Dear All, > > In my code I'm trying to do something slightly tricky. I include packages > that provide imported libraries (amongst other things). Then, because of > how my project is structured, I don't make use of the imported libraries > directly, but first make "copies" of them, and then make use of these > copies in my build. > > (The reason is that I allow the project to override libraries that are > available from the base packages as well. In which case components using > this overridden library need to use this instance instead of the imported > one. But if no such override is in place, I need to give the library a name > that the components in the project expect to find it with.) > > If there would be a way in CMake to "clone" an imported library with a new > name, that would be perfect for my use case. Since as far as I know there's > no such thing, I use code like: > > ... > add_library( ${libName} SHARED IMPORTED GLOBAL ) > # Check which builds it is available for: > get_property( _builds TARGET ${prefix}_${libName} > PROPERTY IMPORTED_CONFIGURATIONS ) > set_property( TARGET ${libName} PROPERTY > IMPORTED_CONFIGURATIONS ${_builds} ) > ... > > Now, I recently started producing MODULE and INTERFACE libraries as well. > So the first line in this code is no longer correct for all the imported > libraries. Plus, for INTERFACE libraries the get_property call on > IMPORTED_CONFIGURATIONS just fails with an error message. > > So now I wonder: Is there a target property on INTERFACE libraries that I > could use to identify them? Like how there is the target property IMPORTED > on the imported libraries. > > Cheers, > Attila > -- > > 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 attila.krasznahorkay at gmail.com Thu Oct 29 18:51:24 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Thu, 29 Oct 2015 23:51:24 +0100 Subject: [CMake] How to figure out the "type" of an imported library In-Reply-To: References: <545D4B32-9076-488B-BBB9-117837CD7B2D@gmail.com> Message-ID: Thanks! It indeed looks like it will do the job. Cheers, Attila > On 29 Oct 2015, at 20:42, Tam?s Ken?z wrote: > > There's a TYPE property which should contain what you need: https://cmake.org/cmake/help/latest/prop_tgt/TYPE.html > > On Thu, Oct 29, 2015 at 4:53 PM, Attila Krasznahorkay wrote: > Dear All, > > In my code I'm trying to do something slightly tricky. I include packages that provide imported libraries (amongst other things). Then, because of how my project is structured, I don't make use of the imported libraries directly, but first make "copies" of them, and then make use of these copies in my build. > > (The reason is that I allow the project to override libraries that are available from the base packages as well. In which case components using this overridden library need to use this instance instead of the imported one. But if no such override is in place, I need to give the library a name that the components in the project expect to find it with.) > > If there would be a way in CMake to "clone" an imported library with a new name, that would be perfect for my use case. Since as far as I know there's no such thing, I use code like: > > ... > add_library( ${libName} SHARED IMPORTED GLOBAL ) > # Check which builds it is available for: > get_property( _builds TARGET ${prefix}_${libName} > PROPERTY IMPORTED_CONFIGURATIONS ) > set_property( TARGET ${libName} PROPERTY > IMPORTED_CONFIGURATIONS ${_builds} ) > ... > > Now, I recently started producing MODULE and INTERFACE libraries as well. So the first line in this code is no longer correct for all the imported libraries. Plus, for INTERFACE libraries the get_property call on IMPORTED_CONFIGURATIONS just fails with an error message. > > So now I wonder: Is there a target property on INTERFACE libraries that I could use to identify them? Like how there is the target property IMPORTED on the imported libraries. > > Cheers, > Attila > -- > > 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 954371544 at qq.com Fri Oct 30 06:32:26 2015 From: 954371544 at qq.com (=?gb18030?B?wO7I2bnzX2RvbmduYW4=?=) Date: Fri, 30 Oct 2015 18:32:26 +0800 Subject: [CMake] The project files that CMake generates can't be moved Message-ID: Dear Sir Or madam, Thank you very much for taking time to read my email. I?m a graduate student of Southeast University in China.I encountered a problem when I use CMake recently, so I write this email to you. If you have time, I hope you can give me some guidance. Recently, I use CMake to build the source code of a software in the platform of windows and I make it. However, I found if I move the whole file to other place, some errors will take place when the program run. According to the prompt information, I know CMake uses absolute path when building. Then I read a lot of relevant datum on the net. One solution is to open the variable ?CMAKE_USE_RELATIVE_PATHS?. I have tried it and it doesn?t work. Someone also say this problem has not been effectively solved yet. I want to make this problem clear, so I decide to write this email. Looking forward to your reply. Besides, my English is not very. So there may be some mistakes in my email. I hope you can forgive me. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Fri Oct 30 06:59:08 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 30 Oct 2015 11:59:08 +0100 Subject: [CMake] The project files that CMake generates can't be moved In-Reply-To: References: Message-ID: <56334D7C.6090505@gmail.com> On 10/30/2015 11:32 AM, ???_dongnan wrote: > > Recently, I use CMake to build the source code of a software in the > platform of windows and I make it. However, I found if I move the > whole file to other place, some errors will take place when the > program run. According to the prompt information, I know CMake uses > absolute path when building. Then I read a lot of relevant datum on > the net. One solution is to open the variable > ?CMAKE_USE_RELATIVE_PATHS?. I have tried it and it doesn?t work. > Someone also say this problem has not been effectively solved yet. I > want to make this problem clear, so I decide to write this email. > CMAKE_USE_RELATIVE_PATHS has been removed from CMake [1]. Even before that its use was not recommended. CMake build directories are not meant to be transferable or moved around; if you need a build in a different location you will have to rerun cmake / the build there. Nils [1] https://cmake.org/gitweb?p=cmake.git;a=commit;h=1335992c8f4e8b96f1a21d5dcc7d65a9fbd84c11 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.custin at hpe.com Fri Oct 30 11:18:24 2015 From: jay.custin at hpe.com (Custin, Jay (CSC Sw Middleware)) Date: Fri, 30 Oct 2015 15:18:24 +0000 Subject: [CMake] CMake on OpenVMS - Apparent roadblock buried within cmake-3.3.2\Tests\CMakeLists.txt Message-ID: Q: What makes you think there is a problem in Tests/CMakeLists.txt? A: Certainly the "problem" could exist in any of the myriad of files that get processed as a result of the Tests/CMakeLists.txt file, but I base my hypothesis on the following MESSAGE statements which I added to the main CMakeLists.txt file: MESSAGE( STATUS "CMAKELISTS.TXT Marker 17 add_subdirectory(Tests)" ) add_subdirectory(Tests) MESSAGE( STATUS "CMAKELISTS.TXT Marker 18") And when I execute the configure script (or manually execute the equivalent CMake execution at the tail end of the bootstrap) I see the following: -- Marker 16g add_subdirectory(Utilities) -- CMAKELISTS.TXT Marker 17 add_subdirectory(Tests) -- if(DEFINED ENV{HOME} AND NOT CTEST_NO_TEST_HOME) ==> TRUE < And NEVER see the "CMAKELISTS.TXT Marker 18") appear in the output... so it "enters" the statement: add_subdirectory(Tests) on a "one-way ticket" (meaning it appears to never return to the parsing/calling CMakeLists.txt file) > Does anyone know where (specifically) I should investigate to > determine where the Makefile itself should get generated? > What files are generated in the build tree? For the moment skipping this question in lieu of pursuing your suggestion of the results of using the bootstrapped CMake to configure a simple project further (below) The toplevel makefile is created here: void cmGlobalUnixMakefileGenerator3::WriteMainCMakefile() But there are lots of other files that get created. One thing you could try is to use the bootstrapped cmake to configure a more simple project. Something like: project(foo) add_library(foo foo.c) foo.c can be an empty file. Does the bootstrapped cmake work on that project? Initially I feared that I would have to answer "No", but after some further excavation I did make some significant progress (which probably also reveals some things that still, not surprisingly, need more tweaking). ITAN1* cmake "-DCMAKE_BOOTSTRAP=1" CMake Error: Error in cmake code at /JAY/CMAKE/CMakeLists.txt:1: Parse error. Expected a newline, got identifier with text "add_library". -- Configuring incomplete, errors occurred! ITAN1* d Directory JAY:[cmake] CMakeCache.txt;1 CMakeFiles.DIR;1 cmakelists.txt;5 foo.c;1 After beating my head on the desk for a while... I finally decided to beat the cmakelists.txt file instead (force the file structure on the file - thank you OpenVMS for defaulting to CRLF) and after that I managed to get the following result: ITAN1* ty *.* JAY:[cmake]cmakelists.txt;10 project(foo) add_library(foo foo.c) JAY:[cmake]foo.c;3 #include main() { printf("Hello World"); } ITAN1* I did try my level-headed best to get this to work from the OpenVMS DCL prompt directly, but (at the moment) without success. That said... from the GNV Bash prompt I did (with some additional switch definitions) get it to generate the Makefile: So taking my simple "hello world" project files and copying them to a clean directory: ITAN1* create/dir jay:[cmake_simple_test] ITAN1* copy foo.c,cmakelists.txt jay:[cmake_simple_test]/log %COPY-S-COPIED, JAY:[cmake]foo.c;3 copied to JAY:[cmake_simple_test]foo.c;3 (1 block) %COPY-S-COPIED, JAY:[cmake]cmakelists.txt;10 copied to JAY:[cmake_simple_test]cmakelists.txt;10 (1 block) %COPY-S-NEWFILES, 2 files created ITAN1* set default jay:[cmake_simple_test] JAY:[CMAKE_SIMPLE_TEST] ITAN1* dir Directory JAY:[cmake_simple_test] cmakelists.txt;10 foo.c;3 Total of 2 files. And switching to the GNV Bash shell it ran (in MY opinion) very cleanly, though I did ultimately determine that I had to manually define the CMAKE_C_COMPILER variable in the command line): ITAN1* bash bash-4.3$ /PRJ_ROOT/CMAKE-3_3_2/BOOTSTRAP_CMK/CMAKE -DCMAKE_BOOTSTRAP=1 -DCMAKE_C_COMPILER=/bin/cc -- The C compiler identification is unknown -- The CXX compiler identification is unknown -- Check for working C compiler: /bin/cc -- Check for working C compiler: /bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /bin/CC -- Check for working CXX compiler: /bin/CC -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Configuring done -- Generating done -- Build files have been written to: /JAY/CMAKE_SIMPLE_TEST bash-4.3$ ls CMakeCache.txt CMakeFiles Makefile cmake_install.cmake cmakelists.txt foo.c Dropping back to the DCL prompt you can see it has created quie a few files: ITAN1* dir [...] Directory JAY:[cmake_simple_test] CMakeCache.txt;1 CMakeFiles.DIR;1 cmakelists.txt;10 cmake_install.cmake;1 foo.c;3 Makefile.;1 Total of 6 files. Directory JAY:[cmake_simple_test.CMakeFiles] 3^.3^.2.DIR;1 cmake.check_cache;2 cmake.check_cache;1 CMakeDirectoryInformation.cmake;1 CMakeError.log;1 CMakeOutput.log;1 CMakeTmp.DIR;1 foo_dir.DIR;1 Makefile.cmake;1 Makefile2.;1 progress.marks;1 TargetDirectories.txt;1 Total of 12 files. Directory JAY:[cmake_simple_test.CMakeFiles.3^.3^.2] CMakeCCompiler.cmake;1 CMakeCXXCompiler.cmake;1 CMakeDetermineCompilerABI_C.bin;1 CMakeDetermineCompilerABI_CXX.bin;1 CMakeSystem.cmake;1 CompilerIdC.DIR;1 CompilerIdCXX.DIR;1 Total of 7 files. Directory JAY:[cmake_simple_test.CMakeFiles.3^.3^.2.CompilerIdC] cc_temp9dedd1.;1 cc_temp9df5d2.;1 CMakeCCompilerId.c;1 Total of 3 files. Directory JAY:[cmake_simple_test.CMakeFiles.3^.3^.2.CompilerIdCXX] cc_temp9df5d5.;1 cc_temp9dfdd7.;1 CMakeCXXCompilerId.cpp;1 Total of 3 files. Directory JAY:[cmake_simple_test.CMakeFiles.foo_dir] build.make;1 cmake_clean.cmake;1 cmake_clean_target.cmake;1 depend.make;1 DependInfo.cmake;1 flags.make;1 progress.make;1 Total of 7 files. Grand total of 6 directories, 38 files. Switching, yet again, back to the GNV Bash shell, the makefile does process without HORRIBLE errors, but the make does only create the file libfoo.a: ITAN1* bash bash-4.3$ make Scanning dependencies of target foo [-50%] Building C object CMakeFiles/foo_dir/foo.c.o [ 0%] Linking C static library libfoo.a [ 0%] Built target foo bash-4.3$ ls CMakeCache.txt CMakeFiles Makefile cmake_install.cmake cmakelists.txt foo.c libfoo.a I wanted to send this reply back now, but will do some further investigation into the "real" build... Among the things I will try: Interrupting/preventing the automatic execution of the bootstrapped CMake in the end of the bootstrap script and then try to execute it from the shell prompt using the same basic switches I used for the "simple" project above. JayC From bill.hoffman at kitware.com Fri Oct 30 12:00:03 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Fri, 30 Oct 2015 12:00:03 -0400 Subject: [CMake] CMake on OpenVMS - Apparent roadblock buried within cmake-3.3.2\Tests\CMakeLists.txt In-Reply-To: References: Message-ID: <56339403.5080804@kitware.com> On 10/30/2015 11:18 AM, Custin, Jay (CSC Sw Middleware) wrote: > Interrupting/preventing the automatic execution of the bootstrapped > CMake in the end of the bootstrap script and then try to execute it > from the shell prompt using the same basic switches I used for the > "simple" project above. This sounds like a good plan. You have a basic makefile working! That is pretty cool. I would run everything from bash all the time. Next step would be to run the bootstrapped cmake from the bash shell on CMake itself. Must be a configure file or execute_process in there that is messing things up. But hey, you have the basic CMake working! -Bill From jay.custin at hpe.com Fri Oct 30 12:42:29 2015 From: jay.custin at hpe.com (Custin, Jay (CSC Sw Middleware)) Date: Fri, 30 Oct 2015 16:42:29 +0000 Subject: [CMake] CMake on OpenVMS - Apparent roadblock buried within cmake-3.3.2\Tests\CMakeLists.txt Message-ID: Well one thing that DOES still concern me... this matter of the LF vs CRLF issue and the CMakeLists.txt file. I do need to investigate if that simply doesn't factor in when run from the GNV Bash shell, but I would certainly like to avoid having to manually tweak the file. At the moment I don't consider that that big of a deal so down on the To Do list. -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Bill Hoffman Sent: Friday, October 30, 2015 12:00 PM To: cmake at cmake.org Subject: Re: [CMake] CMake on OpenVMS - Apparent roadblock buried within cmake-3.3.2\Tests\CMakeLists.txt On 10/30/2015 11:18 AM, Custin, Jay (CSC Sw Middleware) wrote: > Interrupting/preventing the automatic execution of the bootstrapped > CMake in the end of the bootstrap script and then try to execute it > from the shell prompt using the same basic switches I used for the > "simple" project above. This sounds like a good plan. You have a basic makefile working! That is pretty cool. I would run everything from bash all the time. Next step would be to run the bootstrapped cmake from the bash shell on CMake itself. Must be a configure file or execute_process in there that is messing things up. But hey, you have the basic CMake working! -Bill -- 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 attila.krasznahorkay at gmail.com Fri Oct 30 13:48:33 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Fri, 30 Oct 2015 18:48:33 +0100 Subject: [CMake] The project files that CMake generates can't be moved In-Reply-To: <56334D7C.6090505@gmail.com> References: <56334D7C.6090505@gmail.com> Message-ID: <0FDD363C-C506-4E15-A7FB-CE42F16388D1@gmail.com> Hi, I'm a bit surprised about this answer. Sure, build areas are not to be moved around. I completely agree. But this is why we have the concept of installing releases. As long as you configure your build correctly, you should be able to move around your install directory. As the binaries by default will not have absolute paths in them after installation. At least not to "themselves". (I am myself working these days on how to install larger projects such that after installation, after moving the installed directories around, including the directories that the build was done against, the code would still work. It's not trivial to do, but it's not impossible either. One just has to use $ in a clever way...) Cheers, Attila > On 30 Oct 2015, at 11:59, Nils Gladitz wrote: > > On 10/30/2015 11:32 AM, ???_dongnan wrote: >> >> Recently, I use CMake to build the source code of a software in the platform of windows and I make it. However, I found if I move the whole file to other place, some errors will take place when the program run. According to the prompt information, I know CMake uses absolute path when building. Then I read a lot of relevant datum on the net. One solution is to open the variable ?CMAKE_USE_RELATIVE_PATHS?. I have tried it and it doesn?t work. Someone also say this problem has not been effectively solved yet. I want to make this problem clear, so I decide to write this email. >> > > CMAKE_USE_RELATIVE_PATHS has been removed from CMake [1]. Even before that its use was not recommended. > CMake build directories are not meant to be transferable or moved around; if you need a build in a different location you will have to rerun cmake / the build there. > > Nils > > [1] https://cmake.org/gitweb?p=cmake.git;a=commit;h=1335992c8f4e8b96f1a21d5dcc7d65a9fbd84c11 > -- > > 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 bill.hoffman at kitware.com Fri Oct 30 13:59:12 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Fri, 30 Oct 2015 13:59:12 -0400 Subject: [CMake] The project files that CMake generates can't be moved In-Reply-To: <0FDD363C-C506-4E15-A7FB-CE42F16388D1@gmail.com> References: <56334D7C.6090505@gmail.com> <0FDD363C-C506-4E15-A7FB-CE42F16388D1@gmail.com> Message-ID: <5633AFF0.20007@kitware.com> On 10/30/2015 1:48 PM, Attila Krasznahorkay wrote: > I'm a bit surprised about this answer. > > Sure, build areas are not to be moved around. I completely agree. But > this is why we have the concept of installing releases. As long as > you configure your build correctly, you should be able to move around > your install directory. As the binaries by default will not have > absolute paths in them after installation. At least not to > "themselves". > > (I am myself working these days on how to install larger projects > such that after installation, after moving the installed directories > around, including the directories that the build was done against, > the code would still work. It's not trivial to do, but it's not > impossible either. One just has to use $ in a > clever way...) > > Cheers, Install trees should be relocatable (that is how cpack works). However, build trees are not. -Bill From orion at cora.nwra.com Fri Oct 30 21:59:43 2015 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 30 Oct 2015 19:59:43 -0600 Subject: [CMake] [ANNOUNCE] CMake 3.4.0-rc1 is now ready! In-Reply-To: <56291D38.6070409@kitware.com> References: <56148ABA.5070303@cora.nwra.com> <56154C15.3030806@cora.nwra.com> <562900AE.1060704@cora.nwra.com> <56291D38.6070409@kitware.com> Message-ID: <5634208F.3070900@cora.nwra.com> On 10/22/2015 11:30 AM, Brad King wrote: > On 10/22/2015 11:28 AM, Orion Poplawski wrote: >>>> This appears to have broken plplot's ada build on Fedora. >> >> FYI - builds still fail with cmake 3.4.0-rc2. Have had time to look at it >> closer. plplot issue seems to be triggered by a change in Ada_FLAGS: >> >> -Ada_FLAGS = >> -I/home/orion/fedora/plplot/plplot-5.11.1/build-3.3.2/examples/ada >> -I/home/orion/fedora/plplot/plplot-5.11.1/bindings/ada >> +Ada_FLAGS = >> >> but plplot I believe has custom Ada cmake platform support. I am still >> concerned about possible regressions here. > > Plplot's Ada support uses CMake internal APIs so it is plplot's > responsibility to adapt to our changes: > > https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeAddNewLanguage.txt;hb=v3.4.0-rc2 > Maintainers of external language support are responsible for porting > it to each version of CMake as upstream changes are made. > > Our 3.4.0-rc2 release notes point out a change likely causing this problem: > > https://cmake.org/gitweb?p=cmake.git;a=blob;f=Help/release/3.4.rst;hb=v3.4.0-rc2#l271 > * The internal "CMAKE__COMPILE_OBJECT" rule variable now > substitutes compiler include flags in a separate "" > placeholder instead of the main "" placeholder. > > Where Plplot currently writes: > > SET(CMAKE_Ada_COMPILE_OBJECT > " -c -o > ") > > try: > > if(NOT CMAKE_VERSION VERSION_LESS 3.4) > set(CMAKE_Ada_COMPILE_OBJECT > " -c -o ") > else() > set(CMAKE_Ada_COMPILE_OBJECT > " -c -o ") > endif() > > -Brad > Ah, thank you very much. The attached patch fixes this. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -------------- next part -------------- A non-text attachment was scrubbed... Name: plplot-cmake34.patch Type: text/x-patch Size: 3053 bytes Desc: not available URL: From nico.schloemer at gmail.com Sat Oct 31 10:49:21 2015 From: nico.schloemer at gmail.com (=?UTF-8?Q?Nico_Schl=C3=B6mer?=) Date: Sat, 31 Oct 2015 14:49:21 +0000 Subject: [CMake] add_custom_command not triggered Message-ID: After downloading a file with ExternalData_Expand_Arguments [1], I would like to execute a command on the data to produce another file. So far, I have ``` ExternalData_Expand_Arguments( noshTestFetchData OUT_DATA DATA{${CMAKE_SOURCE_DIR}/test/data/${file}} ) ExternalData_Add_Target(noshTestFetchData) add_custom_command( OUTPUT ${CMAKE_BINARY_DIR}/test/data/pacman.e.2.0 COMMAND decomp -p 2 ${CMAKE_BINARY_DIR}/test/data/pacman.e DEPENDS noshTestFetchData ) ``` The file is downloaded alright, but the `add_custom_command` is never triggered. Why not? This is with CMake 3.2.2. Cheers, Nico [1] https://cmake.org/cmake/help/v3.3/module/ExternalData.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Sat Oct 31 11:17:33 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Sat, 31 Oct 2015 16:17:33 +0100 Subject: [CMake] add_custom_command not triggered In-Reply-To: References: Message-ID: <5634DB8D.4090701@gmail.com> On 31.10.2015 15:49, Nico Schl?mer wrote: > > add_custom_command( > OUTPUT ${CMAKE_BINARY_DIR}/test/data/pacman.e.2.0 > COMMAND decomp -p 2 ${CMAKE_BINARY_DIR}/test/data/pacman.e > DEPENDS noshTestFetchData > ) > I don't know anything about the ExternalData module but assuming this is unrelated ... do you have a target that depends on the new output? Without one the custom command does not get emitted. E.g. add_custom_target(foobar ALL DEPENDS ${CMAKE_BINARY_DIR}/test/data/pacman.e.2.0) or list it in the sources of an existing add_executable() or add_library() target. Nils From DLRdave at aol.com Sat Oct 31 11:41:58 2015 From: DLRdave at aol.com (David Cole) Date: Sat, 31 Oct 2015 11:41:58 -0400 Subject: [CMake] add_custom_command not triggered In-Reply-To: References: Message-ID: Because you're giving DEPENDS as a target name, this is only an ordering dependency, stating that the command should run after the target is built. But not necessarily re-build whenever the target is re-built... If you want to re-run the command based on a file changing instead, then use the full path to a file name as your DEPENDS argument. The downloaded file itself, or the extracted data file the command uses would probably be reasonable choices. Read the DEPENDS section of https://cmake.org/cmake/help/v3.3/command/add_custom_command.html carefully. HTH, David C. On Saturday, October 31, 2015, Nico Schl?mer wrote: > After downloading a file with ExternalData_Expand_Arguments [1], I would > like to execute a command on the data to produce another file. So far, I > have > ``` > ExternalData_Expand_Arguments( > noshTestFetchData > OUT_DATA DATA{${CMAKE_SOURCE_DIR}/test/data/${file}} > ) > ExternalData_Add_Target(noshTestFetchData) > > add_custom_command( > OUTPUT ${CMAKE_BINARY_DIR}/test/data/pacman.e.2.0 > COMMAND decomp -p 2 ${CMAKE_BINARY_DIR}/test/data/pacman.e > DEPENDS noshTestFetchData > ) > ``` > The file is downloaded alright, but the `add_custom_command` is never > triggered. Why not? > > This is with CMake 3.2.2. > > Cheers, > Nico > > [1] https://cmake.org/cmake/help/v3.3/module/ExternalData.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Sat Oct 31 11:43:32 2015 From: DLRdave at aol.com (David Cole) Date: Sat, 31 Oct 2015 11:43:32 -0400 Subject: [CMake] add_custom_command not triggered In-Reply-To: References: Message-ID: Oh wait, I read it wrong... Try ${} to get the value of the variable. (It contains a file name, right?) D On Saturday, October 31, 2015, David Cole wrote: > Because you're giving DEPENDS as a target name, this is only an ordering > dependency, stating that the command should run after the target is built. > But not necessarily re-build whenever the target is re-built... > > If you want to re-run the command based on a file changing instead, then > use the full path to a file name as your DEPENDS argument. The downloaded > file itself, or the extracted data file the command uses would probably be > reasonable choices. > > Read the DEPENDS section of > https://cmake.org/cmake/help/v3.3/command/add_custom_command.html > carefully. > > > HTH, > David C. > > > On Saturday, October 31, 2015, Nico Schl?mer > wrote: > >> After downloading a file with ExternalData_Expand_Arguments [1], I would >> like to execute a command on the data to produce another file. So far, I >> have >> ``` >> ExternalData_Expand_Arguments( >> noshTestFetchData >> OUT_DATA DATA{${CMAKE_SOURCE_DIR}/test/data/${file}} >> ) >> ExternalData_Add_Target(noshTestFetchData) >> >> add_custom_command( >> OUTPUT ${CMAKE_BINARY_DIR}/test/data/pacman.e.2.0 >> COMMAND decomp -p 2 ${CMAKE_BINARY_DIR}/test/data/pacman.e >> DEPENDS noshTestFetchData >> ) >> ``` >> The file is downloaded alright, but the `add_custom_command` is never >> triggered. Why not? >> >> This is with CMake 3.2.2. >> >> Cheers, >> Nico >> >> [1] https://cmake.org/cmake/help/v3.3/module/ExternalData.html >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iosif.neitzke+cmake at gmail.com Sat Oct 31 11:53:42 2015 From: iosif.neitzke+cmake at gmail.com (Iosif Neitzke) Date: Sat, 31 Oct 2015 10:53:42 -0500 Subject: [CMake] add_dependencies being ignored for add_custom_command? In-Reply-To: <562EA9C3.6060704@ettus.com> References: <562AD24E.5030908@ettus.com> <562E63BA.5030906@ettus.com> <562EA9C3.6060704@ettus.com> Message-ID: Yes, Header.hpp will be generated before the target is built. I do not believe the order of files listed in add_library() matters at all. On Mon, Oct 26, 2015 at 5:31 PM, Martin Braun wrote: > Gotcha, Iosif, > > thanks for clearing that up for me. To summarize, I should ... > > On 26.10.2015 12:51, Iosif Neitzke wrote: >> [...] >> add_library( somelib ${CMAKE_CURRENT_BINARY_DIR}/Header.hpp >> ${CMAKE_CURRENT_BINARY_DIR}/Header.cpp source.cpp ) > > ...add the generated files as to the target. > > That leads me to another question, though (hopefully the last): If > source.cpp depends on Header.hpp, is it guaranteed that Header.hpp will > be generated before the compiler tries to compile source.cpp? Does the > list order of the files inside add_library() matter? > > Cheers, > Martin > -- > > 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 irwin at beluga.phys.uvic.ca Sat Oct 31 13:10:25 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Sat, 31 Oct 2015 10:10:25 -0700 (PDT) Subject: [CMake] [Plplot-devel] [ANNOUNCE] CMake 3.4.0-rc1 is now ready! In-Reply-To: <5634208F.3070900@cora.nwra.com> References: <56148ABA.5070303@cora.nwra.com> <56154C15.3030806@cora.nwra.com> <562900AE.1060704@cora.nwra.com> <56291D38.6070409@kitware.com> <5634208F.3070900@cora.nwra.com> Message-ID: On 2015-10-30 19:59-0600 Orion Poplawski wrote: > On 10/22/2015 11:30 AM, Brad King wrote: [...] >> Where Plplot currently writes: >> >> SET(CMAKE_Ada_COMPILE_OBJECT >> " -c -o >> ") >> >> try: >> >> if(NOT CMAKE_VERSION VERSION_LESS 3.4) >> set(CMAKE_Ada_COMPILE_OBJECT >> " -c -o ") >> else() >> set(CMAKE_Ada_COMPILE_OBJECT >> " -c -o ") >> endif() >> >> -Brad >> > > Ah, thank you very much. The attached patch fixes this. Hi Orion: Thanks for implementing Brad's suggestion to fix the PLplot Ada language support issue for CMake-3.4. To help give you PLplot git credit for your work, would you please put the patch in "git format-patch" form? I also notice substantial use of in the PLplot D language support case. I assume your tests did not reveal any issues for D because you were not trying any D compiler flags, but I predict if you do that, you will encounter the same problem. For example, if you try export DFLAGS=-Iwhatever I assume that (harmless) compile flag will correctly propagate to the D compile step (as seen by the VERBOSE=1 option for make) for older versions of CMake but will not propagate correctly for CMake-3.4. Anyhow, I am virtually positive there is also a PLplot D language support issue for CMake-3.4 so if you don't beat me to it, I plan (likely late next week because I am currently tied up with something else) to expose that issue with a test like the one I suggested above and also plan to fix the issue following Brad's suggestion. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From forumer at smartmobili.com Sat Oct 31 15:35:12 2015 From: forumer at smartmobili.com (forumer at smartmobili.com) Date: Sat, 31 Oct 2015 20:35:12 +0100 Subject: [CMake] Add suppport for new IDE Message-ID: Hi, I would like to add some support for generating makefiles/IDE solutions for the D language (http://dlang.org). Especially I would like to be able to generate VisualD and monoD projects. The language is hold inside files with a .d extension and that can be compiled by 3 differents compilers: 1)dmd: the official compiler 2)gdc: compiler based on gcc 3)ldc: compiler based on llvm There is already a kind of makefile system called dub that build libraries/application but it cannot generate ide projects. So in a perfect world it would be cool to add support for dub makefile, VisualD and MonoD. Is there any example about how to do that ? Do you support other languages except C/C++ ? Thanks