From hong.gyu.kim at lge.com Wed Jul 1 04:34:52 2015 From: hong.gyu.kim at lge.com (Honggyu Kim) Date: Wed, 1 Jul 2015 17:34:52 +0900 Subject: [cmake-developers] dry-run support Message-ID: <12ed01d0b3d8$cd0f6370$672e2a50$@lge.com> Hi all, I would like to see the exact command execution list when I build using cmake. Make has an option "--dry-run" as many of you already know: $ make --help -n, --just-print, --dry-run, --recon Don't actually run any commands; just print them. Can anyone please let me know if there's a way to do dry-run in cmake. I appreciate all your comments. Thanks, Honggyu From eric.noulard at gmail.com Wed Jul 1 05:14:05 2015 From: eric.noulard at gmail.com (Eric Noulard) Date: Wed, 1 Jul 2015 11:14:05 +0200 Subject: [cmake-developers] dry-run support In-Reply-To: <12ed01d0b3d8$cd0f6370$672e2a50$@lge.com> References: <12ed01d0b3d8$cd0f6370$672e2a50$@lge.com> Message-ID: 2015-07-01 10:34 GMT+02:00 Honggyu Kim : > Hi all, > > I would like to see the exact command execution list when I build using > cmake. > Make has an option "--dry-run" as many of you already know: > > $ make --help > -n, --just-print, --dry-run, --recon > Don't actually run any commands; just print > them. > > Can anyone please let me know if there's a way to do dry-run in cmake. > I appreciate all your comments. > There is one big noticeable difference between make and cmake. CMake does not "build" software it creates build system that will be used to build. So dry-running CMake will not give you "exact command execution for building". The other main difference is that CMake has control statements-(option, find_package, if-else, ...) so that action/command executed during CMake run may heavily depend on the **effective execution** (e.g. find_package) of a previous line of the CMake script. So I my idea is that "dry-run" is not as useful for CMake as it is for make (or ninja -n or other build tool dry run mode). What you already have with CMake is the --trace option which can be very useful to understand what happen at CMake time. Then it may also be useful to dry-run the resulting build files produced by CMake. i.e.: make --dry-run ninja -n -v ... -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From hong.gyu.kim at lge.com Wed Jul 1 08:25:23 2015 From: hong.gyu.kim at lge.com (Honggyu Kim) Date: Wed, 1 Jul 2015 21:25:23 +0900 Subject: [cmake-developers] dry-run support In-Reply-To: References: <12ed01d0b3d8$cd0f6370$672e2a50$@lge.com> Message-ID: <133301d0b3f9$00e79530$02b6bf90$@lge.com> > From: Eric Noulard [mailto:eric.noulard at gmail.com] > Sent: Wednesday, July 01, 2015 6:14 PM > To: Honggyu Kim > Cc: CMake Developers > Subject: Re: [cmake-developers] dry-run support > What you already have with CMake is the --trace option which can be very useful > to understand what happen at CMake time. I will try --trace option later. > Then it may also be useful to dry-run the resulting build files produced by CMake. > i.e.: > make --dry-run > ninja -n -v > ... You're right. There's no such dry-running in CMake and it just generates the normal Makefile. I got the list of execution commands by running dry-run on generated Makefile with --dry-run and --always-make options. --always-make forces to show the entire command list regardless it is already compiled or not. So my problem is solved anyway. > -- > Eric I appreciate your comment. Thanks, Honggyu From d.dewald at dsfishlabs.com Wed Jul 1 09:14:55 2015 From: d.dewald at dsfishlabs.com (Daniel Dewald) Date: Wed, 1 Jul 2015 13:14:55 +0000 Subject: [cmake-developers] Post generate step Message-ID: Howdy folks, I'm currently in the process of converting our internal projects from premake to cmake. The process is almost complete. However I've been stuck on a seemingly simple problem the last few days that I could need some help /advise on. Since premake as well as CMake don't have an option to integrate Icon and LaunchImage support for iOS builds in XCode, we have a bash script, that patches the generated project files, to insert the appropriate lines to enable the icon support (this basically is 1.) copying the images into the app folder 2.) including the prepared xcasset file into the resource "folder" of the project and 3.) creating a "Copy Bundle Resources" build phase step with the .xcassets file in the targets build phases). The script is currently run after cmake is done (in our projects batch file) and this works fine so far for premake as well as cmake. The problem now is that if something is changed, cmake will regenerate the project files and erase those changes. The logical idea would be to execute the script whenever cmake is run. However there is no such functionality in cmake as far as anyone could tell me so far. I would be willing to contribute the changes that would be necessary to give us such an option (Basically a post-generate step / command). Another way would be to include support for iOS Icons into cmake. However I'm not sure if I do get enough time from my employer to implement that solution nor am I confident that I actually have enough knowledge of XCode and the build phases to provide a generally working and stable solution for this. I'd very much like to have your feedback on this because if we create a feature we would of course like to get that feature into the official source at some point so we wouldn't have to constantly push people to use some "patched" version of cmake that we provide locally. Greetz Daniel -- Daniel Dewald Build Engineer ___________________________________________________________________________________ Deep Silver FISHLABS Koch Media GmbH Ludwig-Erhard-Stra?e 1 | 20459 Hamburg | Germany (Time zone UTC +1) Fon: +49.40.88 88 00 - 227 | Fax: - 166 Mail: d.dewald at dsfishlabs.com | Web: www.dsfishlabs.com District Court Munich HRB 105290 | Managing Partner Dr. Klemens Kundratitz, Stefan Kapelari ____________________________________________________________________________________ ________________________________ Diese E-mail enth?lt VERTRAULICHE UND PERS?NLICHE INFORMATIONEN und/oder PRIVILEGIERTE UND VERTRAULICHE MITTEILUNGEN, die ausschlie?lich f?r die angesprochenen Empf?nger bestimmt sind. Ohne ausdr?ckliche schriftliche Zustimmung des Absenders d?rfen diese Informationen und Mitteilungen nicht an irgendeinen Dritten au?erhalb der Organisation des Empf?ngers weitergeleitet oder zur Kenntnis gebracht werden. Wenn Sie diese E-mail versehentlich empfangen haben, teilen Sie dies bitte dem Absender umgehend telefonisch oder durch R?cksendung dieser E-mail mit, und zerst?ren Sie die Mail sowie Ihre evtl. R?ckmail bitte anschlie?end, ohne eine Kopie zu erstellen. Koch Media ?bernimmt keinerlei Verantwortung f?r m?gliche Verluste oder Besch?digungen, resultierend aus virus-infizierten E-mails bzw. Viren in Anh?ngen. This e-mail may contain CONFIDENTIAL AND PROPRIETARY INFORMATION and/or PRIVILEGED AND CONFIDENTIAL COMMUNICATION intended solely for the recipient and, therefore, may not be retransmitted to any party outside of the recipient's organization without the prior written consent of the sender. If you have received this e-mail in error please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Koch Media accepts no liability for any losses or damages resulting from infected e-mail transmissions and viruses in e-mail attachment. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Wed Jul 1 10:32:46 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 1 Jul 2015 10:32:46 -0400 Subject: [cmake-developers] [CMake 0015637]: Consider escaping all utf8 chars in XML test output Message-ID: <28ddf4453062ae6bb8c6a8d014bc1dfb@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15637 ====================================================================== Reported By: Zach Mullen Assigned To: ====================================================================== Project: CMake Issue ID: 15637 Category: CTest Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-01 10:32 EDT Last Modified: 2015-07-01 10:32 EDT ====================================================================== Summary: Consider escaping all utf8 chars in XML test output Description: Right now, any characters we deem non-printable are escaped in a non-standard way, e.g.: "[NON-XML-CHAR-0x1B]" Instead of the standard NCR escaping: "". I propose that we change to using NCR escaping to provide more portable XML and let CDash (or other consumers of the XML) decide how to render those characters. For instance, my personal use case involves terminal control characters -- services like travis render colors and styles in the web UI just as they would appear in a terminal, and it would be nice to enable CDash to do the same thing without having to look for our nonstandard string. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-01 10:32 Zach Mullen New Issue ====================================================================== From d.dewald at dsfishlabs.com Wed Jul 1 11:33:31 2015 From: d.dewald at dsfishlabs.com (Daniel Dewald) Date: Wed, 1 Jul 2015 15:33:31 +0000 Subject: [cmake-developers] Post generate step In-Reply-To: References: Message-ID: Disregard my last E-Mail.. I found the solution in the source code. The support for the iOS icons is already there ;o). -- Daniel Dewald Build Engineer ____________________________________________________________________________________ Deep Silver FISHLABS Koch Media GmbH Ludwig-Erhard-Stra?e 1 | 20459 Hamburg | Germany (Time zone UTC +1) Fon: +49.40.88 88 00 - 227 | Fax: - 166 Mail: d.dewald at dsfishlabs.com | Web: www.dsfishlabs.com District Court Munich HRB 105290 | Managing Partner Dr. Klemens Kundratitz, Stefan Kapelari ____________________________________________________________________________________ Von: cmake-developers [mailto:cmake-developers-bounces at cmake.org] Im Auftrag von Daniel Dewald Gesendet: Mittwoch, 1. Juli 2015 15:26 An: cmake-developers at cmake.org Betreff: [cmake-developers] Post generate step Howdy folks, I'm currently in the process of converting our internal projects from premake to cmake. The process is almost complete. However I've been stuck on a seemingly simple problem the last few days that I could need some help /advise on. Since premake as well as CMake don't have an option to integrate Icon and LaunchImage support for iOS builds in XCode, we have a bash script, that patches the generated project files, to insert the appropriate lines to enable the icon support (this basically is 1.) copying the images into the app folder 2.) including the prepared xcasset file into the resource "folder" of the project and 3.) creating a "Copy Bundle Resources" build phase step with the .xcassets file in the targets build phases). The script is currently run after cmake is done (in our projects batch file) and this works fine so far for premake as well as cmake. The problem now is that if something is changed, cmake will regenerate the project files and erase those changes. The logical idea would be to execute the script whenever cmake is run. However there is no such functionality in cmake as far as anyone could tell me so far. I would be willing to contribute the changes that would be necessary to give us such an option (Basically a post-generate step / command). Another way would be to include support for iOS Icons into cmake. However I'm not sure if I do get enough time from my employer to implement that solution nor am I confident that I actually have enough knowledge of XCode and the build phases to provide a generally working and stable solution for this. I'd very much like to have your feedback on this because if we create a feature we would of course like to get that feature into the official source at some point so we wouldn't have to constantly push people to use some "patched" version of cmake that we provide locally. Greetz Daniel -- Daniel Dewald Build Engineer ___________________________________________________________________________________ Deep Silver FISHLABS Koch Media GmbH Ludwig-Erhard-Stra?e 1 | 20459 Hamburg | Germany (Time zone UTC +1) Fon: +49.40.88 88 00 - 227 | Fax: - 166 Mail: d.dewald at dsfishlabs.com | Web: www.dsfishlabs.com District Court Munich HRB 105290 | Managing Partner Dr. Klemens Kundratitz, Stefan Kapelari ____________________________________________________________________________________ ________________________________ Diese E-mail enth?lt VERTRAULICHE UND PERS?NLICHE INFORMATIONEN und/oder PRIVILEGIERTE UND VERTRAULICHE MITTEILUNGEN, die ausschlie?lich f?r die angesprochenen Empf?nger bestimmt sind. Ohne ausdr?ckliche schriftliche Zustimmung des Absenders d?rfen diese Informationen und Mitteilungen nicht an irgendeinen Dritten au?erhalb der Organisation des Empf?ngers weitergeleitet oder zur Kenntnis gebracht werden. Wenn Sie diese E-mail versehentlich empfangen haben, teilen Sie dies bitte dem Absender umgehend telefonisch oder durch R?cksendung dieser E-mail mit, und zerst?ren Sie die Mail sowie Ihre evtl. R?ckmail bitte anschlie?end, ohne eine Kopie zu erstellen. Koch Media ?bernimmt keinerlei Verantwortung f?r m?gliche Verluste oder Besch?digungen, resultierend aus virus-infizierten E-mails bzw. Viren in Anh?ngen. This e-mail may contain CONFIDENTIAL AND PROPRIETARY INFORMATION and/or PRIVILEGED AND CONFIDENTIAL COMMUNICATION intended solely for the recipient and, therefore, may not be retransmitted to any party outside of the recipient's organization without the prior written consent of the sender. If you have received this e-mail in error please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Koch Media accepts no liability for any losses or damages resulting from infected e-mail transmissions and viruses in e-mail attachment. ________________________________ Diese E-mail enth?lt VERTRAULICHE UND PERS?NLICHE INFORMATIONEN und/oder PRIVILEGIERTE UND VERTRAULICHE MITTEILUNGEN, die ausschlie?lich f?r die angesprochenen Empf?nger bestimmt sind. Ohne ausdr?ckliche schriftliche Zustimmung des Absenders d?rfen diese Informationen und Mitteilungen nicht an irgendeinen Dritten au?erhalb der Organisation des Empf?ngers weitergeleitet oder zur Kenntnis gebracht werden. Wenn Sie diese E-mail versehentlich empfangen haben, teilen Sie dies bitte dem Absender umgehend telefonisch oder durch R?cksendung dieser E-mail mit, und zerst?ren Sie die Mail sowie Ihre evtl. R?ckmail bitte anschlie?end, ohne eine Kopie zu erstellen. Koch Media ?bernimmt keinerlei Verantwortung f?r m?gliche Verluste oder Besch?digungen, resultierend aus virus-infizierten E-mails bzw. Viren in Anh?ngen. This e-mail may contain CONFIDENTIAL AND PROPRIETARY INFORMATION and/or PRIVILEGED AND CONFIDENTIAL COMMUNICATION intended solely for the recipient and, therefore, may not be retransmitted to any party outside of the recipient's organization without the prior written consent of the sender. If you have received this e-mail in error please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Koch Media accepts no liability for any losses or damages resulting from infected e-mail transmissions and viruses in e-mail attachment. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tgamblin at llnl.gov Wed Jul 1 12:14:39 2015 From: tgamblin at llnl.gov (Todd Gamblin) Date: Wed, 01 Jul 2015 09:14:39 -0700 Subject: [cmake-developers] CMake adds -qalias=noansi by XLC Message-ID: Hi, I asked this over on the regular cmake list and got no answer, so maybe developers is the right place for it. I noticed while poking around CMake's compiler modules that the defaults for XL are kind of inconsistent. Specifically, If you look here: https://github.com/Kitware/CMake/blob/master/Modules/Compiler/XL-C.cmake CMake adds -qalias=noansi by default, which prevents a bunch of optimizations. CMake does not add that for XL C++. It also doesn't tweak any default aliasing settings for other compilers. Why XLC? At LLNL, we don't like qalias=noansi because it prevents a lot of optimizations, so we typically recommend that users NOT use that flag. It's been surprising for us that CMake adds it by default when it's not a default for XL, which uses -qalias=ansi (type-based aliasing) by default. So, two questions: - Is there some reason CMake adds the -qalias=noansi arg for XLC? - Could it be removed in future versions for consistency with other compilers' C++ settings? I can push a feature branch if people agree that this is a good idea. -Todd -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Wed Jul 1 14:17:49 2015 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 01 Jul 2015 20:17:49 +0200 Subject: [cmake-developers] A policy for Policies References: <55759F3A.7030003@kitware.com> <5575F56A.50404@kitware.com> <5575FA50.5080208@kitware.com> <5576008C.3040505@kitware.com> <557636B1.9020500@gmail.com> <5576ED34.7090208@kitware.com> <55784507.7000104@kitware.com> <557984FA.4000508@kitware.com> <5582C785.8040005@kitware.com> <558C0FB4.4030009@kitware.com> Message-ID: Brad King wrote: > On 06/20/2015 05:29 AM, Stephen Kelly wrote: >> Even -Wno-dev should have no effect on the warning when the warning is >> unconditional. > > I think that makes sense. We would need to update the wording > accordingly. > >> I don't think more conditions with deprecation states is a good idea. > > I was brainstorming ways to make OLD behavior an error earlier than > the normal deprecation schedule for projects that are maintained. I see. > I don't think I called out the more important part of my previous > message well enough. We need to provide project authors with tools > to hunt down all OLD/unset behavior warnings before they become errors > by default. This includes warnings buried in script mode at build time > or in other cases that the output (which might have a warning) is never > visible. This means CMAKE_ERROR_DEPRECATED should turn policy warnings > into errors. We may need a way to activate such errors with an > environment variable. I see. > We need to provide such capabilities so authors that do maintain > their projects can be confident they've ported away from behavior > that will later become an error. We should also apply these tools > to our own test suite. Makes sense to me. >> CMake 3.4: >> >> * Policies <= CMP0011 >> -- emit unconditional warnings for each policy (no OLD anymore - 6 years >> old) > > Okay. IIUC the warnings should appear when: > > (1) the policy is explicit set to OLD, or > (2) the policy triggers without having been set to OLD or NEW > > For (2) we don't need to warn if the policy has been set to OLD > because (1) would have warned first. Therefore the logic in the > actual policy warning implementations does not have to change, > just the wording of the messages. Additionally, the cases cmPolicies::OLD and cmPolicies::WARN need to be reordered such that both issue a warning. I think the warning should indicate which version of CMake introduced the policy (already the case) and the date that was released. This might provide the information needed to prioritize that Alex was looking for by instead asking for the date it would become an error. > >> * Policies CMP0051 -> CMP0054 >> -- emit unconditional warnings for each policy (no OLD anymore - 3 >> releases old) > > Let's skip these for 3.4 and see how the warnings for the 14 policies > in the above and below groups work out. The reason I suggested emitting these unconditional warnings is that we should establish what the lifecycle of policies actually is. We should do that in the next release by actually implementing it for the policies which match the criteria we decide which are at that part of the lifecycle. However, those policies will be three releases old for CMake 3.4. Maybe that is too old, and we should aim for allowing silencing the warning with cmake_policy for only one CMake release, and allow silencing it with the cmake option -Wno-dev for three releases. That should be easy enough to do by introducing a new MESSAGE_TYPE. Afaik, the only legitimate use designed for setting a policy to OLD is to relieve consumers of a project from the requirement of having to use the cmake option -Wno-dev while building the latest release of the project with the latest CMake. Setting a policy to OLD is not designed to be a convenience for the maintainer of the project, who can schedule appropriate handling of the policy. Consumers whose cmake version in use progresses faster than the maintained project in use still get to use -Wno-dev to silence the warnings for a few CMake releases. Thanks, Steve. From radovan.bast at gmail.com Thu Jul 2 04:14:33 2015 From: radovan.bast at gmail.com (Radovan Bast) Date: Thu, 02 Jul 2015 08:14:33 +0000 Subject: [cmake-developers] Fortran module dependencies and preprocessing in CMake 3.3.0-rc3 Message-ID: dear CMake developers, We have observed a changed and surprising behavior in CMake 3.3.0-rc3 with Fortran module dependency scanning and preprocessing compared to earlier CMake versions (for instance 3.2.3). I have checked open bugs and email list archives but could not find this mentioned. To give an example the following Fortran source fails to compile: """ program example #ifdef SOMEDEF use mymodule #endif call hello() end program """ with: """ main.F90:3:7: use mymodule 1 Fatal Error: Can't open module file ?mymodule.mod? for reading at (1): No such file or directory """ It seems that Fortran dependencies are scanned prior to pre-processing. This seems different compared to 3.2.3 (and earlier versions). Not sure this is a bug or a feature. All relevant files (CMakeLists.txt, main.F90, mymodule.F90) for a complete minimal example are attached. I can also submit this directly to http://www.cmake.org/Bug/ in case this is not a feature. Thank you and best wishes, radovan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- cmake_minimum_required(VERSION 2.8 FATAL_ERROR) project(example) enable_language(Fortran) add_definitions(-DSOMEDEF) add_executable(example.x main.F90 mymodule.F90) -------------- next part -------------- A non-text attachment was scrubbed... Name: mymodule.F90 Type: text/x-fortran Size: 163 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: main.F90 Type: text/x-fortran Size: 82 bytes Desc: not available URL: From brad.king at kitware.com Thu Jul 2 09:24:26 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 02 Jul 2015 09:24:26 -0400 Subject: [cmake-developers] CMake adds -qalias=noansi by XLC In-Reply-To: References: Message-ID: <55953B8A.20004@kitware.com> On 07/01/2015 12:14 PM, Todd Gamblin wrote: > - Is there some reason CMake adds the -qalias=noansi arg for XLC? It was added here: Add initial XL C compiler flags for safer builds http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e1729238 but I don't recall why it was included among the other defaults and the commit message doesn't say anything about it :( > - Could it be removed in future versions for consistency with > other compilers' C++ settings? Yes, we can try dropping it: XL: Drop -qalias=noansi from default C flags http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a33fb493 Thanks, -Brad From brad.king at kitware.com Thu Jul 2 09:30:58 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 02 Jul 2015 09:30:58 -0400 Subject: [cmake-developers] Fortran module dependencies and preprocessing in CMake 3.3.0-rc3 In-Reply-To: References: Message-ID: <55953D12.7010706@kitware.com> On 07/02/2015 04:14 AM, Radovan Bast wrote: > We have observed a changed and surprising behavior in CMake 3.3.0-rc3 > with Fortran module dependency scanning and preprocessing compared to > earlier CMake versions (for instance 3.2.3). I don't recall any changes related to this since 3.2. I also cannot reproduce the problem with the example you provided. > It seems that Fortran dependencies are scanned prior to pre-processing. CMake does its own approximate preprocessing for dependency scanning. This hasn't changed in a long time. Can you please provide a more complete example to reproduce this? Or, if you can consistently reproduce it locally please try bisecting our Git history between 3.2 and 3.3 to see if you can find the commit that introduced the problem. Thanks, -Brad From michael.stuermer at schaeffler.com Thu Jul 2 09:53:44 2015 From: michael.stuermer at schaeffler.com (Stuermer, Michael SP/HZA-ZSEP) Date: Thu, 2 Jul 2015 13:53:44 +0000 Subject: [cmake-developers] C# support? In-Reply-To: <55929E58.6030600@kitware.com> References: <4797EDAAB4843944A70CA99A7DE7D8BD0400AAC9@DE012432.schaeffler.com> <55917AD8.6070305@kitware.com> <4797EDAAB4843944A70CA99A7DE7D8BD0400BEA1@DE012432.schaeffler.com> <55929E58.6030600@kitware.com> Message-ID: <4797EDAAB4843944A70CA99A7DE7D8BD0400C3A9@DE012432.schaeffler.com> Hi all, I got the first sort of working version running. Would be great if some people could have a look at it if it's going into a good direction. Some explanations: Patch 0001: - adds the necessary Module/* files for enabling C# as a language - CAUTION: only Visual Studio 2013 generators are supported at the moment - there is a verbose message which is shown when C# is used to guide people where to go for improvement Patch 0002: - some minor changes to mostly visual studio related classes to enable .csproj support o .csproj GUID is added o a method to check if the target is C# is added Patch 0003: - the actual implementation of the .csproj generation - all generation takes place inside VisualStudio10TargetGenerator class There is an example project in the appendix of this mail which you can use to see how .csproj can be generated now. And yes, there are still quite some things missing: - Tests (!!!!) - NMake support (even though that should not bee too hard) o better handling of the flagtable that I added (not sure if I understood correctly how the concept is supposed to be used) - documentation (!!!!) Most questions on how to use the C# language and mixing with C++ targets should be answered by looking at the example project. Some VS_* target properties already existed which I reused. I added two Property-"Groups": - VS_DOTNET_REFERENCE_ properties for references with a tag, though they also can be added to the normal VS_DOTNET_REFERENCES. This is a target-property - CSharpPROJ_ the tag will be added to the tag of the specified Source files. This is a source property. - CSharpPROJ_SubType the currently only used case of above property group. It's needed to tell visual studio what kind of file is added. You can safely omit this, but visual studio will not be able to run the designer in the correct mode without it. Project references are added by simply using target_link_libraries(). All other references must use done in one of the above described ways. It would be great if some people could try if the example project works for them. If you have improvements don't hesitate to submit any patch to my current fork on github (branch "csharp"): https://github.com/micst/CMake.git The example project can be found there as well: https://github.com/micst/CMakeCSharpTest.git best regards, Michael > -----Original Message----- > From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On > Behalf Of Brad King > Sent: Tuesday, June 30, 2015 3:49 PM > To: cmake-developers at cmake.org > Subject: Re: [cmake-developers] C# support? > > On 06/30/2015 03:21 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > > it would be great if some people could step forward once everything > is > > running from my side to help get makefile and linux support (and test > > other Visual Studio versions). > > Once you have it working in VS 2013 the other VS >= 2010 versions > should be easy. I'm not sure about other generators yet. If you have > good coverage in the test suite updates then that will make the task of > adding support to other generators easier. > > For now you can have CMakeDetermineCSharpCompiler do a > message(FATAL_ERROR) when CMAKE_GENERATOR is set to a value that is not > supported. That can be lifted when the other generators implement the > language. > > > About enable_language(): > > > > have the appropriate cmake-scripts in "Module" directory > [snip] > > Almost everything relevant goes in the target generator class > > VisualStudio10TargetGenerator. > > Great! > > > Once done, do you want patchfiles here on the list or a pull request > > from my fork on github? > > Please send patch files here as requested in CONTRIBUTING.rst. > Please re-organize commits into a logical series of updates rather than > the original unorganized development history. > > Thanks! > -Brad > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For > more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-adding-CSharp-support-adding-some-necessary-methods.patch Type: application/octet-stream Size: 6473 bytes Desc: 0002-adding-CSharp-support-adding-some-necessary-methods.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-adding-CSharp-support-adding-generation-of-csproj.patch Type: application/octet-stream Size: 52433 bytes Desc: 0003-adding-CSharp-support-adding-generation-of-csproj.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake-csharp-testproject.zip Type: application/x-zip-compressed Size: 56438 bytes Desc: cmake-csharp-testproject.zip URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-adding-CSharp-support-adding-language-support.patch Type: application/octet-stream Size: 19276 bytes Desc: 0001-adding-CSharp-support-adding-language-support.patch URL: From michael.scott250 at gmail.com Thu Jul 2 16:45:26 2015 From: michael.scott250 at gmail.com (Michael Scott) Date: Thu, 2 Jul 2015 21:45:26 +0100 Subject: [cmake-developers] Add command line options for deprecation message control Message-ID: <5595A2E6.3000906@gmail.com> > What is the difference between the intended uses of those existing options > and the intended uses of the new options, given that -Wno-dev is mostly > useful for third parties to silence policy warnings? Working on this issue, I did find the different variables/options a bit confusing. dev and deprecated both change the effect of message modes, pretty much doing the same thing but slightly different (for example there is -Wdev and -Wno-dev, but not -Werror=dev or -Wno-error=dev). Would it be worth refactoring the -W dev options to be in line with the -W deprecated options? > If the new options are merged to master should -Wdev and -Wno-dev also be > changed to affect CMAKE_WARN_DEPRECATED? That would be sensible behaviour to me, shall I modify cmake::Configure to do this? Cheers, Michael From michael.scott250 at gmail.com Thu Jul 2 16:51:49 2015 From: michael.scott250 at gmail.com (Michael Scott) Date: Thu, 2 Jul 2015 21:51:49 +0100 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: <558C1520.5070805@kitware.com> References: <5589BA2F.1010101@gmail.com> <558AC26E.4040702@kitware.com> <558B2163.7080602@gmail.com> <558C1520.5070805@kitware.com> Message-ID: <5595A465.2060102@gmail.com> Sorry, I've added in the missing method to cmake.cxx, which updates the WarningLevel map according to the boolean provided. cmake-gui compiles without errors again. I could add support for the new options to the GUI, in which case I would probably also go back to the changes I made to cmake.cxx and make the code related to WarningLevel a bit more generic and replace instances of "dev" and "deprecated" with constants to make the changes a bit more maintainable. Cheers, Michael On 25/06/2015 15:50, Brad King wrote: > On 06/24/2015 05:30 PM, Michael Scott wrote: >> Thanks for the comments, here is the previous patch, with the suggested >> amendments. > Thanks. > > This hunk: > >> - void SetSuppressDevWarnings(bool v) >> - { >> - this->SuppressDevWarnings = v; >> - this->DoSuppressDevWarnings = true; >> - } > causes the cmake-gui Qt dialog to fail to compile: > > $ git grep SetSuppressDevWarnings > Source/QtDialog/QCMake.cxx: this->CMakeInstance->SetSuppressDevWarnings(this->SuppressDevWarnings); > > Sorry I didn't notice that last time. > > Please enable the BUILD_QtDialog option at CMake build time to > build this part and make sure it compiles after the changes. > It would be nice to also provide settings in cmake-gui for > these deprecation levels (as there is for -Wdev), but I won't > make that a requirement for acceptance of the patch. > > Thanks, > -Brad > -------------- next part -------------- From c19b143756a9ecf800ac42a37dd2d4bac64d7025 Mon Sep 17 00:00:00 2001 From: Michael Scott Date: Sat, 13 Jun 2015 18:34:31 +0100 Subject: [PATCH] Refactored the -Wdev and -Wno-dev to use a generic -W parser, which follows the GCC pattern. Included support for setting CMAKE_ERROR_DEPRECATED and CMAKE_WARN_DEPRECATED via the deprecated warning. Added tests for new options and updated cmake documentation and release notes to list new options. --- Help/manual/OPTIONS_BUILD.txt | 24 ++++ Help/release/dev/cmake-Wdeprecated.rst | 9 ++ Help/variable/CMAKE_ERROR_DEPRECATED.rst | 4 + Help/variable/CMAKE_WARN_DEPRECATED.rst | 4 + Source/cmake.cxx | 127 ++++++++++++++++++--- Source/cmake.h | 24 ++-- Tests/RunCMake/CommandLine/RunCMakeTest.cmake | 37 ++++++ Tests/RunCMake/CommandLine/W_bad-arg1-result.txt | 1 + Tests/RunCMake/CommandLine/W_bad-arg1-stderr.txt | 2 + Tests/RunCMake/CommandLine/W_bad-arg2-result.txt | 1 + Tests/RunCMake/CommandLine/W_bad-arg2-stderr.txt | 2 + Tests/RunCMake/CommandLine/W_bad-arg3-result.txt | 1 + Tests/RunCMake/CommandLine/W_bad-arg3-stderr.txt | 2 + Tests/RunCMake/CommandLine/Wdeprecated-stderr.txt | 4 + Tests/RunCMake/CommandLine/Wdeprecated.cmake | 1 + .../CommandLine/Werror_deprecated-result.txt | 1 + .../CommandLine/Werror_deprecated-stderr.txt | 4 + Tests/RunCMake/CommandLine/Werror_deprecated.cmake | 1 + Tests/RunCMake/CommandLine/Wno-deprecated.cmake | 1 + .../CommandLine/Wno-error_deprecated.cmake | 1 + 20 files changed, 223 insertions(+), 28 deletions(-) create mode 100644 Help/release/dev/cmake-Wdeprecated.rst create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg1-result.txt create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg1-stderr.txt create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg2-result.txt create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg2-stderr.txt create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg3-result.txt create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg3-stderr.txt create mode 100644 Tests/RunCMake/CommandLine/Wdeprecated-stderr.txt create mode 100644 Tests/RunCMake/CommandLine/Wdeprecated.cmake create mode 100644 Tests/RunCMake/CommandLine/Werror_deprecated-result.txt create mode 100644 Tests/RunCMake/CommandLine/Werror_deprecated-stderr.txt create mode 100644 Tests/RunCMake/CommandLine/Werror_deprecated.cmake create mode 100644 Tests/RunCMake/CommandLine/Wno-deprecated.cmake create mode 100644 Tests/RunCMake/CommandLine/Wno-error_deprecated.cmake diff --git a/Help/manual/OPTIONS_BUILD.txt b/Help/manual/OPTIONS_BUILD.txt index 4207db4..5366cae 100644 --- a/Help/manual/OPTIONS_BUILD.txt +++ b/Help/manual/OPTIONS_BUILD.txt @@ -84,3 +84,27 @@ Enable warnings that are meant for the author of the CMakeLists.txt files. + +``-Wdeprecated`` + Enable deprecated macro and function warnings. + + Enable warnings for usage of deprecated macros and functions, that are meant + for the author of the CMakeLists.txt files. + +``-Wno-deprecated`` + Suppress deprecated macro and function warnings. + + Suppress warnings for usage of deprecated macros and functions, that are meant + for the author of the CMakeLists.txt files. + +``-Werror=deprecated`` + Make deprecated macro and function warnings errors. + + Make warnings for usage of deprecated macros and functions, that are meant + for the author of the CMakeLists.txt files, errors. + +``-Wno-error=deprecated`` + Make deprecated macro and function warnings not errors. + + Make warnings for usage of deprecated macros and functions, that are meant + for the author of the CMakeLists.txt files, not errors. diff --git a/Help/release/dev/cmake-Wdeprecated.rst b/Help/release/dev/cmake-Wdeprecated.rst new file mode 100644 index 0000000..7b89fc3 --- /dev/null +++ b/Help/release/dev/cmake-Wdeprecated.rst @@ -0,0 +1,9 @@ +cmake-Wdeprecated +----------------- + +The :variable:`CMAKE_ERROR_DEPRECATED` variable can now be set using the +``-Werror=deprecated`` and ``-Wno-error=deprecated`` :manual:`cmake(1)` +options. + +The :variable:`CMAKE_WARN_DEPRECATED` variable can now be set using the +``-Wdeprecated`` and ``-Wno-deprecated`` :manual:`cmake(1)` options. diff --git a/Help/variable/CMAKE_ERROR_DEPRECATED.rst b/Help/variable/CMAKE_ERROR_DEPRECATED.rst index 43ab282..68befc2 100644 --- a/Help/variable/CMAKE_ERROR_DEPRECATED.rst +++ b/Help/variable/CMAKE_ERROR_DEPRECATED.rst @@ -6,3 +6,7 @@ Whether to issue deprecation errors for macros and functions. If TRUE, this can be used by macros and functions to issue fatal errors when deprecated macros or functions are used. This variable is FALSE by default. + +These errors can be enabled with the ``-Werror=deprecated`` option, or +disabled with the ``-Wno-error=deprecated`` option, when running +:manual:`cmake(1)`. diff --git a/Help/variable/CMAKE_WARN_DEPRECATED.rst b/Help/variable/CMAKE_WARN_DEPRECATED.rst index 7b2510b..2a13895 100644 --- a/Help/variable/CMAKE_WARN_DEPRECATED.rst +++ b/Help/variable/CMAKE_WARN_DEPRECATED.rst @@ -5,3 +5,7 @@ Whether to issue deprecation warnings for macros and functions. If TRUE, this can be used by macros and functions to issue deprecation warnings. This variable is FALSE by default. + +These warnings can be enabled with the ``-Wdeprecated`` option, or +disabled with the ``-Wno-deprecated`` option, when running +:manual:`cmake(1)`. diff --git a/Source/cmake.cxx b/Source/cmake.cxx index eeb6575..4c6550a 100644 --- a/Source/cmake.cxx +++ b/Source/cmake.cxx @@ -125,8 +125,6 @@ cmake::cmake() this->WarnUnused = false; this->WarnUnusedCli = true; this->CheckSystemVars = false; - this->SuppressDevWarnings = false; - this->DoSuppressDevWarnings = false; this->DebugOutput = false; this->DebugTryCompile = false; this->ClearBuildSystem = false; @@ -186,7 +184,7 @@ cmake::~cmake() void cmake::CleanupCommandsAndMacros() { - this->State->Reset(); + this->CurrentSnapshot = this->State->Reset(); this->State->RemoveUserDefinedCommands(); } @@ -251,15 +249,69 @@ bool cmake::SetCacheArgs(const std::vector& args) return false; } } - else if(arg.find("-Wno-dev",0) == 0) + else if(cmHasLiteralPrefix(arg, "-W")) { - this->SuppressDevWarnings = true; - this->DoSuppressDevWarnings = true; + std::string entry = arg.substr(2); + if (entry.empty()) + { + ++i; + if (i < args.size()) + { + entry = args[i]; + } + else + { + cmSystemTools::Error("-W must be followed with [no-][error=]."); + return false; + } } - else if(arg.find("-Wdev",0) == 0) - { - this->SuppressDevWarnings = false; - this->DoSuppressDevWarnings = true; + + std::string name; + bool foundNo = false; + bool foundError = false; + unsigned int nameStartPosition = 0; + + if (entry.find("no-", nameStartPosition) == 0) + { + foundNo = true; + nameStartPosition += 3; + } + + if (entry.find("error=", nameStartPosition) == 0) + { + foundError = true; + nameStartPosition += 6; + } + + name = entry.substr(nameStartPosition); + if (name.empty()) + { + cmSystemTools::Error("No warning name provided."); + return false; + } + + if (!foundNo && !foundError) + { + // -W + this->WarningLevels[name] = std::max(this->WarningLevels[name], + WARNING_LEVEL); + } + else if (foundNo && !foundError) + { + // -Wno + this->WarningLevels[name] = IGNORE_LEVEL; + } + else if (!foundNo && foundError) + { + // -Werror= + this->WarningLevels[name] = ERROR_LEVEL; + } + else + { + // -Wno-error= + this->WarningLevels[name] = std::min(this->WarningLevels[name], + WARNING_LEVEL); + } } else if(arg.find("-U",0) == 0) { @@ -370,6 +422,7 @@ void cmake::ReadListFile(const std::vector& args, // read in the list file to fill the cache if(path) { + this->CurrentSnapshot = this->State->Reset(); std::string homeDir = this->GetHomeDirectory(); std::string homeOutputDir = this->GetHomeOutputDirectory(); this->SetHomeDirectory(cmSystemTools::GetCurrentWorkingDirectory()); @@ -482,7 +535,7 @@ bool cmake::FindPackage(const std::vector& args) std::string linkPath; std::string flags; std::string linkFlags; - gg->CreateGeneratorTargets(mf); + gg->CreateGeneratorTargets(lg.get()); cmGeneratorTarget *gtgt = gg->GetGeneratorTarget(tgt); lg->GetTargetFlags(linkLibs, frameworkPath, linkPath, flags, linkFlags, gtgt, false); @@ -587,11 +640,7 @@ void cmake::SetArgs(const std::vector& args, // skip for now i++; } - else if(arg.find("-Wno-dev",0) == 0) - { - // skip for now - } - else if(arg.find("-Wdev",0) == 0) + else if(arg.find("-W",0) == 0) { // skip for now } @@ -1171,9 +1220,33 @@ int cmake::HandleDeleteCacheVariables(const std::string& var) int cmake::Configure() { - if(this->DoSuppressDevWarnings) + WarningLevel warningLevel; + + if (this->WarningLevels.count("deprecated") == 1) { - if(this->SuppressDevWarnings) + warningLevel = this->WarningLevels["deprecated"]; + if (warningLevel == WARNING_LEVEL) + { + this->CacheManager-> + AddCacheEntry("CMAKE_WARN_DEPRECATED", "TRUE", + "Whether to issue deprecation warnings for" + " macros and functions.", + cmState::BOOL); + } + else if (warningLevel == ERROR_LEVEL) + { + this->CacheManager-> + AddCacheEntry("CMAKE_ERROR_DEPRECATED", "TRUE", + "Whether to issue deprecation errors for macros" + " and functions.", + cmState::BOOL); + } + } + + if (this->WarningLevels.count("dev") == 1) + { + warningLevel = this->WarningLevels["dev"]; + if (warningLevel == IGNORE_LEVEL) { this->CacheManager-> AddCacheEntry("CMAKE_SUPPRESS_DEVELOPER_WARNINGS", "TRUE", @@ -1181,7 +1254,7 @@ int cmake::Configure() " the author of the CMakeLists.txt files.", cmState::INTERNAL); } - else + else if (warningLevel == WARNING_LEVEL) { this->CacheManager-> AddCacheEntry("CMAKE_SUPPRESS_DEVELOPER_WARNINGS", "FALSE", @@ -1190,6 +1263,7 @@ int cmake::Configure() cmState::INTERNAL); } } + int ret = this->ActualConfigure(); const char* delCacheVars = this->State ->GetGlobalProperty("__CMAKE_DELETE_CACHE_CHANGE_VARS_"); @@ -2667,3 +2741,18 @@ void cmake::RunCheckForUnusedVariables() } #endif } + +void cmake::SetSuppressDevWarnings(bool b) +{ + // equivalent to -Wno-dev + if (b) + { + this->WarningLevels["dev"] = IGNORE_LEVEL; + } + // equivalent to -Wdev + else + { + this->WarningLevels["dev"] = std::max(this->WarningLevels["dev"], + WARNING_LEVEL); + } +} diff --git a/Source/cmake.h b/Source/cmake.h index f0f9411..59a7663 100644 --- a/Source/cmake.h +++ b/Source/cmake.h @@ -69,6 +69,12 @@ class cmake DEPRECATION_WARNING }; + enum WarningLevel + { + IGNORE_LEVEL, + WARNING_LEVEL, + ERROR_LEVEL + }; /** \brief Describes the working modes of cmake */ enum WorkingMode @@ -270,6 +276,7 @@ class cmake // Do we want trace output during the cmake run. bool GetTrace() { return this->Trace;} void SetTrace(bool b) { this->Trace = b;} + void SetSuppressDevWarnings(bool b); bool GetWarnUninitialized() { return this->WarnUninitialized;} void SetWarnUninitialized(bool b) { this->WarnUninitialized = b;} bool GetWarnUnused() { return this->WarnUnused;} @@ -290,12 +297,6 @@ class cmake std::string const& GetCMakeEditCommand() const { return this->CMakeEditCommand; } - void SetSuppressDevWarnings(bool v) - { - this->SuppressDevWarnings = v; - this->DoSuppressDevWarnings = true; - } - /** Display a message to the user. */ void IssueMessage(cmake::MessageType t, std::string const& text, cmListFileBacktrace const& backtrace = cmListFileBacktrace()); @@ -339,8 +340,7 @@ protected: cmPolicies *Policies; cmGlobalGenerator *GlobalGenerator; cmCacheManager *CacheManager; - bool SuppressDevWarnings; - bool DoSuppressDevWarnings; + std::map WarningLevels; std::string GeneratorPlatform; std::string GeneratorToolset; @@ -415,7 +415,13 @@ private: {"-T ", "Specify toolset name if supported by generator."}, \ {"-A ", "Specify platform name if supported by generator."}, \ {"-Wno-dev", "Suppress developer warnings."},\ - {"-Wdev", "Enable developer warnings."} + {"-Wdev", "Enable developer warnings."},\ + {"-Wdeprecated", "Enable deprecated macro and function warnings."},\ + {"-Wno-deprecated", "Suppress deprecated macro and function warnings."},\ + {"-Werror=deprecated", "Make deprecated macro and function warnings " \ + "errors."},\ + {"-Wno-error=deprecated", "Make deprecated macro and function warnings " \ + "not errors."} #define FOR_EACH_C_FEATURE(F) \ F(c_function_prototypes) \ diff --git a/Tests/RunCMake/CommandLine/RunCMakeTest.cmake b/Tests/RunCMake/CommandLine/RunCMakeTest.cmake index 69beed9..71d86aa 100644 --- a/Tests/RunCMake/CommandLine/RunCMakeTest.cmake +++ b/Tests/RunCMake/CommandLine/RunCMakeTest.cmake @@ -22,13 +22,30 @@ run_cmake_command(G_bad-arg ${CMAKE_COMMAND} -G NoSuchGenerator) run_cmake_command(P_no-arg ${CMAKE_COMMAND} -P) run_cmake_command(P_no-file ${CMAKE_COMMAND} -P nosuchscriptfile.cmake) +run_cmake_command(build-no-dir + ${CMAKE_COMMAND} --build) run_cmake_command(build-no-cache ${CMAKE_COMMAND} --build ${RunCMake_SOURCE_DIR}) run_cmake_command(build-no-generator ${CMAKE_COMMAND} --build ${RunCMake_SOURCE_DIR}/cache-no-generator) +run_cmake_command(build-bad-dir + ${CMAKE_COMMAND} --build dir-does-not-exist) run_cmake_command(build-bad-generator ${CMAKE_COMMAND} --build ${RunCMake_SOURCE_DIR}/cache-bad-generator) +function(run_BuildDir) + # Use a single build tree for a few tests without cleaning. + set(RunCMake_TEST_BINARY_DIR ${RunCMake_BINARY_DIR}/BuildDir-build) + set(RunCMake_TEST_NO_CLEAN 1) + file(REMOVE_RECURSE "${RunCMake_TEST_BINARY_DIR}") + file(MAKE_DIRECTORY "${RunCMake_TEST_BINARY_DIR}") + + run_cmake(BuildDir) + run_cmake_command(BuildDir--build ${CMAKE_COMMAND} -E chdir .. + ${CMAKE_COMMAND} --build BuildDir-build --target CustomTarget) +endfunction() +run_BuildDir() + if(RunCMake_GENERATOR STREQUAL "Ninja") # Use a single build tree for a few tests without cleaning. set(RunCMake_TEST_BINARY_DIR ${RunCMake_BINARY_DIR}/Build-build) @@ -115,6 +132,26 @@ set(RunCMake_TEST_OPTIONS -Wno-dev -Wdev) run_cmake(Wdev) unset(RunCMake_TEST_OPTIONS) +set(RunCMake_TEST_OPTIONS -Wdeprecated) +run_cmake(Wdeprecated) +unset(RunCMake_TEST_OPTIONS) + +set(RunCMake_TEST_OPTIONS -Wno-deprecated) +run_cmake(Wno-deprecated) +unset(RunCMake_TEST_OPTIONS) + +set(RunCMake_TEST_OPTIONS -Werror=deprecated) +run_cmake(Werror_deprecated) +unset(RunCMake_TEST_OPTIONS) + +set(RunCMake_TEST_OPTIONS -Wno-error=deprecated) +run_cmake(Wno-error_deprecated) +unset(RunCMake_TEST_OPTIONS) + +run_cmake_command(W_bad-arg1 ${CMAKE_COMMAND} -W) +run_cmake_command(W_bad-arg2 ${CMAKE_COMMAND} -Wno-) +run_cmake_command(W_bad-arg3 ${CMAKE_COMMAND} -Werror=) + set(RunCMake_TEST_OPTIONS --debug-output) run_cmake(debug-output) unset(RunCMake_TEST_OPTIONS) diff --git a/Tests/RunCMake/CommandLine/W_bad-arg1-result.txt b/Tests/RunCMake/CommandLine/W_bad-arg1-result.txt new file mode 100644 index 0000000..d00491f --- /dev/null +++ b/Tests/RunCMake/CommandLine/W_bad-arg1-result.txt @@ -0,0 +1 @@ +1 diff --git a/Tests/RunCMake/CommandLine/W_bad-arg1-stderr.txt b/Tests/RunCMake/CommandLine/W_bad-arg1-stderr.txt new file mode 100644 index 0000000..e912728 --- /dev/null +++ b/Tests/RunCMake/CommandLine/W_bad-arg1-stderr.txt @@ -0,0 +1,2 @@ +CMake Error: -W must be followed with \[no-\]\[error=\]. +CMake Error: Problem processing arguments. Aborting. diff --git a/Tests/RunCMake/CommandLine/W_bad-arg2-result.txt b/Tests/RunCMake/CommandLine/W_bad-arg2-result.txt new file mode 100644 index 0000000..d00491f --- /dev/null +++ b/Tests/RunCMake/CommandLine/W_bad-arg2-result.txt @@ -0,0 +1 @@ +1 diff --git a/Tests/RunCMake/CommandLine/W_bad-arg2-stderr.txt b/Tests/RunCMake/CommandLine/W_bad-arg2-stderr.txt new file mode 100644 index 0000000..cc643df --- /dev/null +++ b/Tests/RunCMake/CommandLine/W_bad-arg2-stderr.txt @@ -0,0 +1,2 @@ +CMake Error: No warning name provided. +CMake Error: Problem processing arguments. Aborting. diff --git a/Tests/RunCMake/CommandLine/W_bad-arg3-result.txt b/Tests/RunCMake/CommandLine/W_bad-arg3-result.txt new file mode 100644 index 0000000..d00491f --- /dev/null +++ b/Tests/RunCMake/CommandLine/W_bad-arg3-result.txt @@ -0,0 +1 @@ +1 diff --git a/Tests/RunCMake/CommandLine/W_bad-arg3-stderr.txt b/Tests/RunCMake/CommandLine/W_bad-arg3-stderr.txt new file mode 100644 index 0000000..cc643df --- /dev/null +++ b/Tests/RunCMake/CommandLine/W_bad-arg3-stderr.txt @@ -0,0 +1,2 @@ +CMake Error: No warning name provided. +CMake Error: Problem processing arguments. Aborting. diff --git a/Tests/RunCMake/CommandLine/Wdeprecated-stderr.txt b/Tests/RunCMake/CommandLine/Wdeprecated-stderr.txt new file mode 100644 index 0000000..e9be1dc --- /dev/null +++ b/Tests/RunCMake/CommandLine/Wdeprecated-stderr.txt @@ -0,0 +1,4 @@ +^CMake Deprecation Warning at Wdeprecated.cmake:1 \(message\): + Some deprecated warning +Call Stack \(most recent call first\): + CMakeLists.txt:3 \(include\) diff --git a/Tests/RunCMake/CommandLine/Wdeprecated.cmake b/Tests/RunCMake/CommandLine/Wdeprecated.cmake new file mode 100644 index 0000000..3142b42 --- /dev/null +++ b/Tests/RunCMake/CommandLine/Wdeprecated.cmake @@ -0,0 +1 @@ +message(DEPRECATION "Some deprecated warning") diff --git a/Tests/RunCMake/CommandLine/Werror_deprecated-result.txt b/Tests/RunCMake/CommandLine/Werror_deprecated-result.txt new file mode 100644 index 0000000..d00491f --- /dev/null +++ b/Tests/RunCMake/CommandLine/Werror_deprecated-result.txt @@ -0,0 +1 @@ +1 diff --git a/Tests/RunCMake/CommandLine/Werror_deprecated-stderr.txt b/Tests/RunCMake/CommandLine/Werror_deprecated-stderr.txt new file mode 100644 index 0000000..6acdc73 --- /dev/null +++ b/Tests/RunCMake/CommandLine/Werror_deprecated-stderr.txt @@ -0,0 +1,4 @@ +^CMake Deprecation Error at Werror_deprecated.cmake:1 \(message\): + Some deprecated warning +Call Stack \(most recent call first\): + CMakeLists.txt:3 \(include\) diff --git a/Tests/RunCMake/CommandLine/Werror_deprecated.cmake b/Tests/RunCMake/CommandLine/Werror_deprecated.cmake new file mode 100644 index 0000000..3142b42 --- /dev/null +++ b/Tests/RunCMake/CommandLine/Werror_deprecated.cmake @@ -0,0 +1 @@ +message(DEPRECATION "Some deprecated warning") diff --git a/Tests/RunCMake/CommandLine/Wno-deprecated.cmake b/Tests/RunCMake/CommandLine/Wno-deprecated.cmake new file mode 100644 index 0000000..3142b42 --- /dev/null +++ b/Tests/RunCMake/CommandLine/Wno-deprecated.cmake @@ -0,0 +1 @@ +message(DEPRECATION "Some deprecated warning") diff --git a/Tests/RunCMake/CommandLine/Wno-error_deprecated.cmake b/Tests/RunCMake/CommandLine/Wno-error_deprecated.cmake new file mode 100644 index 0000000..3142b42 --- /dev/null +++ b/Tests/RunCMake/CommandLine/Wno-error_deprecated.cmake @@ -0,0 +1 @@ +message(DEPRECATION "Some deprecated warning") -- 2.1.4 From radovan.bast at gmail.com Thu Jul 2 18:25:27 2015 From: radovan.bast at gmail.com (Radovan Bast) Date: Thu, 02 Jul 2015 22:25:27 +0000 Subject: [cmake-developers] Fortran module dependencies and preprocessing in CMake 3.3.0-rc3 In-Reply-To: <55953D12.7010706@kitware.com> References: <55953D12.7010706@kitware.com> Message-ID: dear Brad, thanks for testing it on your side and also for the suggestions! I can consistently reproduce it locally on 3 different machines (Ubuntu 14.04 and Arch derivative; gfortran 4.8.4 and 5.1.0). I have Git bisected the history and this is the commit that broke this example on my machines: https://github.com/Kitware/CMake/commit/0b945ea9a6a38d1b3ee27cc32afb4268bd571600 Can you see something possibly related in there? thank you & best wishes, radovan On Thu, Jul 2, 2015 at 3:30 PM Brad King wrote: > On 07/02/2015 04:14 AM, Radovan Bast wrote: > > We have observed a changed and surprising behavior in CMake 3.3.0-rc3 > > with Fortran module dependency scanning and preprocessing compared to > > earlier CMake versions (for instance 3.2.3). > > I don't recall any changes related to this since 3.2. I also cannot > reproduce the problem with the example you provided. > > > It seems that Fortran dependencies are scanned prior to pre-processing. > > CMake does its own approximate preprocessing for dependency scanning. > This hasn't changed in a long time. > > Can you please provide a more complete example to reproduce this? > Or, if you can consistently reproduce it locally please try bisecting > our Git history between 3.2 and 3.3 to see if you can find the commit > that introduced the problem. > > Thanks, > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewmailing at gmail.com Thu Jul 2 19:54:26 2015 From: ewmailing at gmail.com (Eric Wing) Date: Thu, 2 Jul 2015 16:54:26 -0700 Subject: [cmake-developers] Adding Swift support to CMake In-Reply-To: <559191D6.5080403@kitware.com> References: <55842C6C.4050504@kitware.com> <559191D6.5080403@kitware.com> Message-ID: On 6/29/15, Brad King wrote: > On 06/25/2015 09:24 AM, Eric Wing wrote: >> I pushed up a couple of repos for everybody to try. > > Thanks. From that I was able to make some progress with getting > CMakeDetermineSwiftCompiler to work. > > I've made two tweaks to CMakeDetermineCompilerId to make it easier to > use from a new CMakeDetermineSwiftCompiler module: > > CMakeDetermineCompilerId: Simplify src reference in IDE projects > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8306108f > > CMakeDetermineCompilerId: Use per-language regex to match Xcode compiler > tool > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6452291c > > Once these changes test cleanly on nightly builds I will look at > the rest of the changes for basic Swift + Xcode. > > -Brad > Thank you Brad. When you are ready, let me know how I can help next. Thanks, Eric From jafelds at gmail.com Thu Jul 2 22:22:27 2015 From: jafelds at gmail.com (Jason Felds) Date: Thu, 2 Jul 2015 22:22:27 -0400 Subject: [cmake-developers] Feature Request: Modify CXX_STANDARD behavior for Xcode Generator: Starting Tips? Message-ID: Salutations. I right now use CXX_STANDARD and CXX_STANDARD_LIBRARY for some test projects since I want to utilize smart pointers. As I am on a Mac, my preferred IDE is Xcode (sometimes called XCode), so I generate Xcode targets by default. I've noticed, however, that whenever I use CXX_STANDARD and its companions, it places the -std=gnu++11 (or equivalent) calls in the OTHER_CPLUSPLUSFLAGS attribute instead of the CLANG_CXX_LANGUAGE_STANDARD attribute. Here's my current knowledge of this code base to see what currently happens and what needs to be done. - The source file Source/cmGlobalXCodeGenerator.cxx is what generates the Xcode file. - Lines 2272 to 2277 (assuming master branch) are where the OTHER_CPLUSPLUSFLAGS are written. - The flags are coming from either one of cflags[*li] or defFlags. defFlags is filled in via GetDefineFlags() within Source/cmMakefile.h, whereas cflags is filled in with the contents of gflags. - Doing a grep for `gnu++11` gives me either .rst files or .cmake files, but no .h or .cxx files. I guess I'm still a little confused as to where I need to modify the Xcode generator. My questions are thus the following: - Is there a proper source location where the standard is defined? - Which variable does it get set to: cflags or defFlags? - Is there a clean way to remove the std flag and place it in a more Apple friendly location, or would I have to do so? Sincerely, Jason Felds -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.stuermer at schaeffler.com Fri Jul 3 05:38:16 2015 From: michael.stuermer at schaeffler.com (Stuermer, Michael SP/HZA-ZSEP) Date: Fri, 3 Jul 2015 09:38:16 +0000 Subject: [cmake-developers] C# support? In-Reply-To: <4797EDAAB4843944A70CA99A7DE7D8BD0400C3A9@DE012432.schaeffler.com> References: <4797EDAAB4843944A70CA99A7DE7D8BD0400AAC9@DE012432.schaeffler.com> <55917AD8.6070305@kitware.com> <4797EDAAB4843944A70CA99A7DE7D8BD0400BEA1@DE012432.schaeffler.com> <55929E58.6030600@kitware.com> <4797EDAAB4843944A70CA99A7DE7D8BD0400C3A9@DE012432.schaeffler.com> Message-ID: <4797EDAAB4843944A70CA99A7DE7D8BD0400C52C@DE012432.schaeffler.com> Hi all, some minor updates to the patches. There where 2-3 bugs somewhere... https://github.com/micst/CMake/tree/csharp is up to date. best regards, Michael > -----Original Message----- > From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On > Behalf Of Stuermer, Michael SP/HZA-ZSEP > Sent: Thursday, July 02, 2015 3:54 PM > To: cmake-developers at cmake.org > Subject: Re: [cmake-developers] C# support? > > Hi all, > > I got the first sort of working version running. Would be great if some > people could have a look at it if it's going into a good direction. > > Some explanations: > > Patch 0001: > - adds the necessary Module/* files for enabling C# as a language > - CAUTION: only Visual Studio 2013 generators are supported at the > moment > - there is a verbose message which is shown when C# is used to guide > people where to go for improvement > > Patch 0002: > - some minor changes to mostly visual studio related classes to enable > .csproj support > o .csproj GUID is added > o a method to check if the target is C# is added > > Patch 0003: > - the actual implementation of the .csproj generation > - all generation takes place inside VisualStudio10TargetGenerator > class > > > There is an example project in the appendix of this mail which you can > use to see how .csproj can be generated now. > > And yes, there are still quite some things missing: > > - Tests (!!!!) > - NMake support (even though that should not bee too hard) > o better handling of the flagtable that I added (not sure if I > understood correctly how the concept is supposed to be used) > - documentation (!!!!) > > Most questions on how to use the C# language and mixing with C++ > targets should be answered by looking at the example project. > > Some VS_* target properties already existed which I reused. > > I added two Property-"Groups": > - VS_DOTNET_REFERENCE_ properties for references with a > tag, though they > also can be added to the normal > VS_DOTNET_REFERENCES. This is > a target-property > - CSharpPROJ_ the tag will be added to > the tag of the specified > Source files. This is a source > property. > - CSharpPROJ_SubType the currently only used case of > above property group. It's needed > to tell visual studio what kind of > file is added. You can safely omit > this, but visual studio will not > be able to run the designer in the > correct mode without it. > > Project references are added by simply using target_link_libraries(). > All other references must use done in one of the above described ways. > > It would be great if some people could try if the example project works > for them. If you have improvements don't hesitate to submit any patch > to my current fork on github (branch "csharp"): > > https://github.com/micst/CMake.git > > The example project can be found there as well: > > https://github.com/micst/CMakeCSharpTest.git > > > best regards, > Michael > > > > > -----Original Message----- > > From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On > > Behalf Of Brad King > > Sent: Tuesday, June 30, 2015 3:49 PM > > To: cmake-developers at cmake.org > > Subject: Re: [cmake-developers] C# support? > > > > On 06/30/2015 03:21 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > > > it would be great if some people could step forward once everything > > is > > > running from my side to help get makefile and linux support (and > > > test other Visual Studio versions). > > > > Once you have it working in VS 2013 the other VS >= 2010 versions > > should be easy. I'm not sure about other generators yet. If you > have > > good coverage in the test suite updates then that will make the task > > of adding support to other generators easier. > > > > For now you can have CMakeDetermineCSharpCompiler do a > > message(FATAL_ERROR) when CMAKE_GENERATOR is set to a value that is > > not supported. That can be lifted when the other generators > implement > > the language. > > > > > About enable_language(): > > > > > > have the appropriate cmake-scripts in "Module" directory > > [snip] > > > Almost everything relevant goes in the target generator class > > > VisualStudio10TargetGenerator. > > > > Great! > > > > > Once done, do you want patchfiles here on the list or a pull > request > > > from my fork on github? > > > > Please send patch files here as requested in CONTRIBUTING.rst. > > Please re-organize commits into a logical series of updates rather > > than the original unorganized development history. > > > > Thanks! > > -Brad > > > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For > > more information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake-developers -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-added-necessary-methods-for-.csproj-generation.patch Type: application/octet-stream Size: 6446 bytes Desc: 0002-added-necessary-methods-for-.csproj-generation.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-added-.csproj-generation.patch Type: application/octet-stream Size: 52451 bytes Desc: 0003-added-.csproj-generation.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-added-CSharp-files-to-Modules.patch Type: application/octet-stream Size: 19339 bytes Desc: 0001-added-CSharp-files-to-Modules.patch URL: From konstantin at podsvirov.pro Fri Jul 3 09:09:52 2015 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Fri, 03 Jul 2015 16:09:52 +0300 Subject: [cmake-developers] [PATCH] Option CMAKE_INSTALL_COMPONENTS and IFW installer Message-ID: <1392021435928992@web3g.yandex.ru> Hi, Brad! A long time ago... About 6 months ago I started a topic cmake-install-components. Today I am ready to share the results. The basic idea is to use the COMPONENT option in the install command inside the CMake. So as not to disturb those who do not need it I have added the option CMAKE_INSTALL_COMPONENTS, which by default is set to OFF. CMake IFW installer recognizes this option. In the attachment to the letter patch file and screenshots of what I did. Also these changes are reflected in the branch on my server: http://git.podsvirov.pro/?p=kitware/cmake.git;a=shortlog;h=refs/heads/cmake-install-components I have tested in Windows and Debian for QtIFW 2.0. Please consider my code and apply it. Changes quite a lot and I'm ready for the discussion. Have a nice weekend, and I'm waiting for an answer. -- Regards, Konstantin Podsvirov -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake-install-components.png Type: image/png Size: 42902 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake-install-components-licenses.png Type: image/png Size: 43419 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake-install-components.patch Type: text/x-diff Size: 19355 bytes Desc: not available URL: From daniel at pfeifer-mail.de Fri Jul 3 17:02:29 2015 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Fri, 3 Jul 2015 23:02:29 +0200 Subject: [cmake-developers] CTest: hide progress ticks in verbose output Message-ID: Hi, The progress ticks and information about the length of the output are useful when the actual output is not visible. When the output is printed, the progress ticks * add no useful information * do not look pretty * make the output hard to parse for tools. The attached patch hides the progress ticks when the output is shown (-VV). Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-CTest-hide-progress-ticks-in-verbose-output.patch Type: text/x-patch Size: 4474 bytes Desc: not available URL: From umireon at gmail.com Fri Jul 3 22:48:15 2015 From: umireon at gmail.com (=?utf-8?Q?umireon=40gmail.com?=) Date: Sat, 4 Jul 2015 11:48:15 +0900 Subject: [cmake-developers] Xcode generator does not recognize -Ofast Message-ID: Hi all, I am working on Xcode with CMake's Xcode Generator and it works nicely. However, the?Xcode Generator does not handle the -Ofast flag properly, and then it is necessary to the set Optimization Level manually when -Ofast flag is utilized in the project. This is because the Xcode Generator uses just one letter right after the `-O` to determine what the project setting should be. When `-O3` is given, `3` is used for Optimization Level and everything is fine, but when `-Ofast` is given, `f` is used for it, which is an invalid value. It is not tested but it can be resolved by accepting all letter after `-O` flags. Here is the relevant code handling Optimization Level: https://github.com/Kitware/CMake/blob/3ae8e84ef5c94e5fa250b4e2466aa6632a233bb2/Source/cmGlobalXCodeGenerator.cxx#L2218 The following is an example to reproduce this problem: -- CMakeLists.txt cmake_minimum_required(VERSION 3.2) add_executable(hello hello.c) target_compile_definitions(hello PRIVATE -Ofast) #target_compile_definitions(hello PRIVATE -O3) -- hello.c #include int main(void) { ? printf("hello world\n"); ? return 0; } -- Shell $ cd /path/to/project $ mkdir build; cd build $ cmake -G Xcode .. $ open Project.xcodeproj Then open the project setting on Xcode and show the setting of 'hello' Finally it is found that Optimization Level is -O0, not -Ofast When -O3 is specified,?Optimization Level is set to -O3, correctly. I would appreciate any comments. Thank you for reading, Kaito -- Signed-Off-By: Udagawa Kaito From mantis at public.kitware.com Sat Jul 4 08:39:44 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 4 Jul 2015 08:39:44 -0400 Subject: [cmake-developers] [CMake 0015638]: interface libraries and --graphviz Message-ID: <53246c7b446f7d343c533a4134ee95c3@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15638 ====================================================================== Reported By: tim blechmann Assigned To: ====================================================================== Project: CMake Issue ID: 15638 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-04 08:39 EDT Last Modified: 2015-07-04 08:39 EDT ====================================================================== Summary: interface libraries and --graphviz Description: currently interface libraries are not taken into account when visualising the dependencies via --graphviz Steps to Reproduce: consider the following project: ----------- project(foo) add_library( a STATIC a.cpp ) add_library( b_interface INTERFACE ) target_link_libraries( b_interface INTERFACE a) add_library( b STATIC b.cpp ) target_link_libraries( b PUBLIC b_interface ) ----------- expected behaviour: edge between a and b actual behaviour: no edge between a and b ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-04 08:39 tim blechmann New Issue ====================================================================== From daniel at pfeifer-mail.de Sat Jul 4 18:27:08 2015 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Sun, 5 Jul 2015 00:27:08 +0200 Subject: [cmake-developers] PATCH: add subcommand string(APPEND) Message-ID: Attached is a patch that adds a subcommand string(APPEND). This allows to write > string(APPEND string_variable "some string") instead of > set(string_variable "${string_variable}some string") Two other patches make use of this subcommand. The changes have been created with > find Modules -type f -print0 | xargs -0 perl -i -0pe \ > 's/set\(([a-zA-Z0-9_]+)(\s+)"\$\{\1\}([^"])/string(APPEND \1\2"\3/g' cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-add-subcommand-string-APPEND.patch Type: text/x-patch Size: 3250 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Use-string-APPEND-in-Modules.patch Type: text/x-patch Size: 92866 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Use-string-APPEND-in-Tests.patch Type: text/x-patch Size: 39681 bytes Desc: not available URL: From mantis at public.kitware.com Sun Jul 5 11:24:35 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 5 Jul 2015 11:24:35 -0400 Subject: [cmake-developers] [CMake 0015639]: [Feature Request] Generate one VS solution for several toolsets and architectures Message-ID: <4a7857dbdc7f70eae362be5841d7604f@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15639 ====================================================================== Reported By: KindDragon Assigned To: ====================================================================== Project: CMake Issue ID: 15639 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-05 11:24 EDT Last Modified: 2015-07-05 11:24 EDT ====================================================================== Summary: [Feature Request] Generate one VS solution for several toolsets and architectures Description: I want generate one "Visual Studio 14 2015" solution for several toolsets (VS2012, VS2013, VS2015) and several architectures (Win32, x64) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-05 11:24 KindDragon New Issue ====================================================================== From johnstonj.public at codenest.com Mon Jul 6 01:52:34 2015 From: johnstonj.public at codenest.com (James Johnston) Date: Mon, 6 Jul 2015 05:52:34 -0000 Subject: [cmake-developers] [PATCH] ExternalProject: Added new USES_TERMINAL options Message-ID: <00f401d0b7af$f661f8c0$e325ea40$@codenest.com> Hi, I worked on a patch to allow you to pass USES_TERMINAL through ExternalProject to the underlying add_custom_command(). Here is the commit message: ExternalProject: Added new USES_TERMINAL options Added new USES_TERMINAL option to the ExternalProject_Add_Step function. This option passes USES_TERMINAL to the underlying add_custom_command call so that the Ninja console pool is used. Also, corresponding new USES_TERMINAL_ options were added to the ExternalProject_Add function. Justification: if using Ninja with a CMake superbuild, it's often desirable to limit the superbuild to ONE sub-Ninja process at a time to avoid oversubscribing the CPU. Using the console pool also makes it easy to monitor the progress of the sub-Ninja process. Independent USES_TERMINAL_ arguments are passed to ExternalProject_Add instead of one USES_TERMINAL argument that controls everything. Users may wish to run some steps in parallel but not others (e.g. parallelize configure but not build). Best regards, James Johnston -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-ExternalProject-Added-new-USES_TERMINAL-options.patch Type: application/octet-stream Size: 13915 bytes Desc: not available URL: From brad.king at kitware.com Mon Jul 6 09:02:55 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 06 Jul 2015 09:02:55 -0400 Subject: [cmake-developers] Fortran module dependencies and preprocessing in CMake 3.3.0-rc3 In-Reply-To: References: <55953D12.7010706@kitware.com> Message-ID: <559A7C7F.9030002@kitware.com> On 07/02/2015 06:25 PM, Radovan Bast wrote: > I can consistently reproduce it locally on 3 different machines (Ubuntu 14.04 > and Arch derivative; gfortran 4.8.4 and 5.1.0). > > I have Git bisected the history and this is the commit that broke this > example on my machines: > https://github.com/Kitware/CMake/commit/0b945ea9a6a38d1b3ee27cc32afb4268bd571600 Thanks for bisecting! > Can you see something possibly related in there? That change may have accidentally affected the preprocessor definitions sent to the Fortran compiler. The error message you're seeing is actually coming from the compiler trying to use the module, so SOMEDEF must be getting defined. However, without seeing your CMake code I cannot determine how. Can you provide a minimal source tarball that exhibits the problem? Thanks, -Brad From radovan.bast at gmail.com Mon Jul 6 09:13:38 2015 From: radovan.bast at gmail.com (Radovan Bast) Date: Mon, 06 Jul 2015 13:13:38 +0000 Subject: [cmake-developers] Fortran module dependencies and preprocessing in CMake 3.3.0-rc3 In-Reply-To: <559A7C7F.9030002@kitware.com> References: <55953D12.7010706@kitware.com> <559A7C7F.9030002@kitware.com> Message-ID: dear Brad, SOMEDEF is defined at compile time. Attached is a tarball that contains the CMakeLists.txt which defines SOMEDEF, a main.F90 and a mymodule.F90 which contains the module which is not built prior to building main.F90. In principle the problem can be reproduced like this: ``` tar xvzf example.tar.gz cd example/ mkdir build cd build/ cmake .. make ``` Thank you for looking into this! Best wishes, radovan On Mon, Jul 6, 2015 at 3:02 PM Brad King wrote: > On 07/02/2015 06:25 PM, Radovan Bast wrote: > > I can consistently reproduce it locally on 3 different machines (Ubuntu > 14.04 > > and Arch derivative; gfortran 4.8.4 and 5.1.0). > > > > I have Git bisected the history and this is the commit that broke this > > example on my machines: > > > https://github.com/Kitware/CMake/commit/0b945ea9a6a38d1b3ee27cc32afb4268bd571600 > > Thanks for bisecting! > > > Can you see something possibly related in there? > > That change may have accidentally affected the preprocessor definitions > sent to the Fortran compiler. The error message you're seeing is actually > coming from the compiler trying to use the module, so SOMEDEF must be > getting defined. However, without seeing your CMake code I cannot > determine how. > > Can you provide a minimal source tarball that exhibits the problem? > > Thanks, > -Brad > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: example.tar.gz Type: application/gzip Size: 496 bytes Desc: not available URL: From brad.king at kitware.com Mon Jul 6 10:41:19 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 06 Jul 2015 10:41:19 -0400 Subject: [cmake-developers] Fortran module dependencies and preprocessing in CMake 3.3.0-rc3 In-Reply-To: References: <55953D12.7010706@kitware.com> <559A7C7F.9030002@kitware.com> Message-ID: <559A938F.4010201@kitware.com> On 07/06/2015 09:13 AM, Radovan Bast wrote: > SOMEDEF is defined at compile time. Attached is a tarball that contains > the CMakeLists.txt which defines SOMEDEF, a main.F90 and a mymodule.F90 > which contains the module which is not built prior to building main.F90. Thanks. I've drafted a fix and a test case: Fortran: Fix passing of preprocessor definitions to dependency scanner http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0a203db5 If it passes nightly testing I'll merge it to 'release' for 3.3. Thanks, -Brad From radovan.bast at gmail.com Mon Jul 6 10:46:49 2015 From: radovan.bast at gmail.com (Radovan Bast) Date: Mon, 06 Jul 2015 14:46:49 +0000 Subject: [cmake-developers] Fortran module dependencies and preprocessing in CMake 3.3.0-rc3 In-Reply-To: <559A938F.4010201@kitware.com> References: <55953D12.7010706@kitware.com> <559A7C7F.9030002@kitware.com> <559A938F.4010201@kitware.com> Message-ID: dear Brad, thanks a lot! This is very much appreciated. Best wishes, radovan On Mon, Jul 6, 2015 at 4:41 PM Brad King wrote: > On 07/06/2015 09:13 AM, Radovan Bast wrote: > > SOMEDEF is defined at compile time. Attached is a tarball that contains > > the CMakeLists.txt which defines SOMEDEF, a main.F90 and a mymodule.F90 > > which contains the module which is not built prior to building main.F90. > > Thanks. I've drafted a fix and a test case: > > Fortran: Fix passing of preprocessor definitions to dependency scanner > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0a203db5 > > If it passes nightly testing I'll merge it to 'release' for 3.3. > > Thanks, > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roman.donchenko at itseez.com Mon Jul 6 10:54:19 2015 From: roman.donchenko at itseez.com (Roman Donchenko) Date: Mon, 6 Jul 2015 17:54:19 +0300 Subject: [cmake-developers] [PATCH] cmArchiveWrite: don't store sparse files when using standard tar formats Message-ID: <1436194459-8713-1-git-send-email-roman.donchenko@itseez.com> Sparse files in tars are a GNU extension that libarchive will use if it detects holes in the input file, even when using the standard pax/paxr formats. Not all tar implementations can handle sparse files; in particular, the internal implementation dpkg uses to extract packages can't. To maximize archive portability, turn this feature off by clearing the sparseness information from archive entries. --- Source/cmArchiveWrite.cxx | 11 ++++++++++- Source/cmArchiveWrite.h | 1 + 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/Source/cmArchiveWrite.cxx b/Source/cmArchiveWrite.cxx index 72818f5..32afde1 100644 --- a/Source/cmArchiveWrite.cxx +++ b/Source/cmArchiveWrite.cxx @@ -84,7 +84,8 @@ cmArchiveWrite::cmArchiveWrite( Stream(os), Archive(archive_write_new()), Disk(archive_read_disk_new()), - Verbose(false) + Verbose(false), + Format(format) { switch (c) { @@ -282,6 +283,14 @@ bool cmArchiveWrite::AddFile(const char* file, archive_entry_acl_clear(e); archive_entry_xattr_clear(e); archive_entry_set_fflags(e, 0, 0); + + if (Format == "pax" || Format == "paxr") + { + // Sparse files are a GNU tar extension. Don't use them in standard + // tar files. + archive_entry_sparse_clear(e); + } + if(archive_write_header(this->Archive, e) != ARCHIVE_OK) { this->Error = "archive_write_header: "; diff --git a/Source/cmArchiveWrite.h b/Source/cmArchiveWrite.h index 794cb28..e6f515d 100644 --- a/Source/cmArchiveWrite.h +++ b/Source/cmArchiveWrite.h @@ -84,6 +84,7 @@ private: struct archive* Archive; struct archive* Disk; bool Verbose; + std::string Format; std::string Error; std::string MTime; }; -- 1.9.1 From brad.king at kitware.com Mon Jul 6 14:00:55 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 06 Jul 2015 14:00:55 -0400 Subject: [cmake-developers] [PATCH] Option CMAKE_INSTALL_COMPONENTS and IFW installer In-Reply-To: <1392021435928992@web3g.yandex.ru> References: <1392021435928992@web3g.yandex.ru> Message-ID: <559AC257.4000309@kitware.com> On 07/03/2015 09:09 AM, Konstantin Podsvirov wrote: > About 6 months ago I started a topic cmake-install-components. > Today I am ready to share the results. Great, thanks! The changes look good except for comments below. > So as not to disturb those who do not need it I have added the > option CMAKE_INSTALL_COMPONENTS, which by default is set to OFF. Please rename this to "CMake_INSTALL_COMPONENTS". We've started a convention of using "CMake_" for options affecting the build of CMake itself and "CMAKE_" for general CMake-defined options that could be used by any project. In this hunk: > -install(TARGETS cmake ctest cpack DESTINATION bin) > +# Install tools > + > +set(_tools cmake ctest cpack) > + > if(APPLE) > - install(TARGETS cmakexbuild DESTINATION bin) > + list(APPEND _tools cmakexbuild) > endif() > > +foreach(_tool ${_tools}) > + install(TARGETS ${_tool} DESTINATION bin COMPONENT ${_tool}) > +endforeach() The cmakexbuild tool is an implementation detail of cmake/ctest/cpack that must be installed along with them. Whatever enforces that those three components are required should cover cmakexbuild too. Thanks, -Brad From brad.king at kitware.com Mon Jul 6 14:18:21 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 06 Jul 2015 14:18:21 -0400 Subject: [cmake-developers] Feature Request: Modify CXX_STANDARD behavior for Xcode Generator: Starting Tips? In-Reply-To: References: Message-ID: <559AC66D.60009@kitware.com> On 07/02/2015 10:22 PM, Jason Felds wrote: > it places the -std=gnu++11 (or equivalent) calls in the OTHER_CPLUSPLUSFLAGS > attribute instead of the CLANG_CXX_LANGUAGE_STANDARD attribute. Yes. This is just because the generator hasn't been taught to do so. If this is added it also needs to be made dependent on the version of Xcode because older versions may not support the explicit attribute. > * The flags are coming from either one of cflags[*li] or defFlags. defFlags > is filled in via GetDefineFlags() within Source/cmMakefile.h, whereas > cflags is filled in with the contents of gflags. > * Doing a grep for `gnu++11` gives me either .rst files or .cmake files, > but no .h or .cxx files. [snip] > * Is there a proper source location where the standard is defined? > * Which variable does it get set to: cflags or defFlags? The actual content of the flag comes from a platform information variable populated by Modules/Compiler/*.cmake files for the current toolchain. The generators use various internal APIs to lookup the flags along with others. I don't recall whether it goes through cflags or defFlags for the Xcode generator in this case, but it doesn't matter which one because the way to fix this is the same. See below. > * Is there a clean way to remove the std flag and place it in a more > Apple friendly location, or would I have to do so? The Visual Studio generators parse the final set of flags and maps them to IDE project file property/attribute settings. The Xcode generator does this only for a tiny subset of attributes simply because no one has taken the time to implement full mapping infrastructure yet. Therefore many attributes beyond just the standard level are not properly expressed in Xcode's dialogs. The code here: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmGlobalXCodeGenerator.cxx;hb=v3.3.0-rc3#l2211 does the minimal flag mapping for optimization levels right now. This is the place to add other mappings. Ideally it would be done with a full parser and lookup tables like the VS generators do. -Brad From brad.king at kitware.com Mon Jul 6 14:22:05 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 06 Jul 2015 14:22:05 -0400 Subject: [cmake-developers] Xcode generator does not recognize -Ofast In-Reply-To: References: Message-ID: <559AC74D.9060006@kitware.com> On 07/03/2015 10:48 PM, umireon at gmail.com wrote: > However, the Xcode Generator does not handle the -Ofast flag properly, > and then it is necessary to the set Optimization Level manually > when -Ofast flag is utilized in the project. > > This is because the Xcode Generator uses just one letter right after the `-O` > to determine what the project setting should be. > When `-O3` is given, `3` is used for Optimization Level and everything is fine, > but when `-Ofast` is given, `f` is used for it, which is an invalid value. > > It is not tested but it can be resolved by accepting all letter after `-O` flags. > > Here is the relevant code handling Optimization Level: > https://github.com/Kitware/CMake/blob/3ae8e84ef5c94e5fa250b4e2466aa6632a233bb2/Source/cmGlobalXCodeGenerator.cxx#L2218 This is basically the same problem discussed here: Feature Request: Modify CXX_STANDARD behavior for Xcode Generator: Starting Tips http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13557/focus=13572 The Xcode generator needs more complete flag->attribute mapping. Since we already have special handling for optimization flags one could extend it to cover the -Ofast case explicitly without introducing the full solution. -Brad From brad.king at kitware.com Mon Jul 6 14:36:11 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 06 Jul 2015 14:36:11 -0400 Subject: [cmake-developers] CTest: hide progress ticks in verbose output In-Reply-To: References: Message-ID: <559ACA9B.8080603@kitware.com> On 07/03/2015 05:02 PM, Daniel Pfeifer wrote: > The attached patch hides the progress ticks when the output is shown (-VV). Good idea. Applied: CTest: hide progress ticks in verbose output http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=140b1864 Thanks, -Brad From brad.king at kitware.com Mon Jul 6 14:41:04 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 06 Jul 2015 14:41:04 -0400 Subject: [cmake-developers] PATCH: add subcommand string(APPEND) In-Reply-To: References: Message-ID: <559ACBC0.9080600@kitware.com> On 07/04/2015 06:27 PM, Daniel Pfeifer wrote: > Attached is a patch that adds a subcommand string(APPEND). > This allows to write > >> string(APPEND string_variable "some string") > > instead of > >> set(string_variable "${string_variable}some string") Thanks. Please extend the first patch to also add explicit coverage of the feature in the test suite, perhaps in Tests/RunCMake/string similar to the Concat test case. I'd prefer to get the implementation, documentation, and tests of the new command integrated and working before considering use of the command everywhere else. > Two other patches make use of this subcommand. The changes have been > created with > >> find Modules -type f -print0 | xargs -0 perl -i -0pe \ >> 's/set\(([a-zA-Z0-9_]+)(\s+)"\$\{\1\}([^"])/string(APPEND \1\2"\3/g' Nice. I'm also glad to see those instructions in the commit message. This will make it easy to create these changes later after the feature itself is worked out as above. Thanks, -Brad From brad.king at kitware.com Mon Jul 6 14:53:35 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 06 Jul 2015 14:53:35 -0400 Subject: [cmake-developers] [PATCH] ExternalProject: Added new USES_TERMINAL options In-Reply-To: <00f401d0b7af$f661f8c0$e325ea40$@codenest.com> References: <00f401d0b7af$f661f8c0$e325ea40$@codenest.com> Message-ID: <559ACEAF.3030809@kitware.com> On 07/06/2015 01:52 AM, James Johnston wrote: > I worked on a patch to allow you to pass USES_TERMINAL through > ExternalProject to the underlying add_custom_command(). Very nice. I applied the commit: ExternalProject: Added new USES_TERMINAL options http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e4947639 I tweaked UsesTerminal-check.cmake with a better way to avoid the CMP0012 warning (by just ensuring the policy is set to NEW). Thanks, -Brad From brad.king at kitware.com Mon Jul 6 15:03:01 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 06 Jul 2015 15:03:01 -0400 Subject: [cmake-developers] [PATCH] cmArchiveWrite: don't store sparse files when using standard tar formats In-Reply-To: <1436194459-8713-1-git-send-email-roman.donchenko@itseez.com> References: <1436194459-8713-1-git-send-email-roman.donchenko@itseez.com> Message-ID: <559AD0E5.60703@kitware.com> On 07/06/2015 10:54 AM, Roman Donchenko wrote: > Sparse files in tars are a GNU extension that libarchive will use if it > detects holes in the input file, even when using the standard pax/paxr > formats. Not all tar implementations can handle sparse files; in particular, > the internal implementation dpkg uses to extract packages can't. To > maximize archive portability, turn this feature off by clearing the > sparseness information from archive entries. Thanks, applied: cmArchiveWrite: do not store sparse files when using standard tar formats http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=edae4023 -Brad From brad.king at kitware.com Mon Jul 6 15:24:17 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 06 Jul 2015 15:24:17 -0400 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: References: <5589BA2F.1010101@gmail.com> <558AC26E.4040702@kitware.com> <558B2163.7080602@gmail.com> Message-ID: <559AD5E1.8040302@kitware.com> On 07/02/2015 04:45 PM, Michael Scott wrote: > On 06/30/2015 05:42 PM, Stephen Kelly wrote: >> What is the difference between the intended uses of those existing options >> and the intended uses of the new options, given that -Wno-dev is mostly >> useful for third parties to silence policy warnings? > > Working on this issue, I did find the different variables/options a bit > confusing. dev and deprecated both change the effect of message modes, > pretty much doing the same thing but slightly different For reference, the -Wdev/-Wno-dev options were added originally to control the cmake::AUTHOR_WARNING message type introduced for cmake policy warnings. Later message(AUTHOR_WARNING) was added to expose it to the CMake language. Then message(DEPRECATION) was added as completely separate functionality without considering its overlap with AUTHOR_WARNING. This thread is a good chance to resolve or distinguish the overlapping warning types more clearly, perhaps with documentation updates. The AUTHOR_WARNING and DEPRECATION_WARNING are not necessarily the same. The former is a superset of the latter. CMake language code may want to warn about doing something wrong that is not deprecated behavior. Both types are of interest to project authors but not necessarily users. > (for example there is -Wdev and -Wno-dev, but not -Werror=dev or -Wno-error=dev). The need for the latter recently came up here: A policy for Policies http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13376/focus=13476 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13376/focus=13512 In that discussion we decided to start making some policy OLD behavior produce deprecation warnings, and also that we need a way to help users find them (e.g. by optionally making them errors). > Would it be worth refactoring the -W dev options to be in line with the -W > deprecated options? > >> If the new options are merged to master should -Wdev and -Wno-dev also be >> changed to affect CMAKE_WARN_DEPRECATED? > > That would be sensible behaviour to me, shall I modify cmake::Configure to > do this? Since AUTHOR_WARNING is a superset of DEPRECATION_WARNING I think -W[no-]dev can influence CMAKE_WARN_DEPRECATED. Please also add -W[no-]error=dev to turn AUTHOR_WARNING into an error and also make it influence CMAKE_ERROR_DEPRECATED. Then -Wdeprecated and friends can still be used to control the DEPRECATION messages separately. Thanks, -Brad From daniel at pfeifer-mail.de Mon Jul 6 16:47:25 2015 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Mon, 6 Jul 2015 22:47:25 +0200 Subject: [cmake-developers] PATCH: add subcommand string(APPEND) In-Reply-To: <559ACBC0.9080600@kitware.com> References: <559ACBC0.9080600@kitware.com> Message-ID: On Mon, Jul 6, 2015 at 8:41 PM, Brad King wrote: > On 07/04/2015 06:27 PM, Daniel Pfeifer wrote: >> Attached is a patch that adds a subcommand string(APPEND). >> This allows to write >> >>> string(APPEND string_variable "some string") >> >> instead of >> >>> set(string_variable "${string_variable}some string") > > Thanks. Please extend the first patch to also add explicit coverage > of the feature in the test suite, perhaps in Tests/RunCMake/string > similar to the Concat test case. I'd prefer to get the implementation, > documentation, and tests of the new command integrated and working > before considering use of the command everywhere else. OK, now with tests and release notes. There is a debatable edge case: When a variable is not-set and zero elements are appended, do we expect the result to be a) not-set or b) an empty string? My current implementation considers appending zero elements a no-op, i.e. it follows approach a). cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-add-subcommand-string-APPEND.patch Type: text/x-patch Size: 7055 bytes Desc: not available URL: From jamesbigler at gmail.com Mon Jul 6 16:55:08 2015 From: jamesbigler at gmail.com (James Bigler) Date: Mon, 6 Jul 2015 14:55:08 -0600 Subject: [cmake-developers] PATCH: add subcommand string(APPEND) In-Reply-To: References: <559ACBC0.9080600@kitware.com> Message-ID: list(APPEND) requires at least one element argument, right? Can you require the same thing for string(APPEND)? That would make it symmetric and remove your edge case. On Mon, Jul 6, 2015 at 2:47 PM, Daniel Pfeifer wrote: > On Mon, Jul 6, 2015 at 8:41 PM, Brad King wrote: > > On 07/04/2015 06:27 PM, Daniel Pfeifer wrote: > >> Attached is a patch that adds a subcommand string(APPEND). > >> This allows to write > >> > >>> string(APPEND string_variable "some string") > >> > >> instead of > >> > >>> set(string_variable "${string_variable}some string") > > > > Thanks. Please extend the first patch to also add explicit coverage > > of the feature in the test suite, perhaps in Tests/RunCMake/string > > similar to the Concat test case. I'd prefer to get the implementation, > > documentation, and tests of the new command integrated and working > > before considering use of the command everywhere else. > > OK, now with tests and release notes. > > There is a debatable edge case: > When a variable is not-set and zero elements are appended, do we > expect the result to be a) not-set or b) an empty string? > My current implementation considers appending zero elements a no-op, > i.e. it follows approach a). > > cheers, Daniel > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/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-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at pfeifer-mail.de Mon Jul 6 17:32:01 2015 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Mon, 6 Jul 2015 23:32:01 +0200 Subject: [cmake-developers] PATCH: add subcommand string(APPEND) In-Reply-To: References: <559ACBC0.9080600@kitware.com> Message-ID: On Mon, Jul 6, 2015 at 10:55 PM, James Bigler wrote: > list(APPEND) requires at least one element argument, right? No, see https://github.com/Kitware/CMake/blob/master/Source/cmListCommand.cxx#L236 From konstantin at podsvirov.pro Tue Jul 7 02:43:55 2015 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Tue, 07 Jul 2015 09:43:55 +0300 Subject: [cmake-developers] [PATCH] Option CMAKE_INSTALL_COMPONENTS and IFW installer In-Reply-To: <559AC257.4000309@kitware.com> References: <1392021435928992@web3g.yandex.ru> <559AC257.4000309@kitware.com> Message-ID: <1270211436251435@web9h.yandex.ru> 06.07.2015, 21:01, "Brad King" : > On 07/03/2015 09:09 AM, Konstantin Podsvirov wrote: >> About 6 months ago I started a topic cmake-install-components. >> Today I am ready to share the results. > > Great, thanks! The changes look good except for comments below. > >> So as not to disturb those who do not need it I have added the >> option CMAKE_INSTALL_COMPONENTS, which by default is set to OFF. > > Please rename this to "CMake_INSTALL_COMPONENTS". We've started > a convention of using "CMake_" options for affecting the build > of CMake itself and "CMAKE_" for general CMake-defined options > that could be used by any project. Done! It's just. When I was choosing a name for the option in SPHINX documentation I have not found of such recommendations. In QtDialog variable CMake_GUI_DISTRIBUTE_WITH_Qt_LGPl to install the license. I have considered this option in the installer, but it is not declared as optional in the framework of the CMake project. > In this hunk: > >> -install(TARGETS cmake cpack ctest DESTINATION bin) >> +# Install tools >> + >> +set(_tools cmake cpack ctest) >> + >> if(APPLE) >> - install(TARGETS cmakexbuild DESTINATION bin) >> + list(APPEND _tools cmakexbuild) >> endif() >> >> +foreach(_tool in ${_tools}) >> + install(TARGETS ${_tool} DESTINATION bin COMPONENT ${_tool}) >> +endforeach() > > The cmakexbuild tool is an implementation detail of cmake/ctest/cpack > that must be installed along with them. Whatever that enforces those > three components are required should cover cmakexbuild too. Done! I added cmakexbuild component in the group of Tools like cmake, ctest, and cpack. This should work for APPLE, but I have no way to check it out. Maybe someone can collect IFW installer on the APPLE platform? > Thanks, > -Brad The project has many minor installation instructions. They are all now accounted for and installed as Unspecified component that hide from the user's eyes. It is not excluded that eventually they will find the name of the component and the location of the installation tree. I used rebase. The last 8 commits in a branch on my server contain change of topic: http://git.podsvirov.pro/?p=kitware/cmake.git;a=shortlog;h=refs/heads/cmake-install-components I hope now will be able to apply the changes. -- Regards, Konstantin Podsvirov From brad.king at kitware.com Tue Jul 7 09:21:46 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 07 Jul 2015 09:21:46 -0400 Subject: [cmake-developers] [PATCH] Option CMAKE_INSTALL_COMPONENTS and IFW installer In-Reply-To: <1270211436251435@web9h.yandex.ru> References: <1392021435928992@web3g.yandex.ru> <559AC257.4000309@kitware.com> <1270211436251435@web9h.yandex.ru> Message-ID: <559BD26A.7040804@kitware.com> On 07/07/2015 02:43 AM, Konstantin Podsvirov wrote: > I used rebase. The last 8 commits in a branch on my server contain change of topic: > > I hope now will be able to apply the changes. Thanks! I've applied the changes with minor tweaks to the history: CMake: Install COMPONENTs http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=938bbc43 CMake: Install COMPONENTs (QtDialog) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2531b909 CMake: Install COMPONENTs (sphinx-man) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7383e4d7 CMake: New option CMake_INSTALL_COMPONENTS http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c823f04e CMake: Fix Web Site shortcut in IFW installer for Windows http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c14f20f7 CMake: optional show LGPLv2.1 license when install cmake-gui component http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ecca2685 CMake: Add cmakexbuild component as REQUIRED to Tools group for IFW installer http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d7725a17 Thanks, -Brad From brad.king at kitware.com Tue Jul 7 09:35:26 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 07 Jul 2015 09:35:26 -0400 Subject: [cmake-developers] PATCH: add subcommand string(APPEND) In-Reply-To: References: <559ACBC0.9080600@kitware.com> Message-ID: <559BD59E.9020107@kitware.com> On 07/06/2015 04:47 PM, Daniel Pfeifer wrote: > OK, now with tests and release notes. Applied, thanks: string: add APPEND subcommand http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2b18cdca > There is a debatable edge case: > When a variable is not-set and zero elements are appended, do we > expect the result to be a) not-set or b) an empty string? > My current implementation considers appending zero elements a no-op, > i.e. it follows approach a). The list(APPEND) command is a no-op when nothing is given, so this would be consistent with that. -Brad From konstantin at podsvirov.pro Tue Jul 7 09:39:59 2015 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Tue, 07 Jul 2015 16:39:59 +0300 Subject: [cmake-developers] [PATCH] Option CMAKE_INSTALL_COMPONENTS and IFW installer In-Reply-To: <559BD26A.7040804@kitware.com> References: <1392021435928992@web3g.yandex.ru> <559AC257.4000309@kitware.com> <1270211436251435@web9h.yandex.ru> <559BD26A.7040804@kitware.com> Message-ID: <769161436276399@web7m.yandex.ru> Hi, Brad! 07.07.2015, 16:21, "Brad King" : > On 07/07/2015 02:43 AM, Konstantin Podsvirov wrote: >> I used rebase. The last 8 commits in a branch on my server contain change of topic: >> >> I hope now will be able to apply the changes. > > Thanks! I've applied the changes with minor tweaks to the history... Glad to hear :-) I Apologize for the macro CMAKE_OPTIONAL_COMPONENT... With these changes IFW installer will become even more beautiful! Once the code gets merged into the master, I will present an online update for wanting to look, but not wanting to build. By the way, nothing wrong that I build and put on public display code branch master using IFW installer? I don't see malicious intent. If someone doesn't like it, please let me know. -- Regards, Konstantin Podsvirov From brad.king at kitware.com Tue Jul 7 09:43:20 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 07 Jul 2015 09:43:20 -0400 Subject: [cmake-developers] [PATCH] Option CMAKE_INSTALL_COMPONENTS and IFW installer In-Reply-To: <769161436276399@web7m.yandex.ru> References: <1392021435928992@web3g.yandex.ru> <559AC257.4000309@kitware.com> <1270211436251435@web9h.yandex.ru> <559BD26A.7040804@kitware.com> <769161436276399@web7m.yandex.ru> Message-ID: <559BD778.5030706@kitware.com> On 07/07/2015 09:39 AM, Konstantin Podsvirov wrote: > By the way, nothing wrong that I build and put on public display > code branch master using IFW installer? That's fine with us! Thanks, -Brad From brad.king at kitware.com Tue Jul 7 09:57:57 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 07 Jul 2015 09:57:57 -0400 Subject: [cmake-developers] Adding Swift support to CMake In-Reply-To: References: <55842C6C.4050504@kitware.com> <559191D6.5080403@kitware.com> Message-ID: <559BDAE5.9010505@kitware.com> On 07/02/2015 07:54 PM, Eric Wing wrote: > Thank you Brad. When you are ready, let me know how I can help next. I have basic support with the Xcode generator done. Please try out this commit: Add rudimentary support for the Apple Swift language with Xcode http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bf112531 Thanks, -Brad From mantis at public.kitware.com Tue Jul 7 11:04:29 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 7 Jul 2015 11:04:29 -0400 Subject: [cmake-developers] [CMake 0015640]: CMake converts generator from Visual Studio 9 2008 to Visual Studio 10 2010 if ZERO_CHECK fails Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15640 ====================================================================== Reported By: James Johnston Assigned To: ====================================================================== Project: CMake Issue ID: 15640 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-07 11:04 EDT Last Modified: 2015-07-07 11:04 EDT ====================================================================== Summary: CMake converts generator from Visual Studio 9 2008 to Visual Studio 10 2010 if ZERO_CHECK fails Description: When using CMake with the Visual Studio 9 2008 generator, if the ZERO_CHECK "project" fails (e.g. due to a FATAL_ERROR or whatever in the CMakeLists.txt file), the entire CMake project is converted to Visual Studio 10 2010! Since the build tree is now in who-knows-what corrupted state, I have no choice but to delete the whole build tree and start over. It's quite time-consuming. The issue doesn't seem to be easily reproduced outside of the ZERO_CHECK project - e.g. I couldn't figure out how to reproduce it with cmake-gui.exe or cmake.exe. Steps to Reproduce: 1. Make a new source tree with the following CMakeLists.txt file: cmake_minimum_required(VERSION 3.3.0 FATAL_ERROR) project(TestProject) #message(FATAL_ERROR "Error") 2. Create empty build tree directory as normal, cd to it, and run: cmake "-GVisual Studio 9 2008" 3. Open the generated Visual Studio solution in Visual C++ 2008. (I used Express version). 4. Edit the CMakeLists.txt and remove the comment on "message" so that the CMake configure will fail now. 5. Build the ZERO_CHECK project; note that it fails as expected. 6. Remark out the "message" from CMakeLists.txt so that CMake once again will configure ok. 7. Build the ZERO_CHECK project again. This time, ZERO_CHECK will convert everything over to Visual Studio 2010: * The CMake output shown in Visual Studio "Output" pane says "Building for Visual Studio 10 2010". * The CMakeCache.txt holds: CMAKE_GENERATOR:INTERNAL=Visual Studio 10 2010 * Visual Studio 2008 refuses to reload the solution ("created by a newer version of this application and cannot be opened") * Examination of the build tree shows a VS2010 solution and VCPROJ/VCXPROJ files side-by-side... Additional Information: The problem has been successfully reproduced with both CMake 3.3.0-rc1 and the nightly cmake-3.3.20150706-g32b76-win32-x86 build. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-07 11:04 James Johnston New Issue ====================================================================== From gjasny at googlemail.com Tue Jul 7 13:10:49 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Tue, 7 Jul 2015 10:10:49 -0700 Subject: [cmake-developers] How is the Visual Studio compiler looked up Message-ID: <559C0819.6090801@googlemail.com> Hello, one of my colleagues is unable to generate a VS2013 solution. He gets the following error: F:\CitrixLibs\ExternalLibs\CMake\3.1.3\Tools_Windows\bin\cmake.exe -G Visual Studio 12 -T v120_xp -A Win32 -DWITH_COPY_PREBUILT_CACHE=ON -DWITH_COPY_PREBUILT=ON -DCMAKE_INSTALL_PREFIX:PATH=C:\Git\med ia-processing-library\_deploy C:\Git\media-processing-library -- The C compiler identification is unknown -- The CXX compiler identification is unknown CMake Error at CMakeLists.txt:7 (project): No CMAKE_C_COMPILER could be found. CMake Error at CMakeLists.txt:7 (project): No CMAKE_CXX_COMPILER could be found. -- Configuring incomplete, errors occurred! See also "C:/Git/media-processing-library/_build_v120_x86/CMakeFiles/CMakeOutput.log". See also "C:/Git/media-processing-library/_build_v120_x86/CMakeFiles/CMakeError.log". Could you please point me to the code which looks up Visual Studio or the CL.exe compiler? How would you debug this problem? Thanks, Gregor -------------- next part -------------- The system is: Windows - 6.1 - AMD64 -------------- next part -------------- Compiling the C compiler identification source file "CMakeCCompilerId.c" failed. Compiler: Build flags: Id flags: The output was: The system cannot find the file specified Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" failed. Compiler: Build flags: Id flags: The output was: The system cannot find the file specified From gjasny at googlemail.com Tue Jul 7 13:12:26 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Tue, 7 Jul 2015 10:12:26 -0700 Subject: [cmake-developers] How is the Visual Studio compiler looked up In-Reply-To: <559C0819.6090801@googlemail.com> References: <559C0819.6090801@googlemail.com> Message-ID: <559C087A.9060202@googlemail.com> On 07/07/15 10:10, Gregor Jasny wrote: > one of my colleagues is unable to generate a VS2013 solution. He gets > the following error: Please disregard. This was a vc12 vs. VS2012 confusion. Sorry for the noise. From darkapostle at rule506.net Wed Jul 8 03:08:52 2015 From: darkapostle at rule506.net (darkapostle at rule506.net) Date: Wed, 08 Jul 2015 03:08:52 -0400 Subject: [cmake-developers] AppleClang-CXX.cmake needs an update Message-ID: <1436339332.2038481.318057305.36E95813@webmail.messagingengine.com> C++14 is a first class citizen in Xcode 6. *diff --git a/Modules/Compiler/AppleClang-CXX.cmake b/Modules/Compiler/AppleClang- CXX.cmake* *index 5194da4..27e4d8a 100644* *--- a/Modules/Compiler/AppleClang-CXX.cmake* *+++ b/Modules/Compiler/AppleClang-CXX.cmake* @@ -13,7 +13,10 @@ if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.0) set(CMAKE_CXX11_EXTENSION_COMPILE_OPTION "-std=gnu++11") endif() -if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 5.1) +if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 6.0) +? set(CMAKE_CXX14_STANDARD_COMPILE_OPTION "-std=c++14") +? set(CMAKE_CXX14_EXTENSION_COMPILE_OPTION "-std=gnu++14") +elseif(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 5.1) # AppleClang 5.0 knows this flag, but does not set a __cplusplus macro greater than 201103L set(CMAKE_CXX14_STANDARD_COMPILE_OPTION "-std=c++1y") set(CMAKE_CXX14_EXTENSION_COMPILE_OPTION "-std=gnu++1y") -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: AppleClang-CXX.cmake.diff Type: application/octet-stream Size: 843 bytes Desc: not available URL: From mantis at public.kitware.com Wed Jul 8 09:27:24 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 8 Jul 2015 09:27:24 -0400 Subject: [cmake-developers] [CMake 0015641]: In CMake 3.3.0-rc3 macro CHECK_CXX_COMPILER_FLAG is broken on OSX for some flags Message-ID: <4957faedbf5180c055b213f517431f32@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15641 ====================================================================== Reported By: Nikolay Zapolnov Assigned To: ====================================================================== Project: CMake Issue ID: 15641 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-08 09:27 EDT Last Modified: 2015-07-08 09:27 EDT ====================================================================== Summary: In CMake 3.3.0-rc3 macro CHECK_CXX_COMPILER_FLAG is broken on OSX for some flags Description: In CMake 3.2.3 the CHECK_CXX_COMPILER_FLAG macro launches compiler and then linker. But tested flag is passed *only* to the compiler and test passes. But in CMake 3.3.0-rc3 argument is passed to *both* the compiler and the linker. This causes an error for some flags, for example for '-x objective-c++'. Passing this flag to the linker makes it recognize .o files as objective-c++ sources and fail. Steps to Reproduce: Use the following CMakeLists.txt INCLUDE(CheckCXXCompilerFlag) CHECK_CXX_COMPILER_FLAG("-x objective-c++" HAVE_OBJC) This will work correctly in CMake 3.2.3 but in CMake 3.3.0-rc3 HAVE_OBJC will be always false. Additional Information: Part of CMakeOutput.log for good case and part of CMakeError.log for broken case are attached to the ticket. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-08 09:27 Nikolay ZapolnovNew Issue 2015-07-08 09:27 Nikolay ZapolnovFile Added: good-cmake322.log ====================================================================== From brad.king at kitware.com Wed Jul 8 09:46:57 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 08 Jul 2015 09:46:57 -0400 Subject: [cmake-developers] AppleClang-CXX.cmake needs an update In-Reply-To: <1436339332.2038481.318057305.36E95813@webmail.messagingengine.com> References: <1436339332.2038481.318057305.36E95813@webmail.messagingengine.com> Message-ID: <559D29D1.4030407@kitware.com> On 07/08/2015 03:08 AM, darkapostle at rule506.net wrote: > C++14 is a first class citizen in Xcode 6. Applied, thanks: AppleClang: Use modern C++14 standard flags for Xcode 6 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d0430c0a -Brad From brad.king at kitware.com Wed Jul 8 10:03:18 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 08 Jul 2015 10:03:18 -0400 Subject: [cmake-developers] [PATCH] fix use of CMAKE_REQUIRED_DEFINITIONS In-Reply-To: <54EC8EF0.5080106@kitware.com> References: <54EC8EF0.5080106@kitware.com> Message-ID: <559D2DA6.1070300@kitware.com> On 02/24/2015 09:47 AM, Brad King wrote: > On 02/24/2015 08:25 AM, Mark Abraham wrote: >> Some modules shoud use CMAKE_REQUIRED_FLAGS, not CMAKE_REQUIRED_DEFINITIONS, I think. > > Actually both technically support any flags, but the latter > only for legacy reasons. I agree CMAKE_REQUIRED_FLAGS is > clearer for this purpose. I've applied the patch with > minor tweaks: > > Check*CompilerFlag: Refactor method used to pass flags > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5d5067ae We need to revert this change from 3.3 because it caused a regression: In CMake 3.3.0-rc3 macro CHECK_CXX_COMPILER_FLAG is broken on OSX for some flags https://public.kitware.com/Bug/view.php?id=15641 See issue tracker entry for further updates. -Brad From mantis at public.kitware.com Wed Jul 8 10:13:17 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 8 Jul 2015 10:13:17 -0400 Subject: [cmake-developers] [CMake 0015642]: empty if case of drive letter changes Message-ID: <3c1685a0c464a3ee8b9f5b480dc8db2b@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15642 ====================================================================== Reported By: Martin Sander Assigned To: ====================================================================== Project: CMake Issue ID: 15642 Category: (No Category) Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-08 10:13 EDT Last Modified: 2015-07-08 10:13 EDT ====================================================================== Summary: empty if case of drive letter changes Description: If cmake is used within cmd.exe and a dependency in add_custom_command(...) has an upper case drive letter and this files occurs otherwise with a lower case drive letter, all tags refererring to the containing directory are empty. The difference is produced with Archive.zip:cmakeBugHunting/build/ttt.bat and visible in Archive.zip:diff.png ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-08 10:13 Martin Sander New Issue 2015-07-08 10:13 Martin Sander File Added: Archive.zip ====================================================================== From ben.boeckel at kitware.com Wed Jul 8 10:34:10 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 8 Jul 2015 10:34:10 -0400 Subject: [cmake-developers] A policy for Policies In-Reply-To: References: <5575F56A.50404@kitware.com> <5575FA50.5080208@kitware.com> <5576008C.3040505@kitware.com> <557636B1.9020500@gmail.com> <5576ED34.7090208@kitware.com> Message-ID: <20150708143410.GA5824@megas.kitware.com> On Tue, Jun 09, 2015 at 11:24:03 -0400, David Cole via cmake-developers wrote: > Is there a single example of a policy wherein the OLD behavior has > actually been removed? Technically, yes. CMP0053 as NEW ignores CMP0010's setting and treats it as NEW (because the new parser doesn't implement the OLD behavior at all). But CMP0010 is one of those "almost assuredly a bug" policies and really easy to fix (just escape the '$' or add the closing '}'). --Ben From jeanmichael.celerier at gmail.com Wed Jul 8 11:01:08 2015 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Wed, 8 Jul 2015 17:01:08 +0200 Subject: [cmake-developers] [PATCH] Macro generation for relaxed constexpr Message-ID: Hello, At the ned of this mail is a patch that adds generation of a macro for the relaxed ("c++14") constexpr in WriteCompilerDetectionHeader. This is intended for compilers that support c++11 constexpr (with everything on a single return statement) like GCC-4.9 and the upcoming MSVC, but not extended constexpr which allows for more complete functions. This way, code bases can reap the benefits of most recent compilers at no cost. Best regards Jean-Micha?l Celerier diff --git a/Modules/WriteCompilerDetectionHeader.cmake b/Modules/WriteCompilerDetectionHeader.cmake index a3b73bb..f7af7ec 100644 --- a/Modules/WriteCompilerDetectionHeader.cmake +++ b/Modules/WriteCompilerDetectionHeader.cmake @@ -144,6 +144,7 @@ # ========================== =================================== ================= # ``c_restrict`` ``_RESTRICT`` ``restrict`` # ``cxx_constexpr`` ``_CONSTEXPR`` ``constexpr`` +# ``cxx_relaxed_constexpr`` ``_RELAXED_CONSTEXPR`` ``constexpr`` # ``cxx_deleted_functions`` ``_DELETED_FUNCTION`` ``= delete`` # ``cxx_extern_templates`` ``_EXTERN_TEMPLATE`` ``extern`` # ``cxx_final`` ``_FINAL`` ``final`` @@ -494,6 +495,16 @@ function(write_compiler_detection_header # endif \n") endif() + if (feature STREQUAL cxx_relaxed_constexpr) + set(def_value "${prefix_arg}_RELAXED_CONSTEXPR") + set(file_content "${file_content} +# if ${def_name} +# define ${def_value} constexpr +# else +# define ${def_value} +# endif +\n") + endif() if (feature STREQUAL cxx_final) set(def_value "${prefix_arg}_FINAL") set(file_content "${file_content} From mfilimonov at nvidia.com Wed Jul 8 11:21:58 2015 From: mfilimonov at nvidia.com (Mikhail Filimonov) Date: Wed, 8 Jul 2015 15:21:58 +0000 Subject: [cmake-developers] [PATCH] Extended Nsight Tegra support for CMake Message-ID: Hi, all! I've extended the Nsight Tegra project generator in CMake and added a bunch of properties with the backing variables to fine-tune the generated projects. The patch adds the following new Target properties: A new Target properties that maps to all "Configuration" PropertyGroups for each configuration defined for Target: ANDROID_ARCH ANDROID_STL_TYPE ? A new Target properties that maps to AntBuild section in generated Visual Studio project file: ANDROID_ANT_ADDITIONAL_OPTIONS 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 Comments and suggestions is welcome, thanks in advance. -Mikhail ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: ExtendedNsightTegraSupport.patch Type: application/octet-stream Size: 34048 bytes Desc: ExtendedNsightTegraSupport.patch URL: From markus.grech at gmail.com Wed Jul 8 12:50:23 2015 From: markus.grech at gmail.com (Markus Grech) Date: Wed, 8 Jul 2015 18:50:23 +0200 Subject: [cmake-developers] Patch to fix incorrect paths in Eclipse CDT generator under Cygwin Message-ID: I've attached a patch to fix a bug in the Eclipse CDT generator under Cygwin. The generator would generate invalid links for source files under "[Targets]", making Eclipse unable to open them. The old links look like "C:/cygdrive/c/...", while new links correctly are "C:/...". Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fixed-generation-of-incorrect-paths-for-target-links.patch Type: application/octet-stream Size: 1145 bytes Desc: not available URL: From tamas.kenez at gmail.com Wed Jul 8 13:53:31 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Wed, 8 Jul 2015 19:53:31 +0200 Subject: [cmake-developers] OBJECT library on left-hand-side of target_link_libraries Message-ID: The documentation states that OBJECT libraries "may not be [...] used in the right hand side of target_link_libraries()". However it turns out that they can't be used on the left hand side either: add_library(objlib OBJECT ...) target_link_libraries(objlib dep-of-objlib) Result: CMake Error at CMakeLists.txt:13 (target_link_libraries): Object library target "objlib" may not link to anything. This makes it impossible to concisely specify if an OBJECT library has a dependency which is an IMPORTED library. Only the legacy way works: add_library(objlib OBJECT ...) target_include_directories(objlib ${ZLIB_INCLUDE_DIRS}) ... add_executable(maintarget $) target_link_libraries(maintarget ${ZLIB_LIBRARIES}) But it would be convenient if this would also work: add_library(objlib OBJECT ...) target_link_libraries(objlib ZLIB::ZLIB) Question: Is this restriction, that an OBJECT library can't be on the left hand side of target_link_libraries, is it a hard, final decision? Or is this issue open for a possible improvement which would allow this and would forward the link dependencies to the main target the OBJECT library is incorporated into? Tamas -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Wed Jul 8 14:11:44 2015 From: DLRdave at aol.com (David Cole) Date: Wed, 8 Jul 2015 14:11:44 -0400 Subject: [cmake-developers] A policy for Policies In-Reply-To: <20150708143410.GA5824@megas.kitware.com> References: <5575F56A.50404@kitware.com> <5575FA50.5080208@kitware.com> <5576008C.3040505@kitware.com> <557636B1.9020500@gmail.com> <5576ED34.7090208@kitware.com> <20150708143410.GA5824@megas.kitware.com> Message-ID: Interesting. So, sort of, but not really. At least not explicitly. I'm still interested in seeing an example commit (even if it's only theoretical and will never actually be merged in) whose explicit purpose is removing the OLD behavior of a single policy. (Is there such a commit which removed the OLD behavior of CMP0010, or is it too entwined in the parser improvement commits from the 3.1 release cycle as to be easily identifiable as a concise diff?) Weird are the things interesting to geeks, right? Thx, David C. On Wed, Jul 8, 2015 at 10:34 AM, Ben Boeckel wrote: > On Tue, Jun 09, 2015 at 11:24:03 -0400, David Cole via cmake-developers wrote: >> Is there a single example of a policy wherein the OLD behavior has >> actually been removed? > > Technically, yes. CMP0053 as NEW ignores CMP0010's setting and treats it > as NEW (because the new parser doesn't implement the OLD behavior at > all). But CMP0010 is one of those "almost assuredly a bug" policies and > really easy to fix (just escape the '$' or add the closing '}'). > > --Ben From ben.boeckel at kitware.com Wed Jul 8 14:14:23 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 8 Jul 2015 14:14:23 -0400 Subject: [cmake-developers] OBJECT library on left-hand-side of target_link_libraries In-Reply-To: References: Message-ID: <20150708181423.GA15850@megas.kitware.com> On Wed, Jul 08, 2015 at 19:53:31 +0200, Tam?s Ken?z wrote: > Is this restriction, that an OBJECT library can't be on the left hand side > of > target_link_libraries, is it a hard, final decision? Or is this issue > open for a possible improvement which would allow this and would forward > the link dependencies to the main target the OBJECT library is incorporated > into? I started a branch to do this, but it is a deep rabbit hole. See this thread: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12509 Development to fix this would be accepted; I'll try and write up the requirements/features Brad and I figured out later today. --Ben From brad.king at kitware.com Wed Jul 8 14:31:57 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 08 Jul 2015 14:31:57 -0400 Subject: [cmake-developers] Patch to fix incorrect paths in Eclipse CDT generator under Cygwin In-Reply-To: References: Message-ID: <559D6C9D.7070508@kitware.com> On 07/08/2015 12:50 PM, Markus Grech wrote: > I've attached a patch to fix a bug in the Eclipse CDT generator under Cygwin. Applied, thanks: Eclipse: Fix paths in target links on cygwin http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a672b16a -Brad From steveire at gmail.com Wed Jul 8 14:35:39 2015 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 08 Jul 2015 20:35:39 +0200 Subject: [cmake-developers] Adding Swift support to CMake References: <55842C6C.4050504@kitware.com> <559191D6.5080403@kitware.com> <559BDAE5.9010505@kitware.com> Message-ID: Brad King wrote: > On 07/02/2015 07:54 PM, Eric Wing wrote: >> Thank you Brad. When you are ready, let me know how I can help next. > > I have basic support with the Xcode generator done. > > Please try out this commit: > > Add rudimentary support for the Apple Swift language with Xcode > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bf112531 "Since Apple is the only vendor implementing the language right now, the compiler id can be just `Apple`." This seems somehow wrong. Naming it based on some state 'right now' doesn't seem future proof. The 'MSVC' compiler id is not called 'Microsoft', the 'QCC' compiler id is not called 'QNX', 'XL' is not called 'IBM'. Is there a better name? Thanks, Steve. From brad.king at kitware.com Wed Jul 8 14:42:03 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 08 Jul 2015 14:42:03 -0400 Subject: [cmake-developers] Adding Swift support to CMake In-Reply-To: References: <55842C6C.4050504@kitware.com> <559191D6.5080403@kitware.com> <559BDAE5.9010505@kitware.com> Message-ID: <559D6EFB.9060009@kitware.com> On 07/08/2015 02:35 PM, Stephen Kelly wrote: > "Since Apple is the only vendor implementing the language > right now, the compiler id can be just `Apple`." Even if another vendor implements it the one we're identifying will still be provided by "Apple". The above wording was poor. > This seems somehow wrong. Naming it based on some state 'right now' doesn't > seem future proof. The 'MSVC' compiler id is not called 'Microsoft', the > 'QCC' compiler id is not called 'QNX', 'XL' is not called 'IBM'. The PGI compiler id is "PGI". The PathScale compiler id is "PathScale". The TI compiler id is "TI". The GNU compiler id is "GNU". The Cray compiler id is "Cray". The Absoft compiler id is "Absoft". There is plenty of precedent to use the vendor name. -Brad From ben.boeckel at kitware.com Wed Jul 8 14:47:01 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 8 Jul 2015 14:47:01 -0400 Subject: [cmake-developers] A policy for Policies In-Reply-To: References: <5575F56A.50404@kitware.com> <5575FA50.5080208@kitware.com> <5576008C.3040505@kitware.com> <557636B1.9020500@gmail.com> <5576ED34.7090208@kitware.com> <20150708143410.GA5824@megas.kitware.com> Message-ID: <20150708184701.GA25820@megas.kitware.com> On Wed, Jul 08, 2015 at 14:11:44 -0400, David Cole wrote: > Interesting. So, sort of, but not really. At least not explicitly. Well, the docs state it, but there's no error for setting CMP0010 OLD and CMP0053 NEW at the same time other than the CMP0053 parser turning any code which would have required CMP0010 into a parse error (and it warns about the two parsers disagreeing if CMP0053 is the default). > I'm still interested in seeing an example commit (even if it's only > theoretical and will never actually be merged in) whose explicit > purpose is removing the OLD behavior of a single policy. (Is there > such a commit which removed the OLD behavior of CMP0010, or is it too > entwined in the parser improvement commits from the 3.1 release cycle > as to be easily identifiable as a concise diff?) My initial attempt at the new parser removed the parser entirely (5000+ lines removed :D ), but it has too many corner cases (allowed escape sequences, CMP0010, and others; look at the tests which came with CMP0053 for a taste). --Ben From mantis at public.kitware.com Wed Jul 8 14:49:58 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 8 Jul 2015 20:49:58 +0200 Subject: [cmake-developers] [CMake 0015643]: Control includes order of project being configured Message-ID: <46ac109af601d9f7ffbcb65ea1c44afa@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15643 ====================================================================== Reported By: Stephen Kelly Assigned To: ====================================================================== Project: CMake Issue ID: 15643 Category: CMake Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-08 20:49 CEST Last Modified: 2015-07-08 20:49 CEST ====================================================================== Summary: Control includes order of project being configured Description: A buildsystem can contain target_link_libraries(foo PRIVATE Vendor1::Dep Vendor2::OtherDep ) I might have otherdep installed in /opt, such that /opt/otherdep/include/otherdep.h exists. The 'dep' dependency might be provided in /usr or /usr/local. I can run cmake with various settings such as CMAKE_PREFIX_PATH or OtherDep_DIR to find otherdep in the correct location. The 'foo' target will be compiled with -I/opt/otherdep/include However, if otherdep headers are also installed in /usr or /usr/local, that -I path will not be used to find the headers, and 'foo' will be miscompiled. There is no generic solution to this. If upstream changes the order of the IMPORTED targets, downstreams with 'dep' in /opt will have the problem instead. This problem is more-common on platforms with package managers which do not split headers into -devel packages, and when using a mixture of libraries which are commonly installed though the package manager (such as Qt), and libraries which are installed outside the package manager using vendor supplied packages (such as Qt). It can be reproduced by installing devel packages on linux too. http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/52883/focus=52895 Perhaps a variable could be introduced to set priority of IMPORTED targets when running cmake. This is an issue local to each actor building the project. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-08 20:49 Stephen Kelly New Issue ====================================================================== From ben.boeckel at kitware.com Wed Jul 8 14:56:03 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 8 Jul 2015 14:56:03 -0400 Subject: [cmake-developers] Adding Swift support to CMake In-Reply-To: <559D6EFB.9060009@kitware.com> References: <55842C6C.4050504@kitware.com> <559191D6.5080403@kitware.com> <559BDAE5.9010505@kitware.com> <559D6EFB.9060009@kitware.com> Message-ID: <20150708185603.GB25820@megas.kitware.com> On Wed, Jul 08, 2015 at 14:42:03 -0400, Brad King wrote: > On 07/08/2015 02:35 PM, Stephen Kelly wrote: > > "Since Apple is the only vendor implementing the language > > right now, the compiler id can be just `Apple`." > > Even if another vendor implements it the one we're identifying > will still be provided by "Apple". The above wording was poor. Or it could follow Clang and there's the FOSS swiftc and then there's AppleSwift. --Ben From steveire at gmail.com Wed Jul 8 15:04:42 2015 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 08 Jul 2015 21:04:42 +0200 Subject: [cmake-developers] Adding Swift support to CMake References: <55842C6C.4050504@kitware.com> <559191D6.5080403@kitware.com> <559BDAE5.9010505@kitware.com> <559D6EFB.9060009@kitware.com> Message-ID: Brad King wrote: >> This seems somehow wrong. Naming it based on some state 'right now' >> doesn't seem future proof. The 'MSVC' compiler id is not called >> 'Microsoft', the 'QCC' compiler id is not called 'QNX', 'XL' is not >> called 'IBM'. > > The PGI compiler id is "PGI". The PathScale compiler id is "PathScale". > The TI compiler id is "TI". The GNU compiler id is "GNU". The Cray > compiler id is "Cray". The Absoft compiler id is "Absoft". There is > plenty of precedent to use the vendor name. I guess. I think part of the reason it seems wrong to me is that there is a platform id called 'APPLE' (different case) and a variable of that name There is also an existing GNU platorm/compiler id (same case). If the same name is to be used, is there any reason not to use the same case? Thanks, Steve. From brad.king at kitware.com Wed Jul 8 15:10:01 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 08 Jul 2015 15:10:01 -0400 Subject: [cmake-developers] Adding Swift support to CMake In-Reply-To: References: <55842C6C.4050504@kitware.com> <559191D6.5080403@kitware.com> <559BDAE5.9010505@kitware.com> <559D6EFB.9060009@kitware.com> Message-ID: <559D7589.8000701@kitware.com> On 07/08/2015 03:04 PM, Stephen Kelly wrote: > I guess. I think part of the reason it seems wrong to me is that there is a > platform id called 'APPLE' (different case) and a variable of that name > > There is also an existing GNU platorm/compiler id (same case). > > If the same name is to be used, is there any reason not to use the same > case? All compiler id values use CamelCase or are acronyms. The variable named "APPLE" is historical and meant to match the __APPLE__ preprocessor macro. Compiler id values are different. What do you think of Ben's "AppleSwift" suggestion? -Brad From steveire at gmail.com Wed Jul 8 15:19:50 2015 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 08 Jul 2015 21:19:50 +0200 Subject: [cmake-developers] Adding Swift support to CMake References: <55842C6C.4050504@kitware.com> <559191D6.5080403@kitware.com> <559BDAE5.9010505@kitware.com> <559D6EFB.9060009@kitware.com> <559D7589.8000701@kitware.com> Message-ID: Brad King wrote: > On 07/08/2015 03:04 PM, Stephen Kelly wrote: >> I guess. I think part of the reason it seems wrong to me is that there is >> a platform id called 'APPLE' (different case) and a variable of that name >> >> There is also an existing GNU platorm/compiler id (same case). >> >> If the same name is to be used, is there any reason not to use the same >> case? > > All compiler id values use CamelCase or are acronyms. The variable > named "APPLE" is historical and meant to match the __APPLE__ > preprocessor macro. Compiler id values are different. > > What do you think of Ben's "AppleSwift" suggestion? It made me wonder what would AppleClang be called if it was introduced in the future. If the Swift compiler id is 'Apple', and the Clang CXX compiler id was 'Apple' then we would have, eg Apple-CXX.cmake Apple-Swift.cmake instead of AppleClang-CXX.cmake Apple-Swift.cmake or AppleClang-CXX.cmake AppleSwift-Swift.cmake Seen this way, it looks like 'Apple' is the future proof compiler id and 'AppleClang' is the outlier (an alias could be introduced). So, I don't think the name 'Apple' is so strange anymore. Thanks, Steve. From brad.king at kitware.com Wed Jul 8 15:34:39 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 08 Jul 2015 15:34:39 -0400 Subject: [cmake-developers] Adding Swift support to CMake In-Reply-To: References: <55842C6C.4050504@kitware.com> <559191D6.5080403@kitware.com> <559BDAE5.9010505@kitware.com> <559D6EFB.9060009@kitware.com> <559D7589.8000701@kitware.com> Message-ID: <559D7B4F.6050702@kitware.com> On 07/08/2015 03:19 PM, Stephen Kelly wrote: > Seen this way, it looks like 'Apple' is the future proof compiler id and > 'AppleClang' is the outlier (an alias could be introduced). It is "AppleClang" because it is Apple's distribution of Clang. The reason it cannot just be "Clang" (like we use for Debian's distribution of Clang, for example) is that the version scheme is different. Perhaps it could have been "Apple" but we needed to keep "Clang" in the name for compatibility with code that checks if the compiler id MATCHES "Clang". Also during Apple's transition from GNU to Clang compilers it could have been confusing. The compiler id for the old Apple distributions of the GNU compiler should probably be AppleGNU because the feature set for each version number differs a bit, but those compilers are going away so there is no point in changing that now. > So, I don't think the name 'Apple' is so strange anymore. Okay, I think we'll stick with "Apple" for Swift. Thanks, -Brad From konstantin at podsvirov.pro Wed Jul 8 15:33:27 2015 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Wed, 08 Jul 2015 22:33:27 +0300 Subject: [cmake-developers] [PREVIEW] Meet CMake components-based cross-platform GUI installer Message-ID: <965531436384007@web29o.yandex.ru> All kind time of day! This is not the official installer, but who might someday become. Straight to the point - here online installers Debian 8: http://ifw.podsvirov.pro/cmake/cmake-master-amd64-online.run Windows 7: http://ifw.podsvirov.pro/cmake/cmake-master-win64-online.exe If you have ispolzovali them before, you can just be updated from "cmake-maintenance". Version for 32 bit will update the other day. Installers based on QtIFW 2.0.1. QtDialog (cmake-gui) for Windows is built on the basis of Qt 5.5. If some kind person can collect under MacOS it will be possible to please and lovers of apples. Source code in branch 'master' now. I will be glad to hear from you. If you have questions, ask it. -- Regards, Konstantin Podsvirov -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake-install-components-linux.png Type: image/png Size: 57424 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake-install-coponents-windows.png Type: image/png Size: 45577 bytes Desc: not available URL: From steveire at gmail.com Wed Jul 8 15:46:35 2015 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 08 Jul 2015 21:46:35 +0200 Subject: [cmake-developers] [PATCH] Macro generation for relaxed constexpr References: Message-ID: Jean-Micha?l Celerier wrote: > Hello, > > At the ned of this mail is a patch that adds generation of a macro for > the relaxed ("c++14") constexpr in WriteCompilerDetectionHeader. Thanks for working on this. I have some thoughts for archival purposes on the mailing list. These aren't things you necessarily need to address: * I think I've read about constexpr being made even more relaxed in a future CXX standard. Would we then call it 'yet_more_relaxed_constexpr'? Clang, whose names CMake follows, likely won't introduce a name for it because it will likely start to rely on SD-6 macros instead of extending __has_feature. SD-6 doesn't have that problem because it would just use a new value for the __cpp_constexpr macro (which already has two possible values 200704 and 201304). * The 'relaxed' name is already what is currently used for this feature. Future developments don't really matter. * It's appropriate for this macro to expand to empty if cxx_relaxed_constexpr is not available, because a function marked constexpr which is only cxx11-constexpr but not cxx14-constexpr will fail to compile anyway. Programmers are aware of ways to implement methods in a way that is cxx11-constexpr, even if making it cxx14-constexpr would be more easy/readable. * A method marked constexpr will fail to compile with a compiler which does not support relaxed constexpr if the method uses language which requires relaxed mode (such as a for loop), even if the method is evaluated in a non- constant expression. I tested GCC and Clang. So assuming all that is correct, I think this patch is good. I think there should be a test for the different allowed contexts of the ${prefix_arg}_RELAXED_CONSTEXPR and ${prefix_arg}_CONSTEXPR macros. Could you extend Tests/Module/WriteCompilerDetectionHeader with a test for that? Thanks, Steve. From konstantin at podsvirov.pro Wed Jul 8 15:40:17 2015 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Wed, 08 Jul 2015 22:40:17 +0300 Subject: [cmake-developers] [PATCH] CPackIFW: Variable CPACK_IFW_FRAMEWORK_VERSION cheking Message-ID: <976911436384417@web29o.yandex.ru> Hi, Brad! A very small patch single commit from multiple rows in a topic branch 'cpack-ifw-generator' on my server: http://git.podsvirov.pro/?p=kitware/cmake.git;a=shortlog;h=refs/heads/cpack-ifw-generator Here is the commit itself: CPackIFW: Variable CPACK_IFW_FRAMEWORK_VERSION cheking http://git.podsvirov.pro/?p=kitware/cmake.git;a=commit;h=2d8a3bd27b2f2be911a3c8c30dd667460281beaf I found that CPack IFW generator does not work on the basis QtIFW 2.0 and above for projects which include CPackIFW.cmake module... This hotfix corrects this chip :-) Will be asked to contribute, what would this change was brought in release 3.3. -- Regards, Konstantin Podsvirov From steveire at gmail.com Wed Jul 8 15:49:59 2015 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 08 Jul 2015 21:49:59 +0200 Subject: [cmake-developers] [PATCH] Macro generation for relaxed constexpr References: Message-ID: Stephen Kelly wrote: > * A method marked constexpr will fail to compile with a compiler which > does not support relaxed constexpr if the method uses language which > requires relaxed mode (such as a for loop), even if the method is > evaluated in a non- constant expression. I tested GCC and Clang. Are there any values of '...' where constexpr foo = ...; would compile or not depending only on whether using cxx11-constexpr or cxx14-constexpr? Thanks, Steve. From michael.scott250 at gmail.com Wed Jul 8 16:01:38 2015 From: michael.scott250 at gmail.com (Michael Scott) Date: Wed, 8 Jul 2015 21:01:38 +0100 Subject: [cmake-developers] Add command line options for deprecation message control Message-ID: <559D81A2.5020307@gmail.com> > Since AUTHOR_WARNING is a superset of DEPRECATION_WARNING I think > -W[no-]dev can influence CMAKE_WARN_DEPRECATED. Please also add > -W[no-]error=dev to turn AUTHOR_WARNING into an error and also make > it influence CMAKE_ERROR_DEPRECATED. Then -Wdeprecated and friends > can still be used to control the DEPRECATION messages separately. Making dev influence deprecation variables is not a problem. To support -Werror=dev we'll need a new variable I'm thinking though, something like a boolean CMAKE_SUPPRESS_DEVELOPER_ERRORS? What should be the expected behaviour when combining dev and deprecated now, as they affect each other. If for example the user used the options "-Wno-deprecated -Wdev" in a cmake invocation, the most logical to me would be that this causes CMAKE_SUPPRESS_DEVELOPER_WARNINGS to be TRUE and CMAKE_WARN_DEPRECATED to be FALSE, but implementing that might make the code more complicated than I'd hoped. Cheers, Michael From jeanmichael.celerier at gmail.com Wed Jul 8 16:02:45 2015 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Wed, 8 Jul 2015 22:02:45 +0200 Subject: [cmake-developers] [PATCH] Macro generation for relaxed constexpr In-Reply-To: References: Message-ID: > I think there should be a test for the different allowed contexts of the ${prefix_arg}_RELAXED_CONSTEXPR and ${prefix_arg}_CONSTEXPR macros. Could you extend Tests/Module/WriteCompilerDetectionHeader with a test for that? For sure, I'll do this asap. > constexpr foo = ...; If I read http://en.cppreference.com/w/cpp/language/constexpr correctly, there should be no differences in variable handling between C++11 and 14 for constexpr, the changes are only for function bodies. Jean-Micha?l On Wed, Jul 8, 2015 at 9:49 PM, Stephen Kelly wrote: > Stephen Kelly wrote: > >> * A method marked constexpr will fail to compile with a compiler which >> does not support relaxed constexpr if the method uses language which >> requires relaxed mode (such as a for loop), even if the method is >> evaluated in a non- constant expression. I tested GCC and Clang. > > Are there any values of '...' where > > constexpr foo = ...; > > would compile or not depending only on whether using cxx11-constexpr or > cxx14-constexpr? > > Thanks, > > Steve. > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/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-developers From brad.king at kitware.com Wed Jul 8 16:06:57 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 08 Jul 2015 16:06:57 -0400 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: <559D81A2.5020307@gmail.com> References: <559D81A2.5020307@gmail.com> Message-ID: <559D82E1.2090405@kitware.com> On 07/08/2015 04:01 PM, Michael Scott wrote: > Making dev influence deprecation variables is not a problem. To support > -Werror=dev we'll need a new variable I'm thinking though, something > like a boolean CMAKE_SUPPRESS_DEVELOPER_ERRORS? Yes, thanks. > What should be the expected behaviour when combining dev and deprecated > now, as they affect each other. If for example the user used the options > "-Wno-deprecated -Wdev" in a cmake invocation, the most logical to me > would be that this causes CMAKE_SUPPRESS_DEVELOPER_WARNINGS to be TRUE > and CMAKE_WARN_DEPRECATED to be FALSE, but implementing that might make > the code more complicated than I'd hoped. Yes, I think you'll need some kind of tracking for what settings were explicitly specified. Thanks, -Brad P.S. Your mailer is breaking the message threading. From brad.king at kitware.com Wed Jul 8 16:09:19 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 08 Jul 2015 16:09:19 -0400 Subject: [cmake-developers] [PATCH] CPackIFW: Variable CPACK_IFW_FRAMEWORK_VERSION cheking In-Reply-To: <976911436384417@web29o.yandex.ru> References: <976911436384417@web29o.yandex.ru> Message-ID: <559D836F.60801@kitware.com> On 07/08/2015 03:40 PM, Konstantin Podsvirov wrote: > I found that CPack IFW generator does not work on the basis QtIFW 2.0 > and above for projects which include CPackIFW.cmake module... This > hotfix corrects this chip :-) Applied, thanks: CPackIFW: Load module to set CPACK_IFW_FRAMEWORK_VERSION http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ad5c76af > Will be asked to contribute, what would this change was brought in > release 3.3. Yes, this falls in the "bug in new feature" category of allowed updates to the release. I've queued it for merge to the 'release' branch once it tests cleanly. Thanks, -Brad From steveire at gmail.com Wed Jul 8 16:40:03 2015 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 08 Jul 2015 22:40:03 +0200 Subject: [cmake-developers] [PATCH] Macro generation for relaxed constexpr References: Message-ID: Jean-Micha?l Celerier wrote: >> I think there should be a test for the different allowed contexts of the > ${prefix_arg}_RELAXED_CONSTEXPR and ${prefix_arg}_CONSTEXPR macros. Could > you extend Tests/Module/WriteCompilerDetectionHeader with a test for that? > > For sure, I'll do this asap. > >> constexpr foo = ...; > > If I read http://en.cppreference.com/w/cpp/language/constexpr > correctly, there should be no differences in variable handling between > C++11 and 14 for constexpr, the changes are only for function bodies. Right. Qt 5 provides a macro for this context which expands to either 'const' or 'constexpr' depending on whether cxx_constexpr is available, and another macro which expands to either 'const' or 'constexpr' depending on whether cxx_relaxed_constexpr is available. Compare the assembly of the following when compiled with -std=c++98/11/14: #if __has_feature(cxx_constexpr) #define DECL_CONSTEXPR constexpr #else #define DECL_CONSTEXPR #endif #if __has_feature(cxx_relaxed_constexpr) #define DECL_RELAXED_CONSTEXPR constexpr #else #define DECL_RELAXED_CONSTEXPR #endif DECL_CONSTEXPR int getNumRegular() { return 42; } DECL_RELAXED_CONSTEXPR int getNumRelaxed() { int result = 0; for (int i = 0; i < 4; ++i) result += 10; return result + 2; } DECL_CONSTEXPR int betterIfConstexprParameter(int param) { return param / 2; } #if __has_feature(cxx_constexpr) #define CXX11_CONSTEXPR_VARIABLE constexpr #else #define CXX11_CONSTEXPR_VARIABLE const #endif #if __has_feature(cxx_relaxed_constexpr) #define CXX14_CONSTEXPR_VARIABLE constexpr #else #define CXX14_CONSTEXPR_VARIABLE const #endif int main() { CXX11_CONSTEXPR_VARIABLE int num1 = getNumRegular(); CXX11_CONSTEXPR_VARIABLE int result1 = betterIfConstexprParameter(num1); CXX14_CONSTEXPR_VARIABLE int num2 = getNumRelaxed(); CXX14_CONSTEXPR_VARIABLE int result2 = betterIfConstexprParameter(num2); return result1 - result2; } $ wc -l 98.s 11.s 14.s 126 98.s 90 11.s 31 14.s Of course, such macros don't belong in the same patch as the one you submitted and could be in a follow-up. Thanks, Steve. From steveire at gmail.com Wed Jul 8 16:42:10 2015 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 08 Jul 2015 22:42:10 +0200 Subject: [cmake-developers] [PATCH] Macro generation for relaxed constexpr References: Message-ID: Jean-Micha?l Celerier wrote: >> I think there should be a test for the different allowed contexts of the > ${prefix_arg}_RELAXED_CONSTEXPR and ${prefix_arg}_CONSTEXPR macros. Could > you extend Tests/Module/WriteCompilerDetectionHeader with a test for that? > > For sure, I'll do this asap. > Great, thanks! Steve. From Robert.Goulet at autodesk.com Wed Jul 8 16:57:33 2015 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Wed, 8 Jul 2015 20:57:33 +0000 Subject: [cmake-developers] Generator expressions for output directory/name (and install?) In-Reply-To: <558030D9.7030000@kitware.com> References: <557831B5.4080902@kitware.com> <82afa15571354e998152a8eba50d0beb@CO1PR79MB027.MGDADSK.autodesk.com> <55798507.5080101@kitware.com> <56888292a6bb429a9e90964ffaca7524@CO1PR79MB027.MGDADSK.autodesk.com> <557EDE74.6000202@kitware.com> <345c3a7fe7074debbfbd9dd4cf7f3717@BN1PR79MB024.MGDADSK.autodesk.com> <558030D9.7030000@kitware.com> Message-ID: Ok let's start with the simplest one, OUTPUT_NAME generator expressions support, then we'll do the others. Patch in attachment. -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Tuesday, June 16, 2015 10:21 AM To: Robert Goulet Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] Generator expressions for output directory/name (and install?) On 06/15/2015 03:03 PM, Robert Goulet wrote: > Updated with improved tests and added docs. Thanks. Here are more comments. Please split the patch to do the OUTPUT_NAME/dir changes first. Update the Tests/PerConfig test to cover these. Since the RUNTIME_OUTPUT_DIRECTORY properties are learning this, please do it for ARCHIVE_OUTPUT_DIRECTORY and LIBRARY_OUTPUT_DIRECTORY too for completeness. Then do the install DESTINATION changes in a second patch. That will simplify review. In this hunk: > cmInstallTargetGenerator( > - cmTarget& t, const char* dest, bool implib, > + cmMakefile* mf, cmTarget& t, const char* dest, bool implib, The cmTarget has a GetMakefile() method so there should be no need to pass the mf separately. In this hunk: > @@ -216,6 +216,7 @@ void cmScriptGenerator::GenerateScriptActionsPerConfig(std::ostream& os, > i != this->ConfigurationTypes->end(); ++i) > { > const char* config = i->c_str(); > + this->ConfigurationName = config; > if(this->GeneratesForConfig(config)) > { > // Generate a per-configuration block. This should not be needed if things are factored correctly. Everything in that block already passes "config" through as a parameter. Thanks, -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: output-name-genex.patch Type: application/octet-stream Size: 6136 bytes Desc: output-name-genex.patch URL: From mantis at public.kitware.com Thu Jul 9 08:08:01 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 9 Jul 2015 08:08:01 -0400 Subject: [cmake-developers] [CMake 0015644]: AUTORCC not generating files Message-ID: <87c197cc928e2143fcbba6d2057e4df9@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15644 ====================================================================== Reported By: Lectem Assigned To: ====================================================================== Project: CMake Issue ID: 15644 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-09 08:08 EDT Last Modified: 2015-07-09 08:08 EDT ====================================================================== Summary: AUTORCC not generating files Description: AUTORCC is not generating the qrc_*.cpp files, rcc isn't even called. I suspect the problem coming from the fact that I'm getting an error while configuring the project : /usr/lib/x86_64-linux-gnu/qt5/bin/rcc: Unknown option: '--list' It is coming from this line : https://github.com/Kitware/CMake/blob/master/Source/cmQtAutoGenerators.cxx#L193 I don't understand what the script is trying to do since --list isn't available for qt4 nor qt5. The resources are present, with the correct path. It is working when using QT5_ADD_RESOURCES. Additional Information: CMakeLists.txt : set(CMAKE_INCLUDE_CURRENT_DIR ON) set(CMAKE_AUTOMOC ON) set(CMAKE_AUTORCC ON) set(CMAKE_AUTOUIC ON) find_package(Qt5Core REQUIRED) find_package(Qt5Widgets REQUIRED) find_package(Qt5LinguistTools REQUIRED) find_package(Qt5Multimedia REQUIRED) add_executable(myexe main.cpp resource_file.qrc) resource_file.qrc : images/copy.png images/cut.png images/new.png images/open.png images/paste.png images/save.png ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-09 08:08 Lectem New Issue ====================================================================== From brennan at lanl.gov Thu Jul 9 10:42:13 2015 From: brennan at lanl.gov (Brennan, Sean M) Date: Thu, 9 Jul 2015 14:42:13 +0000 Subject: [cmake-developers] [PATCH] FindMPI: Intel-MPI 5+ workaround Message-ID: <0AADAA6FB87FDC438CA0C4168DB19B9E450ABB8E@ECS-EXG-P-MB03.win.lanl.gov> See attached git patch. FindMPI: Intel-MPI 5+ workaround needs an additional/alternate keyword to recognize this case with recent GCCs. Confirmed working with intel-mpi/5.0.1 using gcc/4.4.7, gcc/4.6.1, gcc/4.7.2, gcc/4.8.2, intel/11.1.072, intel/12.1.5, intel/13.1.3, intel/14.0.4, intel/15.0.090, pgi/10.9, pgi/12.6, pgi/13.7, pgi/14.10. Tested by building LLNL's PnMPI library. ############################ Sean M. Brennan, Ph.D. High Performance Computing Systems Los Alamos National Laboratory PO Box 1663, MS T080 Los Alamos, NM 87545 (505) 667-1092, fax: (505) 667-7665 -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-findmpi-intelmpi.patch Type: text/x-patch Size: 968 bytes Desc: fix-findmpi-intelmpi.patch URL: From brad.king at kitware.com Thu Jul 9 11:01:59 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 09 Jul 2015 11:01:59 -0400 Subject: [cmake-developers] [PATCH] Extended Nsight Tegra support for CMake In-Reply-To: References: Message-ID: <559E8CE7.2070408@kitware.com> On 07/08/2015 11:21 AM, Mikhail Filimonov wrote: > I've extended the Nsight Tegra project generator in CMake and added a bunch > of properties with the backing variables to fine-tune the generated projects. Thanks! Here are some comments. > - --build-options -DCMAKE_SYSTEM_NAME=Android > + --build-options -DCMAKE_SYSTEM_NAME=Android -DCMAKE_TOOLCHAIN_FILE= "${CMake_SOURCE_DIR}/Tests/VSNsightTegra/NsightTegraToolchain.cmake" [snip] > +# CMake toolchain file used for the generation of Nsight Tegra project files > + > +set(CMAKE_GENERATOR_TOOLSET clang-3.5) > +set(CMAKE_SYSTEM_NAME Android) We'd like to keep testing the default behavior without an explicit toolchain file. Also we need to be independent of the toolsets that happen to be available on the system where the test runs, so we should avoid hard-coding a toolset name if possible. Is this part of the patch needed to test everything else? If so, please look at adding more test cases for the new combinations (which can just be more builds of the same test source tree). > +set_property(TARGET twolib-second APPEND PROPERTY ANDROID_NATIVE_LIB_DIRECTORIES c:\\wrk c:\\wrk\\cmake) The test should not name directories outside control of the test suite. Please name directories in the test source tree or something. Also, in Source/* C++ sources please wrap lines to keep them <= 79 columns. Thanks, -Brad From brad.king at kitware.com Thu Jul 9 11:03:59 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 09 Jul 2015 11:03:59 -0400 Subject: [cmake-developers] AppleClang-CXX.cmake needs an update In-Reply-To: <559D29D1.4030407@kitware.com> References: <1436339332.2038481.318057305.36E95813@webmail.messagingengine.com> <559D29D1.4030407@kitware.com> Message-ID: <559E8D5F.1000201@kitware.com> On 07/08/2015 09:46 AM, Brad King wrote: > On 07/08/2015 03:08 AM, darkapostle at rule506.net wrote: >> C++14 is a first class citizen in Xcode 6. > > AppleClang: Use modern C++14 standard flags for Xcode 6 > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d0430c0a It turns out that the newer flags are not available until Xcode 6.3 (which is Apple Clang 6.1). I've revised the change: AppleClang: Use modern C++14 standard flags for Apple Clang 6.1 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=228643af -Brad From brad.king at kitware.com Thu Jul 9 11:05:13 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 09 Jul 2015 11:05:13 -0400 Subject: [cmake-developers] [PATCH] FindMPI: Intel-MPI 5+ workaround In-Reply-To: <0AADAA6FB87FDC438CA0C4168DB19B9E450ABB8E@ECS-EXG-P-MB03.win.lanl.gov> References: <0AADAA6FB87FDC438CA0C4168DB19B9E450ABB8E@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: <559E8DA9.7040407@kitware.com> On 07/09/2015 10:42 AM, Brennan, Sean M wrote: > See attached git patch. Applied, thanks: FindMPI: Extend Intel-MPI 5+ workaround for recent GCCs http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5d7653a0 -Brad From mfilimonov at nvidia.com Thu Jul 9 11:42:33 2015 From: mfilimonov at nvidia.com (Mikhail Filimonov) Date: Thu, 9 Jul 2015 15:42:33 +0000 Subject: [cmake-developers] [PATCH] Extended Nsight Tegra support for CMake In-Reply-To: <559E8CE7.2070408@kitware.com> References: <559E8CE7.2070408@kitware.com> Message-ID: Thanks for your feedback, Brad From: Brad King [mailto:brad.king at kitware.com] Sent: 9 ???? 2015 ?. 18:02 >We'd like to keep testing the default behavior without an explicit toolchain file. Also we need to be independent of the toolsets that happen to be available on the system where the test runs, so we >should avoid hard-coding a toolset name if possible. Is this part of the patch needed to test everything else? If so, please look at adding more test cases for the new combinations (which can just be >more builds of the same test source tree). That's more like a demonstration sample that will show the developers how the various Nsight Tegra project properties could be defined via the various CMake properties even if not directly related to Android - i.e. C_STANDARD and CMAKE_GENERATOR_TOOLSET Currently where's no samples directory in CMake source tree - so I've slightly reworked the existing test case. Maybe you could propose a better way to deliver that sample? Thanks, -Mikhail ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- From brad.king at kitware.com Thu Jul 9 12:55:25 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 09 Jul 2015 12:55:25 -0400 Subject: [cmake-developers] Generator expressions for output directory/name (and install?) In-Reply-To: References: <557831B5.4080902@kitware.com> <82afa15571354e998152a8eba50d0beb@CO1PR79MB027.MGDADSK.autodesk.com> <55798507.5080101@kitware.com> <56888292a6bb429a9e90964ffaca7524@CO1PR79MB027.MGDADSK.autodesk.com> <557EDE74.6000202@kitware.com> <345c3a7fe7074debbfbd9dd4cf7f3717@BN1PR79MB024.MGDADSK.autodesk.com> <558030D9.7030000@kitware.com> Message-ID: <559EA77D.3050406@kitware.com> On 07/08/2015 04:57 PM, Robert Goulet wrote: > Ok let's start with the simplest one, OUTPUT_NAME generator > expressions support, then we'll do the others. I made one documentation update: Help: Improve OUTPUT_NAME documentation formatting http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9a1ef0dc Then I rebased your patch on it and revised the docs a bit. Applied: Add generator expression support to OUTPUT_NAME target property http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=809159c9 Thanks, -Brad From Robert.Goulet at autodesk.com Thu Jul 9 12:59:56 2015 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Thu, 9 Jul 2015 16:59:56 +0000 Subject: [cmake-developers] Generator expressions for output directory/name (and install?) In-Reply-To: <559EA77D.3050406@kitware.com> References: <557831B5.4080902@kitware.com> <82afa15571354e998152a8eba50d0beb@CO1PR79MB027.MGDADSK.autodesk.com> <55798507.5080101@kitware.com> <56888292a6bb429a9e90964ffaca7524@CO1PR79MB027.MGDADSK.autodesk.com> <557EDE74.6000202@kitware.com> <345c3a7fe7074debbfbd9dd4cf7f3717@BN1PR79MB024.MGDADSK.autodesk.com> <558030D9.7030000@kitware.com> <559EA77D.3050406@kitware.com> Message-ID: <145dca5bcd414a0ab59d46f4cc0210aa@BN1PR79MB024.MGDADSK.autodesk.com> Awesome, thanks Brad. I'm guessing it's too late for 3.3? -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Thursday, July 9, 2015 12:55 PM To: Robert Goulet Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] Generator expressions for output directory/name (and install?) On 07/08/2015 04:57 PM, Robert Goulet wrote: > Ok let's start with the simplest one, OUTPUT_NAME generator > expressions support, then we'll do the others. I made one documentation update: Help: Improve OUTPUT_NAME documentation formatting http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9a1ef0dc Then I rebased your patch on it and revised the docs a bit. Applied: Add generator expression support to OUTPUT_NAME target property http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=809159c9 Thanks, -Brad From brad.king at kitware.com Thu Jul 9 13:04:16 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 09 Jul 2015 13:04:16 -0400 Subject: [cmake-developers] Generator expressions for output directory/name (and install?) In-Reply-To: <145dca5bcd414a0ab59d46f4cc0210aa@BN1PR79MB024.MGDADSK.autodesk.com> References: <557831B5.4080902@kitware.com> <82afa15571354e998152a8eba50d0beb@CO1PR79MB027.MGDADSK.autodesk.com> <55798507.5080101@kitware.com> <56888292a6bb429a9e90964ffaca7524@CO1PR79MB027.MGDADSK.autodesk.com> <557EDE74.6000202@kitware.com> <345c3a7fe7074debbfbd9dd4cf7f3717@BN1PR79MB024.MGDADSK.autodesk.com> <558030D9.7030000@kitware.com> <559EA77D.3050406@kitware.com> <145dca5bcd414a0ab59d46f4cc0210aa@BN1PR79MB024.MGDADSK.autodesk.com> Message-ID: <559EA990.6060205@kitware.com> On 07/09/2015 12:59 PM, Robert Goulet wrote: > Awesome, thanks Brad. > > I'm guessing it's too late for 3.3? Yes ;) -Brad From cliffyapp at gmail.com Thu Jul 9 13:35:43 2015 From: cliffyapp at gmail.com (Clifford Yapp) Date: Thu, 9 Jul 2015 13:35:43 -0400 Subject: [cmake-developers] Wrapping functions in CMake Message-ID: A problem has arisen with CMake and BRL-CAD in 3.3, and it looks like it may relate to some command overriding BRL-CAD does in order to support some of our more advanced build features. The feature we are using to do this is an unsupported debug feature, and Brad King suggested moving over to cmake-developers list to discuss why we are doing what we're doing and how it might be supported. (The initial context of the discussion can be found here: http://public.kitware.com/pipermail/cmake/2015-July/061026.html) Our use of function overrides of basic CMake commands is driven by four primary needs: 1. First, we need to maintain a list of all files in the source repository that are known to the build system. To do this we maintain a global list of files, define a custom CMAKEFILES command to allow us to manually specify miscellaneous files as "known", and override all of the primary target creating commands to add their files to the list (for example, add_executable is passed a list of source files, and all of those files are automatically added to the "known files" list by the function override of add_executable.) This list is used for both our "make-clean-in-src-dir" feature and our distcheck build target (which does a number of verification steps using the version control system, the build system and the files-on-filesystem information to make sure the build logic is current.) 2. Second we maintain global lists of all exec, library, and custom targets. This allows us to run timestamping build targets that run at the very beginning and very end of the build process, by setting up target dependences for the beginning and ending timestamp targets. The ending time stamp target must depend on every other build target, and the beginning timestamp is depended on by every other build target. To do this, as far as I know, we need lists of all build targets so we can set this up with the add_dependencies command. 3. Third, we override the message function to append all messages written to the console to a log file. This is to allow users to send us a complete record of what they saw on the console during a configure process. Normally this sort of thing is handled by custom wrapper functions or macros, rather than overriding the CMake defaults. For our own build targets, we actually do have our own custom wrappers where we do much more than the above three steps. The reason these three steps must be done for "vanilla" CMake commands is that we need this information from our src/other build dependencies as well. These dependencies are separate build logic that does not rely on BRL-CAD macros, and we try to change the upstream logic as little as possible. For a number of reasons, we have found that the best way to handle these src/other sub-projects is to add them to our overall project build directly. However, this means we need a way to override the behaviour of their target generating functions and message outputs to fit into the overall BRL-CAD system without changing the logic of the src/other sub-builds. My "ideal" CMake features to accomplish each of the above would be: 1. Have CMake internally maintain a list (or maybe per-command lists for more flexibility) of all files with paths relative to the root source directory that have been "observed" by add_executable, add_library, add_custom_target, add_subdirectory, and configure_file that can be accessed via CMake variables (e.g. CMAKE_EXECUTABLE_SOURCE_FILES, CMAKE_LIBRARY_SOURCE_FILES, etc.) This is essentially the bookkeeping we are doing manually now, and a CMake provided global variable set would make it unnecessary to override the commands to get it. Files marked as "GENERATED" are not counted in these lists, as they are considered build output. 2. Provide similar lists of all defined targets for the various types (e.g. CMAKE_EXECUTABLE_TARGETS, CMAKE_LIBRARY_TARGETS, CMAKE_CUSTOM_TARGETS). 3. Have one or a number of variables that will hold in memory all the text written out by message (CMAKE_MESSAGES, CMAKE_STATUS_MESSAGES, CMAKE_ERROR_MESSAGES, etc.) so the CMakeLists.txt file can create log files reflecting what the user is seeing on the console window. It's possible some of these features have been added over the years and I missed the announcements, so if they already exist I'd be grateful for any pointers. If they don't exist, would it be practical to add them? Thanks, Cliff From cliffyapp at gmail.com Thu Jul 9 13:53:48 2015 From: cliffyapp at gmail.com (Clifford Yapp) Date: Thu, 9 Jul 2015 13:53:48 -0400 Subject: [cmake-developers] Wrapping functions in CMake In-Reply-To: References: Message-ID: On Thu, Jul 9, 2015 at 1:35 PM, Clifford Yapp wrote: > 3. Have one or a number of variables that will hold in memory all the > text written out by message (CMAKE_MESSAGES, CMAKE_STATUS_MESSAGES, > CMAKE_ERROR_MESSAGES, etc.) so the CMakeLists.txt file can create log > files reflecting what the user is seeing on the console window. Actually, thinking about that, what's really needed is not an in-memory log but a way to specify log files, since an unexpected crash or exit is not a situation under which such in-memory logs could be reliably written to disk. So it would instead need to be CMAKE_STATUS_MESSAGE_LOG, CMAKE_ERROR_MESSAGES_LOG, etc. which would hold paths to which messages would be copied before being written to stdout/stderr. Cheers, Cliff From brad.king at kitware.com Thu Jul 9 14:41:28 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 09 Jul 2015 14:41:28 -0400 Subject: [cmake-developers] [CMake] Problem with CMake 3.3.0-rc3 In-Reply-To: References: <559AA461.5070104@kitware.com> Message-ID: <559EC058.6000209@kitware.com> On 07/09/2015 01:43 PM, Clifford Yapp wrote: > OK, more info - it looks like the problem is limited to the CMake GUI > configure (although I haven't been able to test ccmake, the basic > cmake works) and the test file is pretty simple: Thanks. I've narrowed it down to this session: ------------------------------------------------------------- $ cat ../CMakeLists.txt cmake_minimum_required(VERSION 3.2) project(Sample NONE) message("message") function(message) _message(${ARGN}) endfunction() $ cmake-gui .. (click configure twice) ------------------------------------------------------------- It bisects to this commit: cmake: Simplify command clean up loop. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=97e53ebb Steve, please take a look. It looks like the cmState methods RemoveUserDefinedCommands and RenameCommand need to work better together. This needs to be fixed for 3.3. Thanks, -Brad From patrikhuber at gmail.com Thu Jul 9 16:39:14 2015 From: patrikhuber at gmail.com (Patrik Huber) Date: Thu, 9 Jul 2015 21:39:14 +0100 Subject: [cmake-developers] Header-only library targets Message-ID: Hi all, I've recently switched from CMake 2.8.12 to 3.2, full of enthusiasm that header-only libraries would now be better supported through the INTERFACE option/target. However, the support for header-only libraries isn't really great, in particular if you're using an IDE like Visual Studio. The main problem is that if you define an INTERFACE target, there's no way to specify headers, and they won't show up in IDEs. There's workarounds with a custom target, but that's not really great for example to set dependencies, populate the include directory of the library or to INSTALL the target. Brad King said in this (http://www.cmake.org/Bug/view.php?id=15234) ticket that posting here would be appropriate. I've posted a couple of links to Stackoverflow in the ticket as well - other people have this issue as well and the only way out of it is some hacks, neither of which are satisfactory. I'm sorry if this has been been discussed before, I just joined the list, and I couldn't find any means to search through the mailing list archives (except through Google, whose results didn't indicate it had been discussed before). But even if it has been discussed before, I think it's appropriate to raise this issue again - hopefully, a fix should not be that hard. Thanks, Patrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Fri Jul 10 02:56:17 2015 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 10 Jul 2015 08:56:17 +0200 Subject: [cmake-developers] [PATCH] FindMPI: Intel-MPI 5+ workaround In-Reply-To: <559E8DA9.7040407@kitware.com> References: <0AADAA6FB87FDC438CA0C4168DB19B9E450ABB8E@ECS-EXG-P-MB03.win.lanl.gov> <559E8DA9.7040407@kitware.com> Message-ID: <3430682.FbuVj3uGB3@caliban.sf-tec.de> Am Donnerstag, 9. Juli 2015, 11:05:13 schrieb Brad King: > On 07/09/2015 10:42 AM, Brennan, Sean M wrote: > > See attached git patch. > > Applied, thanks: > > FindMPI: Extend Intel-MPI 5+ workaround for recent GCCs > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5d7653a0 For the usual reasons, can we please change this from "${cmdline}" to cmdline? Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From eike at sf-mail.de Fri Jul 10 02:58:33 2015 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 10 Jul 2015 08:58:33 +0200 Subject: [cmake-developers] [PATCH] FindMPI: Intel-MPI 5+ workaround In-Reply-To: <0AADAA6FB87FDC438CA0C4168DB19B9E450ABB8E@ECS-EXG-P-MB03.win.lanl.gov> References: <0AADAA6FB87FDC438CA0C4168DB19B9E450ABB8E@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: <8869609.xOtBjabmh6@caliban.sf-tec.de> Am Donnerstag, 9. Juli 2015, 14:42:13 schrieb Brennan, Sean M: > See attached git patch. > > FindMPI: Intel-MPI 5+ workaround needs an additional/alternate keyword to > recognize this case with recent GCCs. > > Confirmed working with intel-mpi/5.0.1 using gcc/4.4.7, gcc/4.6.1, > gcc/4.7.2, gcc/4.8.2, intel/11.1.072, intel/12.1.5, intel/13.1.3, > intel/14.0.4, intel/15.0.090, pgi/10.9, pgi/12.6, pgi/13.7, pgi/14.10. > Tested by building LLNL's PnMPI library. That's quite an impressive list of tools. Is there any chance that we can get an automated nigthly build that has access to them? Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From konstantin at podsvirov.pro Fri Jul 10 04:12:51 2015 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Fri, 10 Jul 2015 11:12:51 +0300 Subject: [cmake-developers] [PREVIEW] Meet CMake components-based cross-platform GUI installer In-Reply-To: <965531436384007@web29o.yandex.ru> References: <965531436384007@web29o.yandex.ru> Message-ID: <1988621436515971@web21h.yandex.ru> Meet fresh CMake 3.3.20150710 from branch 'master'! 08.07.2015, 22:42, "Konstantin Podsvirov" : > All kind time of day! > > This is not the official installer, but who might someday become. > > Straight to the point - here online installers > > Debian 8: > > http://ifw.podsvirov.pro/cmake/cmake-master-amd64-online.run > > Windows 7: > > http://ifw.podsvirov.pro/cmake/cmake-master-win64-online.exe > > If you have them before, you can just be updated from "cmake-maintenance". > > Version for 32 bit will update the other day. Two installer builded in Debian 8: http://ifw.podsvirov.pro/cmake/cmake-master-i386-online.run http://ifw.podsvirov.pro/cmake/cmake-master-amd64-online.run And two installer builded in Windows 7: http://ifw.podsvirov.pro/cmake/cmake-master-win32-online.exe http://ifw.podsvirov.pro/cmake/cmake-master-win64-online.exe The other day we introduced and tested a small hotfix for CPack IFW generator. Changes in branch master and should soon get into the next release. If some kind person can build installer under MacOS it will be possible to please and lovers of apples. If you have any questions, feel free to ask them. -- Regards, Konstantin Podsvirov From brad.king at kitware.com Fri Jul 10 08:57:21 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 10 Jul 2015 08:57:21 -0400 Subject: [cmake-developers] [PATCH] FindMPI: Intel-MPI 5+ workaround In-Reply-To: <3430682.FbuVj3uGB3@caliban.sf-tec.de> References: <0AADAA6FB87FDC438CA0C4168DB19B9E450ABB8E@ECS-EXG-P-MB03.win.lanl.gov> <559E8DA9.7040407@kitware.com> <3430682.FbuVj3uGB3@caliban.sf-tec.de> Message-ID: <559FC131.9000501@kitware.com> On 07/10/2015 02:56 AM, Rolf Eike Beer wrote: > Am Donnerstag, 9. Juli 2015, 11:05:13 schrieb Brad King: >> FindMPI: Extend Intel-MPI 5+ workaround for recent GCCs >> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5d7653a0 > > For the usual reasons, can we please change this from > "${cmdline}" to cmdline? Yes, revised: FindMPI: Extend Intel-MPI 5+ workaround for recent GCCs http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cfd23d3f Thanks, -Brad From michael at ensslin.cc Fri Jul 10 14:31:48 2015 From: michael at ensslin.cc (=?UTF-8?B?TWljaGFlbCBFbsOfbGlu?=) Date: Fri, 10 Jul 2015 20:31:48 +0200 Subject: [cmake-developers] Adding a custom property that is queried from cmGlobalUnixMakefileGenerator3 Message-ID: <55A00F94.7030403@ensslin.cc> Hi, I'm trying to add a custom global property that is queried from cmGlobalUnixMakefileGenerator3's constructor. For that, I use this piece of code in the constructor: this->TargetMessages = true; if(const char* ruleStatus = this ->GetCMakeInstance() ->GetState() ->GetGlobalProperty("TARGET_MESSAGES")) { this->TargetMessages = cmSystemTools::IsOn(ruleStatus); } This is analogous to how it's done in cmMakefileTargetGenerator's constructor for the RULE_MESSAGES global property. However, ruleStatus is always nullptr, whatever I try. Some hours of printing pointers in debugging messages later, it seems like cmGlobalUnixMakefileGenerator3 isn't getting the same global "cmake" object, and thus cmState object, that the entire rest of the program uses (especially the one used during set_property(GLOBAL PROPERTY) calls). Could you please enlighten me why that happens, and what to do about it? ~ Michael Ensslin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From michael at ensslin.cc Fri Jul 10 15:18:56 2015 From: michael at ensslin.cc (=?UTF-8?B?TWljaGFlbCBFbsOfbGlu?=) Date: Fri, 10 Jul 2015 21:18:56 +0200 Subject: [cmake-developers] [Patch] Added property to disable the "Built target" progress messages in Makefile targets Message-ID: <55A01AA0.3090809@ensslin.cc> ===== Motivation: In my project, openage, the build system currently produces fairly much useless output, even if not a single file of the project has changed: mic at mic ~/git/openage $ make [ 0%] Built target compilepy [ 1%] Built target cythonize [ 1%] Built target codegen [ 83%] Built target libopenage [ 84%] Built target openage_testing_cpp_testing [ 86%] Built target run [ 87%] Built target openage_cabextract_cabchecksum [ 88%] Built target openage_cabextract_lzxd [ 89%] Built target openage_cppinterface_exctranslate [ 90%] Built target openage_cppinterface_exctranslate_tests [ 91%] Built target openage_cppinterface_setup_checker [ 93%] Built target openage_cppinterface_pyobject [ 94%] Built target openage_game_main_cpp [ 95%] Built target openage_log_log_cpp [ 96%] Built target openage_util_fslike_cpp [ 98%] Built target openage_testing_misc_cpp [ 99%] Built target inplacemodules [ 99%] Built target pxdgen [100%] Built target distfiles mic at mic ~/git/openage $ That list of targets is expected to grow fairly large in the near-distant future; at some point, it might even get large enough to hide actual important compilation messages. ===== Patch: The patch adds a global property, "TARGET_MESSAGES", which behaves analogous to "RULE_MESSAGES" in that it can be explicitly set to OFF to suppress some build output. When set to OFF, the above invocation of `make` will produce no output. Otherwise, CMake will behave as usual. The patch includes some documentation. ~ Michael Ensslin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Added-the-TARGET_MESSAGES-property.patch Type: text/x-patch Size: 3876 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From cliffyapp at gmail.com Fri Jul 10 15:42:57 2015 From: cliffyapp at gmail.com (Clifford Yapp) Date: Fri, 10 Jul 2015 15:42:57 -0400 Subject: [cmake-developers] Wrapping functions in CMake In-Reply-To: References: Message-ID: On Thu, Jul 9, 2015 at 1:35 PM, Clifford Yapp wrote: > 2. Provide similar lists of all defined targets for the various types > (e.g. CMAKE_EXECUTABLE_TARGETS, CMAKE_LIBRARY_TARGETS, > CMAKE_CUSTOM_TARGETS). Looking into the CMake sources, it seems like this information is stored already in the global target map - what would be the "correct" way to expose that information in variables in CMake script space? Thanks, Cliff From mantis at public.kitware.com Sat Jul 11 15:59:32 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 11 Jul 2015 15:59:32 -0400 Subject: [cmake-developers] [CMake 0015647]: automoc is not run on some files with lots of targets in a CMakeLists.txt Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15647 ====================================================================== Reported By: Friedrich Assigned To: ====================================================================== Project: CMake Issue ID: 15647 Category: CMake Reproducibility: have not tried Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-11 15:59 EDT Last Modified: 2015-07-11 15:59 EDT ====================================================================== Summary: automoc is not run on some files with lots of targets in a CMakeLists.txt Description: CMake at least in the versions 3.1.3-3.2.3 for some not yet known reasons fails to run automoc on random targets if there are a lot of targets in a file. It's random as in, changing target names has an effect on with which files of which target automoc fails to be run (e.g. appending another letter to the name suddenly makes it work, just to fail on files of another target, and then the game restarts). With 3.3.0-rc2 the problem was not seen. Steps to Reproduce: (Sorry, had no time to create a small example) The problem can be seen in the build of the KDE project "Calligra" in the "frameworks" branch. The CMakeLists.txt file where things are screwed up is "krita/image/tests/CMakeLists.txt", http://quickgit.kde.org/?p=calligra.git&a=blob&h=c0f2c77373fb1b624296d27e66c2deb3c86b6c07&hb=0629fef375cfc5520cab57a3920e88fe84526c94&f=krita%2Fimage%2Ftests%2FCMakeLists.txt It's enough to build the Krita part of Calligra to trigger this: # get Calligra sources, use frameworks branch # (sadly no way known to directly get a tarball with a snapshot) git clone git://anongit.kde.org/calligra.git cd calligra; git checkout frameworks; cd .. Use an texteditor of your choice and remove the cmake version check at the beging of "krita/image/tests/CMakeLists.txt". Then go on: # create build dir and run cmake, reduce to just building krita (+ internal deps) mkdir build; cd build cmake ../calligra -DBUILD_TESTING=ON -DPRODUCTSET=KRITA If at the end of the configure log you see -- ------ The following product(set)s/features will be built --------- -- KRITA: Full Krita we are good to finally test the problem. cd krita/image/tests/ make And now wait for the build to fail, it should be something like CMakeFiles/KisAsyncMergerTest.dir/kis_async_merger_test.cpp.o: In function `KisAsyncMergerTest::KisAsyncMergerTest()': /home/jenkins/builds/calligra/kf5- qt5/krita/image/tests/kis_async_merger_test.h:24: undefined reference to `vtable for KisAsyncMergerTest' CMakeFiles/KisAsyncMergerTest.dir/kis_async_merger_test.cpp.o: In function `KisAsyncMergerTest::~KisAsyncMergerTest()': /home/jenkins/builds/calligra/kf5- qt5/krita/image/tests/kis_async_merger_test.h:24: undefined reference to `vtable for KisAsyncMergerTest' collect2: error: ld returned 1 exit status krita/image/tests/CMakeFiles/KisAsyncMergerTest.dir/build.make:89: recipe for target 'krita/image/tests/KisAsyncMergerTest' failed Give kis_async_merger_test.{h,cpp} a good look, but it seems fine, Q_OBJECT exists and whatever is needed that should trigger automoc (and does for all the other files around and with other cmake versions). Now in "krita/image/tests/CMakeLists.txt" change the target name "KisAsyncMergerTest" to e.g. "KisAsyncMergerTestA" and rerun the build. Suddenly automoc is run on "kis_async_merger_test.h"... only to fail on the next. Additional Information: See https://mail.kde.org/pipermail/kde-buildsystem/2015-June/010819.html for related short discussion. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-11 15:59 Friedrich New Issue ====================================================================== From petr.kmoch at gmail.com Mon Jul 13 03:37:18 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Mon, 13 Jul 2015 09:37:18 +0200 Subject: [cmake-developers] Wrapping functions in CMake In-Reply-To: References: Message-ID: On Thu, Jul 9, 2015 at 7:35 PM, Clifford Yapp wrote: > [...] > > 2. Second we maintain global lists of all exec, library, and custom > targets. This allows us to run timestamping build targets that run at > the very beginning and very end of the build process, by setting up > target dependences for the beginning and ending timestamp targets. > The ending time stamp target must depend on every other build target, > and the beginning timestamp is depended on by every other build > target. To do this, as far as I know, we need lists of all build > targets so we can set this up with the add_dependencies command. > In our project suite setup, we need a list of all existing targets as well. Having access to it from CMakeLists would be invaluable. Petr -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Mon Jul 13 04:38:03 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 13 Jul 2015 04:38:03 -0400 Subject: [cmake-developers] [CMake 0015648]: FindXercesC.cmake does not work on Windows Message-ID: <88447c41a6d23c78785a4733486062dc@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15648 ====================================================================== Reported By: Martin Baute Assigned To: ====================================================================== Project: CMake Issue ID: 15648 Category: Modules Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-13 04:38 EDT Last Modified: 2015-07-13 04:38 EDT ====================================================================== Summary: FindXercesC.cmake does not work on Windows Description: The FindXercesC module shipping with CMake is rather simple. It looks for the Xerces-C library using this line: find_library( XercesC_LIBRARY "xerces-c" DOC "Xerces-C++ libraries" ) This does not work on Windows -- here, the Xerces-C library is named xerces-c_3.lib (or ...-c_3D.lib for the debug build), making FindXercesC.cmake fail with "XercesC_LIBRARY-NOTFOUND". Suggested fix would be using this line: find_library( XercesC_LIBRARY NAMES xerces-c xerces-c_3 xerces-c_2 DOC "Xerces-C++ libraries" ) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-13 04:38 Martin Baute New Issue ====================================================================== From tim at klingt.org Mon Jul 13 05:38:06 2015 From: tim at klingt.org (Tim Blechmann) Date: Mon, 13 Jul 2015 18:38:06 +0900 Subject: [cmake-developers] Header-only library targets In-Reply-To: References: Message-ID: > I've recently switched from CMake 2.8.12 to 3.2, full of enthusiasm that > header-only libraries would now be better supported through the > INTERFACE option/target. However, the support for header-only libraries > isn't really great, in particular if you're using an IDE like Visual Studio. > > The main problem is that if you define an INTERFACE target, there's no > way to specify headers, and they won't show up in IDEs. There's > workarounds with a custom target, but that's not really great for > example to set dependencies, populate the include directory of the > library or to INSTALL the target. i'm sometimes using the workaround of generating a dummy cpp file and use a static library instead of an interface library ... ugly hack, but allows to populate msvc/xcode/qtcreator projects ... From mfilimonov at nvidia.com Mon Jul 13 12:44:46 2015 From: mfilimonov at nvidia.com (Mikhail Filimonov) Date: Mon, 13 Jul 2015 16:44:46 +0000 Subject: [cmake-developers] [PATCH] Extended Nsight Tegra support for CMake In-Reply-To: References: <559E8CE7.2070408@kitware.com> Message-ID: <1843116e4d0f41ef922563c26aea86fd@UKMAIL102.nvidia.com> I've improved the patch according to the Brad's and Dmitry's comments - namely: 1. Improved the documentation for a few target properties. 2. Removed the explicit toolchain file for Nsight Tegra generator test. 3. Improved the generator heuristics for NsightTegraProjectRevisionNumber attribute. Thanks, -Mikhail -----Original Message----- From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Mikhail Filimonov Sent: 9 ???? 2015 ?. 18:43 To: Brad King Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] [PATCH] Extended Nsight Tegra support for CMake Thanks for your feedback, Brad From: Brad King [mailto:brad.king at kitware.com] Sent: 9 ???? 2015 ?. 18:02 >We'd like to keep testing the default behavior without an explicit toolchain file. Also we need to be independent of the toolsets that happen to be available on the system where the test runs, so we >should avoid hard-coding a toolset name if possible. Is this part of the patch needed to test everything else? If so, please look at adding more test cases for the new combinations (which can just be >more builds of the same test source tree). That's more like a demonstration sample that will show the developers how the various Nsight Tegra project properties could be defined via the various CMake properties even if not directly related to Android - i.e. C_STANDARD and CMAKE_GENERATOR_TOOLSET Currently where's no samples directory in CMake source tree - so I've slightly reworked the existing test case. Maybe you could propose a better way to deliver that sample? Thanks, -Mikhail ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: ExtendedNsightTegraSupport2.patch Type: application/octet-stream Size: 35219 bytes Desc: ExtendedNsightTegraSupport2.patch URL: From dpolyanitsa at nvidia.com Mon Jul 13 12:47:24 2015 From: dpolyanitsa at nvidia.com (Dmitry Polyanitsa) Date: Mon, 13 Jul 2015 16:47:24 +0000 Subject: [cmake-developers] [PATCH] Extended Nsight Tegra support for CMake In-Reply-To: <1843116e4d0f41ef922563c26aea86fd@UKMAIL102.nvidia.com> References: <559E8CE7.2070408@kitware.com> <1843116e4d0f41ef922563c26aea86fd@UKMAIL102.nvidia.com> Message-ID: <4792ade676b64342a45644bddfa36123@UKMAIL102.nvidia.com> I've reviewed the patch and tried it locally - looks good. -Dmitry -----Original Message----- From: Mikhail Filimonov Sent: Monday, July 13, 2015 7:45 PM To: cmake-developers at cmake.org Subject: RE: [cmake-developers] [PATCH] Extended Nsight Tegra support for CMake I've improved the patch according to the Brad's and Dmitry's comments - namely: 1. Improved the documentation for a few target properties. 2. Removed the explicit toolchain file for Nsight Tegra generator test. 3. Improved the generator heuristics for NsightTegraProjectRevisionNumber attribute. Thanks, -Mikhail -----Original Message----- From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Mikhail Filimonov Sent: 9 ???? 2015 ?. 18:43 To: Brad King Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] [PATCH] Extended Nsight Tegra support for CMake Thanks for your feedback, Brad From: Brad King [mailto:brad.king at kitware.com] Sent: 9 ???? 2015 ?. 18:02 >We'd like to keep testing the default behavior without an explicit toolchain file. Also we need to be independent of the toolsets that happen to be available on the system where the test runs, so we >should avoid hard-coding a toolset name if possible. Is this part of the patch needed to test everything else? If so, please look at adding more test cases for the new combinations (which can just be >more builds of the same test source tree). That's more like a demonstration sample that will show the developers how the various Nsight Tegra project properties could be defined via the various CMake properties even if not directly related to Android - i.e. C_STANDARD and CMAKE_GENERATOR_TOOLSET Currently where's no samples directory in CMake source tree - so I've slightly reworked the existing test case. Maybe you could propose a better way to deliver that sample? Thanks, -Mikhail ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- From lanxingcan at gmail.com Mon Jul 13 13:19:33 2015 From: lanxingcan at gmail.com (=?gb2312?B?wLbQx7LT?=) Date: Tue, 14 Jul 2015 01:19:33 +0800 Subject: [cmake-developers] Header-only library targets In-Reply-To: References: Message-ID: Yeah, we all do such ugly hack for header project. However it's time to change this situation right? I think current version of interface library is already closed to what header library project wants, through maybe original design goal was not going to do so, but I couldn?t see any scene to use interface library except for header-only library target. Yes, I?m badly want this feature, because AFAK there doesn?t exist an open source, cross-platform build system yet to support header-only target in a graceful way. CMake already did many things right as a C/C++ build system, compared to many other ones, I hope Make could be the first one fulfill this. > ? 2015?7?13????5:38?Tim Blechmann ??? > >> I've recently switched from CMake 2.8.12 to 3.2, full of enthusiasm that >> header-only libraries would now be better supported through the >> INTERFACE option/target. However, the support for header-only libraries >> isn't really great, in particular if you're using an IDE like Visual Studio. >> >> The main problem is that if you define an INTERFACE target, there's no >> way to specify headers, and they won't show up in IDEs. There's >> workarounds with a custom target, but that's not really great for >> example to set dependencies, populate the include directory of the >> library or to INSTALL the target. > > i'm sometimes using the workaround of generating a dummy cpp file and > use a static library instead of an interface library ... ugly hack, but > allows to populate msvc/xcode/qtcreator projects ... > > From Robert.Goulet at autodesk.com Mon Jul 13 13:44:06 2015 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Mon, 13 Jul 2015 17:44:06 +0000 Subject: [cmake-developers] cmake.exe parameters and system command line length limit Message-ID: <6e59a5b8144d4b27b522c780c006e138@CO1PR79MB027.MGDADSK.autodesk.com> Hi all, We use a custom script to handle which parameters we set to cmake.exe on Windows. It sets CMake values based on the options provided to this script, using the -D cmake parameter. This works well, but recently we've reached the limit on how many characters we can set to a single system command line (cmd.exe), because our number of options is growing. Is there a work-around for this using CMake, or perhaps feed CMake parameters from a file rather than from command-line parameters? i.e. "cmake.exe < params.txt" ? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Mon Jul 13 13:56:09 2015 From: DLRdave at aol.com (David Cole) Date: Mon, 13 Jul 2015 13:56:09 -0400 Subject: [cmake-developers] cmake.exe parameters and system command line length limit In-Reply-To: <6e59a5b8144d4b27b522c780c006e138@CO1PR79MB027.MGDADSK.autodesk.com> References: <6e59a5b8144d4b27b522c780c006e138@CO1PR79MB027.MGDADSK.autodesk.com> Message-ID: You could use the -C command line option to pass in the name of a file containing initial cache values. See the "-C " section at the top of this documentation section: http://www.cmake.org/cmake/help/v3.3/manual/cmake.1.html#options The format of the file is just a bunch of set(... CACHE ...) commands. Read the doc paragraph carefully, and give it a try. Maybe somebody else can point to a valid example of a live -C file being used out there on the Internet. HTH, David C. On Mon, Jul 13, 2015 at 1:44 PM, Robert Goulet wrote: > Hi all, > > > > We use a custom script to handle which parameters we set to cmake.exe on > Windows. It sets CMake values based on the options provided to this script, > using the -D cmake parameter. This works well, but recently we?ve reached > the limit on how many characters we can set to a single system command line > (cmd.exe), because our number of options is growing. > > > > Is there a work-around for this using CMake, or perhaps feed CMake > parameters from a file rather than from command-line parameters? i.e. > ?cmake.exe < params.txt? ? > > > > Thanks! > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers From Robert.Goulet at autodesk.com Mon Jul 13 14:01:25 2015 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Mon, 13 Jul 2015 18:01:25 +0000 Subject: [cmake-developers] cmake.exe parameters and system command line length limit In-Reply-To: References: <6e59a5b8144d4b27b522c780c006e138@CO1PR79MB027.MGDADSK.autodesk.com> Message-ID: <0ba586a68ceb4469884fb90df344c48d@CO1PR79MB027.MGDADSK.autodesk.com> Hi David, That option looks interesting. How do we populate it with the other CMake cache values that are originally set by CMake and not by our command line options? Thanks. -----Original Message----- From: David Cole [mailto:DLRdave at aol.com] Sent: Monday, July 13, 2015 1:56 PM To: Robert Goulet Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] cmake.exe parameters and system command line length limit You could use the -C command line option to pass in the name of a file containing initial cache values. See the "-C " section at the top of this documentation section: http://www.cmake.org/cmake/help/v3.3/manual/cmake.1.html#options The format of the file is just a bunch of set(... CACHE ...) commands. Read the doc paragraph carefully, and give it a try. Maybe somebody else can point to a valid example of a live -C file being used out there on the Internet. HTH, David C. On Mon, Jul 13, 2015 at 1:44 PM, Robert Goulet wrote: > Hi all, > > > > We use a custom script to handle which parameters we set to cmake.exe > on Windows. It sets CMake values based on the options provided to this > script, using the -D cmake parameter. This works well, but recently > we?ve reached the limit on how many characters we can set to a single > system command line (cmd.exe), because our number of options is growing. > > > > Is there a work-around for this using CMake, or perhaps feed CMake > parameters from a file rather than from command-line parameters? i.e. > ?cmake.exe < params.txt? ? > > > > Thanks! > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For > more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers From DLRdave at aol.com Mon Jul 13 15:42:14 2015 From: DLRdave at aol.com (David Cole) Date: Mon, 13 Jul 2015 15:42:14 -0400 Subject: [cmake-developers] cmake.exe parameters and system command line length limit In-Reply-To: <0ba586a68ceb4469884fb90df344c48d@CO1PR79MB027.MGDADSK.autodesk.com> References: <6e59a5b8144d4b27b522c780c006e138@CO1PR79MB027.MGDADSK.autodesk.com> <0ba586a68ceb4469884fb90df344c48d@CO1PR79MB027.MGDADSK.autodesk.com> Message-ID: You don't. It's just another way to specify the command line arguments, but as a single command line argument instead of dozens or hundreds. It's a mechanism for you to avoid the command line length limit. Wasn't that your question...? On Mon, Jul 13, 2015 at 2:01 PM, Robert Goulet wrote: > Hi David, > > That option looks interesting. How do we populate it with the other CMake cache values that are originally set by CMake and not by our command line options? > > Thanks. > > -----Original Message----- > From: David Cole [mailto:DLRdave at aol.com] > Sent: Monday, July 13, 2015 1:56 PM > To: Robert Goulet > Cc: cmake-developers at cmake.org > Subject: Re: [cmake-developers] cmake.exe parameters and system command line length limit > > You could use the -C command line option to pass in the name of a file containing initial cache values. See the "-C " section at the top of this documentation section: > > http://www.cmake.org/cmake/help/v3.3/manual/cmake.1.html#options > > The format of the file is just a bunch of set(... CACHE ...) commands. > Read the doc paragraph carefully, and give it a try. Maybe somebody else can point to a valid example of a live -C file being used out there on the Internet. > > > HTH, > David C. > > > > On Mon, Jul 13, 2015 at 1:44 PM, Robert Goulet wrote: >> Hi all, >> >> >> >> We use a custom script to handle which parameters we set to cmake.exe >> on Windows. It sets CMake values based on the options provided to this >> script, using the -D cmake parameter. This works well, but recently >> we?ve reached the limit on how many characters we can set to a single >> system command line (cmd.exe), because our number of options is growing. >> >> >> >> Is there a work-around for this using CMake, or perhaps feed CMake >> parameters from a file rather than from command-line parameters? i.e. >> ?cmake.exe < params.txt? ? >> >> >> >> Thanks! >> >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For >> more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake-developers From robert.maynard at kitware.com Mon Jul 13 16:18:15 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 13 Jul 2015 16:18:15 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.3.0-rc4 is now ready! Message-ID: I am proud to announce the fourth CMake 3.3 release candidate. Sources and binaries are available at: http://www.cmake.org/download/ Documentation is available at: http://www.cmake.org/cmake/help/v3.3 Release notes appear below and are also published at http://www.cmake.org/cmake/help/v3.3/release/3.3.html Some of the more significant features of CMake 3.3 are: * The "if()" command learned a new "IN_LIST" operator that evaluates to true if a given element is contained in a named list. * The "add_dependencies()" command learned to allow dependencies to be added to *interface libraries*. Dependencies added to an interface library are followed transitively in its place since the target itself does not build. * The "find_library()", "find_path()", and "find_file()" commands now search in installation prefixes derived from the "PATH" environment variable. * The "_VISIBILITY_PRESET" and "VISIBILITY_INLINES_HIDDEN" target properties now affect compilation in sources of all target types. See policy "CMP0063". * A "_INCLUDE_WHAT_YOU_USE" target property and supporting "CMAKE__INCLUDE_WHAT_YOU_USE" variable were introduced to tell the *Makefile Generators* and the "Ninja" generator to run "include- what-you-use" along with the compiler for "C" and "CXX" languages. Deprecated and Removed Features: * The "ctest_build()" and "build_command()" commands no longer tell "make" tools to ignore errors with the "-i" option. Previously this was done for *Makefile Generators* but not others. See policy "CMP0061". * The "Visual Studio 7" generator (.NET 2002) is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 6" generator is now deprecated and will be removed in a future version of CMake. * The "add_definitions()" command no longer causes a "DEFINITIONS" directory property to be populated. See policy "CMP0059". CMake 3.3 Release Notes *********************** Changes made since CMake 3.2 include the following. New Features ============ Generators ---------- * The *Makefile Generators* now add ".DELETE_ON_ERROR" to the makefiles that contain the actual build rules for files on disk. This tells GNU make to remove rule outputs when their recipe modifies an output but fails. * The *Visual Studio Generators* learned to support ".xaml" source files and automatically associate them with corresponding ".h" and ".cpp" sources. * A new experimental "Green Hills MULTI" generator was added on Windows. Green Hills MULTI is an IDE for embedded real-time systems. Commands -------- * The "add_dependencies()" command learned to allow dependencies to be added to *interface libraries*. Dependencies added to an interface library are followed transitively in its place since the target itself does not build. * The "execute_process()" command learned to support specifying the same file for "OUTPUT_FILE" and "ERROR_FILE". * The "file(GLOB)" and "file(GLOB_RECURSE)" commands learned a new "LIST_DIRECTORIES " option to specify whether the glob result should include directories. * The "find_library()", "find_path()", and "find_file()" commands now search in installation prefixes derived from the "PATH" environment variable. * The "if()" command learned a new "IN_LIST" operator that evaluates to true if a given element is contained in a named list. * The "install(EXPORT)" and "export()" commands learned to export targets that populate the "INTERFACE_SOURCES" target property. * The "install(TARGETS)" command learned to support generator expressions in the "DESTINATION" value. Variables --------- * The version of some Fortran compilers is now detected and stored in the "CMAKE_Fortran_COMPILER_VERSION" variable. * The *Visual Studio Generators* learned a new "CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD" option to put the "INSTALL" target in the default build of a solution (".sln") file. Properties ---------- * A "CROSSCOMPILING_EMULATOR" target property and supporting "CMAKE_CROSSCOMPILING_EMULATOR" variable were introduced to allow target platform binaries to run on the host during cross compiling. * A "_INCLUDE_WHAT_YOU_USE" target property and supporting "CMAKE__INCLUDE_WHAT_YOU_USE" variable were introduced to tell the *Makefile Generators* and the "Ninja" generator to run "include- what-you-use" along with the compiler for "C" and "CXX" languages. * The "_VISIBILITY_PRESET" and "VISIBILITY_INLINES_HIDDEN" target properties now affect compilation in sources of all target types. See policy "CMP0063". * The "XCODE_ATTRIBUTE_" target property learned to support generator expressions. Modules ------- * The "CheckFortranCompilerFlag" module was introduced to check "Fortran" compiler flags, much like the "CheckCCompilerFlag" module already does for "C". * The "ExternalData" module learned a new "ExternalData_NO_SYMLINKS" option to disable use of symbolic links to populate the real data files and use copies instead. * The "ExternalData" module learned a new "RECURSE:" option in "DATA{}" references specifying directories. This allows an entire directory tree of associated files to be matched. * The "ExternalData" module learned a new URL template placeholder "%(algo:)" to allow custom mapping from algorithm name to URL component through configuration of new "ExternalData_URL_ALGO__" variables. This allows more flexibility in remote URLs. * The "ExternalProject" module learned to replace tokens like "" in the "BYPRODUCTS" of each step. * The "ExternalProject" module APIs learned to support "generator expressions" when using "LOG_*" options and in CMake initial cache options. * The "FindBoost" module now tracks the directories containing libraries separately for RELEASE and DEBUG configurations. * The "FindCUDA" module now defaults to using the static CUDA runtime library if it is available. A new "CUDA_USE_STATIC_CUDA_RUNTIME" option is offered to control this behavior. * The "FindMatlab" module was completely rewritten. It learned about versions and components and to find Matlab in a more precise and multiplatform way. The module now offers APIs to create mex extensions, documentation, and unit tests. * The "FindPackageHandleStandardArgs" module "FIND_PACKAGE_HANDLE_STANDARD_ARGS" function now always populates both the "_FOUND" and "_FOUND" variables (the latter for backwards compatibility). The "FOUND_VAR" option is now ignored except to enforce its allowed values. * The "InstallRequiredSystemLibraries" module learned a new "CMAKE_INSTALL_SYSTEM_RUNTIME_COMPONENT" option to specify the installation component. Generator Expressions --------------------- * A new "COMPILE_LANGUAGE" generator expression was introduced to allow specification of compile options for target files based on the "LANGUAGE" of each source file. Due to limitations of the underlying native build tools, this feature has varying support across generators. See the "cmake-generator-expressions(7)" manual for details. CTest ----- * The "ctest(1)" tool learned a new "--repeat-until-fail " option to help find sporadic test failures. * The "CTestCoverageCollectGCOV" module learned to support the same "CTEST_CUSTOM_COVERAGE_EXCLUDE" option as the "ctest_coverage()" command. CPack ----- * The "cpack(1)" "IFW" generator and the "CPackIFW" module learned to support Qt Framework Installer 2.0 tools. * The "CPackDeb" module learned a new "CPACK_DEBIAN__PACKAGE_SHLIBDEPS" variable to specify per-component use of "dpkg-shlibdeps". * The "CPackDeb" module learned a new "CPACK_DEBIAN__PACKAGE_DEPENDS" option to specify per- component dependencies. * The "CPackRPM" module learned to package symbolic links more cleanly and now supports directory symlinks with recent "rpmbuild" versions. * The "CPackRPM" module learned a new "CPACK_RPM_ADDITIONAL_MAN_DIRS" variable to specify directories containing man pages for the brp- compress RPM macro. * The "CPackRPM" module learned a new "CPACK_RPM__PACKAGE_ARCHITECTURE" variable to specify a component-specific package architecture. * The CPack WIX generator learned the new "CPACK_START_MENU_SHORTCUTS", "CPACK_DESKTOP_SHORTCUTS" and "CPACK_STARTUP_SHORTCUTS" installed file properties which can be used to install shorcuts in the Start Menu, on the Desktop and in the Startup Folder respectively. Other ----- * The "Compile Features" functionality is now aware of features supported by GNU compilers on Windows, versions 4.4 through 5.0. * The "cmake(1)" "-E tar" command learned a new "--format" option to specify the archive format to be written. * On OS X, CMake learned to create XCTest bundles to test Frameworks and App Bundles within Xcode. The "FindXCTest" module provides convenience functions to handle "XCTEST" bundles. Deprecated and Removed Features =============================== * On OS X the "cmake-gui(1)" no longer has the "Install For Command Line Use" menu item. Instead there is a "How to Install For Command Line Use" menu item that shows an informational dialog box explaining how to make the command line tools available. For example: /Applications/CMake.app/Contents/bin/cmake-gui --install * The "ctest_build()" and "build_command()" commands no longer tell "make" tools to ignore errors with the "-i" option. Previously this was done for *Makefile Generators* but not others. See policy "CMP0061". * The "Visual Studio 10 2010" generator no longer checks for running VS IDEs with the project open or asks them to reload. This was originally done for VS 10 because it had been done for VS 7 through 9 to avoid prompting for every project in a solution. Since VS >= 10 allow the whole solution to reload at once they do not need CMake to help them. * The "Visual Studio 7" generator (.NET 2002) is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 6" generator is now deprecated and will be removed in a future version of CMake. * The "find_package()" command no longer considers project build trees recently configured in a "cmake-gui(1)". This was previously done only on Windows and is now never done. The "NO_CMAKE_BUILDS_PATH" option is now ignored if given and effectively always on. Projects may populate the *User Package Registry* to aid users building multiple dependent projects one after another. * The "add_definitions()" command no longer causes a "DEFINITIONS" directory property to be populated. See policy "CMP0059". * With Visual Studio 7, 8, and 9 generators the value of the "$(OutDir)" placeholder no longer evaluates to the configuration name. Projects should use "$(ConfigurationName)" for that instead. * Using the output of "export()" with the "install(FILES)" command is no longer allowed. See policy "CMP0062" for details. Other Changes ============= * The "Ninja" generator now requires that calls to the "add_custom_command()" and "add_custom_target()" commands use the "BYPRODUCTS" option to explicitly specify any files generated by the custom commands that are not listed as outputs (perhaps because their timestamps are allowed to be older than the inputs). See policy "CMP0058". * Build-time progress output of *Makefile Generators* has been improved. It no longer mixes progress and build rule messages during parallel builds. The link rule messages now have progress and are displayed as bold green instead of bold red (since red is often associated with an error message). * The "CMAKE_CFG_INTDIR" variable value for Visual Studio 7, 8, and 9 is now "$(ConfigurationName)" instead of "$(OutDir)". This should have no effect on the intended use cases of the variable. * Linking to library files by a full path in an implicit linker search directory (e.g. "/usr/lib/libfoo.a") no longer asks the linker to search for the library (e.g. "-lfoo") and now links by full path. See policy "CMP0060". ------------------------------------------------------------------- Changes made since CMake 3.3.0-rc3: Brad King (4): Fortran: Fix passing of preprocessor definitions to dependency scanner Check*CompilerFlag: Revert to previous method used to pass flags (#15641) set_property: Fix crash when setting LINK_LIBRARIES to nothing CMake 3.3.0-rc4 Konstantin Podsvirov (1): CPackIFW: Load module to set CPACK_IFW_FRAMEWORK_VERSION Sean Brennan (1): FindMPI: Extend Intel-MPI 5+ workaround for recent GCCs Stephen Kelly (1): cmState: Restore renamed commands on cleanup. Tamas Kenez (1): FindMatlab: Fix documentation section header underline style ------------------------------------------------------------------- From raffi.enficiaud at mines-paris.org Mon Jul 13 18:43:19 2015 From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud) Date: Tue, 14 Jul 2015 00:43:19 +0200 Subject: [cmake-developers] OSX - Application bundle and private frameworks? Message-ID: Hi, I am trying to copy a private framework into an application bundle: - I can find the frameworks properly with the "find_library", - I put those frameworks in the add_executable command add_executable( xxxx MACOSX_BUNDLE ### source files ... ### frameworks ${sbigudFramework} ${fcCamFramework} ) target_link_libraries(xxxx [...] ${sbigudFramework} ${fcCamFramework}) - and I specify the location of those frameworks within the application bundle: set_source_files_properties(${fcCamFramework} PROPERTIES MACOSX_PACKAGE_LOCATION Frameworks) set_source_files_properties(${sbigudFramework} PROPERTIES MACOSX_PACKAGE_LOCATION Frameworks) The problem is the following: - Everything works fine with XCode, I have the full content of the frameworks at the specified location - When I use the Makefile generator, I have only one file per framework instead of the directory and the framework content: > ls -al xxxx.app/Contents/Frameworks/ total 0 drwxr-xr-x 4 raffi staff 136 Jul 14 00:26 . drwxr-xr-x 6 raffi staff 204 Jul 14 00:08 .. -rwxr-xr-x 1 raffi staff 0 Jul 14 00:26 SBIGUDrv.framework -rwxr-xr-x 1 raffi staff 0 Jul 14 00:26 fcCamFw.framework Am I doing something wrong? I am using cmake 3.0.2 & 3.2.3 / OSX 10.10. Best, Raffi From cliffyapp at gmail.com Mon Jul 13 23:53:11 2015 From: cliffyapp at gmail.com (Clifford Yapp) Date: Mon, 13 Jul 2015 23:53:11 -0400 Subject: [cmake-developers] [CMake] Problem with CMake 3.3.0-rc3 In-Reply-To: References: <559AA461.5070104@kitware.com> <559EC058.6000209@kitware.com> Message-ID: On Sat, Jul 11, 2015 at 5:07 AM, Stephen Kelly wrote: > Brad King wrote: > >> Steve, please take a look. It looks like the cmState methods >> RemoveUserDefinedCommands and RenameCommand need to work better >> together. This needs to be fixed for 3.3. > > Fixed with > > http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f2ee169d > cmState: Restore renamed commands on cleanup Confirmed in rc4 - thanks! CY From mantis at public.kitware.com Tue Jul 14 03:24:38 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 14 Jul 2015 03:24:38 -0400 Subject: [cmake-developers] [CMake 0015649]: Add "cmake -E date [format] [UTC]" command to output the current date in the same way STRING(TIMESTAMP [format] [UTC]) does. Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15649 ====================================================================== Reported By: dbanet Assigned To: ====================================================================== Project: CMake Issue ID: 15649 Category: CMake Reproducibility: N/A Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-14 03:24 EDT Last Modified: 2015-07-14 03:24 EDT ====================================================================== Summary: Add "cmake -E date [format] [UTC]" command to output the current date in the same way STRING(TIMESTAMP [format] [UTC]) does. Description: It would be extremely useful to have a cross-platform way to obtain the date just like with STRING(TIMESTAMP [format] [UTC]) in CMake command mode. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-14 03:24 dbanet New Issue ====================================================================== From mantis at public.kitware.com Tue Jul 14 07:07:22 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 14 Jul 2015 07:07:22 -0400 Subject: [cmake-developers] [CMake 0015650]: Linking large files on OS X can result in linker failing with "command line too long" error Message-ID: <342fec430bed4ef03a6368fc8908df47@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15650 ====================================================================== Reported By: Abigail Assigned To: ====================================================================== Project: CMake Issue ID: 15650 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-14 07:07 EDT Last Modified: 2015-07-14 07:07 EDT ====================================================================== Summary: Linking large files on OS X can result in linker failing with "command line too long" error Description: When a project contains sufficiently many source files - the one I'm compiling has 1689 .cpp files - the linker will fail, with the message "Error running link command: Argument list too long". When using response lists (via set(CMAKE_CXX_USE_RESPONSE_FILE_FOR_OBJECTS 1)), the issue still occurs. This is because the response file is specified as a linker flag with @ResponseFile.rsp syntax, which is expanded by the compiler driver rather than being passed through and then expanded internally by the linker. OS X's linker, ld64, doesn't support the @ResponseFile.rsp syntax, so it's not possible to work around this with set(CMAKE_CXX_RESPONSE_FILE_LINK_FLAG "-Wl,@"). However, it does support -filelist, but this requires the file to be newline-separated rather than space-separated. Steps to Reproduce: In an empty directory: for i in {0000..9999}; echo "void f$i() {}" >> $i.c find . > files.txt cat << EOF > CMakeLists.txt cmake_minimum_required(VERSION 2.8) project(long_file_test) file(STRINGS "files.txt" files) add_executable(long_file_test ${files}) EOF cmake . && cmake --build . -- -j 24 ...This will compile everything correctly, and then at the end emit: [100%] Linking C executable long_file_test Error running link command: Argument list too long make[2]: *** [long_file_test] Error 2 make[1]: *** [CMakeFiles/long_file_test.dir/all] Error 2 make: *** [all] Error 2 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-14 07:07 Abigail New Issue ====================================================================== From mantis at public.kitware.com Tue Jul 14 07:22:27 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 14 Jul 2015 07:22:27 -0400 Subject: [cmake-developers] [CMake 0015651]: Missing information in documentation about creation OS X/iOS Frameworks Message-ID: <3bca6f77c4d0e1443187aa9645a5c677@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15651 ====================================================================== Reported By: gang65 Assigned To: ====================================================================== Project: CMake Issue ID: 15651 Category: Documentation Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-14 07:22 EDT Last Modified: 2015-07-14 07:22 EDT ====================================================================== Summary: Missing information in documentation about creation OS X/iOS Frameworks Description: The Cmake documentation is not updated with information about how to create OS X Frameworks: http://www.cmake.org/cmake/help/v3.2/command/set_target_properties.html More information about Frameworks: https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkAnatomy.html#//apple_ref/doc/uid/20002253-BAJEJJAB It is possible to create OS X and iOS Framework with following CMake code: set_target_properties(ReflectionIOS PROPERTIES OUTPUT_NAME Reflection FRAMEWORK TRUE FRAMEWORK_VERSION A PUBLIC_HEADER REFLECTION_INCLUDE_FILES ) Could you please update documentation: http://www.cmake.org/cmake/help/v3.2/command/set_target_properties.html Thanks. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-14 07:22 gang65 New Issue ====================================================================== From Robert.Goulet at autodesk.com Tue Jul 14 09:34:57 2015 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Tue, 14 Jul 2015 13:34:57 +0000 Subject: [cmake-developers] cmake.exe parameters and system command line length limit In-Reply-To: References: <6e59a5b8144d4b27b522c780c006e138@CO1PR79MB027.MGDADSK.autodesk.com> <0ba586a68ceb4469884fb90df344c48d@CO1PR79MB027.MGDADSK.autodesk.com> Message-ID: <935c1e7919d7400faab8a025c61c8017@CO1PR79MB027.MGDADSK.autodesk.com> Ah ok this means the -C option is in addition to the cmake cache, and not replace it? -----Original Message----- From: David Cole [mailto:DLRdave at aol.com] Sent: Monday, July 13, 2015 3:42 PM To: Robert Goulet Cc: David Cole; cmake-developers at cmake.org Subject: Re: [cmake-developers] cmake.exe parameters and system command line length limit You don't. It's just another way to specify the command line arguments, but as a single command line argument instead of dozens or hundreds. It's a mechanism for you to avoid the command line length limit. Wasn't that your question...? On Mon, Jul 13, 2015 at 2:01 PM, Robert Goulet wrote: > Hi David, > > That option looks interesting. How do we populate it with the other CMake cache values that are originally set by CMake and not by our command line options? > > Thanks. > > -----Original Message----- > From: David Cole [mailto:DLRdave at aol.com] > Sent: Monday, July 13, 2015 1:56 PM > To: Robert Goulet > Cc: cmake-developers at cmake.org > Subject: Re: [cmake-developers] cmake.exe parameters and system > command line length limit > > You could use the -C command line option to pass in the name of a file containing initial cache values. See the "-C " section at the top of this documentation section: > > http://www.cmake.org/cmake/help/v3.3/manual/cmake.1.html#options > > The format of the file is just a bunch of set(... CACHE ...) commands. > Read the doc paragraph carefully, and give it a try. Maybe somebody else can point to a valid example of a live -C file being used out there on the Internet. > > > HTH, > David C. > > > > On Mon, Jul 13, 2015 at 1:44 PM, Robert Goulet wrote: >> Hi all, >> >> >> >> We use a custom script to handle which parameters we set to cmake.exe >> on Windows. It sets CMake values based on the options provided to >> this script, using the -D cmake parameter. This works well, but >> recently we?ve reached the limit on how many characters we can set to >> a single system command line (cmd.exe), because our number of options is growing. >> >> >> >> Is there a work-around for this using CMake, or perhaps feed CMake >> parameters from a file rather than from command-line parameters? i.e. >> ?cmake.exe < params.txt? ? >> >> >> >> Thanks! >> >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For >> more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake-developers From Robert.Goulet at autodesk.com Tue Jul 14 10:53:40 2015 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Tue, 14 Jul 2015 14:53:40 +0000 Subject: [cmake-developers] Generator expressions for output directory Message-ID: <3fc3c649d1554819b46dc06f738fff9c@CO1PR79MB027.MGDADSK.autodesk.com> Greetings! Patch in attachment for all OUTPUT_DIRECTORY variants to support generator expressions. Thanks! -Robert Goulet -------------- next part -------------- A non-text attachment was scrubbed... Name: output-dir-genex.patch Type: application/octet-stream Size: 9408 bytes Desc: output-dir-genex.patch URL: From DLRdave at aol.com Tue Jul 14 11:25:44 2015 From: DLRdave at aol.com (David Cole) Date: Tue, 14 Jul 2015 11:25:44 -0400 Subject: [cmake-developers] cmake.exe parameters and system command line length limit In-Reply-To: <935c1e7919d7400faab8a025c61c8017@CO1PR79MB027.MGDADSK.autodesk.com> References: <6e59a5b8144d4b27b522c780c006e138@CO1PR79MB027.MGDADSK.autodesk.com> <0ba586a68ceb4469884fb90df344c48d@CO1PR79MB027.MGDADSK.autodesk.com> <935c1e7919d7400faab8a025c61c8017@CO1PR79MB027.MGDADSK.autodesk.com> Message-ID: Correct -- it's typically used as an **initial** cache only, in a clean build tree. Actually, I'm not sure what happens on subsequent (2nd and later) runs... It may be that the cache has precedence, and the -C file has no effect on subsequent runs unless you use "FORCE" in it... But I'm uncertain. I'd have to do some code analysis or experimentation to figure it out. D On Tue, Jul 14, 2015 at 9:34 AM, Robert Goulet wrote: > Ah ok this means the -C option is in addition to the cmake cache, and not replace it? > > -----Original Message----- > From: David Cole [mailto:DLRdave at aol.com] > Sent: Monday, July 13, 2015 3:42 PM > To: Robert Goulet > Cc: David Cole; cmake-developers at cmake.org > Subject: Re: [cmake-developers] cmake.exe parameters and system command line length limit > > You don't. It's just another way to specify the command line arguments, but as a single command line argument instead of dozens or hundreds. > > It's a mechanism for you to avoid the command line length limit. > Wasn't that your question...? > > > On Mon, Jul 13, 2015 at 2:01 PM, Robert Goulet wrote: >> Hi David, >> >> That option looks interesting. How do we populate it with the other CMake cache values that are originally set by CMake and not by our command line options? >> >> Thanks. >> >> -----Original Message----- >> From: David Cole [mailto:DLRdave at aol.com] >> Sent: Monday, July 13, 2015 1:56 PM >> To: Robert Goulet >> Cc: cmake-developers at cmake.org >> Subject: Re: [cmake-developers] cmake.exe parameters and system >> command line length limit >> >> You could use the -C command line option to pass in the name of a file containing initial cache values. See the "-C " section at the top of this documentation section: >> >> http://www.cmake.org/cmake/help/v3.3/manual/cmake.1.html#options >> >> The format of the file is just a bunch of set(... CACHE ...) commands. >> Read the doc paragraph carefully, and give it a try. Maybe somebody else can point to a valid example of a live -C file being used out there on the Internet. >> >> >> HTH, >> David C. >> >> >> >> On Mon, Jul 13, 2015 at 1:44 PM, Robert Goulet wrote: >>> Hi all, >>> >>> >>> >>> We use a custom script to handle which parameters we set to cmake.exe >>> on Windows. It sets CMake values based on the options provided to >>> this script, using the -D cmake parameter. This works well, but >>> recently we?ve reached the limit on how many characters we can set to >>> a single system command line (cmd.exe), because our number of options is growing. >>> >>> >>> >>> Is there a work-around for this using CMake, or perhaps feed CMake >>> parameters from a file rather than from command-line parameters? i.e. >>> ?cmake.exe < params.txt? ? >>> >>> >>> >>> Thanks! >>> >>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For >>> more information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake-developers From s.kabaivanov at euros-embedded.com Tue Jul 14 11:52:29 2015 From: s.kabaivanov at euros-embedded.com (Stanimir Kabaivanov) Date: Tue, 14 Jul 2015 18:52:29 +0300 Subject: [cmake-developers] Suggestion to add EUROS RTOS platform description Message-ID: <55A5303D.7000109@euros-embedded.com> Hello CMake-developers, I would like to contribute with EUROS RTOS platform description file that would allow us to build EUROS RTOS projects with CMake. Best regards, Stanimir Kabaivanov -------------- next part -------------- # CMake Platform File for EUROS RTOS Libraries # # Author: Stanimir Kabaivanov # Gerhard Gappmeier # # Guard against multiple inclusion, which e.g. leads to multiple calls to add_definition() #12987 if(__EUROS_CMAKE_INCLUDED) return() endif() set(__EUROS_CMAKE_INCLUDED TRUE) set(CMAKE_LINK_LIBRARY_SUFFIX "") set(CMAKE_STATIC_LIBRARY_PREFIX "") set(CMAKE_STATIC_LIBRARY_SUFFIX ".lib") set(CMAKE_SHARED_LIBRARY_PREFIX "") set(CMAKE_SHARED_LIBRARY_SUFFIX ".lib") set(CMAKE_EXECUTABLE_SUFFIX ".elf") set(CMAKE_DL_LIBS "") set(CMAKE_FIND_LIBRARY_PREFIXES "") set(CMAKE_FIND_LIBRARY_SUFFIXES ".lib") # (embedded) targets without operating system usually don't support shared libraries set_property(GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS FALSE) set(CMAKE_CXX_LINK_SHARED_LIBRARY ) set(CMAKE_CXX_LINK_MODULE_LIBRARY ) set(CMAKE_C_LINK_SHARED_LIBRARY ) set(CMAKE_C_LINK_MODULE_LIBRARY ) From Robert.Goulet at autodesk.com Tue Jul 14 13:21:47 2015 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Tue, 14 Jul 2015 17:21:47 +0000 Subject: [cmake-developers] cmake.exe parameters and system command line length limit In-Reply-To: References: <6e59a5b8144d4b27b522c780c006e138@CO1PR79MB027.MGDADSK.autodesk.com> <0ba586a68ceb4469884fb90df344c48d@CO1PR79MB027.MGDADSK.autodesk.com> <935c1e7919d7400faab8a025c61c8017@CO1PR79MB027.MGDADSK.autodesk.com> Message-ID: I just tested, and you were right on everything you said. The CMake cache gets populated on the first run in the clean build tree. However, if we use the set FORCE option in the initial cache file, we can work-around this limitation and force it to always write to the CMake cache, which works fine for us in this setup. That's great, it fixed our command line length limit issue! Thanks a lot! -----Original Message----- From: David Cole [mailto:DLRdave at aol.com] Sent: Tuesday, July 14, 2015 11:26 AM To: Robert Goulet Cc: David Cole; cmake-developers at cmake.org Subject: Re: [cmake-developers] cmake.exe parameters and system command line length limit Correct -- it's typically used as an **initial** cache only, in a clean build tree. Actually, I'm not sure what happens on subsequent (2nd and later) runs... It may be that the cache has precedence, and the -C file has no effect on subsequent runs unless you use "FORCE" in it... But I'm uncertain. I'd have to do some code analysis or experimentation to figure it out. D On Tue, Jul 14, 2015 at 9:34 AM, Robert Goulet wrote: > Ah ok this means the -C option is in addition to the cmake cache, and not replace it? > > -----Original Message----- > From: David Cole [mailto:DLRdave at aol.com] > Sent: Monday, July 13, 2015 3:42 PM > To: Robert Goulet > Cc: David Cole; cmake-developers at cmake.org > Subject: Re: [cmake-developers] cmake.exe parameters and system > command line length limit > > You don't. It's just another way to specify the command line arguments, but as a single command line argument instead of dozens or hundreds. > > It's a mechanism for you to avoid the command line length limit. > Wasn't that your question...? > > > On Mon, Jul 13, 2015 at 2:01 PM, Robert Goulet wrote: >> Hi David, >> >> That option looks interesting. How do we populate it with the other CMake cache values that are originally set by CMake and not by our command line options? >> >> Thanks. >> >> -----Original Message----- >> From: David Cole [mailto:DLRdave at aol.com] >> Sent: Monday, July 13, 2015 1:56 PM >> To: Robert Goulet >> Cc: cmake-developers at cmake.org >> Subject: Re: [cmake-developers] cmake.exe parameters and system >> command line length limit >> >> You could use the -C command line option to pass in the name of a file containing initial cache values. See the "-C " section at the top of this documentation section: >> >> http://www.cmake.org/cmake/help/v3.3/manual/cmake.1.html#options >> >> The format of the file is just a bunch of set(... CACHE ...) commands. >> Read the doc paragraph carefully, and give it a try. Maybe somebody else can point to a valid example of a live -C file being used out there on the Internet. >> >> >> HTH, >> David C. >> >> >> >> On Mon, Jul 13, 2015 at 1:44 PM, Robert Goulet wrote: >>> Hi all, >>> >>> >>> >>> We use a custom script to handle which parameters we set to >>> cmake.exe on Windows. It sets CMake values based on the options >>> provided to this script, using the -D cmake parameter. This works >>> well, but recently we?ve reached the limit on how many characters we >>> can set to a single system command line (cmd.exe), because our number of options is growing. >>> >>> >>> >>> Is there a work-around for this using CMake, or perhaps feed CMake >>> parameters from a file rather than from command-line parameters? i.e. >>> ?cmake.exe < params.txt? ? >>> >>> >>> >>> Thanks! >>> >>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For >>> more information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake-developers From ewmailing at gmail.com Wed Jul 15 06:16:08 2015 From: ewmailing at gmail.com (Eric Wing) Date: Wed, 15 Jul 2015 03:16:08 -0700 Subject: [cmake-developers] Adding Swift support to CMake In-Reply-To: <559BDAE5.9010505@kitware.com> References: <55842C6C.4050504@kitware.com> <559191D6.5080403@kitware.com> <559BDAE5.9010505@kitware.com> Message-ID: On 7/7/15, Brad King wrote: > On 07/02/2015 07:54 PM, Eric Wing wrote: >> Thank you Brad. When you are ready, let me know how I can help next. > > I have basic support with the Xcode generator done. > > Please try out this commit: > > Add rudimentary support for the Apple Swift language with Xcode > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bf112531 > > Thanks, > -Brad > > Hi Brad, I just tried out the July 15th nightly build and it looks like it is working (Xcode generator). I got a little fancy and did an intermixed C/Swift test. I have a simple SDL (C) based program with Swift bindings and I'm able to build/run it and step the Xcode debugger through the Swift parts. Cosmetically, the Swift files are not being grouped with the other C/Obj-C files in the "Source Files" group. But that is a pretty minor thing. (There are other things more important to me I would like to see fixed in the Xcode generator first :)) So is the next step the Makefile generator? Thanks, Eric From mantis at public.kitware.com Wed Jul 15 08:28:05 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 15 Jul 2015 08:28:05 -0400 Subject: [cmake-developers] [CMake 0015652]: get_target_property() called with non-existent target "boost_chrono-mt-shared" Message-ID: <872c68ab3db58a16d370acfa4c501801@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15652 ====================================================================== Reported By: Mathieu Malaterre Assigned To: ====================================================================== Project: CMake Issue ID: 15652 Category: CMake Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-15 08:28 EDT Last Modified: 2015-07-15 08:28 EDT ====================================================================== Summary: get_target_property() called with non-existent target "boost_chrono-mt-shared" Description: I cannot use FindBoost.cmake on CentOS6 (boost 1.41), it fails with: CMake Error at /usr/lib64/boost/BoostConfig.cmake:64 (get_target_property): get_target_property() called with non-existent target "boost_chrono-mt-shared". Call Stack (most recent call first): /opt/tools/cmake-3.0.1/share/cmake-3.0/Modules/FindBoost.cmake:206 (find_package) CMakeLists.txt:33 (find_package) CMake Error at /usr/lib64/boost/BoostConfig.cmake:72 (get_target_property): get_target_property() called with non-existent target "boost_chrono-mt-shared-debug". Call Stack (most recent call first): /opt/tools/cmake-3.0.1/share/cmake-3.0/Modules/FindBoost.cmake:206 (find_package) CMakeLists.txt:33 (find_package) Boost 1.41 found. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-15 08:28 Mathieu MalaterreNew Issue ====================================================================== From mantis at public.kitware.com Wed Jul 15 08:30:39 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 15 Jul 2015 08:30:39 -0400 Subject: [cmake-developers] [CMake 0015652]: get_target_property() called with non-existent target "boost_chrono-mt-shared" In-Reply-To: <872c68ab3db58a16d370acfa4c501801@www.cmake.org> Message-ID: <054f89d2d1161274b0681d39987bc5e1@www.cmake.org> The following issue has been DELETED. ====================================================================== Reported By: Mathieu Malaterre Assigned To: ====================================================================== Project: CMake Issue ID: 15652 Category: CMake Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-15 08:28 EDT Last Modified: 2015-07-15 08:28 EDT ====================================================================== Summary: get_target_property() called with non-existent target "boost_chrono-mt-shared" Description: I cannot use FindBoost.cmake on CentOS6 (boost 1.41), it fails with: CMake Error at /usr/lib64/boost/BoostConfig.cmake:64 (get_target_property): get_target_property() called with non-existent target "boost_chrono-mt-shared". Call Stack (most recent call first): /opt/tools/cmake-3.0.1/share/cmake-3.0/Modules/FindBoost.cmake:206 (find_package) CMakeLists.txt:33 (find_package) CMake Error at /usr/lib64/boost/BoostConfig.cmake:72 (get_target_property): get_target_property() called with non-existent target "boost_chrono-mt-shared-debug". Call Stack (most recent call first): /opt/tools/cmake-3.0.1/share/cmake-3.0/Modules/FindBoost.cmake:206 (find_package) CMakeLists.txt:33 (find_package) Boost 1.41 found. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-15 08:28 Mathieu MalaterreNew Issue 2015-07-15 08:30 Mathieu MalaterreIssue Deleted: 0015652 ====================================================================== From brad.king at kitware.com Wed Jul 15 09:10:01 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 15 Jul 2015 09:10:01 -0400 Subject: [cmake-developers] [Patch] Added property to disable the "Built target" progress messages in Makefile targets In-Reply-To: <55A01AA0.3090809@ensslin.cc> References: <55A01AA0.3090809@ensslin.cc> Message-ID: <55A65BA9.7030701@kitware.com> On 07/10/2015 03:18 PM, Michael En?lin wrote: > The patch adds a global property, "TARGET_MESSAGES", which behaves > analogous to "RULE_MESSAGES" in that it can be explicitly set to OFF to > suppress some build output. Thanks! I've applied it with minor tweaks: Makefile: Optionally disable target completion messages in build output http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1d398478 I also added test cases: Tests: Add test for TARGET_MESSAGES global property http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f0cad193 -Brad From brad.king at kitware.com Wed Jul 15 09:10:11 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 15 Jul 2015 09:10:11 -0400 Subject: [cmake-developers] [PATCH] Extended Nsight Tegra support for CMake In-Reply-To: <1843116e4d0f41ef922563c26aea86fd@UKMAIL102.nvidia.com> References: <559E8CE7.2070408@kitware.com> <1843116e4d0f41ef922563c26aea86fd@UKMAIL102.nvidia.com> Message-ID: <55A65BB3.1010605@kitware.com> On 07/13/2015 12:44 PM, Mikhail Filimonov wrote: > I've improved the patch according to the Brad's and Dmitry's comments - namely: > 1. Improved the documentation for a few target properties. > 2. Removed the explicit toolchain file for Nsight Tegra generator test. > 3. Improved the generator heuristics for NsightTegraProjectRevisionNumber attribute. Thanks. I've applied the patch with minor tweaks: VS: Add more Nsight Tegra generator Android property settings http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8c0afaf4 -Brad From brad.king at kitware.com Wed Jul 15 09:10:26 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 15 Jul 2015 09:10:26 -0400 Subject: [cmake-developers] Suggestion to add EUROS RTOS platform description In-Reply-To: <55A5303D.7000109@euros-embedded.com> References: <55A5303D.7000109@euros-embedded.com> Message-ID: <55A65BC2.6070408@kitware.com> On 07/14/2015 11:52 AM, Stanimir Kabaivanov wrote: > I would like to contribute with EUROS RTOS platform description file > that would allow us to build EUROS RTOS projects with CMake. Thanks. Applied with minor tweaks: Add EUROS RTOS platform description file http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=606b29d4 The multi-inclusion guard is not needed here. The guard in eCos.cmake is specific to that module's use of add_definitions (which platform modules are normally not supposed to do). -Brad From brad.king at kitware.com Wed Jul 15 09:10:32 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 15 Jul 2015 09:10:32 -0400 Subject: [cmake-developers] OSX - Application bundle and private frameworks? In-Reply-To: References: Message-ID: <55A65BC8.5080700@kitware.com> On 07/13/2015 06:43 PM, Raffi Enficiaud wrote: > - and I specify the location of those frameworks within the application bundle: > > set_source_files_properties(${fcCamFramework} PROPERTIES MACOSX_PACKAGE_LOCATION Frameworks) > set_source_files_properties(${sbigudFramework} PROPERTIES MACOSX_PACKAGE_LOCATION Frameworks) > > The problem is the following: > - Everything works fine with XCode, I have the full content of the > frameworks at the specified location > - When I use the Makefile generator, I have only one file per framework > instead of the directory and the framework content: The MACOSX_PACKAGE_LOCATION source file property was created for marking individual source files. The possibility of marking a (framework) directory with the property was never considered AFAIK. For Xcode it may work by accident. I would not be opposed to a change to make something like this work for directories too, but someone would have to investigate it. Meanwhile take a look at the BundleUtilities module: http://www.cmake.org/cmake/help/v3.3/module/BundleUtilities.html and its fixup_bundle() helper. They are meant for preparing complete bundles for packaging and distribution. -Brad From brad.king at kitware.com Wed Jul 15 09:10:39 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 15 Jul 2015 09:10:39 -0400 Subject: [cmake-developers] Header-only library targets In-Reply-To: References: Message-ID: <55A65BCF.4090302@kitware.com> On 07/13/2015 01:19 PM, ??? wrote: > However it's time to change this situation right? I think current version of > interface library is already closed to what header library project wants, > through maybe original design goal was not going to do so, but I couldn't see > any scene to use interface library except for header-only library target. IIRC the current INTERFACE library functionality was designed with header-only libraries in mind. They work well from the buildsystem perspective: one can "link" to a (header-only) INTERFACE library using target_link_libraries and get the include directories added to compilation of one's own sources. What is missing is a notion of the headers (header-only "sources") that are actually in the library. This information is needed in particular for IDE project file generators like VS and Xcode so they can make the sources available in the IDE for humans to see. An open question is where to specify this information. Perhaps it should simply be in the add_library call: add_library(myHeaderLib INTERFACE a.h b.h) Currently that produces an error: CMake Error at CMakeLists.txt:... (add_library): add_library INTERFACE library requires no source arguments. We could consider lifting this restriction for sources that do not compile (but make it an error to add a compiling source). Note that INTERFACE libraries by design cannot specify any actual build rules, so any appearance in an IDE would be attached to a dummy target. This would be similar to current add_custom_target hacks but could be generated automatically and given the same name as the interface library target. -Brad From brad.king at kitware.com Wed Jul 15 09:10:45 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 15 Jul 2015 09:10:45 -0400 Subject: [cmake-developers] Capturing messages to log files (was: Wrapping functions in CMake) In-Reply-To: References: Message-ID: <55A65BD5.5000903@kitware.com> On 07/09/2015 01:53 PM, Clifford Yapp wrote: > Actually, thinking about that, what's really needed is not an > in-memory log but a way to specify log files, since an unexpected > crash or exit is not a situation under which such in-memory logs could > be reliably written to disk. So it would instead need to be > CMAKE_STATUS_MESSAGE_LOG, CMAKE_ERROR_MESSAGES_LOG, etc. which would > hold paths to which messages would be copied before being written to > stdout/stderr. These could be defined as GLOBAL properties since there can only be one. Internally we already have callback infrastructure to dispatch where these messages go. Hooks could be added to check these properties too. Or, the property setting logic could have special handling for these properties to install the needed callbacks internally. This approach would avoid opening/closing the log files over and over. We could just keep them open all the time and flush after each write. -Brad From brad.king at kitware.com Wed Jul 15 09:10:50 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 15 Jul 2015 09:10:50 -0400 Subject: [cmake-developers] Listing all targets (was: Wrapping functions in CMake) In-Reply-To: References: Message-ID: <55A65BDA.4010808@kitware.com> On 07/10/2015 03:42 PM, Clifford Yapp wrote: > On Thu, Jul 9, 2015 at 1:35 PM, Clifford Yapp wrote: > >> 2. Provide similar lists of all defined targets for the various types >> (e.g. CMAKE_EXECUTABLE_TARGETS, CMAKE_LIBRARY_TARGETS, >> CMAKE_CUSTOM_TARGETS). > > Looking into the CMake sources, it seems like this information is > stored already in the global target map - what would be the "correct" > way to expose that information in variables in CMake script space? We shouldn't need separate lists for each because one can check the TYPE target property given the target name. The list of globally-scoped (non-imported) targets could be made available through a (read-only) global property whose implementation computes the list on the fly. -Brad From brad.king at kitware.com Wed Jul 15 09:10:57 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 15 Jul 2015 09:10:57 -0400 Subject: [cmake-developers] Listing source-tree files encountered (was: Wrapping functions in CMake) In-Reply-To: References: Message-ID: <55A65BE1.3000509@kitware.com> On 07/09/2015 01:35 PM, Clifford Yapp wrote: > 1. First, we need to maintain a list of all files in the source > repository that are known to the build system. To do this we maintain > a global list of files, define a custom CMAKEFILES command to allow us > to manually specify miscellaneous files as "known", and override all > of the primary target creating commands to add their files to the list > (for example, add_executable is passed a list of source files, and all > of those files are automatically added to the "known files" list by > the function override of add_executable.) This list is used for both > our "make-clean-in-src-dir" feature and our distcheck build target > (which does a number of verification steps using the version control > system, the build system and the files-on-filesystem information to > make sure the build logic is current.) These days it is the job of version control tools to know what files are part of the source and what files are not. Commands like "git clean" are then responsible for cleaning out a source tree, not the build system. CMake is mainly designed for out-of-source builds where nothing in the source tree is touched at all. This makes distclean unnecessary. We support in-source builds for end-user convenience when installing a project from a source tarball, but in general development should always be done with out-of-source builds to keep the source pristine. > 1. Have CMake internally maintain a list (or maybe per-command lists > for more flexibility) of all files with paths relative to the root > source directory that have been "observed" by add_executable, > add_library, add_custom_target, add_subdirectory, and configure_file > that can be accessed via CMake variables Many of the source file locations are not actually determined until generate time, so a configuration-time list is not possible to implement reliably in general. Maintaining the list would force source file locations to be finalized too early. -Brad From mfilimonov at nvidia.com Wed Jul 15 10:14:15 2015 From: mfilimonov at nvidia.com (Mikhail Filimonov) Date: Wed, 15 Jul 2015 14:14:15 +0000 Subject: [cmake-developers] [PATCH] Extended Nsight Tegra support for CMake In-Reply-To: <55A65BB3.1010605@kitware.com> References: <559E8CE7.2070408@kitware.com> <1843116e4d0f41ef922563c26aea86fd@UKMAIL102.nvidia.com> <55A65BB3.1010605@kitware.com> Message-ID: <8996dfb82e514c06b77596b78a55974e@UKMAIL102.nvidia.com> Thanks, Brad. As usual, we're open for community feedback on Nsight Tegra project generator. -Mikhail -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: 15 ???? 2015 ?. 16:10 To: Mikhail Filimonov Cc: cmake-developers at cmake.org; Dmitry Polyanitsa Subject: Re: [cmake-developers] [PATCH] Extended Nsight Tegra support for CMake On 07/13/2015 12:44 PM, Mikhail Filimonov wrote: > I've improved the patch according to the Brad's and Dmitry's comments - namely: > 1. Improved the documentation for a few target properties. > 2. Removed the explicit toolchain file for Nsight Tegra generator test. > 3. Improved the generator heuristics for NsightTegraProjectRevisionNumber attribute. Thanks. I've applied the patch with minor tweaks: VS: Add more Nsight Tegra generator Android property settings http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8c0afaf4 -Brad ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- From Robert.Goulet at autodesk.com Wed Jul 15 10:30:03 2015 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Wed, 15 Jul 2015 14:30:03 +0000 Subject: [cmake-developers] [PATCH] Extended Nsight Tegra support for CMake In-Reply-To: <8996dfb82e514c06b77596b78a55974e@UKMAIL102.nvidia.com> References: <559E8CE7.2070408@kitware.com> <1843116e4d0f41ef922563c26aea86fd@UKMAIL102.nvidia.com> <55A65BB3.1010605@kitware.com> <8996dfb82e514c06b77596b78a55974e@UKMAIL102.nvidia.com> Message-ID: <99cc1fdcf7344c179cc2cc1d000386b7@CO1PR79MB027.MGDADSK.autodesk.com> We use it for our game engine Android development, and I must say this is definitively super awesome. Looking forward for these improvements! Thanks a lot for all this work. -----Original Message----- From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Mikhail Filimonov Sent: Wednesday, July 15, 2015 10:14 AM To: Brad King Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] [PATCH] Extended Nsight Tegra support for CMake Thanks, Brad. As usual, we're open for community feedback on Nsight Tegra project generator. -Mikhail -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: 15 ???? 2015 ?. 16:10 To: Mikhail Filimonov Cc: cmake-developers at cmake.org; Dmitry Polyanitsa Subject: Re: [cmake-developers] [PATCH] Extended Nsight Tegra support for CMake On 07/13/2015 12:44 PM, Mikhail Filimonov wrote: > I've improved the patch according to the Brad's and Dmitry's comments - namely: > 1. Improved the documentation for a few target properties. > 2. Removed the explicit toolchain file for Nsight Tegra generator test. > 3. Improved the generator heuristics for NsightTegraProjectRevisionNumber attribute. Thanks. I've applied the patch with minor tweaks: VS: Add more Nsight Tegra generator Android property settings http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8c0afaf4 -Brad ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/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-developers From brad.king at kitware.com Wed Jul 15 10:35:50 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 15 Jul 2015 10:35:50 -0400 Subject: [cmake-developers] Adding Swift support to CMake In-Reply-To: References: <55842C6C.4050504@kitware.com> <559191D6.5080403@kitware.com> <559BDAE5.9010505@kitware.com> Message-ID: <55A66FC6.5080502@kitware.com> On 07/15/2015 06:16 AM, Eric Wing wrote: > I just tried out the July 15th nightly build and it looks like it is > working (Xcode generator). I got a little fancy and did an intermixed > C/Swift test. I have a simple SDL (C) based program with Swift > bindings and I'm able to build/run it and step the Xcode debugger > through the Swift parts. Great, thanks for testing. > So is the next step the Makefile generator? The Makefile and Ninja generators should be done together. I recently refactored things to help them share more infrastructure. The hard part is figuring out what command lines actually need to be invoked. There is no documentation from Apple for this AFAIK so someone will have to figure it out based on what Xcode does. I have no time to work on any of this myself. My goal with getting it working in Xcode was just to do the minimum needed to get the basic language module infrastructure in place within CMake. Others will have to take over from there. -Brad From brad.king at kitware.com Wed Jul 15 10:48:50 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 15 Jul 2015 10:48:50 -0400 Subject: [cmake-developers] C# support? In-Reply-To: <4797EDAAB4843944A70CA99A7DE7D8BD0400C3A9@DE012432.schaeffler.com> References: <4797EDAAB4843944A70CA99A7DE7D8BD0400AAC9@DE012432.schaeffler.com> <55917AD8.6070305@kitware.com> <4797EDAAB4843944A70CA99A7DE7D8BD0400BEA1@DE012432.schaeffler.com> <55929E58.6030600@kitware.com> <4797EDAAB4843944A70CA99A7DE7D8BD0400C3A9@DE012432.schaeffler.com> Message-ID: <55A672D2.7060605@kitware.com> On 07/02/2015 09:53 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > I got the first sort of working version running. Would be great > if some people could have a look at it if it's going into a > good direction. Thanks again for working on this. Sorry for the delay in response. I was working on the basic Apple Swift support and thought it could be a useful example for CSharp work. > Patch 0001: > - adds the necessary Module/* files for enabling C# as a language Some of the CMakeCSharpInformation module content like: > +set(CMAKE_CSharp_FLAGS_INIT "/define:TRACE /langversion:3 /nowin32manifest") > +set(CMAKE_CSharp_FLAGS_DEBUG_INIT "/debug:full /optimize- /warn:3 /errorreport:prompt /define:DEBUG") > +set(CMAKE_CSharp_FLAGS_RELEASE_INIT "/debug:none /optimize /warn:1 /errorreport:queue") > +set(CMAKE_CSharp_FLAGS_RELWITHDEBINFO_INIT "/debug:full /optimize-") > +set(CMAKE_CSharp_FLAGS_MINSIZEREL_INIT "/debug:none /optimize") belongs in a file such as Modules/Platform/Windows-MSVC-CSharp.cmake file. The CMakeCSharpInformation file should have only information specific to the C# language and not any particular toolchain and then load other modules that provide information specific to the platform and toolchain vendor (compiler id). See the recently added CMakeSwiftInformation module for an example. > Patch 0002: > - some minor changes to mostly visual studio related classes to enable .csproj support > o .csproj GUID is added > o a method to check if the target is C# is added Looks good at a glance. > Patch 0003: > - the actual implementation of the .csproj generation > - all generation takes place inside VisualStudio10TargetGenerator class That looks like the right direction. How did you generate the flag table? The other flag tables we have for VS >= 10 generators are generated by Source/cmparseMSBuildXML.py. See commit VS14: Generate flag tables from MSBuild v140 tool files http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d96b3f68 for an example. Typically we add a new flag table generated by the script in one commit and then add follow-up commits to apply manual tweaks. That way we know exactly how to reproduce the table. Thanks, -Brad From daniel at pfeifer-mail.de Wed Jul 15 10:57:48 2015 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Wed, 15 Jul 2015 16:57:48 +0200 Subject: [cmake-developers] topic 'ctest-change-id' Message-ID: Hi, The new element `ChangeId` is added to Build.xml and Test.xml. Did you consider adding it as an attribute in `cmCTest::StartXML` instead? That would make this (very useful) information available in all xml files. cheers, Daniel From brad.king at kitware.com Wed Jul 15 11:07:43 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 15 Jul 2015 11:07:43 -0400 Subject: [cmake-developers] topic 'ctest-change-id' In-Reply-To: References: Message-ID: <55A6773F.9080502@kitware.com> On 07/15/2015 10:57 AM, Daniel Pfeifer wrote: > The new element `ChangeId` is added to Build.xml and Test.xml. > Did you consider adding it as an attribute in `cmCTest::StartXML` instead? > That would make this (very useful) information available in all xml files. I think that would make sense since all submitted .xml files are associated with the change identified by the ChangeId. Zack? Thanks, -Brad From zack.galbreath at kitware.com Wed Jul 15 11:22:05 2015 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Wed, 15 Jul 2015 11:22:05 -0400 Subject: [cmake-developers] topic 'ctest-change-id' In-Reply-To: <55A6773F.9080502@kitware.com> References: <55A6773F.9080502@kitware.com> Message-ID: On Wed, Jul 15, 2015 at 11:07 AM, Brad King wrote: > On 07/15/2015 10:57 AM, Daniel Pfeifer wrote: > > The new element `ChangeId` is added to Build.xml and Test.xml. > > Did you consider adding it as an attribute in `cmCTest::StartXML` > instead? > > That would make this (very useful) information available in all xml > files. > > I think that would make sense since all submitted .xml files are > associated with the change identified by the ChangeId. > > Zack? > I did consider that. The reason I went with the current approach is that StartXML() only defines attributes on the tag, which doesn't logically seem like the right location for this information. Change ID should be associated with the build/test/update/etc step being performed. Instead, I followed the example set by , which is independently set by each of the CTest handlers. That being said, I don't have very strong feelings about this, so if you're all okay with Change ID being a Site attribute I could move it to StartXML(). -------------- next part -------------- An HTML attachment was scrubbed... URL: From tamas.kenez at gmail.com Wed Jul 15 11:56:27 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Wed, 15 Jul 2015 17:56:27 +0200 Subject: [cmake-developers] [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES if non-empty Message-ID: The CMakeExpandedImportedTargets module used only the deprecated IMPORTED_LINK_INTERFACE_LIBRARIES property to resolve transitive dependencies. Since the current `install(EXPORT ...)` command generates target files that populate INTERFACE_LINK_LIBRARIES instead, the expand module was not working correctly with the imported libraries generated by `install(EXPORT ...)`. I considered this a bugfix so I based the commit onto the release branch. Please review and apply if it's ok. Tamas >From f2df88ec4180595a3fcc4c6be9b2d38e46162cc3 Mon Sep 17 00:00:00 2001 From: Tamas Kenez Date: Wed, 15 Jul 2015 17:47:50 +0200 Subject: [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES if non-empty The deprecated IMPORTED_LINK_INTERFACE_LIBRARIES should be overridden by INTERFACE_LINK_LIBRARIES if it's non-empty. Unlike IMPORTED_LINK_INTERFACE_LIBRARIES, INTERFACE_LINK_LIBRARIES usually contains config-related generator expressions which must be resolved according to the selected configuration. --- Modules/CMakeExpandImportedTargets.cmake | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/Modules/CMakeExpandImportedTargets.cmake b/Modules/CMakeExpandImportedTargets.cmake index 8ac3364..b110e51 100644 --- a/Modules/CMakeExpandImportedTargets.cmake +++ b/Modules/CMakeExpandImportedTargets.cmake @@ -102,7 +102,27 @@ function(CMAKE_EXPAND_IMPORTED_TARGETS _RESULT ) list(GET _importedConfigs ${_configIndexToUse} _importedConfigToUse) get_target_property(_importedLocation "${_CURRENT_LIB}" IMPORTED_LOCATION_${_importedConfigToUse}) - get_target_property(_linkInterfaceLibs "${_CURRENT_LIB}" IMPORTED_LINK_INTERFACE_LIBRARIES_${_importedConfigToUse} ) + get_target_property(_linkInterfaceLibs "${_CURRENT_LIB}" INTERFACE_LINK_LIBRARIES) + if(_linkInterfaceLibs) + # resolve $ generator expressions + string(REGEX REPLACE "\\$" "1" + _linkInterfaceLibs "${_linkInterfaceLibs}") + string(REGEX REPLACE "\\$]*>" "0" + _linkInterfaceLibs "${_linkInterfaceLibs}") + # resolve $ + string(REGEX REPLACE "\\$" "1" + _linkInterfaceLibs "${_linkInterfaceLibs}") + string(REGEX REPLACE "\\$" "0" + _linkInterfaceLibs "${_linkInterfaceLibs}") + # resolve $<(0|1):...> + # empty items will be ignored by `foreach` later + string(REGEX REPLACE "\\$<0:[^>]*>" "" + _linkInterfaceLibs "${_linkInterfaceLibs}") + string(REGEX REPLACE "\\$<1:([^>]*)>" "\\1" + _linkInterfaceLibs "${_linkInterfaceLibs}") + else() + get_target_property(_linkInterfaceLibs "${_CURRENT_LIB}" IMPORTED_LINK_INTERFACE_LIBRARIES_${_importedConfigToUse} ) + endif() list(APPEND _CCSR_NEW_REQ_LIBS "${_importedLocation}") # message(STATUS "Appending lib ${_CURRENT_LIB} as ${_importedLocation}") -- 1.9.4.msysgit.2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Wed Jul 15 13:27:55 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 15 Jul 2015 13:27:55 -0400 Subject: [cmake-developers] [CMake 0015653]: add PERMISSIONS flag to file(GENERATE) Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15653 ====================================================================== Reported By: James Bigler Assigned To: ====================================================================== Project: CMake Issue ID: 15653 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-15 13:27 EDT Last Modified: 2015-07-15 13:27 EDT ====================================================================== Summary: add PERMISSIONS flag to file(GENERATE) Description: We can set executable permissions with file(WRITE|COPY), but we can't do so with file(GENERATE). It would be helpful when generating scripts to be able to set the permissions, otherwise we can't use file(GENERATE). ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-15 13:27 James Bigler New Issue ====================================================================== From mantis at public.kitware.com Wed Jul 15 13:35:05 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 15 Jul 2015 13:35:05 -0400 Subject: [cmake-developers] [CMake 0015654]: Need generator expression CONFIG that works for both multi-config and single config generators Message-ID: <8340ccef88072a404e8691c59a1083f8@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15654 ====================================================================== Reported By: James Bigler Assigned To: ====================================================================== Project: CMake Issue ID: 15654 Category: CMake Reproducibility: N/A Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-15 13:35 EDT Last Modified: 2015-07-15 13:35 EDT ====================================================================== Summary: Need generator expression CONFIG that works for both multi-config and single config generators Description: The value of $ works just fine for generators like Visual Studio (e.g. Debug, RelWithDebInfo), but for generators like Makefiles it maps to CMAKE_BUILD_TYPE, which is less useful for doing stuff like this: file(GENERATE ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$/myfile) This will do the right thing for VS, but not for Makefile. It would be helpful to have such a value that could make this work. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-15 13:35 James Bigler New Issue ====================================================================== From mantis at public.kitware.com Wed Jul 15 13:42:23 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 15 Jul 2015 13:42:23 -0400 Subject: [cmake-developers] [CMake 0015655]: file(GENERATE) fails of the destination directory doesn't exist Message-ID: <4f9b4b7dd5de5b218498f8bff52d2dd2@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15655 ====================================================================== Reported By: James Bigler Assigned To: ====================================================================== Project: CMake Issue ID: 15655 Category: (No Category) Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-15 13:42 EDT Last Modified: 2015-07-15 13:42 EDT ====================================================================== Summary: file(GENERATE) fails of the destination directory doesn't exist Description: I wanted to use file(GENERATE) to create some files in an output build directory, but these directories don't exist at the time of configure and build so the command fails. These directories are created during build, though so CMake knows about them somehow. set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin) file(GENERATE OUTPUT ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$/test.out CONTENT "Hello, world") file(WRITE a.cpp "int main() { return 0; }") add_executable(a a.cpp) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-15 13:42 James Bigler New Issue ====================================================================== From tamas.kenez at gmail.com Wed Jul 15 15:00:05 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Wed, 15 Jul 2015 21:00:05 +0200 Subject: [cmake-developers] [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES if non-empty In-Reply-To: References: Message-ID: I've just read the discussion at http://www.cmake.org/Bug/view.php?id=15299 about the deprecation of CMakeExpandImportedTargets. I guess it means no fixes to it. I'm checking BundleUtilities as suggested there. Tamas On Wed, Jul 15, 2015 at 5:56 PM, Tam?s Ken?z wrote: > The CMakeExpandedImportedTargets module used only the deprecated > IMPORTED_LINK_INTERFACE_LIBRARIES property to resolve transitive > dependencies. > Since the current `install(EXPORT ...)` command generates target files > that populate INTERFACE_LINK_LIBRARIES instead, the expand module was not > working correctly with the imported libraries generated by `install(EXPORT > ...)`. > > I considered this a bugfix so I based the commit onto the release branch. > > Please review and apply if it's ok. > Tamas > > > From f2df88ec4180595a3fcc4c6be9b2d38e46162cc3 Mon Sep 17 00:00:00 2001 > From: Tamas Kenez > Date: Wed, 15 Jul 2015 17:47:50 +0200 > Subject: [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES > if > non-empty > > The deprecated IMPORTED_LINK_INTERFACE_LIBRARIES should be > overridden by INTERFACE_LINK_LIBRARIES if it's non-empty. > > Unlike IMPORTED_LINK_INTERFACE_LIBRARIES, INTERFACE_LINK_LIBRARIES > usually contains config-related generator expressions which must > be resolved according to the selected configuration. > --- > Modules/CMakeExpandImportedTargets.cmake | 22 +++++++++++++++++++++- > 1 file changed, 21 insertions(+), 1 deletion(-) > > diff --git a/Modules/CMakeExpandImportedTargets.cmake > b/Modules/CMakeExpandImportedTargets.cmake > index 8ac3364..b110e51 100644 > --- a/Modules/CMakeExpandImportedTargets.cmake > +++ b/Modules/CMakeExpandImportedTargets.cmake > @@ -102,7 +102,27 @@ function(CMAKE_EXPAND_IMPORTED_TARGETS _RESULT ) > list(GET _importedConfigs ${_configIndexToUse} > _importedConfigToUse) > > get_target_property(_importedLocation "${_CURRENT_LIB}" > IMPORTED_LOCATION_${_importedConfigToUse}) > - get_target_property(_linkInterfaceLibs "${_CURRENT_LIB}" > IMPORTED_LINK_INTERFACE_LIBRARIES_${_importedConfigToUse} ) > + get_target_property(_linkInterfaceLibs "${_CURRENT_LIB}" > INTERFACE_LINK_LIBRARIES) > + if(_linkInterfaceLibs) > + # resolve $ generator expressions > + string(REGEX REPLACE "\\$" > "1" > + _linkInterfaceLibs "${_linkInterfaceLibs}") > + string(REGEX REPLACE "\\$]*>" "0" > + _linkInterfaceLibs "${_linkInterfaceLibs}") > + # resolve $ > + string(REGEX REPLACE "\\$" "1" > + _linkInterfaceLibs "${_linkInterfaceLibs}") > + string(REGEX REPLACE "\\$" "0" > + _linkInterfaceLibs "${_linkInterfaceLibs}") > + # resolve $<(0|1):...> > + # empty items will be ignored by `foreach` later > + string(REGEX REPLACE "\\$<0:[^>]*>" "" > + _linkInterfaceLibs "${_linkInterfaceLibs}") > + string(REGEX REPLACE "\\$<1:([^>]*)>" "\\1" > + _linkInterfaceLibs "${_linkInterfaceLibs}") > + else() > + get_target_property(_linkInterfaceLibs "${_CURRENT_LIB}" > IMPORTED_LINK_INTERFACE_LIBRARIES_${_importedConfigToUse} ) > + endif() > > list(APPEND _CCSR_NEW_REQ_LIBS "${_importedLocation}") > # message(STATUS "Appending lib ${_CURRENT_LIB} as > ${_importedLocation}") > -- > 1.9.4.msysgit.2 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.scott250 at gmail.com Wed Jul 15 17:08:12 2015 From: michael.scott250 at gmail.com (Michael Scott) Date: Wed, 15 Jul 2015 22:08:12 +0100 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: References: Message-ID: <55A6CBBC.8050102@gmail.com> Looking at the cmMessageCommand::InitialPass and cmake::PrintMessagePreamble code, if we want to mirror the deprecation message behaviour, I'm tempted to suggest we also modify the message mode "AUTHOR_WARNING" to be "AUTHOR" instead. It would make the mode clearer on it's new behaviour and allow the code to be more consistent with regards to dev and deprecated. I imagine this might be a big user affecting change though, so it might be better to not do that and just make AUTHOR_WARNING cause fatal error messages depending on the state of the associated cmake variables. What are your thoughts on this? P.S. Sorry my previous email broke the message threading, I'm replying in a different way this time but please let me know if I'm still breaking the message threading. Cheers, Michael From steveire at gmail.com Wed Jul 15 17:17:24 2015 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 15 Jul 2015 23:17:24 +0200 Subject: [cmake-developers] Generator expressions for output directory References: <3fc3c649d1554819b46dc06f738fff9c@CO1PR79MB027.MGDADSK.autodesk.com> Message-ID: Robert Goulet wrote: > Greetings! > > Patch in attachment for all OUTPUT_DIRECTORY variants to support generator > expressions. Thanks! There are two signatures for cmCompiledGeneratorExpression::Evaluate. Did you use the correct one? Does this support all generator expressions? Including TARGET_PROPERTY? I didn't check/test this. These are just review comments. Thanks, Steve. From steveire at gmail.com Wed Jul 15 17:19:23 2015 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 15 Jul 2015 21:19:23 +0000 (UTC) Subject: [cmake-developers] =?utf-8?q?Adding_an_option_for_relative_compil?= =?utf-8?q?er=09invocations?= References: <54C0C700.5010801@ensslin.cc> Message-ID: Michael En?lin writes: > Over the last several decades, at least on the POSIX platform, it has > become common practice to invoke compilers with relative file paths, and > compilers have adopted to act accordingly. While the true culprit is the > C standard's lax definition of __FILE__, I'm blaming cmake's unusual, > absolute-path invocation behavior. FYI: http://thread.gmane.org/gmane.comp.lang.c++.isocpp.general/6088 Thanks, Steve. From Robert.Goulet at autodesk.com Wed Jul 15 17:27:15 2015 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Wed, 15 Jul 2015 21:27:15 +0000 Subject: [cmake-developers] Generator expressions for output directory In-Reply-To: References: <3fc3c649d1554819b46dc06f738fff9c@CO1PR79MB027.MGDADSK.autodesk.com> Message-ID: I didn't know about the two signature of cmCompiledGeneratorExpression::Evaluate, what's the difference? Could it create an issue? As for the TARGET_PROPERTY generator expression, are you suggesting this could potentially be an issue? I haven't tried it. -----Original Message----- From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Stephen Kelly Sent: Wednesday, July 15, 2015 5:17 PM To: cmake-developers at cmake.org Subject: Re: [cmake-developers] Generator expressions for output directory Robert Goulet wrote: > Greetings! > > Patch in attachment for all OUTPUT_DIRECTORY variants to support > generator expressions. Thanks! There are two signatures for cmCompiledGeneratorExpression::Evaluate. Did you use the correct one? Does this support all generator expressions? Including TARGET_PROPERTY? I didn't check/test this. These are just review comments. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/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-developers From cliffyapp at gmail.com Wed Jul 15 22:38:26 2015 From: cliffyapp at gmail.com (Clifford Yapp) Date: Wed, 15 Jul 2015 22:38:26 -0400 Subject: [cmake-developers] Listing source-tree files encountered (was: Wrapping functions in CMake) In-Reply-To: <55A65BE1.3000509@kitware.com> References: <55A65BE1.3000509@kitware.com> Message-ID: On Wed, Jul 15, 2015 at 9:10 AM, Brad King wrote: > On 07/09/2015 01:35 PM, Clifford Yapp wrote: >> 1. First, we need to maintain a list of all files in the source >> repository that are known to the build system. To do this we maintain >> a global list of files, define a custom CMAKEFILES command to allow us >> to manually specify miscellaneous files as "known", and override all >> of the primary target creating commands to add their files to the list >> (for example, add_executable is passed a list of source files, and all >> of those files are automatically added to the "known files" list by >> the function override of add_executable.) This list is used for both >> our "make-clean-in-src-dir" feature and our distcheck build target >> (which does a number of verification steps using the version control >> system, the build system and the files-on-filesystem information to >> make sure the build logic is current.) > > These days it is the job of version control tools to know what files > are part of the source and what files are not. Commands like "git clean" > are then responsible for cleaning out a source tree, not the build system. Maybe we're a bit "retro", but we've got a system set up which uses the VCS (subversion, in our case) to cross check the build system's awareness of files. We have a number of reasons for this approach, which I can go into if anyone's interested, but the punchline is we've implemented our own "distcheck" system which has a number of (for our project, at least) important features. > CMake is mainly designed for out-of-source builds where nothing in the > source tree is touched at all. This makes distclean unnecessary. > We support in-source builds for end-user convenience when installing > a project from a source tarball, but in general development should > always be done with out-of-source builds to keep the source pristine. Agreed, but since historically we've allowed in-src-dir builds (in the dark old days that's actually the only way things worked for us, but that's another story) the decision was made to continue support for them. It just so happened that the system we implemented to support distcheck was also the primary piece needed to make in-src-dir practical, so in the end we opted to support it and one of our distcheck test targets is set up specifically to ensure it keeps working. >> 1. Have CMake internally maintain a list (or maybe per-command lists >> for more flexibility) of all files with paths relative to the root >> source directory that have been "observed" by add_executable, >> add_library, add_custom_target, add_subdirectory, and configure_file >> that can be accessed via CMake variables > > Many of the source file locations are not actually determined until > generate time, so a configuration-time list is not possible to > implement reliably in general. Maintaining the list would force > source file locations to be finalized too early. Lists that contains a verbatim collection of all path specifiers, regardless of form, that are passed to the various add_* targets would be enough, I think - it'd then be up to our own CMake logic to make sense of it all. I'm not hoping to push our whole in-src-dir/distcheck system into mainstream CMake, just looking for a way to achieve the current result without requiring the built-in-command overrides - I think collecting raw lists of paths supplied to targets is the key piece that is currently driving the command overrides. Would such "verbatim transcription" lists (un-resolved path specifiers and all) be something that could be provided? Thanks, CY From mantis at public.kitware.com Thu Jul 16 05:38:49 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 16 Jul 2015 05:38:49 -0400 Subject: [cmake-developers] [CMake 0015656]: pls. add CPACK_RPM_PACKAGE_CONFLICTS Message-ID: <4208a0ff93df819df1cf820e729641a5@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15656 ====================================================================== Reported By: Frank-Christian Otto Assigned To: ====================================================================== Project: CMake Issue ID: 15656 Category: CPack Reproducibility: N/A Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-16 05:38 EDT Last Modified: 2015-07-16 05:38 EDT ====================================================================== Summary: pls. add CPACK_RPM_PACKAGE_CONFLICTS Description: RPM packaging via cpack allows to set positive dependencies using CPACK_RPM_PACKAGE_REQUIRES RPM also allows negative dependencies (packages that must not be installed). I patched Modules/CPackRPM.cmake to support this. Pls. consider adding this to the code base. patch added as attachment ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-16 05:38 Frank-Christian OttoNew Issue 2015-07-16 05:38 Frank-Christian OttoFile Added: Modules_CPackRPM.cmake_3.2_patch ====================================================================== From tamas.kenez at gmail.com Thu Jul 16 11:29:39 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Thu, 16 Jul 2015 17:29:39 +0200 Subject: [cmake-developers] [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES if non-empty In-Reply-To: References: Message-ID: I submitted a patch to update `CMakeExpandImportedTargets` with `INTERFACE_LINK_LIBRARIES`. Shortly after I read the discussion at http://www.cmake .org/Bug/view.php?id=15299 which suggested `CMakeExpandImportedTargets` is deprecated and one should use `BundleUtilities` instead. Well, it seems that `BundleUtilities` can't expand a single static imported library target to the list of all dependent libraries (that's what I need) so I think `CMakeExpandImportedTargets` is still benefitial and could be benefitial to others, too. My patch enables `CMakeExpandImportedTargets` to use the `INTERFACE_LINK_LIBRARIES` property and also resolves the $, $ and $<0|1:> generator expressions. I found no elegant way to resolve all generator expressions (`file(GENERATE ...)` can't be used since it does not output the resolved content instantly). Tamas On Wed, Jul 15, 2015 at 5:56 PM, Tam?s Ken?z wrote: > The CMakeExpandedImportedTargets module used only the deprecated > IMPORTED_LINK_INTERFACE_LIBRARIES property to resolve transitive > dependencies. > Since the current `install(EXPORT ...)` command generates target files > that populate INTERFACE_LINK_LIBRARIES instead, the expand module was not > working correctly with the imported libraries generated by `install(EXPORT > ...)`. > > I considered this a bugfix so I based the commit onto the release branch. > > Please review and apply if it's ok. > Tamas > > > From f2df88ec4180595a3fcc4c6be9b2d38e46162cc3 Mon Sep 17 00:00:00 2001 > From: Tamas Kenez > Date: Wed, 15 Jul 2015 17:47:50 +0200 > Subject: [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES > if > non-empty > > The deprecated IMPORTED_LINK_INTERFACE_LIBRARIES should be > overridden by INTERFACE_LINK_LIBRARIES if it's non-empty. > > Unlike IMPORTED_LINK_INTERFACE_LIBRARIES, INTERFACE_LINK_LIBRARIES > usually contains config-related generator expressions which must > be resolved according to the selected configuration. > --- > Modules/CMakeExpandImportedTargets.cmake | 22 +++++++++++++++++++++- > 1 file changed, 21 insertions(+), 1 deletion(-) > > diff --git a/Modules/CMakeExpandImportedTargets.cmake > b/Modules/CMakeExpandImportedTargets.cmake > index 8ac3364..b110e51 100644 > --- a/Modules/CMakeExpandImportedTargets.cmake > +++ b/Modules/CMakeExpandImportedTargets.cmake > @@ -102,7 +102,27 @@ function(CMAKE_EXPAND_IMPORTED_TARGETS _RESULT ) > list(GET _importedConfigs ${_configIndexToUse} > _importedConfigToUse) > > get_target_property(_importedLocation "${_CURRENT_LIB}" > IMPORTED_LOCATION_${_importedConfigToUse}) > - get_target_property(_linkInterfaceLibs "${_CURRENT_LIB}" > IMPORTED_LINK_INTERFACE_LIBRARIES_${_importedConfigToUse} ) > + get_target_property(_linkInterfaceLibs "${_CURRENT_LIB}" > INTERFACE_LINK_LIBRARIES) > + if(_linkInterfaceLibs) > + # resolve $ generator expressions > + string(REGEX REPLACE "\\$" > "1" > + _linkInterfaceLibs "${_linkInterfaceLibs}") > + string(REGEX REPLACE "\\$]*>" "0" > + _linkInterfaceLibs "${_linkInterfaceLibs}") > + # resolve $ > + string(REGEX REPLACE "\\$" "1" > + _linkInterfaceLibs "${_linkInterfaceLibs}") > + string(REGEX REPLACE "\\$" "0" > + _linkInterfaceLibs "${_linkInterfaceLibs}") > + # resolve $<(0|1):...> > + # empty items will be ignored by `foreach` later > + string(REGEX REPLACE "\\$<0:[^>]*>" "" > + _linkInterfaceLibs "${_linkInterfaceLibs}") > + string(REGEX REPLACE "\\$<1:([^>]*)>" "\\1" > + _linkInterfaceLibs "${_linkInterfaceLibs}") > + else() > + get_target_property(_linkInterfaceLibs "${_CURRENT_LIB}" > IMPORTED_LINK_INTERFACE_LIBRARIES_${_importedConfigToUse} ) > + endif() > > list(APPEND _CCSR_NEW_REQ_LIBS "${_importedLocation}") > # message(STATUS "Appending lib ${_CURRENT_LIB} as > ${_importedLocation}") > -- > 1.9.4.msysgit.2 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cliffyapp at gmail.com Thu Jul 16 11:42:00 2015 From: cliffyapp at gmail.com (Clifford Yapp) Date: Thu, 16 Jul 2015 11:42:00 -0400 Subject: [cmake-developers] Listing all targets (was: Wrapping functions in CMake) In-Reply-To: <55A65BDA.4010808@kitware.com> References: <55A65BDA.4010808@kitware.com> Message-ID: On Wed, Jul 15, 2015 at 9:10 AM, Brad King wrote: > On 07/10/2015 03:42 PM, Clifford Yapp wrote: >> On Thu, Jul 9, 2015 at 1:35 PM, Clifford Yapp wrote: >> >>> 2. Provide similar lists of all defined targets for the various types >>> (e.g. CMAKE_EXECUTABLE_TARGETS, CMAKE_LIBRARY_TARGETS, >>> CMAKE_CUSTOM_TARGETS). >> >> Looking into the CMake sources, it seems like this information is >> stored already in the global target map - what would be the "correct" >> way to expose that information in variables in CMake script space? > > We shouldn't need separate lists for each because one can check > the TYPE target property given the target name. Ah, good point. > The list of globally-scoped (non-imported) targets could be made available > through a (read-only) global property whose implementation > computes the list on the fly. Sounds workable - are there any pre-existing properties like that that can serve as a guide for implementation? Thanks, CY From cliffyapp at gmail.com Thu Jul 16 11:42:42 2015 From: cliffyapp at gmail.com (Clifford Yapp) Date: Thu, 16 Jul 2015 11:42:42 -0400 Subject: [cmake-developers] Capturing messages to log files (was: Wrapping functions in CMake) In-Reply-To: <55A65BD5.5000903@kitware.com> References: <55A65BD5.5000903@kitware.com> Message-ID: On Wed, Jul 15, 2015 at 9:10 AM, Brad King wrote: > On 07/09/2015 01:53 PM, Clifford Yapp wrote: >> Actually, thinking about that, what's really needed is not an >> in-memory log but a way to specify log files, since an unexpected >> crash or exit is not a situation under which such in-memory logs could >> be reliably written to disk. So it would instead need to be >> CMAKE_STATUS_MESSAGE_LOG, CMAKE_ERROR_MESSAGES_LOG, etc. which would >> hold paths to which messages would be copied before being written to >> stdout/stderr. > > These could be defined as GLOBAL properties since there can only > be one. Makes sense. > Internally we already have callback infrastructure to > dispatch where these messages go. Hooks could be added to check > these properties too. Or, the property setting logic could have > special handling for these properties to install the needed > callbacks internally. This approach would avoid opening/closing > the log files over and over. We could just keep them open all > the time and flush after each write. Sounds good! (Always in favor of less filesystem hits, especially on Windows...) In hopes of writing an acceptable patch, is there an approach that would be preferred? Cheers, CY From DLRdave at aol.com Thu Jul 16 13:27:12 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 16 Jul 2015 13:27:12 -0400 Subject: [cmake-developers] Listing all targets (was: Wrapping functions in CMake) In-Reply-To: References: <55A65BDA.4010808@kitware.com> Message-ID: This would best be added as a "TARGETS" variant of the existing http://www.cmake.org/cmake/help/v3.3/command/get_cmake_property.html command. (In my opinion...) David C. On Thu, Jul 16, 2015 at 11:42 AM, Clifford Yapp wrote: > On Wed, Jul 15, 2015 at 9:10 AM, Brad King wrote: >> On 07/10/2015 03:42 PM, Clifford Yapp wrote: >>> On Thu, Jul 9, 2015 at 1:35 PM, Clifford Yapp wrote: >>> >>>> 2. Provide similar lists of all defined targets for the various types >>>> (e.g. CMAKE_EXECUTABLE_TARGETS, CMAKE_LIBRARY_TARGETS, >>>> CMAKE_CUSTOM_TARGETS). >>> >>> Looking into the CMake sources, it seems like this information is >>> stored already in the global target map - what would be the "correct" >>> way to expose that information in variables in CMake script space? >> >> We shouldn't need separate lists for each because one can check >> the TYPE target property given the target name. > > Ah, good point. > >> The list of globally-scoped (non-imported) targets could be made available >> through a (read-only) global property whose implementation >> computes the list on the fly. > > Sounds workable - are there any pre-existing properties like that that > can serve as a guide for implementation? > > Thanks, > CY > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/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-developers From nick.lewis at usa.g4s.com Fri Jul 17 10:06:05 2015 From: nick.lewis at usa.g4s.com (Nick Lewis) Date: Fri, 17 Jul 2015 15:06:05 +0100 Subject: [cmake-developers] install(EXCLUDE_FROM_ALL) new feature - request for comment Message-ID: >>>There is currently no way to exclude a component install() from a full >>>installation. Current workarounds using OPTIONAL do not work reliably because >>>they depend on previous builds and on the order execution of the build and >>>install commands for the components and the default target >>>Steps to Reproduce: >>>make >>>make tests >>>make install >>>DESTDIR=/testpkgs make install-tests >>>This results in test components in the default installation as well as the >>>testpkg >>>Judging by questions on the mail list, users typically try to overcome this >>>problem by adding the unsupported EXCLUDE_FROM_ALL keyword to the install >>>command >>> http://www.cmake.org/Bug/view.php?id=14921 >>Interesting proposal. I think a change along these lines could also improve a >>case mentioned in the install() command documentation: >> http://www.cmake.org/cmake/help/v3.0/command/install.html >> "Installing a target with the EXCLUDE_FROM_ALL target property set to TRUE has >>undefined behavior." >>That refers to the use case when a target build is EXCLUDE_FROM_ALL and so is >>not created by "make" and may then be missing when "make install" is issued. >>This looks intended to support the same use case by making the install rule >>excluded from the default installation too. Perhaps install(TARGETS) should >>activate ExcludeFromAll when the corresponding property is set on the target. >Rebased patch on 3.2.2. Still no automatic setting of install(EXCLUDE_FROM_ALL) >based on the setting of add_executable(EXCLUDE_FROM_ALL) though Thanks for working on this. I think it will be better discussed on the cmake-developers mailing list: http://www.cmake.org/mailman/listinfo/cmake-developers That allows for design discussion with a broader audience than the issue -- This company is part of the G4S group of companies. This communication contains information which may be confidential, personal and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, forwarding, copying or use of this communication or the information in it is strictly prohibited. Any personal views expressed in this e-mail are those of the individual sender and the Company does not endorse or accept responsibility for them. Prior to taking any action based upon this e-mail message, you should seek appropriate confirmation of its authenticity. This message has been checked for viruses on behalf of the Company. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Fri Jul 17 10:14:01 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 17 Jul 2015 10:14:01 -0400 Subject: [cmake-developers] Listing all targets (was: Wrapping functions in CMake) In-Reply-To: References: <55A65BDA.4010808@kitware.com> Message-ID: <20150717141401.GB31310@megas.kitware.com> On Thu, Jul 16, 2015 at 13:27:12 -0400, David Cole via cmake-developers wrote: > This would best be added as a "TARGETS" variant of the existing > http://www.cmake.org/cmake/help/v3.3/command/get_cmake_property.html > command. > > (In my opinion...) The get_property command would also need to handle it. I don't know if it hooks into the more specific commands' implementations though. Doesn't seem like it from a cursory reading though. --Ben From brad.king at kitware.com Fri Jul 17 10:43:30 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 17 Jul 2015 10:43:30 -0400 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: <55A6CBBC.8050102@gmail.com> References: <55A6CBBC.8050102@gmail.com> Message-ID: <55A91492.6050303@kitware.com> On 07/15/2015 05:08 PM, Michael Scott wrote: > Looking at the cmMessageCommand::InitialPass and > cmake::PrintMessagePreamble code, if we want to mirror the deprecation > message behaviour, I'm tempted to suggest we also modify the message > mode "AUTHOR_WARNING" to be "AUTHOR" instead. It would make the mode > clearer on it's new behaviour and allow the code to be more consistent > with regards to dev and deprecated. > > I imagine this might be a big user affecting change though, so it might > be better to not do that and just make AUTHOR_WARNING cause fatal error > messages depending on the state of the associated cmake variables. What > are your thoughts on this? I think the name "AUTHOR_WARNING" is fine even after these changes because the new options explicitly request to make these warnings into errors. C++ compiler "#pragma warn"-like options are spelled "warn" but can still be errors with the right options. > P.S. Sorry my previous email broke the message threading, I'm replying > in a different way this time but please let me know if I'm still > breaking the message threading. It still breaks the threading. Your first few responses (e.g. on 2015-06-24) were threaded correctly. -Brad From brad.king at kitware.com Fri Jul 17 10:44:04 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 17 Jul 2015 10:44:04 -0400 Subject: [cmake-developers] Generator expressions for output directory In-Reply-To: References: <3fc3c649d1554819b46dc06f738fff9c@CO1PR79MB027.MGDADSK.autodesk.com> Message-ID: <55A914B4.60400@kitware.com> On 07/15/2015 05:27 PM, Robert Goulet wrote: > I didn't know about the two signature of > cmCompiledGeneratorExpression::Evaluate, what's the difference? > > As for the TARGET_PROPERTY generator expression, are you suggesting > this could potentially be an issue? I haven't tried it. If cmCompiledGeneratorExpression::Evaluate is given the current target ("this") as the headTarget then one can use the TARGET_PROPERTY generator expression to refer to other properties on the target whose name is being determined. This would be nice to have but could also be enabled by future changes so I won't insist on it now. Your original patch did not evaluate the generator expressions in quite the right place. On Wednesday I had updated the patch and applied for testing in 'next': Add genex for {ARCHIVE,LIBRARY,RUNTIME}_OUTPUT_DIRECTORY[_] http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f6f05443 Although testing was clean, I reverted the change from 'next' this morning after Steve's review led me to realize that the change causes a crash in a self-reference case like: set_property(TARGET myexe PROPERTY RUNTIME_OUTPUT_DIRECTORY $) This is also a problem for the recent OUTPUT_NAME changes: set_property(TARGET myexe PROPERTY OUTPUT_NAME $) In each case the implementation fails to diagnose the ill-defined self-reference case. Fixing these cases may require some kind of check in cmTarget methods to see if they end up being called recursively. Thanks, -Brad From Robert.Goulet at autodesk.com Fri Jul 17 10:55:12 2015 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Fri, 17 Jul 2015 14:55:12 +0000 Subject: [cmake-developers] Generator expressions for output directory In-Reply-To: <55A914B4.60400@kitware.com> References: <3fc3c649d1554819b46dc06f738fff9c@CO1PR79MB027.MGDADSK.autodesk.com> <55A914B4.60400@kitware.com> Message-ID: Ok I'd like to fix the crash, what is the clean way to deal with this kind of situation? I'm guessing this might be a problem that was solved elsewhere for other cases before? -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Friday, July 17, 2015 10:44 AM To: Robert Goulet Cc: Stephen Kelly; cmake-developers at cmake.org Subject: Re: [cmake-developers] Generator expressions for output directory On 07/15/2015 05:27 PM, Robert Goulet wrote: > I didn't know about the two signature of > cmCompiledGeneratorExpression::Evaluate, what's the difference? > > As for the TARGET_PROPERTY generator expression, are you suggesting > this could potentially be an issue? I haven't tried it. If cmCompiledGeneratorExpression::Evaluate is given the current target ("this") as the headTarget then one can use the TARGET_PROPERTY generator expression to refer to other properties on the target whose name is being determined. This would be nice to have but could also be enabled by future changes so I won't insist on it now. Your original patch did not evaluate the generator expressions in quite the right place. On Wednesday I had updated the patch and applied for testing in 'next': Add genex for {ARCHIVE,LIBRARY,RUNTIME}_OUTPUT_DIRECTORY[_] http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f6f05443 Although testing was clean, I reverted the change from 'next' this morning after Steve's review led me to realize that the change causes a crash in a self-reference case like: set_property(TARGET myexe PROPERTY RUNTIME_OUTPUT_DIRECTORY $) This is also a problem for the recent OUTPUT_NAME changes: set_property(TARGET myexe PROPERTY OUTPUT_NAME $) In each case the implementation fails to diagnose the ill-defined self-reference case. Fixing these cases may require some kind of check in cmTarget methods to see if they end up being called recursively. Thanks, -Brad From brad.king at kitware.com Fri Jul 17 11:41:19 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 17 Jul 2015 11:41:19 -0400 Subject: [cmake-developers] [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES if non-empty In-Reply-To: References: Message-ID: <55A9221F.5030808@kitware.com> On 07/16/2015 11:29 AM, Tam?s Ken?z wrote: > Well, it seems that `BundleUtilities` can't expand a single static imported > library target to the list of all dependent libraries (that's what I need) > so I think `CMakeExpandImportedTargets` is still benefitial and could be > benefitial to others, too. The BundleUtilities suggestion in the issue tracker page you linked was specific to the CPack use case discussed there. > My patch enables `CMakeExpandImportedTargets` to use the > `INTERFACE_LINK_LIBRARIES` property and also resolves the $, > $ and $<0|1:> generator expressions. This module should not be further maintained and should instead be deprecated: * Its original use case was to expand imported targets for calling try_compile and try_run. Both now support imported targets natively in their LINK_LIBRARIES options so it is no longer needed (or used by CMake's own modules) for this purpose. * It is not possible to implement with generator expressions in general (see below). > I found no elegant way to resolve all generator expressions > (`file(GENERATE ...)` can't be used since it does not output the > resolved content instantly). Generator expressions by definition cannot be evaluated until generate time because their evaluation can access information that is not available until then. Even for imported targets with a given CONFIGURATION value we may not have all the information needed to expand INTERFACE_LINK_LIBRARIES. For example, that property may contain expressions like $ that refer to the target for which the link line is currently generating. What is your actual use case for expanding this info during the configuration process? -Brad From brad.king at kitware.com Fri Jul 17 11:46:48 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 17 Jul 2015 11:46:48 -0400 Subject: [cmake-developers] Generator expressions for output directory In-Reply-To: References: <3fc3c649d1554819b46dc06f738fff9c@CO1PR79MB027.MGDADSK.autodesk.com> <55A914B4.60400@kitware.com> Message-ID: <55A92368.5010605@kitware.com> On 07/17/2015 10:55 AM, Robert Goulet wrote: > Ok I'd like to fix the crash, what is the clean way to deal with > this kind of situation? I'm guessing this might be a problem that > was solved elsewhere for other cases before? I don't recall other cases where this specific problem has come up. There is code to deal with generator expression reference cycles e.g. for $ expressions but that is not quite the same thing. For the OUTPUT_DIRECTORY case the GetOutputInfo method: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmTarget.cxx;hb=v3.3.0-rc4#l2612 memoizes the ComputeOutputDir result in a map. Currently it does not update the map until after computing the value. You could try teaching it to insert a placeholder (empty?) value in the map first. Then in the check for an existing map entry, if it is found to contain the placeholder then you know recursion is occurring and you can diagnose it with an error message and return early. The GetOutputName method could be refactored to use a map and then work the same way. Thanks, -Brad From brad.king at kitware.com Fri Jul 17 11:50:18 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 17 Jul 2015 11:50:18 -0400 Subject: [cmake-developers] Listing source-tree files encountered In-Reply-To: References: <55A65BE1.3000509@kitware.com> Message-ID: <55A9243A.5000500@kitware.com> On 07/15/2015 10:38 PM, Clifford Yapp wrote: > Lists that contains a verbatim collection of all path specifiers, > regardless of form, that are passed to the various add_* targets would > be enough, I think - it'd then be up to our own CMake logic to make > sense of it all. I'm not hoping to push our whole > in-src-dir/distcheck system into mainstream CMake, just looking for a > way to achieve the current result without requiring the > built-in-command overrides - I think collecting raw lists of paths > supplied to targets is the key piece that is currently driving the > command overrides. Once the list of all targets is available in a global property as discussed in another branch of this thread, then you could loop over that and check the SOURCES target property to get the list of original path specifiers. That would handle almost everything. What would be left for your use case? -Brad From DLRdave at aol.com Fri Jul 17 12:18:18 2015 From: DLRdave at aol.com (David Cole) Date: Fri, 17 Jul 2015 12:18:18 -0400 Subject: [cmake-developers] Listing all targets (was: Wrapping functions in CMake) In-Reply-To: <20150717141401.GB31310@megas.kitware.com> References: <55A65BDA.4010808@kitware.com> <20150717141401.GB31310@megas.kitware.com> Message-ID: Are you saying there should be a named GLOBAL property with this information in it...? It seems like more of a fit to get_cmake_property. On Fri, Jul 17, 2015 at 10:14 AM, Ben Boeckel wrote: > On Thu, Jul 16, 2015 at 13:27:12 -0400, David Cole via cmake-developers wrote: >> This would best be added as a "TARGETS" variant of the existing >> http://www.cmake.org/cmake/help/v3.3/command/get_cmake_property.html >> command. >> >> (In my opinion...) > > The get_property command would also need to handle it. I don't know if > it hooks into the more specific commands' implementations though. > Doesn't seem like it from a cursory reading though. > > --Ben From tamas.kenez at gmail.com Fri Jul 17 13:43:38 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Fri, 17 Jul 2015 19:43:38 +0200 Subject: [cmake-developers] [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES if non-empty In-Reply-To: <55A9221F.5030808@kitware.com> References: <55A9221F.5030808@kitware.com> Message-ID: > What is your actual use case for expanding this info during the configuration process? We feed our static lib and the list of its dependencies to the `libtool` to create an amalgamated, standalone static library. This is an iOS-specific issue: we need this because iOS doesn't support shared libraries and we want to provide our users a single static lib instead of 20-30. Anyway, I understand if `CMakeExpandImportedTargets' doesn't fit the current concepts. We will then use a local modified copy of it or try to solve the issue by `install(CODE ..)` to postpone the amalgamation to install time where the generator expressions can be resolved. Thanks, Tamas (sorry for not replying-to-all in previous email) On Fri, Jul 17, 2015 at 5:41 PM, Brad King wrote: > On 07/16/2015 11:29 AM, Tam?s Ken?z wrote: > > Well, it seems that `BundleUtilities` can't expand a single static > imported > > library target to the list of all dependent libraries (that's what I > need) > > so I think `CMakeExpandImportedTargets` is still benefitial and could be > > benefitial to others, too. > > The BundleUtilities suggestion in the issue tracker page you linked > was specific to the CPack use case discussed there. > > > My patch enables `CMakeExpandImportedTargets` to use the > > `INTERFACE_LINK_LIBRARIES` property and also resolves the $, > > $ and $<0|1:> generator expressions. > > This module should not be further maintained and should instead be > deprecated: > > * Its original use case was to expand imported targets for calling > try_compile and try_run. Both now support imported targets > natively in their LINK_LIBRARIES options so it is no longer > needed (or used by CMake's own modules) for this purpose. > > * It is not possible to implement with generator expressions in > general (see below). > > > I found no elegant way to resolve all generator expressions > > (`file(GENERATE ...)` can't be used since it does not output the > > resolved content instantly). > > Generator expressions by definition cannot be evaluated until generate > time because their evaluation can access information that is not > available until then. Even for imported targets with a given > CONFIGURATION value we may not have all the information needed to > expand INTERFACE_LINK_LIBRARIES. For example, that property may > contain expressions like $ that refer to the > target for which the link line is currently generating. > > What is your actual use case for expanding this info during the > configuration process? > > -Brad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Fri Jul 17 13:54:25 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 17 Jul 2015 13:54:25 -0400 Subject: [cmake-developers] Listing all targets (was: Wrapping functions in CMake) In-Reply-To: References: <55A65BDA.4010808@kitware.com> <20150717141401.GB31310@megas.kitware.com> Message-ID: <20150717175424.GA26601@megas.kitware.com> On Fri, Jul 17, 2015 at 12:18:18 -0400, David Cole wrote: > Are you saying there should be a named GLOBAL property with this > information in it...? > > It seems like more of a fit to get_cmake_property. Indeed. It seems there is no overlap between `get_property` and `get_cmake_property`. Which means the docs have a bug. --Ben From DLRdave at aol.com Fri Jul 17 14:16:34 2015 From: DLRdave at aol.com (David Cole) Date: Fri, 17 Jul 2015 14:16:34 -0400 Subject: [cmake-developers] Listing all targets (was: Wrapping functions in CMake) In-Reply-To: <20150717175424.GA26601@megas.kitware.com> References: <55A65BDA.4010808@kitware.com> <20150717141401.GB31310@megas.kitware.com> <20150717175424.GA26601@megas.kitware.com> Message-ID: get_cmake_property is more like "strictly well-pre-defined, read only (ish), built-into CMake" properties. Note there is no set_cmake_property... What docs are you looking at that you think have a bug...? To implement TARGETS for get_cmake_property, I would look to see what logic is used by "if(TARGET" and use the same list it uses as the value returned here. Should I work on a patch/branch, or is somebody here already working on it? D On Fri, Jul 17, 2015 at 1:54 PM, Ben Boeckel wrote: > On Fri, Jul 17, 2015 at 12:18:18 -0400, David Cole wrote: >> Are you saying there should be a named GLOBAL property with this >> information in it...? >> >> It seems like more of a fit to get_cmake_property. > > Indeed. It seems there is no overlap between `get_property` and > `get_cmake_property`. Which means the docs have a bug. > > --Ben From Robert.Goulet at autodesk.com Fri Jul 17 14:34:09 2015 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Fri, 17 Jul 2015 18:34:09 +0000 Subject: [cmake-developers] Generator expressions for output directory In-Reply-To: <55A92368.5010605@kitware.com> References: <3fc3c649d1554819b46dc06f738fff9c@CO1PR79MB027.MGDADSK.autodesk.com> <55A914B4.60400@kitware.com> <55A92368.5010605@kitware.com> Message-ID: I'm going to be away for a few weeks, is it ok if the master branch stays in that state for a while? -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Friday, July 17, 2015 11:47 AM To: Robert Goulet Cc: Stephen Kelly; cmake-developers at cmake.org Subject: Re: [cmake-developers] Generator expressions for output directory On 07/17/2015 10:55 AM, Robert Goulet wrote: > Ok I'd like to fix the crash, what is the clean way to deal with this > kind of situation? I'm guessing this might be a problem that was > solved elsewhere for other cases before? I don't recall other cases where this specific problem has come up. There is code to deal with generator expression reference cycles e.g. for $ expressions but that is not quite the same thing. For the OUTPUT_DIRECTORY case the GetOutputInfo method: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmTarget.cxx;hb=v3.3.0-rc4#l2612 memoizes the ComputeOutputDir result in a map. Currently it does not update the map until after computing the value. You could try teaching it to insert a placeholder (empty?) value in the map first. Then in the check for an existing map entry, if it is found to contain the placeholder then you know recursion is occurring and you can diagnose it with an error message and return early. The GetOutputName method could be refactored to use a map and then work the same way. Thanks, -Brad From ben.boeckel at kitware.com Fri Jul 17 14:55:36 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 17 Jul 2015 14:55:36 -0400 Subject: [cmake-developers] Listing all targets (was: Wrapping functions in CMake) In-Reply-To: References: <55A65BDA.4010808@kitware.com> <20150717141401.GB31310@megas.kitware.com> <20150717175424.GA26601@megas.kitware.com> Message-ID: <20150717185536.GA31013@megas.kitware.com> On Fri, Jul 17, 2015 at 14:16:34 -0400, David Cole wrote: > get_cmake_property is more like "strictly well-pre-defined, read only > (ish), built-into CMake" properties. Note there is no > set_cmake_property... What docs are you looking at that you think have > a bug...? Help/command/get_cmake_property: get_cmake_property ------------------ Get a property of the CMake instance. :: get_cmake_property(VAR property) Get a property from the CMake instance. The value of the property is stored in the variable VAR. If the property is not found, VAR will be set to "NOTFOUND". Some supported properties include: VARIABLES, CACHE_VARIABLES, COMMANDS, MACROS, and COMPONENTS. See also the more general get_property() command. `get_property` has no way (that I see) to ask for the same properties. The whole command docs could use a revamp too (while TARGETS is being implemented to avoid conflicts?). --Ben From DLRdave at aol.com Fri Jul 17 15:03:37 2015 From: DLRdave at aol.com (David Cole) Date: Fri, 17 Jul 2015 15:03:37 -0400 Subject: [cmake-developers] Listing all targets (was: Wrapping functions in CMake) In-Reply-To: <20150717185536.GA31013@megas.kitware.com> References: <55A65BDA.4010808@kitware.com> <20150717141401.GB31310@megas.kitware.com> <20150717175424.GA26601@megas.kitware.com> <20150717185536.GA31013@megas.kitware.com> Message-ID: I think the see also is relevant because it points to another way to get to a whole different set of "properties". Perhaps what they're looking for when they stumble upon get_cmake_property is actually target properties, which are only accessible via get_property. While it's relevant, and I think it should remain, I do think it could use some clarification. I'll take a stab at this, and clarify the docs, too, unless somebody else chimes in and tells me "wait! I'm doing it already...." :-) Cheers, David C. On Fri, Jul 17, 2015 at 2:55 PM, Ben Boeckel wrote: > On Fri, Jul 17, 2015 at 14:16:34 -0400, David Cole wrote: >> get_cmake_property is more like "strictly well-pre-defined, read only >> (ish), built-into CMake" properties. Note there is no >> set_cmake_property... What docs are you looking at that you think have >> a bug...? > > Help/command/get_cmake_property: > > get_cmake_property > ------------------ > > Get a property of the CMake instance. > > :: > > get_cmake_property(VAR property) > > Get a property from the CMake instance. The value of the property is > stored in the variable VAR. If the property is not found, VAR will be > set to "NOTFOUND". Some supported properties include: VARIABLES, > CACHE_VARIABLES, COMMANDS, MACROS, and COMPONENTS. > > See also the more general get_property() command. > > `get_property` has no way (that I see) to ask for the same properties. > The whole command docs could use a revamp too (while TARGETS is being > implemented to avoid conflicts?). > > --Ben From DLRdave at aol.com Fri Jul 17 18:05:01 2015 From: DLRdave at aol.com (David Cole) Date: Fri, 17 Jul 2015 18:05:01 -0400 Subject: [cmake-developers] Listing all targets (was: Wrapping functions in CMake) In-Reply-To: References: <55A65BDA.4010808@kitware.com> <20150717141401.GB31310@megas.kitware.com> <20150717175424.GA26601@megas.kitware.com> <20150717185536.GA31013@megas.kitware.com> Message-ID: Attached is a patch file of my first attempt. I can iterate some more on this (better testing, add docs, clarify existing docs, address anybody's comments, submit to stage) next week. Attached now in case anybody wants to try it out over the weekend. Cheers, David C. On Fri, Jul 17, 2015 at 3:03 PM, David Cole wrote: > I think the see also is relevant because it points to another way to > get to a whole different set of "properties". Perhaps what they're > looking for when they stumble upon get_cmake_property is actually > target properties, which are only accessible via get_property. > > While it's relevant, and I think it should remain, I do think it could > use some clarification. > > I'll take a stab at this, and clarify the docs, too, unless somebody > else chimes in and tells me "wait! I'm doing it already...." > > :-) > > > Cheers, > David C. > > > On Fri, Jul 17, 2015 at 2:55 PM, Ben Boeckel wrote: >> On Fri, Jul 17, 2015 at 14:16:34 -0400, David Cole wrote: >>> get_cmake_property is more like "strictly well-pre-defined, read only >>> (ish), built-into CMake" properties. Note there is no >>> set_cmake_property... What docs are you looking at that you think have >>> a bug...? >> >> Help/command/get_cmake_property: >> >> get_cmake_property >> ------------------ >> >> Get a property of the CMake instance. >> >> :: >> >> get_cmake_property(VAR property) >> >> Get a property from the CMake instance. The value of the property is >> stored in the variable VAR. If the property is not found, VAR will be >> set to "NOTFOUND". Some supported properties include: VARIABLES, >> CACHE_VARIABLES, COMMANDS, MACROS, and COMPONENTS. >> >> See also the more general get_property() command. >> >> `get_property` has no way (that I see) to ask for the same properties. >> The whole command docs could use a revamp too (while TARGETS is being >> implemented to avoid conflicts?). >> >> --Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-CMake-Add-TARGETS-to-get_cmake_property.patch Type: application/octet-stream Size: 4591 bytes Desc: not available URL: From cliffyapp at gmail.com Sat Jul 18 00:06:55 2015 From: cliffyapp at gmail.com (Clifford Yapp) Date: Sat, 18 Jul 2015 00:06:55 -0400 Subject: [cmake-developers] Listing source-tree files encountered In-Reply-To: <55A9243A.5000500@kitware.com> References: <55A65BE1.3000509@kitware.com> <55A9243A.5000500@kitware.com> Message-ID: On Fri, Jul 17, 2015 at 11:50 AM, Brad King wrote: > On 07/15/2015 10:38 PM, Clifford Yapp wrote: >> Lists that contains a verbatim collection of all path specifiers, >> regardless of form, that are passed to the various add_* targets would >> be enough, I think - it'd then be up to our own CMake logic to make >> sense of it all. I'm not hoping to push our whole >> in-src-dir/distcheck system into mainstream CMake, just looking for a >> way to achieve the current result without requiring the >> built-in-command overrides - I think collecting raw lists of paths >> supplied to targets is the key piece that is currently driving the >> command overrides. > > Once the list of all targets is available in a global property as > discussed in another branch of this thread, then you could loop > over that and check the SOURCES target property to get the list > of original path specifiers. That would handle almost everything. > What would be left for your use case? That sounds like it should work - I hadn't considered the possibilities of the SOURCES target property. Is that property available for custom targets as well? Thanks, CY From cliffyapp at gmail.com Sat Jul 18 00:16:00 2015 From: cliffyapp at gmail.com (Clifford Yapp) Date: Sat, 18 Jul 2015 00:16:00 -0400 Subject: [cmake-developers] Listing all targets (was: Wrapping functions in CMake) In-Reply-To: References: <55A65BDA.4010808@kitware.com> <20150717141401.GB31310@megas.kitware.com> <20150717175424.GA26601@megas.kitware.com> <20150717185536.GA31013@megas.kitware.com> Message-ID: On Fri, Jul 17, 2015 at 6:05 PM, David Cole wrote: > Attached is a patch file of my first attempt. I can iterate some more > on this (better testing, add docs, clarify existing docs, address > anybody's comments, submit to stage) next week. Attached now in case > anybody wants to try it out over the weekend. David, Awesome - thank you for doing that! (Way faster than I would have been able to set it up). It may be Monday before I can put it through it's paces, but I'll definitely give this a go and also see if I can combine it with the SOURCES target property Brad pointed out to kill two problems with one patch. I'll try to get at figuring out how to set up GLOBAL properties for collecting various types of message outputs and prepare a patch for that on Monday as well, unless someone else gets to it sooner. Cheers, CY From florent.castelli at gmail.com Sat Jul 18 05:30:39 2015 From: florent.castelli at gmail.com (Florent Castelli) Date: Sat, 18 Jul 2015 11:30:39 +0200 Subject: [cmake-developers] Listing source-tree files encountered In-Reply-To: <55A9243A.5000500@kitware.com> References: <55A65BE1.3000509@kitware.com> <55A9243A.5000500@kitware.com> Message-ID: <55AA1CBF.6020107@gmail.com> I've used that once and you end up with the relative path to the sources from the CMakeLists.txt. If you're in another CMakeLists.txt, then you can't use the paths directly. I tried a few properties but I couldn't find any property to get the folder where the target was defined. How do you get the full path? /Orphis On 17/07/2015 17:50, Brad King wrote: > On 07/15/2015 10:38 PM, Clifford Yapp wrote: >> Lists that contains a verbatim collection of all path specifiers, >> regardless of form, that are passed to the various add_* targets would >> be enough, I think - it'd then be up to our own CMake logic to make >> sense of it all. I'm not hoping to push our whole >> in-src-dir/distcheck system into mainstream CMake, just looking for a >> way to achieve the current result without requiring the >> built-in-command overrides - I think collecting raw lists of paths >> supplied to targets is the key piece that is currently driving the >> command overrides. > Once the list of all targets is available in a global property as > discussed in another branch of this thread, then you could loop > over that and check the SOURCES target property to get the list > of original path specifiers. That would handle almost everything. > What would be left for your use case? > > -Brad > From DLRdave at aol.com Sat Jul 18 11:57:06 2015 From: DLRdave at aol.com (David Cole) Date: Sat, 18 Jul 2015 11:57:06 -0400 Subject: [cmake-developers] Listing all targets (was: Wrapping functions in CMake) In-Reply-To: References: <55A65BDA.4010808@kitware.com> <20150717141401.GB31310@megas.kitware.com> <20150717175424.GA26601@megas.kitware.com> <20150717185536.GA31013@megas.kitware.com> Message-ID: You're welcome. The key to using it effectively, of course, is using it at the very bottom of the top level CMakeLists.txt file. It can only report on the targets defined so far, so if you put it in the middle somewhere, targets may be defined after you use it, and you'll miss them... D On Saturday, July 18, 2015, Clifford Yapp wrote: > On Fri, Jul 17, 2015 at 6:05 PM, David Cole > wrote: > > Attached is a patch file of my first attempt. I can iterate some more > > on this (better testing, add docs, clarify existing docs, address > > anybody's comments, submit to stage) next week. Attached now in case > > anybody wants to try it out over the weekend. > > David, > > Awesome - thank you for doing that! (Way faster than I would have been > able to set it up). > > It may be Monday before I can put it through it's paces, but I'll > definitely give this a go and also see if I can combine it with the > SOURCES target property Brad pointed out to kill two problems with one > patch. > > I'll try to get at figuring out how to set up GLOBAL properties for > collecting various types of message outputs and prepare a patch for > that on Monday as well, unless someone else gets to it sooner. > > Cheers, > CY > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cliffyapp at gmail.com Sat Jul 18 13:49:17 2015 From: cliffyapp at gmail.com (Clifford Yapp) Date: Sat, 18 Jul 2015 13:49:17 -0400 Subject: [cmake-developers] Listing source-tree files encountered In-Reply-To: <55AA1CBF.6020107@gmail.com> References: <55A65BE1.3000509@kitware.com> <55A9243A.5000500@kitware.com> <55AA1CBF.6020107@gmail.com> Message-ID: On Sat, Jul 18, 2015 at 5:30 AM, Florent Castelli wrote: > I've used that once and you end up with the relative path to the sources > from the CMakeLists.txt. > If you're in another CMakeLists.txt, then you can't use the paths directly. > I tried a few properties but I couldn't find any property to get the folder > where the target was defined. > > How do you get the full path? That's a very good point - using the command override approach, the CMAKE_CURRENT_SOURCE_DIR is always the directory of the target in question, and looking at our current code I see we do make use of that assumption. We would need a way to find out what CMAKE_CURRENT_SOURCE_DIR was when the target was defined if we're going to build up a list after the fact - maybe something like get_target_property(TDIR SOURCE_DIR) to get the source directory in which the target was defined. In combination with the SOURCES property it would allow for full path reconstruction. CY From steveire at gmail.com Sat Jul 18 14:03:44 2015 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 18 Jul 2015 20:03:44 +0200 Subject: [cmake-developers] install(EXCLUDE_FROM_ALL) new feature - request for comment References: Message-ID: Nick Lewis wrote: > Thanks for working on this. I think it will be better discussed on the > cmake-developers mailing list I find the title interesting but I didn't attempt to read the email. Please make a proposal instead of just dumping a tree of text which can not be followed: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13700 Thanks, Steve. From cliffyapp at gmail.com Sat Jul 18 14:48:11 2015 From: cliffyapp at gmail.com (Clifford Yapp) Date: Sat, 18 Jul 2015 14:48:11 -0400 Subject: [cmake-developers] Listing source-tree files encountered In-Reply-To: References: <55A65BE1.3000509@kitware.com> <55A9243A.5000500@kitware.com> <55AA1CBF.6020107@gmail.com> Message-ID: On Sat, Jul 18, 2015 at 1:49 PM, Clifford Yapp wrote: > On Sat, Jul 18, 2015 at 5:30 AM, Florent Castelli > wrote: >> I've used that once and you end up with the relative path to the sources >> from the CMakeLists.txt. >> If you're in another CMakeLists.txt, then you can't use the paths directly. >> I tried a few properties but I couldn't find any property to get the folder >> where the target was defined. >> >> How do you get the full path? > > That's a very good point - using the command override approach, the > CMAKE_CURRENT_SOURCE_DIR is always the directory of the target in > question, and looking at our current code I see we do make use of that > assumption. We would need a way to find out what > CMAKE_CURRENT_SOURCE_DIR was when the target was defined if we're > going to build up a list after the fact - maybe something like > get_target_property(TDIR SOURCE_DIR) to get the source > directory in which the target was defined. In combination with the > SOURCES property it would allow for full path reconstruction. > > CY A quick experiment suggests that this will work for associating and exposing a source directory with each target - not sure if this dots all the i's an crosses all the t's though: diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx index 2b73e6f..c9281b7 100644 --- a/Source/cmTarget.cxx +++ b/Source/cmTarget.cxx @@ -2945,6 +2945,7 @@ const char *cmTarget::GetProperty(const std::string& prop, MAKE_STATIC_PROP(COMPILE_DEFINITIONS); MAKE_STATIC_PROP(IMPORTED); MAKE_STATIC_PROP(NAME); + MAKE_STATIC_PROP(SOURCE_DIR); MAKE_STATIC_PROP(SOURCES); #undef MAKE_STATIC_PROP if(specialProps.empty()) @@ -2957,6 +2958,7 @@ const char *cmTarget::GetProperty(const std::string& prop, specialProps.insert(propCOMPILE_DEFINITIONS); specialProps.insert(propIMPORTED); specialProps.insert(propNAME); + specialProps.insert(propSOURCE_DIR); specialProps.insert(propSOURCES); } if(specialProps.count(prop)) @@ -3039,6 +3041,10 @@ const char *cmTarget::GetProperty(const std::string& prop, { return this->GetName().c_str(); } + else if (prop == propSOURCE_DIR) + { + return this->GetMakefile()->GetCurrentSourceDirectory(); + } else if(prop == propSOURCES) { if (this->Internal->SourceEntries.empty()) From cliffyapp at gmail.com Sat Jul 18 15:45:49 2015 From: cliffyapp at gmail.com (Clifford Yapp) Date: Sat, 18 Jul 2015 15:45:49 -0400 Subject: [cmake-developers] Capturing messages to log files (was: Wrapping functions in CMake) In-Reply-To: <55A65BD5.5000903@kitware.com> References: <55A65BD5.5000903@kitware.com> Message-ID: On Wed, Jul 15, 2015 at 9:10 AM, Brad King wrote: > On 07/09/2015 01:53 PM, Clifford Yapp wrote: >> Actually, thinking about that, what's really needed is not an >> in-memory log but a way to specify log files, since an unexpected >> crash or exit is not a situation under which such in-memory logs could >> be reliably written to disk. So it would instead need to be >> CMAKE_STATUS_MESSAGE_LOG, CMAKE_ERROR_MESSAGES_LOG, etc. which would >> hold paths to which messages would be copied before being written to >> stdout/stderr. > > These could be defined as GLOBAL properties since there can only > be one. Internally we already have callback infrastructure to > dispatch where these messages go. Hooks could be added to check > these properties too. Or, the property setting logic could have > special handling for these properties to install the needed > callbacks internally. This approach would avoid opening/closing > the log files over and over. We could just keep them open all > the time and flush after each write. Brad, Am I correct that cmSystemTools::Message is the gateway through which all of the console output from CMake exits? If so, perhaps the simplest thing to do is simply allow copying to a log file at that point? It would be nice to have files containing only errors, only warnings, etc. but it's not immediately clear to me how to set something like that up... CY From cliffyapp at gmail.com Sat Jul 18 15:48:08 2015 From: cliffyapp at gmail.com (Clifford Yapp) Date: Sat, 18 Jul 2015 15:48:08 -0400 Subject: [cmake-developers] Listing source-tree files encountered In-Reply-To: References: <55A65BE1.3000509@kitware.com> <55A9243A.5000500@kitware.com> <55AA1CBF.6020107@gmail.com> Message-ID: With David's patch and the above SOURCE_DIR property, it looks like the necessary pieces are now present for target + source processing. A quick test: get_cmake_property(target_list TARGETS) list(SORT target_list) foreach(targ ${target_list}) get_target_property(ttype ${targ} TYPE) if (NOT "${ttype}" STREQUAL "UTILITY") message("checking files of ${targ}(${ttype}): ") get_target_property(tdir ${targ} SOURCE_DIR) get_target_property(tsrcs ${targ} SOURCES) foreach(fsrc ${tsrcs}) if(NOT EXISTS ${tdir}/${fsrc}) message("NOT PRESENT: ${tdir}/${fsrc}") else(NOT EXISTS ${tdir}/${fsrc}) message("found: ${tdir}/${fsrc}") endif(NOT EXISTS ${tdir}/${fsrc}) endforeach(fsrc ${tsrcs}) endif (NOT "${ttype}" STREQUAL "UTILITY") endforeach(targ ${target_list}) returns the expected results, finding files that are present in the source directories and listed in the target definition with a relative path. Very nice! I believe this combination of abilities will also allow me to avoid the add_subdirectory wrapping, since the set of directories from all targets should be pretty close to the set of directories added via add_subdirectory (warrants a quick test, but probably close enough.) CY From ralf.habacker at freenet.de Sun Jul 19 15:07:15 2015 From: ralf.habacker at freenet.de (Ralf Habacker) Date: Sun, 19 Jul 2015 21:07:15 +0200 Subject: [cmake-developers] Patch for FindBZip2.cmake BZIP2_NEED_PREFIX issue with cross compiled mingw32 applications Message-ID: <55ABF563.9010001@freenet.de> Hi, the appended patch fixes an issue I have with recent cmake (3.2.3) with cross compiling an mingw32 application. The applications requires bzip2 library which is handled by cmake provided FindBZip2.cmake. The problem is that BZIP2_NEED_PREFIX is not set where it should be and results into linker failure not finding bzip2 related symbols. Some details: FindBZip2.cmake uses BZ2_bzCompressInit to detect if BZIP2_NEED_PREFIX should be set. CHECK_LIBRARY_EXISTS("${BZIP2_LIBRARIES}" BZ2_bzCompressInit "" BZIP2_NEED_PREFIX) The check is performed with CheckFunctionExists.c, which converts the function name into a prototype of the form 'char BZ2_bzCompressInit()', while in real it is int BZ2_bzCompressInit ( bz_stream *strm, int blockSize100k, int verbosity, int workFactor ); The compiler converts this function to the symbol '_BZ2_bzCompressInit', which is not in the related import library. Taking a look into the related import library shows that there is objdump -x /usr/i686-w64-mingw32/sys-root/mingw/lib/libbz2.dll.a | grep CompressInit [ 6](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 _BZ2_bzCompressInit at 16 [ 7](sec 3)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 __imp__BZ2_bzCompressInit at 16 The '@16' indicates the size of the parameter list (https://msdn.microsoft.com/en-us/library/zxk0tw93.aspx) with does match the used prototype 'char BZ2_bzCompressInit().' The fix is to use a function which do not have parameters like BZ2_decompress. objdump -x /usr/i686-w64-mingw32/sys-root/mingw/lib/libbz2.dll.a | grep decompress [ 6](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 _BZ2_decompress [ 7](sec 3)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 __imp__BZ2_decompress The appended patch fixes this issue. Regards Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: findbzip2-need-prefix.patch Type: text/x-patch Size: 541 bytes Desc: not available URL: From ralf.habacker at freenet.de Sun Jul 19 15:55:54 2015 From: ralf.habacker at freenet.de (Ralf Habacker) Date: Sun, 19 Jul 2015 21:55:54 +0200 Subject: [cmake-developers] Patch for FindBZip2.cmake BZIP2_NEED_PREFIX issue with cross compiled mingw32 applications In-Reply-To: <55ABF563.9010001@freenet.de> References: <55ABF563.9010001@freenet.de> Message-ID: <55AC00CA.8070900@freenet.de> Am 19.07.2015 um 21:07 schrieb Ralf Habacker: > with does match s/does/does not/ From david at zemon.name Mon Jul 20 00:00:24 2015 From: david at zemon.name (David Zemon) Date: Sun, 19 Jul 2015 23:00:24 -0500 Subject: [cmake-developers] Build OS X packages with CPack from Ubuntu Message-ID: <55AC7258.3090100@zemon.name> Hello, I'd like to build OS X packages for my project. Is that possible with CPack? My project doesn't actually have any native binaries - it's for embedded systems - so I don't need to cross-compile or anything. The installation is very simple and, on Linux, looks like this: * /usr/PropWare/ o include/ Contains headers for embedded target o lib/ Contains static libraries for embedded target o version.txt Version file * /usr/pwcmake/ o CMake binary distribution downloaded from cmake.org - I just add a few extra config files specific to my embedded target to make configuration a bit easier * /usr/bin/ o cmake -> /usr/pwcmake/bin/cmake o cpack -> /usr/pwcmake/bin/cpack o .... (sym links to each of the executables in CMake) That's it! Really simple. But when I run "cpack --help", the list of generators at the bottom doesn't include anything for Mac. Generators 7Z = 7-Zip file format DEB = Debian packages IFW = Qt Installer Framework NSIS = Null Soft Installer NSIS64 = Null Soft Installer (64-bit) RPM = RPM packages STGZ = Self extracting Tar GZip compression TBZ2 = Tar BZip2 compression TGZ = Tar GZip compression TXZ = Tar XZ compression TZ = Tar Compress compression ZIP = ZIP file format Am I dreaming? Can I package my software for Mac from Linux or am I just SOL? Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Jul 20 09:30:29 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 20 Jul 2015 09:30:29 -0400 Subject: [cmake-developers] Listing all targets In-Reply-To: References: <55A65BDA.4010808@kitware.com> <20150717141401.GB31310@megas.kitware.com> <20150717175424.GA26601@megas.kitware.com> <20150717185536.GA31013@megas.kitware.com> Message-ID: <55ACF7F5.1040702@kitware.com> On 07/17/2015 06:05 PM, David Cole via cmake-developers wrote: > Attached is a patch file of my first attempt. I can iterate some more > on this (better testing, add docs, clarify existing docs, address > anybody's comments, submit to stage) next week. Attached now in case > anybody wants to try it out over the weekend. [snip] >> I think the see also is relevant because it points to another way to >> get to a whole different set of "properties". Perhaps what they're >> looking for when they stumble upon get_cmake_property is actually >> target properties, which are only accessible via get_property. get_cmake_property is get_property with the GLOBAL scope, except that it looks like the special VARIABLES, MACROS, and COMPONENTS properties are hard-coded into get_cmake_property incorrectly. This should all be moved over to cmState::GetGlobalProperty and the new TARGETS property added there. That method already has special handling for a few other properties too. Also the documentation of get_cmake_property should be updated to mention "global" properties. -Brad From brad.king at kitware.com Mon Jul 20 09:33:54 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 20 Jul 2015 09:33:54 -0400 Subject: [cmake-developers] Listing source-tree files encountered In-Reply-To: References: <55A65BE1.3000509@kitware.com> <55A9243A.5000500@kitware.com> <55AA1CBF.6020107@gmail.com> Message-ID: <55ACF8C2.4030402@kitware.com> On 07/18/2015 02:48 PM, Clifford Yapp wrote: > A quick experiment suggests that this will work for associating and > exposing a source directory with each target - not sure if this dots > all the i's an crosses all the t's though: > > + MAKE_STATIC_PROP(SOURCE_DIR); That looks good to me. Please extend the patch to also do BINARY_DIR for completeness and also to update the documentation to cover the new properties. The Tests/RunCMake/get_property test should be updated to cover both too. Thanks, -Brad From brad.king at kitware.com Mon Jul 20 09:36:48 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 20 Jul 2015 09:36:48 -0400 Subject: [cmake-developers] Capturing messages to log files In-Reply-To: References: <55A65BD5.5000903@kitware.com> Message-ID: <55ACF970.8070208@kitware.com> On 07/18/2015 03:45 PM, Clifford Yapp wrote: > Am I correct that cmSystemTools::Message is the gateway through which > all of the console output from CMake exits? If so, perhaps the > simplest thing to do is simply allow copying to a log file at that > point? It would be nice to have files containing only errors, only > warnings, etc. but it's not immediately clear to me how to set > something like that up... Look at Source/QtDialog/QCMake.cxx for use of SetStdoutCallback, SetStderrCallback, SetMessageCallback, and SetProgressCallback. The cmake-gui uses those to capture everything for display in the dialog. -Brad From brad.king at kitware.com Mon Jul 20 09:41:41 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 20 Jul 2015 09:41:41 -0400 Subject: [cmake-developers] Build OS X packages with CPack from Ubuntu In-Reply-To: <55AC7258.3090100@zemon.name> References: <55AC7258.3090100@zemon.name> Message-ID: <55ACFA95.4050702@kitware.com> On 07/20/2015 12:00 AM, David Zemon wrote: > Can I package my software for Mac from Linux or am I just SOL? That depends on whether tools to make .dmg files are available on Linux. If so, CPack would have to be taught what to do. -Brad From brad.king at kitware.com Mon Jul 20 10:51:27 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 20 Jul 2015 10:51:27 -0400 Subject: [cmake-developers] [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES if non-empty In-Reply-To: References: <55A9221F.5030808@kitware.com> Message-ID: <55AD0AEF.1040305@kitware.com> On 07/17/2015 01:43 PM, Tam?s Ken?z wrote: > We feed our static lib and the list of its dependencies to the > `libtool` to create an amalgamated, standalone static library. > This is an iOS-specific issue Okay, and of course that needs to include imported static libraries. > Anyway, I understand if `CMakeExpandImportedTargets' doesn't fit > the current concepts. We will then use a local modified copy of > it or try to solve the issue by `install(CODE ..)` to postpone > the amalgamation to install time where the generator expressions > can be resolved. Yes, a locally-maintained solution can work for you without solving the problem in the general case which is much harder. Thanks, -Brad From DLRdave at aol.com Mon Jul 20 13:32:57 2015 From: DLRdave at aol.com (David Cole) Date: Mon, 20 Jul 2015 13:32:57 -0400 Subject: [cmake-developers] Listing all targets In-Reply-To: <55ACF7F5.1040702@kitware.com> References: <55A65BDA.4010808@kitware.com> <20150717141401.GB31310@megas.kitware.com> <20150717175424.GA26601@megas.kitware.com> <20150717185536.GA31013@megas.kitware.com> <55ACF7F5.1040702@kitware.com> Message-ID: Thanks for the comments. I'll incorporate these into my next iteration... On Mon, Jul 20, 2015 at 9:30 AM, Brad King wrote: > On 07/17/2015 06:05 PM, David Cole via cmake-developers wrote: >> Attached is a patch file of my first attempt. I can iterate some more >> on this (better testing, add docs, clarify existing docs, address >> anybody's comments, submit to stage) next week. Attached now in case >> anybody wants to try it out over the weekend. > [snip] >>> I think the see also is relevant because it points to another way to >>> get to a whole different set of "properties". Perhaps what they're >>> looking for when they stumble upon get_cmake_property is actually >>> target properties, which are only accessible via get_property. > > get_cmake_property is get_property with the GLOBAL scope, except that > it looks like the special VARIABLES, MACROS, and COMPONENTS properties > are hard-coded into get_cmake_property incorrectly. > > This should all be moved over to cmState::GetGlobalProperty and the > new TARGETS property added there. That method already has special > handling for a few other properties too. > > Also the documentation of get_cmake_property should be updated to > mention "global" properties. > > -Brad > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers From cliffyapp at gmail.com Mon Jul 20 16:01:29 2015 From: cliffyapp at gmail.com (Clifford Yapp) Date: Mon, 20 Jul 2015 16:01:29 -0400 Subject: [cmake-developers] Listing source-tree files encountered In-Reply-To: <55ACF8C2.4030402@kitware.com> References: <55A65BE1.3000509@kitware.com> <55A9243A.5000500@kitware.com> <55AA1CBF.6020107@gmail.com> <55ACF8C2.4030402@kitware.com> Message-ID: On Mon, Jul 20, 2015 at 9:33 AM, Brad King wrote: > That looks good to me. Please extend the patch to also do BINARY_DIR > for completeness and also to update the documentation to cover the new > properties. The Tests/RunCMake/get_property test should be updated > to cover both too. I've put both in and added the man pages - progress so far attached. Are there any other docs that list target properties, or are the rst files the canonical sources for property docs? For testing these properties, what would you suggest? They're intended to report local configure-time absolute paths, which can't be hard coded... is it enough to check them to make sure they're not empty or is there something more robust that could be devised?" Thanks, CY -------------- next part -------------- diff --git a/Help/manual/cmake-properties.7.rst b/Help/manual/cmake-properties.7.rst index 1d27a64..ac893c2 100644 --- a/Help/manual/cmake-properties.7.rst +++ b/Help/manual/cmake-properties.7.rst @@ -114,6 +114,7 @@ Properties on Targets /prop_tgt/AUTOUIC_OPTIONS /prop_tgt/AUTORCC /prop_tgt/AUTORCC_OPTIONS + /prop_tgt/BINARY_DIR /prop_tgt/BUILD_WITH_INSTALL_RPATH /prop_tgt/BUNDLE_EXTENSION /prop_tgt/BUNDLE @@ -244,6 +245,7 @@ Properties on Targets /prop_tgt/RUNTIME_OUTPUT_NAME_CONFIG /prop_tgt/RUNTIME_OUTPUT_NAME /prop_tgt/SKIP_BUILD_RPATH + /prop_tgt/SOURCE_DIR /prop_tgt/SOURCES /prop_tgt/SOVERSION /prop_tgt/STATIC_LIBRARY_FLAGS_CONFIG diff --git a/Help/prop_tgt/BINARY_DIR.rst b/Help/prop_tgt/BINARY_DIR.rst new file mode 100644 index 0000000..a6c1c12 --- /dev/null +++ b/Help/prop_tgt/BINARY_DIR.rst @@ -0,0 +1,4 @@ +BINARY_DIR +---------- + +Reports the value of CMAKE_CURRENT_BINARY_DIR in the directory in which the target was defined. diff --git a/Help/prop_tgt/SOURCE_DIR.rst b/Help/prop_tgt/SOURCE_DIR.rst new file mode 100644 index 0000000..de93f29 --- /dev/null +++ b/Help/prop_tgt/SOURCE_DIR.rst @@ -0,0 +1,4 @@ +SOURCE_DIR +---------- + +Reports the value of CMAKE_CURRENT_SOURCE_DIR in the directory in which the target was defined. diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx index 0303f1e..ff4f161 100644 --- a/Source/cmTarget.cxx +++ b/Source/cmTarget.cxx @@ -2959,6 +2959,8 @@ const char *cmTarget::GetProperty(const std::string& prop, MAKE_STATIC_PROP(COMPILE_DEFINITIONS); MAKE_STATIC_PROP(IMPORTED); MAKE_STATIC_PROP(NAME); + MAKE_STATIC_PROP(BINARY_DIR); + MAKE_STATIC_PROP(SOURCE_DIR); MAKE_STATIC_PROP(SOURCES); #undef MAKE_STATIC_PROP if(specialProps.empty()) @@ -2971,6 +2973,8 @@ const char *cmTarget::GetProperty(const std::string& prop, specialProps.insert(propCOMPILE_DEFINITIONS); specialProps.insert(propIMPORTED); specialProps.insert(propNAME); + specialProps.insert(propBINARY_DIR); + specialProps.insert(propSOURCE_DIR); specialProps.insert(propSOURCES); } if(specialProps.count(prop)) @@ -3053,6 +3057,14 @@ const char *cmTarget::GetProperty(const std::string& prop, { return this->GetName().c_str(); } + else if (prop == propBINARY_DIR) + { + return this->GetMakefile()->GetCurrentBinaryDirectory(); + } + else if (prop == propSOURCE_DIR) + { + return this->GetMakefile()->GetCurrentSourceDirectory(); + } else if(prop == propSOURCES) { if (this->Internal->SourceEntries.empty()) From ben.boeckel at kitware.com Mon Jul 20 16:42:31 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 20 Jul 2015 16:42:31 -0400 Subject: [cmake-developers] Listing source-tree files encountered In-Reply-To: References: <55A65BE1.3000509@kitware.com> <55A9243A.5000500@kitware.com> <55AA1CBF.6020107@gmail.com> <55ACF8C2.4030402@kitware.com> Message-ID: <20150720204231.GA6364@megas.kitware.com> On Mon, Jul 20, 2015 at 16:01:29 -0400, Clifford Yapp wrote: > I've put both in and added the man pages - progress so far attached. > Are there any other docs that list target properties, or are the rst > files the canonical sources for property docs? Those should be it. > For testing these properties, what would you suggest? They're > intended to report local configure-time absolute paths, which can't be > hard coded... is it enough to check them to make sure they're not > empty or is there something more robust that could be devised?" They should end with the path under the CMake source tree at least (I assume they are absolute?). Try matching this regex: .*/Testing/RunCMake/get_property possibly? You can also put the test under an add_subdirectory() call as well. Other things that come to mind: symlink resolution[1] and how relative paths are handled (if they aren't absolute). Thanks, --Ben [1]My setup is: $HOME/code/cmake -> depot/group-bld/cmake What is the difference if $PWD is $HOME/code/cmake/build versus $HOME/code/depot/group-bld/cmake/build? I doubt this is something that fits in the test suite, but a double test would be good at least. From roman.wueger at gmx.at Tue Jul 21 04:12:34 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Tue, 21 Jul 2015 10:12:34 +0200 Subject: [cmake-developers] CTest threshold exceeds 1024 bytes Message-ID: <26A7A5F1-8B9C-40A1-85B0-40AD29A0FF54@gmx.at> Hello, when I run CTest from the command line with the same parameters as on the build server, then everything is working fine. If I run the command on the build server then I get a message which says that the threshold of 1024 bytes are exceeded. The output are "debug" messages and not failures. I have the output on CDash and on Jenkins. Here is the command which I call: "ctest -C Release --output-on-failure --no-compress-output -T test" Is there a way to get the full output without modifying every CMake Script of about ~ 35 projects? Thanks in advance Best Regards Roman From mantis at public.kitware.com Tue Jul 21 07:16:36 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 21 Jul 2015 07:16:36 -0400 Subject: [cmake-developers] [CMake 0015657]: cmTarget::GetOutputInfo called for mytarget which has type UTILITY (CMake Internal Error) Message-ID: <374371eb581cb58f074ec6a46bce673f@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15657 ====================================================================== Reported By: Erik Sj?lund Assigned To: ====================================================================== Project: CMake Issue ID: 15657 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-21 07:16 EDT Last Modified: 2015-07-21 07:16 EDT ====================================================================== Summary: cmTarget::GetOutputInfo called for mytarget which has type UTILITY (CMake Internal Error) Description: I was experimenting with exporting. I don't know if the content of the CMakeLists.txt makes sense but CMake told me to report a bug: "CMake Internal Error (please report a bug)" Here is the content of the CMakeLists.txt file: cmake_minimum_required(VERSION 3.3) add_custom_command(OUTPUT empty.txt COMMAND touch empty.txt) add_custom_target(mytarget DEPENDS empty.txt) export(TARGETS mytarget FILE export.cmake) Steps to Reproduce: The shell terminal session is attached as a file (terminal-output.txt). ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-21 07:16 Erik Sj?lund New Issue 2015-07-21 07:16 Erik Sj?lund File Added: terminal-output.txt ====================================================================== From brad.king at kitware.com Tue Jul 21 09:46:55 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 21 Jul 2015 09:46:55 -0400 Subject: [cmake-developers] Patch for FindBZip2.cmake BZIP2_NEED_PREFIX issue with cross compiled mingw32 applications In-Reply-To: <55ABF563.9010001@freenet.de> References: <55ABF563.9010001@freenet.de> Message-ID: <55AE4D4F.9000802@kitware.com> On 07/19/2015 03:07 PM, Ralf Habacker wrote: > The check is performed with CheckFunctionExists.c, which converts the > function name into a prototype of the form 'char BZ2_bzCompressInit()', > while in real it is > > int BZ2_bzCompressInit ( bz_stream *strm, > int blockSize100k, > int verbosity, > int workFactor ); Rather than (or in addition to) changing to _BZ2_decompress, please look at changing the check to use CheckSymbolExists. It allows the actual header to be included so we can test using the library the way the project will. That is likely more robust. Note that you may need to set CMAKE_REQUIRED_INCLUDES and CMAKE_REQUIRED_LIBRARIES to make sure the check is run with the desired bzip2 library. Thanks, -Brad From brad.king at kitware.com Tue Jul 21 09:53:07 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 21 Jul 2015 09:53:07 -0400 Subject: [cmake-developers] [CMake] CTest threshold exceeds 1024 bytes In-Reply-To: <26A7A5F1-8B9C-40A1-85B0-40AD29A0FF54@gmx.at> References: <26A7A5F1-8B9C-40A1-85B0-40AD29A0FF54@gmx.at> Message-ID: <55AE4EC3.8050607@kitware.com> On 07/21/2015 04:12 AM, Roman W?ger wrote: > Is there a way to get the full output without modifying every > CMake Script of about ~ 35 projects? CTest always truncates the output of passing tests unless the test output contains the literal text "CTEST_FULL_OUTPUT". This was done long ago to limit the size of submissions of passed tests. CTest will have to be taught an option to skip this. Take a look at the definition and uses of CleanTestOutput in Source/CTest. There are already variables like CustomMaximumPassedTestOutputSize internally but it looks like there is no way to configure them at runtime. -Brad From brad.king at kitware.com Tue Jul 21 09:57:11 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 21 Jul 2015 09:57:11 -0400 Subject: [cmake-developers] install(EXCLUDE_FROM_ALL) new feature - request for comment In-Reply-To: References: Message-ID: <55AE4FB7.5000209@kitware.com> On 07/18/2015 02:03 PM, Stephen Kelly wrote: > I find the title interesting but I didn't attempt to read the email. > > Please make a proposal instead of just dumping a tree of text For reference, the text is from the issue tracker entry: No way to exclude a component install() from a full installation http://www.cmake.org/Bug/view.php?id=14921 It proposes a patch attached to that entry which I've also attached here. The idea is to define install() rules which are *not* part of the default installation when no component is specified. IIUC then one would need to request the specific component explicitly during installation in order to get it. -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake_3_2_2_install_exclude.patch Type: text/x-diff Size: 23369 bytes Desc: not available URL: From brad.king at kitware.com Tue Jul 21 10:03:42 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 21 Jul 2015 10:03:42 -0400 Subject: [cmake-developers] Generator expressions for output directory In-Reply-To: References: <3fc3c649d1554819b46dc06f738fff9c@CO1PR79MB027.MGDADSK.autodesk.com> <55A914B4.60400@kitware.com> <55A92368.5010605@kitware.com> Message-ID: <55AE513E.2080603@kitware.com> On 07/17/2015 02:34 PM, Robert Goulet wrote: > I'm going to be away for a few weeks, is it ok if the master branch > stays in that state for a while? Okay. I've made a note about this issue to make sure it is fixed before 3.4. Meanwhile I have another comment on genex support in the OUTPUT_DIRECTORY properties. Currently the properties support both {ARCHIVE,LIBRARY,RUNTIME}_OUTPUT_DIRECTORY and {ARCHIVE,LIBRARY,RUNTIME}_OUTPUT_DIRECTORY_ variants. When the former is used CMake will still add the / directory suffix to the end of the value. When the latter is used CMake does not do this. With the former, when a genex like $ is used, it is likely that the user does not want CMake to add the / suffix. Perhaps we should detect when a genex is present in the value and skip adding the suffix, thus trusting the user to have done the right thing (e.g. $<1:value> will still not get a suffix). Of course this would have to be documented carefully. We could also disallow a genex in the latter (per-config) variants to encourage modern use of the former. -Brad From ralf.habacker at freenet.de Tue Jul 21 10:32:49 2015 From: ralf.habacker at freenet.de (Ralf Habacker) Date: Tue, 21 Jul 2015 16:32:49 +0200 Subject: [cmake-developers] Patch for FindBZip2.cmake BZIP2_NEED_PREFIX issue with cross compiled mingw32 applications In-Reply-To: <55AE4D4F.9000802@kitware.com> References: <55ABF563.9010001@freenet.de> <55AE4D4F.9000802@kitware.com> Message-ID: <55AE5811.3020907@freenet.de> Am 21.07.2015 um 15:46 schrieb Brad King: > Rather than (or in addition to) changing to _BZ2_decompress, please look > at changing the check to use CheckSymbolExists. It allows the actual > header to be included so we can test using the library the way the > project will. That is likely more robust. Note that you may need > to set CMAKE_REQUIRED_INCLUDES and CMAKE_REQUIRED_LIBRARIES to make > sure the check is run with the desired bzip2 library. Changed to use CheckSymbolExists, see append patch. Regards Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: findbzip2-mingw-need-prefix-fix.patch Type: text/x-patch Size: 766 bytes Desc: not available URL: From brad.king at kitware.com Tue Jul 21 10:43:47 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 21 Jul 2015 10:43:47 -0400 Subject: [cmake-developers] Patch for FindBZip2.cmake BZIP2_NEED_PREFIX issue with cross compiled mingw32 applications In-Reply-To: <55AE5811.3020907@freenet.de> References: <55ABF563.9010001@freenet.de> <55AE4D4F.9000802@kitware.com> <55AE5811.3020907@freenet.de> Message-ID: <55AE5AA3.9030406@kitware.com> On 07/21/2015 10:32 AM, Ralf Habacker wrote: > Changed to use CheckSymbolExists, see append patch. Thanks. We'll also need to set CMAKE_REQUIRED_INCLUDES to ensure the correct bzlib.h header can be found when it is not in a system default location. Thanks, -Brad From mantis at public.kitware.com Tue Jul 21 11:19:22 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 21 Jul 2015 11:19:22 -0400 Subject: [cmake-developers] [CMake 0015658]: Allow generator expressions in add_custom_command (and add_custom_target) Message-ID: <4736617075dac89c00939201a1d9ba25@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15658 ====================================================================== Reported By: Ben Boeckel Assigned To: ====================================================================== Project: CMake Issue ID: 15658 Category: CMake Reproducibility: have not tried Severity: minor Priority: normal Status: new Target Version: CMake 3.4 ====================================================================== Date Submitted: 2015-07-21 11:19 EDT Last Modified: 2015-07-21 11:19 EDT ====================================================================== Summary: Allow generator expressions in add_custom_command (and add_custom_target) Description: Now that LOCATION is disallowed, using a target path as an argument to a custom command is not possible without warnings (or making CMP0026 OLD). At least OUTPUT, COMMAND, MAIN_DEPENDENCY, DEPENDS, WORKING_DIRECTORY, and SOURCES (for a_c_t) should expand generator expressions. Some may already do so via properties being genex-expanded already (just WORKING_DIRECTORY IIRC). ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-21 11:19 Ben Boeckel New Issue ====================================================================== From ben.boeckel at kitware.com Tue Jul 21 11:24:15 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 21 Jul 2015 11:24:15 -0400 Subject: [cmake-developers] Generator expressions for output directory In-Reply-To: <55AE513E.2080603@kitware.com> References: <3fc3c649d1554819b46dc06f738fff9c@CO1PR79MB027.MGDADSK.autodesk.com> <55A914B4.60400@kitware.com> <55A92368.5010605@kitware.com> <55AE513E.2080603@kitware.com> Message-ID: <20150721152415.GB10451@megas.kitware.com> On Tue, Jul 21, 2015 at 10:03:42 -0400, Brad King wrote: > Okay. I've made a note about this issue to make sure it is fixed before 3.4. > > Meanwhile I have another comment on genex support in the OUTPUT_DIRECTORY > properties. Currently the properties support both > > {ARCHIVE,LIBRARY,RUNTIME}_OUTPUT_DIRECTORY > > and > > {ARCHIVE,LIBRARY,RUNTIME}_OUTPUT_DIRECTORY_ > > variants. When the former is used CMake will still add the / > directory suffix to the end of the value. When the latter is used > CMake does not do this. > > With the former, when a genex like $ is used, it is likely > that the user does not want CMake to add the / suffix. > Perhaps we should detect when a genex is present in the value and > skip adding the suffix, thus trusting the user to have done the right > thing (e.g. $<1:value> will still not get a suffix). +1 The main use case I've come across is when generating modules for languages using CMake. Generally, there you want: ${common_output_path}/$/path/to/module.so since the interpreter searches using the last path parts from the module import (here, 'path.to.module'). The only way to reliable do it right is to iterate over CMAKE_CONFIGURATION_TYPES and set the properties that way with ${CMAKE_CFGINT_DIR}. > Of course this would have to be documented carefully. We could also > disallow a genex in the latter (per-config) variants to encourage > modern use of the former. +1 --Ben From cliffyapp at gmail.com Tue Jul 21 11:57:22 2015 From: cliffyapp at gmail.com (Clifford Yapp) Date: Tue, 21 Jul 2015 11:57:22 -0400 Subject: [cmake-developers] Listing source-tree files encountered In-Reply-To: <20150720204231.GA6364@megas.kitware.com> References: <55A65BE1.3000509@kitware.com> <55A9243A.5000500@kitware.com> <55AA1CBF.6020107@gmail.com> <55ACF8C2.4030402@kitware.com> <20150720204231.GA6364@megas.kitware.com> Message-ID: On Mon, Jul 20, 2015 at 4:42 PM, Ben Boeckel wrote: >> For testing these properties, what would you suggest? They're >> intended to report local configure-time absolute paths, which can't be >> hard coded... is it enough to check them to make sure they're not >> empty or is there something more robust that could be devised?" > > They should end with the path under the CMake source tree at least (I > assume they are absolute?). Try matching this regex: > > .*/Testing/RunCMake/get_property > > possibly? You can also put the test under an add_subdirectory() call as > well. The attached patch seems to work - Brad, should I submit this to the issue tracker? If it needs any more tweaking let me know. Looking at the target properties test, should there also be a test for the SOURCES property? The SOURCE_DIR property in particular is intended to work with the current behavior (relative path lists unless original target specifier is a full path) from SOURCES, so IMHO it might be a good idea to put a test in for that as well... Cheers, CY -------------- next part -------------- diff --git a/Help/manual/cmake-properties.7.rst b/Help/manual/cmake-properties.7.rst index 1d27a64..ac893c2 100644 --- a/Help/manual/cmake-properties.7.rst +++ b/Help/manual/cmake-properties.7.rst @@ -114,6 +114,7 @@ Properties on Targets /prop_tgt/AUTOUIC_OPTIONS /prop_tgt/AUTORCC /prop_tgt/AUTORCC_OPTIONS + /prop_tgt/BINARY_DIR /prop_tgt/BUILD_WITH_INSTALL_RPATH /prop_tgt/BUNDLE_EXTENSION /prop_tgt/BUNDLE @@ -244,6 +245,7 @@ Properties on Targets /prop_tgt/RUNTIME_OUTPUT_NAME_CONFIG /prop_tgt/RUNTIME_OUTPUT_NAME /prop_tgt/SKIP_BUILD_RPATH + /prop_tgt/SOURCE_DIR /prop_tgt/SOURCES /prop_tgt/SOVERSION /prop_tgt/STATIC_LIBRARY_FLAGS_CONFIG diff --git a/Help/prop_tgt/BINARY_DIR.rst b/Help/prop_tgt/BINARY_DIR.rst new file mode 100644 index 0000000..a6c1c12 --- /dev/null +++ b/Help/prop_tgt/BINARY_DIR.rst @@ -0,0 +1,4 @@ +BINARY_DIR +---------- + +Reports the value of CMAKE_CURRENT_BINARY_DIR in the directory in which the target was defined. diff --git a/Help/prop_tgt/SOURCE_DIR.rst b/Help/prop_tgt/SOURCE_DIR.rst new file mode 100644 index 0000000..de93f29 --- /dev/null +++ b/Help/prop_tgt/SOURCE_DIR.rst @@ -0,0 +1,4 @@ +SOURCE_DIR +---------- + +Reports the value of CMAKE_CURRENT_SOURCE_DIR in the directory in which the target was defined. diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx index 0303f1e..ff4f161 100644 --- a/Source/cmTarget.cxx +++ b/Source/cmTarget.cxx @@ -2959,6 +2959,8 @@ const char *cmTarget::GetProperty(const std::string& prop, MAKE_STATIC_PROP(COMPILE_DEFINITIONS); MAKE_STATIC_PROP(IMPORTED); MAKE_STATIC_PROP(NAME); + MAKE_STATIC_PROP(BINARY_DIR); + MAKE_STATIC_PROP(SOURCE_DIR); MAKE_STATIC_PROP(SOURCES); #undef MAKE_STATIC_PROP if(specialProps.empty()) @@ -2971,6 +2973,8 @@ const char *cmTarget::GetProperty(const std::string& prop, specialProps.insert(propCOMPILE_DEFINITIONS); specialProps.insert(propIMPORTED); specialProps.insert(propNAME); + specialProps.insert(propBINARY_DIR); + specialProps.insert(propSOURCE_DIR); specialProps.insert(propSOURCES); } if(specialProps.count(prop)) @@ -3053,6 +3057,14 @@ const char *cmTarget::GetProperty(const std::string& prop, { return this->GetName().c_str(); } + else if (prop == propBINARY_DIR) + { + return this->GetMakefile()->GetCurrentBinaryDirectory(); + } + else if (prop == propSOURCE_DIR) + { + return this->GetMakefile()->GetCurrentSourceDirectory(); + } else if(prop == propSOURCES) { if (this->Internal->SourceEntries.empty()) diff --git a/Tests/RunCMake/get_property/target_properties-stderr.txt b/Tests/RunCMake/get_property/target_properties-stderr.txt index d0981ac..8a06b38 100644 --- a/Tests/RunCMake/get_property/target_properties-stderr.txt +++ b/Tests/RunCMake/get_property/target_properties-stderr.txt @@ -3,4 +3,9 @@ get_property: --><-- get_target_property: -->value<-- get_property: -->value<-- get_target_property: -->gtp_val-NOTFOUND<-- -get_property: --><--$ +get_property: --><-- +get_target_property: -->(.*)Tests/RunCMake/get_property<-- +get_property: -->(.*)Tests/RunCMake/get_property<-- +get_target_property: -->(.*)Tests/RunCMake/get_property/target_properties-build<-- +get_property: -->(.*)Tests/RunCMake/get_property/target_properties-build<--$ + diff --git a/Tests/RunCMake/get_property/target_properties.cmake b/Tests/RunCMake/get_property/target_properties.cmake index c5a141d..9ff833a 100644 --- a/Tests/RunCMake/get_property/target_properties.cmake +++ b/Tests/RunCMake/get_property/target_properties.cmake @@ -14,3 +14,5 @@ set_target_properties(tgt PROPERTIES empty "" custom value) check_target_property(tgt empty) check_target_property(tgt custom) check_target_property(tgt noexist) +check_target_property(tgt SOURCE_DIR) +check_target_property(tgt BINARY_DIR) From ralf.habacker at freenet.de Tue Jul 21 12:10:16 2015 From: ralf.habacker at freenet.de (Ralf Habacker) Date: Tue, 21 Jul 2015 18:10:16 +0200 Subject: [cmake-developers] Patch for FindBZip2.cmake BZIP2_NEED_PREFIX issue with cross compiled mingw32 applications In-Reply-To: <55AE5AA3.9030406@kitware.com> References: <55ABF563.9010001@freenet.de> <55AE4D4F.9000802@kitware.com> <55AE5811.3020907@freenet.de> <55AE5AA3.9030406@kitware.com> Message-ID: <55AE6EE8.5070109@freenet.de> Am 21.07.2015 um 16:43 schrieb Brad King: > On 07/21/2015 10:32 AM, Ralf Habacker wrote: >> Changed to use CheckSymbolExists, see append patch. > Thanks. We'll also need to set CMAKE_REQUIRED_INCLUDES to ensure > the correct bzlib.h header can be found when it is not in a system > default location. Thanks for pointing out. I did not had that in mind; updated patch appended Regards Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: findbzip2-mingw-need-prefix-fix.patch Type: text/x-patch Size: 820 bytes Desc: not available URL: From brad.king at kitware.com Tue Jul 21 12:33:30 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 21 Jul 2015 12:33:30 -0400 Subject: [cmake-developers] Listing source-tree files encountered In-Reply-To: References: <55A65BE1.3000509@kitware.com> <55A9243A.5000500@kitware.com> <55AA1CBF.6020107@gmail.com> <55ACF8C2.4030402@kitware.com> <20150720204231.GA6364@megas.kitware.com> Message-ID: <55AE745A.7030600@kitware.com> On 07/21/2015 11:57 AM, Clifford Yapp wrote: > The attached patch seems to work - Brad, should I submit this to the > issue tracker? If it needs any more tweaking let me know. No issue tracker entry needed. CONTRIBUTING.rst explains that the mailing list is preferred. I'll take a look at this when I get a chance. > Looking at the target properties test, should there also be a test for > the SOURCES property? The SOURCE_DIR property in particular is > intended to work with the current behavior (relative path lists unless > original target specifier is a full path) from SOURCES, so IMHO it > might be a good idea to put a test in for that as well... There is some coverage of the SOURCES property in other tests but having a dedicated check for it would be worthwhile too. Thanks, -Brad From cliffyapp at gmail.com Tue Jul 21 12:48:11 2015 From: cliffyapp at gmail.com (Clifford Yapp) Date: Tue, 21 Jul 2015 12:48:11 -0400 Subject: [cmake-developers] Capturing messages to log files In-Reply-To: <55ACF970.8070208@kitware.com> References: <55A65BD5.5000903@kitware.com> <55ACF970.8070208@kitware.com> Message-ID: On Mon, Jul 20, 2015 at 9:36 AM, Brad King wrote: > On 07/18/2015 03:45 PM, Clifford Yapp wrote: >> Am I correct that cmSystemTools::Message is the gateway through which >> all of the console output from CMake exits? If so, perhaps the >> simplest thing to do is simply allow copying to a log file at that >> point? It would be nice to have files containing only errors, only >> warnings, etc. but it's not immediately clear to me how to set >> something like that up... > > Look at Source/QtDialog/QCMake.cxx for use of SetStdoutCallback, > SetStderrCallback, SetMessageCallback, and SetProgressCallback. > The cmake-gui uses those to capture everything for display in > the dialog. > > -Brad Ah - thanks for the pointer. Working on understanding how the various overrides work - cmakemainProgressCallback et. al. and how Qt is handling the various bits. Cheers, CY From brad.king at kitware.com Tue Jul 21 13:56:21 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 21 Jul 2015 13:56:21 -0400 Subject: [cmake-developers] A policy for Policies In-Reply-To: References: <55759F3A.7030003@kitware.com> <5575F56A.50404@kitware.com> <5575FA50.5080208@kitware.com> <5576008C.3040505@kitware.com> <557636B1.9020500@gmail.com> <5576ED34.7090208@kitware.com> <55784507.7000104@kitware.com> <557984FA.4000508@kitware.com> <5582C785.8040005@kitware.com> <558C0FB4.4030009@kitware.com> Message-ID: <55AE87C5.8070700@kitware.com> On 07/01/2015 02:17 PM, Stephen Kelly wrote: > Brad King wrote: >> We need to provide such capabilities so authors that do maintain >> their projects can be confident they've ported away from behavior >> that will later become an error. > > Makes sense to me. I see topic end-Policy-lifetime with commit range e7fbd489..c7512801 currently in 'next', but it doesn't have anything about making things into errors early. I thought we agreed to build that infrastructure first. I guess POLICY_WARNING and POLICY_OPTIONAL_WARNING are a step in that direction but I'd like to see the actual error options be available before we start showing the warnings unconditionally. > I think the warning should indicate which version of CMake introduced the > policy (already the case) and the date that was released. This might provide > the information needed to prioritize that Alex was looking for by instead > asking for the date it would become an error. The problem with such dates is when the policy is introduced we don't know the date of the next release. Even if we had some kind of lookup table maintained as releases are made, the wording of policy messages would then change as a release is made, which is not great for testing. >> Let's skip these for 3.4 and see how the warnings for the 14 policies >> in the above and below groups work out. > > The reason I suggested emitting these unconditional warnings is that we > should establish what the lifecycle of policies actually is. No. My view throughout the conversation in this thread is that we don't know an appropriate length for the lifecycle. We should start by assuming it is longer than some of the oldest policies (e.g. CMP0011) and working our way forward through time. That will let us see how projects handle steps of the lifecycle without aggressively warning even on recently valid code. The lifecycle proposed in commit d5b1839a is way too aggressive. The end-Policy-lifetime topic looks nothing like the schedule or selection of policies discussed in the last few messages of this thread. > Setting a policy to OLD is not designed to be a convenience for the > maintainer of the project, who can schedule appropriate handling of > the policy. Originally it was intended to be exactly that. Not all projects are maintained on the same release schedule that CMake has. If they release only once per year then CMake could be deep into a policy lifecycle as proposed in d5b1839a. Many people skip a few CMake releases at a time and may jump over some of the steps. I think step 2 of that schedule should be at least 3 releases after step 1, but we don't really know yet what the schedule should be as mentioned above. All we've agreed upon in this thread is that 3.4 can emit unconditional warnings for CMP0011 and below and also CMP0024 and CMP0026 (since those are the ones we really want to get rid of and may be frequently set to OLD). Also it should come with options to make the warnings into errors so they are easier to find. -Brad From steveire at gmail.com Tue Jul 21 14:40:40 2015 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 21 Jul 2015 20:40:40 +0200 Subject: [cmake-developers] A policy for Policies References: <55759F3A.7030003@kitware.com> <5575F56A.50404@kitware.com> <5575FA50.5080208@kitware.com> <5576008C.3040505@kitware.com> <557636B1.9020500@gmail.com> <5576ED34.7090208@kitware.com> <55784507.7000104@kitware.com> <557984FA.4000508@kitware.com> <5582C785.8040005@kitware.com> <558C0FB4.4030009@kitware.com> <55AE87C5.8070700@kitware.com> Message-ID: Brad King wrote: > The lifecycle proposed in commit d5b1839a is way too aggressive. The > end-Policy-lifetime topic looks nothing like the schedule or selection > of policies discussed in the last few messages of this thread. Yes. The discussion died after my proposal. I've reverted the branch. Thanks, Steve. From steveire at gmail.com Tue Jul 21 14:50:57 2015 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 21 Jul 2015 20:50:57 +0200 Subject: [cmake-developers] Listing source-tree files encountered References: <55A65BE1.3000509@kitware.com> <55A9243A.5000500@kitware.com> <55AA1CBF.6020107@gmail.com> Message-ID: Clifford Yapp wrote: > With David's patch and the above SOURCE_DIR property, it looks like > the necessary pieces are now present for target + source processing. That might happen to work for brlcad, but it is not really true. CMake looks in the source dir for relative files listed in targets, then the binary dir, then it tries a number of language-specific extensions in each of the source and binary directories. And it does that at generate-time after evaluating generator expressions. And the file extensions it uses as candidates are determined by cmake variables that the user can modify. http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmSourceFile.cxx;h=86f0a7a8;hb=HEAD#l138 So, your cmake function will fail on a target like add_executable(hello # main.cpp exists main # Exists in source dir foo.cpp # Exists in build dir generated_file.cpp # bar.c exists in source dir bar # another_generated_file.h exists in build dir another_generated_file # determined_at_generate_time.cpp exists in source dir $<1:determined_at_generate_time> ) Why not add a generator expression like $ and use that instead? You can implement/define that as creating absolute paths. Thanks, Steve. From brad.king at kitware.com Tue Jul 21 14:55:54 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 21 Jul 2015 14:55:54 -0400 Subject: [cmake-developers] Listing source-tree files encountered In-Reply-To: References: <55A65BE1.3000509@kitware.com> <55A9243A.5000500@kitware.com> <55AA1CBF.6020107@gmail.com> Message-ID: <55AE95BA.9060400@kitware.com> On 07/21/2015 02:50 PM, Stephen Kelly wrote: > Clifford Yapp wrote: > >> With David's patch and the above SOURCE_DIR property, it looks like >> the necessary pieces are now present for target + source processing. > > That might happen to work for brlcad, but it is not really true. The goal here is to get rid of BRL-CAD's need for overriding commands without necessarily solving all the problems in general so long as the changes are independently useful and not specific to BRL-CAD's needs. I think SOURCE_DIR and BINARY_DIR provide useful information, as will the TARGETS global property discussed in another branch of this thread. > Why not add a generator expression like $ and use that > instead? You can implement/define that as creating absolute paths. I would welcome this more complete solution too. -Brad From roman.wueger at gmx.at Tue Jul 21 18:16:37 2015 From: roman.wueger at gmx.at (=?iso-8859-1?Q?Roman_W=FCger?=) Date: Wed, 22 Jul 2015 00:16:37 +0200 Subject: [cmake-developers] [CMake] CTest threshold exceeds 1024 bytes In-Reply-To: <55AE4EC3.8050607@kitware.com> References: <26A7A5F1-8B9C-40A1-85B0-40AD29A0FF54@gmx.at> <55AE4EC3.8050607@kitware.com> Message-ID: <015401d0c402$ea609040$bf21b0c0$@gmx.at> Hi Brad, I've attached a patch which learns CTest to handle it. I hope this patch could be merged. Best Regards Roman > -----Urspr?ngliche Nachricht----- > Von: Brad King [mailto:brad.king at kitware.com] > Gesendet: Dienstag, 21. Juli 2015 15:53 > An: Roman W?ger > Cc: CMake Developer MailingList; CMake MailingList > Betreff: Re: [CMake] CTest threshold exceeds 1024 bytes > > On 07/21/2015 04:12 AM, Roman W?ger wrote: > > Is there a way to get the full output without modifying every CMake > > Script of about ~ 35 projects? > > CTest always truncates the output of passing tests unless the test output > contains the literal text "CTEST_FULL_OUTPUT". > This was done long ago to limit the size of submissions of passed tests. > > CTest will have to be taught an option to skip this. Take a look at the > definition and uses of CleanTestOutput in Source/CTest. > There are already variables like CustomMaximumPassedTestOutputSize > internally but it looks like there is no way to configure them at runtime. > > -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-CTest-learned-to-limit-the-output-of-passed-and-fail.patch Type: application/octet-stream Size: 2949 bytes Desc: not available URL: From erik.sjolund at gmail.com Wed Jul 22 08:25:26 2015 From: erik.sjolund at gmail.com (=?UTF-8?Q?Erik_Sj=C3=B6lund?=) Date: Wed, 22 Jul 2015 14:25:26 +0200 Subject: [cmake-developers] Is this warning really needed: "You have called ADD_LIBRARY for library foobar without any source files."? Message-ID: Hi, I think this warning could be removed: "You have called ADD_LIBRARY for library foobar without any source files. This typically indicates a problem with your CMakeLists.txt file " If you have a function that populates sources to a target, let us say something like this: function(activate_feature target_name) target_sources(${target_name} PRIVATE feature.cc) endfunction() you would like to be able to do add_library(foobar SHARED) activate_feature(foobar) without any CMake warning. I've started using that design scheme more and more. That is, to have a function setting up a target where the target name is given as an input parameter. The nice thing about it is that I can pass both an executable target and a shared library target as input to such a function. cheers, Erik Sj?lund From brad.king at kitware.com Wed Jul 22 11:04:42 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 22 Jul 2015 11:04:42 -0400 Subject: [cmake-developers] Patch for FindBZip2.cmake BZIP2_NEED_PREFIX issue with cross compiled mingw32 applications In-Reply-To: <55AE6EE8.5070109@freenet.de> References: <55ABF563.9010001@freenet.de> <55AE4D4F.9000802@kitware.com> <55AE5811.3020907@freenet.de> <55AE5AA3.9030406@kitware.com> <55AE6EE8.5070109@freenet.de> Message-ID: <55AFB10A.80208@kitware.com> On 07/21/2015 12:10 PM, Ralf Habacker wrote: > updated patch appended Applied, thanks: FindBZip2: Check BZIP2_NEED_PREFIX with real prototype http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=23876eda -Brad From brad.king at kitware.com Wed Jul 22 11:04:54 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 22 Jul 2015 11:04:54 -0400 Subject: [cmake-developers] Listing source-tree files encountered In-Reply-To: <55AE745A.7030600@kitware.com> References: <55A65BE1.3000509@kitware.com> <55A9243A.5000500@kitware.com> <55AA1CBF.6020107@gmail.com> <55ACF8C2.4030402@kitware.com> <20150720204231.GA6364@megas.kitware.com> <55AE745A.7030600@kitware.com> Message-ID: <55AFB116.1090502@kitware.com> On 07/21/2015 12:33 PM, Brad King wrote: > I'll take a look at this when I get a chance. Applied, thanks: Add SOURCE_DIR and BINARY_DIR target properties http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=45c5f8ca > There is some coverage of the SOURCES property in other tests but > having a dedicated check for it would be worthwhile too. This can be provided in a follow-up patch. Thanks, -Brad From brad.king at kitware.com Wed Jul 22 11:10:07 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 22 Jul 2015 11:10:07 -0400 Subject: [cmake-developers] Is this warning really needed: "You have called ADD_LIBRARY for library foobar without any source files."? In-Reply-To: References: Message-ID: <55AFB24F.2010700@kitware.com> On 07/22/2015 08:25 AM, Erik Sj?lund wrote: > I think this warning could be removed: "You have called ADD_LIBRARY > for library foobar without any source files. This typically indicates > a problem with your CMakeLists.txt file " Yes, since we started allowing sources to be modified after the call this warning no longer makes sense. Instead we need to make sure there is a proper diagnostic if at generate time no SOURCES are available. Even if that is already the case we also need to make sure the test suite covers the errors in Tests/RunCMake somewhere, perhaps in new Tests/RunCMake/{add_library,add_executable} cases. Thanks, -Brad From brad.king at kitware.com Wed Jul 22 11:14:37 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 22 Jul 2015 11:14:37 -0400 Subject: [cmake-developers] [CMake] CTest threshold exceeds 1024 bytes In-Reply-To: <015401d0c402$ea609040$bf21b0c0$@gmx.at> References: <26A7A5F1-8B9C-40A1-85B0-40AD29A0FF54@gmx.at> <55AE4EC3.8050607@kitware.com> <015401d0c402$ea609040$bf21b0c0$@gmx.at> Message-ID: <55AFB35D.4000004@kitware.com> On 07/21/2015 06:16 PM, Roman W?ger wrote: > I've attached a patch which learns CTest to handle it. > I hope this patch could be merged. Good start. Please also update Help/manual/ctest.1.rst with documentation for the new options. Also please extend the test suite, likely in Tests/RunCMake/CTestCommandLine, to cover the options. See Tests/RunCMake/README.rst for information about how the existing test works. You could perhaps add a case that uses a -check.cmake script to verify the length of the output in a Test.xml file after running "ctest -M Experimental -T Test" plus the new options. Thanks, -Brad From mantis at public.kitware.com Wed Jul 22 17:34:52 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 22 Jul 2015 17:34:52 -0400 Subject: [cmake-developers] [CMake 0015659]: Visual Studio 2015: check_function_exists doesn't work for stdio functions Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15659 ====================================================================== Reported By: Alex Lamaison Assigned To: ====================================================================== Project: CMake Issue ID: 15659 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-22 17:34 EDT Last Modified: 2015-07-22 17:34 EDT ====================================================================== Summary: Visual Studio 2015: check_function_exists doesn't work for stdio functions Description: check_function_exists worked with previous versions of VS and correctly detected the absence of presence of stdio functions like the printf/scanf families, but with VS2015, those functions are always 'not found' With Visual Studio 2015, those functions are now defined *inline* in stdio.h. This means that CheckFunctionExists.c, which doesn't included stdio.h, can't find any definition of the function to link with. Previously this would have linked with the symbol in the CRT. Steps to Reproduce: Add check_function_exists(snprintf) to a project. Configure with VS2015 generator. It should say 'Looking for snprintf - found'. Instead it says 'Looking for snprintf - not found'. Additional Information: A workaround is to add legacy_stdio_definitions.lib to CMAKE_REQUIRED_LIBRARIES. However, that is not ideal because it requires knowing that library is available and required in the first place. That defeats the object of feature detection. More info here: https://msdn.microsoft.com/en-us/library/bb531344.aspx ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-22 17:34 Alex Lamaison New Issue ====================================================================== From mantis at public.kitware.com Thu Jul 23 02:33:00 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 23 Jul 2015 02:33:00 -0400 Subject: [cmake-developers] [CMake 0015660]: Isssue while installing cmake-curses-gui Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15660 ====================================================================== Reported By: vijay Assigned To: ====================================================================== Project: CMake Issue ID: 15660 Category: CCMake Reproducibility: N/A Severity: minor Priority: immediate Status: new ====================================================================== Date Submitted: 2015-07-23 02:33 EDT Last Modified: 2015-07-23 02:33 EDT ====================================================================== Summary: Isssue while installing cmake-curses-gui Description: I've installed cmake 3.2.2 but when i install cmake-curses-gui, it changes my cmake version to 2.8. I need cmake 3x versions including cmake-curses-gui. Help me ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-23 02:33 vijay New Issue ====================================================================== From roman.wueger at gmx.at Thu Jul 23 03:23:22 2015 From: roman.wueger at gmx.at (=?UTF-8?Q?=22Roman_W=C3=BCger=22?=) Date: Thu, 23 Jul 2015 09:23:22 +0200 Subject: [cmake-developers] [CMake] CTest threshold exceeds 1024 bytes In-Reply-To: <55AFB35D.4000004@kitware.com> References: <26A7A5F1-8B9C-40A1-85B0-40AD29A0FF54@gmx.at> <55AE4EC3.8050607@kitware.com> <015401d0c402$ea609040$bf21b0c0$@gmx.at>, <55AFB35D.4000004@kitware.com> Message-ID: Hi Brad, i've updated the patch with the missing things, but I don't know how to use the -check.cmake scripts to check the length of the output. Maybe you could have a look at it. Best regards Roman Am 22.07.15 um 17:14 schrieb Brad King > On 07/21/2015 06:16 PM, Roman W?ger wrote: > > > I've attached a patch which learns CTest to handle it. > > > I hope this patch could be merged. > > > > Good start. Please also update Help/manual/ctest.1.rst with > > documentation for the new options. Also please extend the test > > suite, likely in Tests/RunCMake/CTestCommandLine, to cover the > > options. See Tests/RunCMake/README.rst for information about > > how the existing test works. You could perhaps add a case that > > uses a -check.cmake script to verify the length of the output > > in a Test.xml file after running "ctest -M Experimental -T Test" > > plus the new options. > > > > Thanks, > > -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-ctest-learned-to-limit-the-output-of-passed-and-fail.patch Type: application/octet-stream Size: 8366 bytes Desc: not available URL: From konstantin at podsvirov.pro Thu Jul 23 05:32:14 2015 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Thu, 23 Jul 2015 12:32:14 +0300 Subject: [cmake-developers] [MODERN] CMake 3.3 vs Qt 5.5 vs MSVC2015 Message-ID: <1821991437643934@web22o.yandex.ru> Hi dear CMake developers! Meet modern CMake built on MSVC2015 c QtDialog based on Qt 5.5 from today :-) Windows 32bit: http://ifw.podsvirov.pro/cmake/cmake-master-win32-online.exe Windows 64bit: http://ifw.podsvirov.pro/cmake/cmake-master-win64-online.exe As always, questions and suggestions are welcome. -- Regards, Konstantin Podsvirov From ruslan_baratov at yahoo.com Thu Jul 23 09:12:17 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Thu, 23 Jul 2015 16:12:17 +0300 Subject: [cmake-developers] [MODERN] CMake 3.3 vs Qt 5.5 vs MSVC2015 In-Reply-To: <1821991437643934@web22o.yandex.ru> References: <1821991437643934@web22o.yandex.ru> Message-ID: <55B0E831.7070603@yahoo.com> On 23-Jul-15 12:32, Konstantin Podsvirov wrote: > Hi dear CMake developers! > > Meet modern CMake built on MSVC2015 c QtDialog based on Qt 5.5 from today :-) > > Windows 32bit: > > http://ifw.podsvirov.pro/cmake/cmake-master-win32-online.exe > > Windows 64bit: > > http://ifw.podsvirov.pro/cmake/cmake-master-win64-online.exe > > As always, questions and suggestions are welcome. > > -- > Regards, > Konstantin Podsvirov Both versions can't start because dll missing: api-ms-win-crt-runtime-l1-1-0.dll Win 7 x64 Ruslan From konstantin at podsvirov.pro Thu Jul 23 09:47:36 2015 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Thu, 23 Jul 2015 16:47:36 +0300 Subject: [cmake-developers] [MODERN] CMake 3.3 vs Qt 5.5 vs MSVC2015 In-Reply-To: <55B0E831.7070603@yahoo.com> References: <1821991437643934@web22o.yandex.ru> <55B0E831.7070603@yahoo.com> Message-ID: <35881437659256@web4h.yandex.ru> Hi Ruslan and other developers! 23.07.2015, 16:12, Ruslan Baratov" : > On 23-Jul-15 12:32, Konstantin Podsvirov wrote: >> Hi dear CMake developers! >> >> Meet modern CMake built on MSVC2015 c QtDialog based on Qt 5.5 from today :-) >> >> Windows 32bit: >> >> http://ifw.podsvirov.pro/cmake/cmake-master-win32-online.exe >> >> Windows 64bit: >> >> http://ifw.podsvirov.pro/cmake/cmake-master-win64-online.exe >> >> As always, questions and suggestions are welcome. >> >> -- >> Regards, >> Konstantin Podsvirov > > Both versions can't start because dll is missing: > api-ms-win-crt-runtime-l1-1-0.dll > Win 7 x64 > > Ruslan To solve the problem quickly, you need to install Visual C++ Redistributable for Visual Studio 2015 from the link below: http://www.microsoft.com/en-us/download/details.aspx?id=48145 Now more interesting :-) Outdoor platforms may not be Universal CRT: http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx CMake uses the module "InstallRequiredSystemLibraries" to install dependencies. Who is in charge here on this module? Should this module to install Universal CRT (api-ms-win-crt-runtime-xxx.dll library) for MSVC14 ? -- Regards, Konstantin Podsvirov From nilsgladitz at gmail.com Thu Jul 23 10:16:09 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 23 Jul 2015 16:16:09 +0200 Subject: [cmake-developers] [MODERN] CMake 3.3 vs Qt 5.5 vs MSVC2015 In-Reply-To: <35881437659256@web4h.yandex.ru> References: <1821991437643934@web22o.yandex.ru> <55B0E831.7070603@yahoo.com> <35881437659256@web4h.yandex.ru> Message-ID: <55B0F729.6020206@gmail.com> On 07/23/2015 03:47 PM, Konstantin Podsvirov wrote: > http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx > > CMake uses the module "InstallRequiredSystemLibraries" to install dependencies. > Who is in charge here on this module? Should this module to install Universal CRT > (api-ms-win-crt-runtime-xxx.dll library) for MSVC14 ? "6. App-local deployment of the Universal CRT is not supported." I think that means installation should not be handled by "InstallRequiredSystemLibraries". You should probably just require users to run "Windows Update". Nils From bill.hoffman at kitware.com Thu Jul 23 10:43:33 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 23 Jul 2015 10:43:33 -0400 Subject: [cmake-developers] [MODERN] CMake 3.3 vs Qt 5.5 vs MSVC2015 In-Reply-To: <55B0F729.6020206@gmail.com> References: <1821991437643934@web22o.yandex.ru> <55B0E831.7070603@yahoo.com> <35881437659256@web4h.yandex.ru> <55B0F729.6020206@gmail.com> Message-ID: <55B0FD95.4050501@kitware.com> On 7/23/2015 10:16 AM, Nils Gladitz wrote: > "6. App-local deployment of the Universal CRT is not supported." > > I think that means installation should not be handled by > "InstallRequiredSystemLibraries". > > You should probably just require users to run "Windows Update". Yuck! That will be a pain. I think we will stay away from this for a while for the CMake distribution. -Bill From JamesJ at motionview3d.com Thu Jul 23 11:24:25 2015 From: JamesJ at motionview3d.com (James Johnston) Date: Thu, 23 Jul 2015 15:24:25 -0000 Subject: [cmake-developers] [MODERN] CMake 3.3 vs Qt 5.5 vs MSVC2015 In-Reply-To: <55B0F729.6020206@gmail.com> References: <1821991437643934@web22o.yandex.ru> <55B0E831.7070603@yahoo.com> <35881437659256@web4h.yandex.ru> <55B0F729.6020206@gmail.com> Message-ID: <025201d0c55b$a977f050$fc67d0f0$@motionview3d.com> > -----Original Message----- > From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] > On Behalf Of Nils Gladitz > > On 07/23/2015 03:47 PM, Konstantin Podsvirov wrote: > > http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-univ > > ersal-crt.aspx > > > > CMake uses the module "InstallRequiredSystemLibraries" to install > dependencies. > > Who is in charge here on this module? Should this module to install > > Universal CRT (api-ms-win-crt-runtime-xxx.dll library) for MSVC14 ? > > "6. App-local deployment of the Universal CRT is not supported." > > I think that means installation should not be handled by > "InstallRequiredSystemLibraries". > > You should probably just require users to run "Windows Update". That sounds horrible - asking a user to manually run Windows Update. But Windows Update packages don't have to be installed ONLY by way of visiting Windows Update manually. I have yet to mess with this stuff myself (but will be soon). But in the meantime, FTA: "Currently these MSU packages are installed as part of the VCRedist installation. In a future build of Visual Studio 2015, these MSU packages will also be distributed separately as part of the Universal CRT SDK and made available for download on support.microsoft.com." So you get this just by running VCRedist - or, if you don't use VCRedist, you can get this by running the MSU packages directly (once said SDK becomes available - if it isn't already available - the blog is 4 months old). Both can be accomplished as part of a setup program. Unfortunately, I suspect the MSU packages can't be invoked from / nested inside a Windows Installer MSI like how the VC++ merge modules were done (and how we currently do); I plan to hack apart VCRedist to try to see what they are doing... Best regards, James Johnston From nilsgladitz at gmail.com Thu Jul 23 12:04:00 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 23 Jul 2015 18:04:00 +0200 Subject: [cmake-developers] [MODERN] CMake 3.3 vs Qt 5.5 vs MSVC2015 In-Reply-To: <025201d0c55b$a977f050$fc67d0f0$@motionview3d.com> References: <1821991437643934@web22o.yandex.ru> <55B0E831.7070603@yahoo.com> <35881437659256@web4h.yandex.ru> <55B0F729.6020206@gmail.com> <025201d0c55b$a977f050$fc67d0f0$@motionview3d.com> Message-ID: <55B11070.6090705@gmail.com> On 23.07.2015 17:24, James Johnston wrote: > That sounds horrible - asking a user to manually run Windows Update. But > Windows Update packages don't have to be installed ONLY by way of visiting > Windows Update manually. The support issue is certainly cumbersome given that users will be told that some DLL that they haven't heard of before is missing rather than that they need to update an operating system component by running windows update. But this will only be an issue for users which don't run windows >= 10 or which don't run regular updates (I'd have assumed this comes in through automated updates as well unless disabled?). Given sufficient time this should therefor become a non-issue. I rather think it is nice that this is considered an operating system component rather than a visual studio version specific runtime component (e.g. reduced application installer sizes and centralized updates) but this might work best if you also treat it as such (unless you specifically have to target e.g. outdated/unnetworked machines). Nils From JamesJ at motionview3d.com Thu Jul 23 13:05:42 2015 From: JamesJ at motionview3d.com (James Johnston) Date: Thu, 23 Jul 2015 17:05:42 -0000 Subject: [cmake-developers] [MODERN] CMake 3.3 vs Qt 5.5 vs MSVC2015 In-Reply-To: <55B11070.6090705@gmail.com> References: <1821991437643934@web22o.yandex.ru> <55B0E831.7070603@yahoo.com> <35881437659256@web4h.yandex.ru> <55B0F729.6020206@gmail.com> <025201d0c55b$a977f050$fc67d0f0$@motionview3d.com> <55B11070.6090705@gmail.com> Message-ID: <028301d0c569$cf201a90$6d604fb0$@motionview3d.com> > -----Original Message----- > From: Nils Gladitz [mailto:nilsgladitz at gmail.com] > > On 23.07.2015 17:24, James Johnston wrote: > > That sounds horrible - asking a user to manually run Windows Update. > > But Windows Update packages don't have to be installed ONLY by way of > > visiting Windows Update manually. > > But this will only be an issue for users which don't run windows >= 10 or > which don't run regular updates (I'd have assumed this comes in through > automated updates as well unless disabled?). Depends on if it is an "important" update or an "optional" update... Or it may not show at all. E.g. the legacy WinHelp MSU package is not pushed via Windows Update at all, but if you want WinHelp, it's installed via a manually-downloaded MSU package that you have to get from Microsoft.com downloads. I'm curious to find out which method they choose... > I rather think it is nice that this is considered an operating system component > rather than a visual studio version specific runtime component (e.g. reduced > application installer sizes and centralized updates) but this might work best if > you also treat it as such (unless you specifically have to target e.g. > outdated/unnetworked machines). To me, this is the worst of both worlds. Not only do we STILL have to distribute the version-specific components (which are not part of the universal CRT) as we always have since VS2005, we now have this MSU package IN ADDITION that has to be installed for every configuration except static runtime linking. You still have the burden of redistributing the rest of the "unstable" VS2015-specific runtime. So it's not like you can wait 10 years for adoption and stop worrying about any VS2015 redistributing runtime files at all. Bonus points if they find a way in Visual Studio 2020 to modify the universal CRT and somehow cause breaking changes with VS2015, even though they promised not to... This was supposedly why the VS2005 CRT & newer are side-by-side installed into winsxs - to fix "DLL hell" from the 1990s... James From mantis at public.kitware.com Thu Jul 23 14:07:46 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 24 Jul 2015 04:07:46 +1000 Subject: [cmake-developers] [CMake 0015661]: FindPythonInterp will accept "python" in the path, even though it is the wrong version Message-ID: <962441a6aaf9c7c5092a405c9d372780@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15661 ====================================================================== Reported By: Paul "TBBle" Hampson Assigned To: ====================================================================== Project: CMake Issue ID: 15661 Category: Modules Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-24 04:07 AEST Last Modified: 2015-07-24 04:07 AEST ====================================================================== Summary: FindPythonInterp will accept "python" in the path, even though it is the wrong version Description: The command FIND_PACKAGE(PythonInterp 2.6 REQUIRED) will discover a Python 3 installation if that is 'python' in the path, in preference to a Python 2 installation. Steps to Reproduce: Call FIND_PACKAGE(PythonInterp 2.6 REQUIRED) in a CMake script, when your PATH contains C:\Python34 but both Python 3.4 and Python 2.7 are installed locally. Expected result: -- Found PythonInterp: C:/Python27/python.exe (found suitable version "2.7.9", minimum required is "2.6") Actual result: -- Found PythonInterp: C:/Python34/python.exe (found suitable version "3.4.3", minimum required is "2.6") Additional Information: I haven't diagnosed this yet, but the problem appears to be the following blocks in FindPythonInterp.cmake: ===== # Search for the current active python version first list(APPEND _Python_VERSIONS ";") list(APPEND _Python_VERSIONS ${_PYTHON_FIND_OTHER_VERSIONS}) .... # Search for newest python version if python executable isn't found if(NOT PYTHON_EXECUTABLE) foreach(_CURRENT_VERSION IN LISTS _Python_VERSIONS) set(_Python_NAMES python${_CURRENT_VERSION}) if(WIN32) list(APPEND _Python_NAMES python) endif() find_program(PYTHON_EXECUTABLE NAMES ${_Python_NAMES} PATHS [HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath] ) endforeach() endif() ===== If I'm reading this correctly, it's possible for _Python_VERSIONS to be empty before this if neither ADDTIONAL_VERSIONS nor PYTHONLIBS_VERSION_STRING (from FindPythonLibs.cmake) are set. This means that when the given loop is hit, the first value of _CURRENT_VERSION is "", so 'python' is searched for by find_program. There's also the WIN32-specific block that explicitly searches for the executable name 'python', as that's the name of the executable on Windows installations. If python.exe is in the Path (a non-default but common installer option) then the first search attempt will discover it and use it. It might be simplest to split this search, and on Win32 not search the system path until the registry walk has completed. I think there's also a couple of other issues here: A per-user install of Python sets a different registry key, and we don't fail if Python 2 was requested but Python 3 is found, or vice-versa. We also don't support py.exe, which as of Python 3.3 supports running python scripts with arbitrary versions by processing the #! initial line the same way an executable .py file is handled on POSIX systems. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-24 04:07 Paul "TBBle" HampsonNew Issue ====================================================================== From mantis at public.kitware.com Thu Jul 23 14:20:17 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 23 Jul 2015 14:20:17 -0400 Subject: [cmake-developers] [CMake 0015662]: CMake looks in the wrong locations for Windows/Windows Phone SDKs with Visual Studio 2015 Message-ID: <4e518fea87ea058639777633b2454b87@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15662 ====================================================================== Reported By: D.E. Goodman-Wilson Assigned To: ====================================================================== Project: CMake Issue ID: 15662 Category: CMake Reproducibility: always Severity: major Priority: urgent Status: new ====================================================================== Date Submitted: 2015-07-23 14:20 EDT Last Modified: 2015-07-23 14:20 EDT ====================================================================== Summary: CMake looks in the wrong locations for Windows/Windows Phone SDKs with Visual Studio 2015 Description: With Visual Studio 2015, the locations of the registry keys for the Windows SDK and WIndows Phone SDK have changed, and so the VS 2015 generator?which relies on the VS 2013 registry settings?generates errors wrongly. Steps to Reproduce: On a freshly installed system with no prior installation of Visual Studio 2013, and a fresh installation of Visual Studio 2015 with Windows SDK 8.1 and Windows Phone SDK 8.1 installed, attempt to cmake a project with set(CMAKE_SYSTEM_NAME "WindowsPhone") set(CMAKE_SYSTEM_VERSION "8.1") The following error is generated: -- Building for: Visual Studio 14 2015 CMake Error at CMakeLists.txt:2 (project): A Windows Phone component with CMake requires both the Windows Desktop SDK as well as the Windows Phone '8.1' SDK. Please make sure that you have both installed Additional Information: I can't find the new Windows Phone SDK registry keys, but they are not where cmake is expecting them for sure. The new WIndows SDK is now located at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.1A\InstallationFolder ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-23 14:20 D.E. Goodman-WilsonNew Issue ====================================================================== From robert.maynard at kitware.com Thu Jul 23 16:48:50 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 23 Jul 2015 16:48:50 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.3.0 Release Message-ID: I am proud to announce that CMake 3.3.0 is now available for download at: http://www.cmake.org/download/ Documentation is available at: http://www.cmake.org/cmake/help/v3.3 Release notes appear below and are also published at http://www.cmake.org/cmake/help/v3.3/release/3.3.html Some of the more significant features of CMake 3.3 are: * The "if()" command learned a new "IN_LIST" operator that evaluates to true if a given element is contained in a named list. * The "add_dependencies()" command learned to allow dependencies to be added to *interface libraries*. Dependencies added to an interface library are followed transitively in its place since the target itself does not build. * The "find_library()", "find_path()", and "find_file()" commands now search in installation prefixes derived from the "PATH" environment variable. * The "_VISIBILITY_PRESET" and "VISIBILITY_INLINES_HIDDEN" target properties now affect compilation in sources of all target types. See policy "CMP0063". * A "_INCLUDE_WHAT_YOU_USE" target property and supporting "CMAKE__INCLUDE_WHAT_YOU_USE" variable were introduced to tell the *Makefile Generators* and the "Ninja" generator to run "include- what-you-use" along with the compiler for "C" and "CXX" languages. Deprecated and Removed Features: * The "ctest_build()" and "build_command()" commands no longer tell "make" tools to ignore errors with the "-i" option. Previously this was done for *Makefile Generators* but not others. See policy "CMP0061". * The "Visual Studio 7" generator (.NET 2002) is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 6" generator is now deprecated and will be removed in a future version of CMake. * The "add_definitions()" command no longer causes a "DEFINITIONS" directory property to be populated. See policy "CMP0059". CMake 3.3 Release Notes *********************** Changes made since CMake 3.2 include the following. New Features ============ Generators ---------- * The *Makefile Generators* now add ".DELETE_ON_ERROR" to the makefiles that contain the actual build rules for files on disk. This tells GNU make to remove rule outputs when their recipe modifies an output but fails. * The *Visual Studio Generators* learned to support ".xaml" source files and automatically associate them with corresponding ".h" and ".cpp" sources. * A new experimental "Green Hills MULTI" generator was added on Windows. Green Hills MULTI is an IDE for embedded real-time systems. Commands -------- * The "add_dependencies()" command learned to allow dependencies to be added to *interface libraries*. Dependencies added to an interface library are followed transitively in its place since the target itself does not build. * The "execute_process()" command learned to support specifying the same file for "OUTPUT_FILE" and "ERROR_FILE". * The "file(GLOB)" and "file(GLOB_RECURSE)" commands learned a new "LIST_DIRECTORIES " option to specify whether the glob result should include directories. * The "find_library()", "find_path()", and "find_file()" commands now search in installation prefixes derived from the "PATH" environment variable. * The "if()" command learned a new "IN_LIST" operator that evaluates to true if a given element is contained in a named list. * The "install(EXPORT)" and "export()" commands learned to export targets that populate the "INTERFACE_SOURCES" target property. * The "install(TARGETS)" command learned to support generator expressions in the "DESTINATION" value. Variables --------- * The version of some Fortran compilers is now detected and stored in the "CMAKE_Fortran_COMPILER_VERSION" variable. * The *Visual Studio Generators* learned a new "CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD" option to put the "INSTALL" target in the default build of a solution (".sln") file. Properties ---------- * A "CROSSCOMPILING_EMULATOR" target property and supporting "CMAKE_CROSSCOMPILING_EMULATOR" variable were introduced to allow target platform binaries to run on the host during cross compiling. * A "_INCLUDE_WHAT_YOU_USE" target property and supporting "CMAKE__INCLUDE_WHAT_YOU_USE" variable were introduced to tell the *Makefile Generators* and the "Ninja" generator to run "include- what-you-use" along with the compiler for "C" and "CXX" languages. * The "_VISIBILITY_PRESET" and "VISIBILITY_INLINES_HIDDEN" target properties now affect compilation in sources of all target types. See policy "CMP0063". * The "XCODE_ATTRIBUTE_" target property learned to support generator expressions. Modules ------- * The "CheckFortranCompilerFlag" module was introduced to check "Fortran" compiler flags, much like the "CheckCCompilerFlag" module already does for "C". * The "ExternalData" module learned a new "ExternalData_NO_SYMLINKS" option to disable use of symbolic links to populate the real data files and use copies instead. * The "ExternalData" module learned a new "RECURSE:" option in "DATA{}" references specifying directories. This allows an entire directory tree of associated files to be matched. * The "ExternalData" module learned a new URL template placeholder "%(algo:)" to allow custom mapping from algorithm name to URL component through configuration of new "ExternalData_URL_ALGO__" variables. This allows more flexibility in remote URLs. * The "ExternalProject" module learned to replace tokens like "" in the "BYPRODUCTS" of each step. * The "ExternalProject" module APIs learned to support "generator expressions" when using "LOG_*" options and in CMake initial cache options. * The "FindBoost" module now tracks the directories containing libraries separately for RELEASE and DEBUG configurations. * The "FindCUDA" module now defaults to using the static CUDA runtime library if it is available. A new "CUDA_USE_STATIC_CUDA_RUNTIME" option is offered to control this behavior. * The "FindMatlab" module was completely rewritten. It learned about versions and components and to find Matlab in a more precise and multiplatform way. The module now offers APIs to create mex extensions, documentation, and unit tests. * The "FindPackageHandleStandardArgs" module "FIND_PACKAGE_HANDLE_STANDARD_ARGS" function now always populates both the "_FOUND" and "_FOUND" variables (the latter for backwards compatibility). The "FOUND_VAR" option is now ignored except to enforce its allowed values. * The "InstallRequiredSystemLibraries" module learned a new "CMAKE_INSTALL_SYSTEM_RUNTIME_COMPONENT" option to specify the installation component. Generator Expressions --------------------- * A new "COMPILE_LANGUAGE" generator expression was introduced to allow specification of compile options for target files based on the "LANGUAGE" of each source file. Due to limitations of the underlying native build tools, this feature has varying support across generators. See the "cmake-generator-expressions(7)" manual for details. CTest ----- * The "ctest(1)" tool learned a new "--repeat-until-fail " option to help find sporadic test failures. * The "CTestCoverageCollectGCOV" module learned to support the same "CTEST_CUSTOM_COVERAGE_EXCLUDE" option as the "ctest_coverage()" command. CPack ----- * The "cpack(1)" "IFW" generator and the "CPackIFW" module learned to support Qt Framework Installer 2.0 tools. * The "CPackDeb" module learned a new "CPACK_DEBIAN__PACKAGE_SHLIBDEPS" variable to specify per-component use of "dpkg-shlibdeps". * The "CPackDeb" module learned a new "CPACK_DEBIAN__PACKAGE_DEPENDS" option to specify per- component dependencies. * The "CPackRPM" module learned to package symbolic links more cleanly and now supports directory symlinks with recent "rpmbuild" versions. * The "CPackRPM" module learned a new "CPACK_RPM_ADDITIONAL_MAN_DIRS" variable to specify directories containing man pages for the brp- compress RPM macro. * The "CPackRPM" module learned a new "CPACK_RPM__PACKAGE_ARCHITECTURE" variable to specify a component-specific package architecture. * The CPack WIX generator learned the new "CPACK_START_MENU_SHORTCUTS", "CPACK_DESKTOP_SHORTCUTS" and "CPACK_STARTUP_SHORTCUTS" installed file properties which can be used to install shorcuts in the Start Menu, on the Desktop and in the Startup Folder respectively. Other ----- * The "Compile Features" functionality is now aware of features supported by GNU compilers on Windows, versions 4.4 through 5.0. * The "cmake(1)" "-E tar" command learned a new "--format" option to specify the archive format to be written. * On OS X, CMake learned to create XCTest bundles to test Frameworks and App Bundles within Xcode. The "FindXCTest" module provides convenience functions to handle "XCTEST" bundles. Deprecated and Removed Features =============================== * On OS X the "cmake-gui(1)" no longer has the "Install For Command Line Use" menu item. Instead there is a "How to Install For Command Line Use" menu item that shows an informational dialog box explaining how to make the command line tools available. For example: /Applications/CMake.app/Contents/bin/cmake-gui --install * The "ctest_build()" and "build_command()" commands no longer tell "make" tools to ignore errors with the "-i" option. Previously this was done for *Makefile Generators* but not others. See policy "CMP0061". * The "Visual Studio 10 2010" generator no longer checks for running VS IDEs with the project open or asks them to reload. This was originally done for VS 10 because it had been done for VS 7 through 9 to avoid prompting for every project in a solution. Since VS >= 10 allow the whole solution to reload at once they do not need CMake to help them. * The "Visual Studio 7" generator (.NET 2002) is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 6" generator is now deprecated and will be removed in a future version of CMake. * The "find_package()" command no longer considers project build trees recently configured in a "cmake-gui(1)". This was previously done only on Windows and is now never done. The "NO_CMAKE_BUILDS_PATH" option is now ignored if given and effectively always on. Projects may populate the *User Package Registry* to aid users building multiple dependent projects one after another. * When building with GNU tools on Windows (MinGW tools), the "find_library()" command will no longer consider ".dll" files to be linkable libraries. All dynamic link libraries are expected to provide separate ".dll.a" or ".lib" import libraries. * The "add_definitions()" command no longer causes a "DEFINITIONS" directory property to be populated. See policy "CMP0059". * With Visual Studio 7, 8, and 9 generators the value of the "$(OutDir)" placeholder no longer evaluates to the configuration name. Projects should use "$(ConfigurationName)" for that instead. * Using the output of "export()" with the "install(FILES)" command is no longer allowed. See policy "CMP0062" for details. Other Changes ============= * The "Ninja" generator now requires that calls to the "add_custom_command()" and "add_custom_target()" commands use the "BYPRODUCTS" option to explicitly specify any files generated by the custom commands that are not listed as outputs (perhaps because their timestamps are allowed to be older than the inputs). See policy "CMP0058". * Build-time progress output of *Makefile Generators* has been improved. It no longer mixes progress and build rule messages during parallel builds. The link rule messages now have progress and are displayed as bold green instead of bold red (since red is often associated with an error message). * The "CMAKE_CFG_INTDIR" variable value for Visual Studio 7, 8, and 9 is now "$(ConfigurationName)" instead of "$(OutDir)". This should have no effect on the intended use cases of the variable. * Linking to library files by a full path in an implicit linker search directory (e.g. "/usr/lib/libfoo.a") no longer asks the linker to search for the library (e.g. "-lfoo") and now links by full path. See policy "CMP0060". ------------------------------------------------------------------- Changes made since CMake 3.3.0-rc4: Brad King (3): Features: Update MSVC features for VS 2015 RTM OS X: Use -iframework with AppleClang only on version >= 4.2 CMake 3.3.0 ------------------------------------------------------------------- From mantis at public.kitware.com Thu Jul 23 16:50:57 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 23 Jul 2015 13:50:57 -0700 Subject: [cmake-developers] [CMake 0015663]: externalproject cause make -j build failure the first time Message-ID: <46228913eb522f0840210e09e1aac5bb@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15663 ====================================================================== Reported By: Laurent Demailly Assigned To: ====================================================================== Project: CMake Issue ID: 15663 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-23 13:50 PDT Last Modified: 2015-07-23 13:50 PDT ====================================================================== Summary: externalproject cause make -j build failure the first time Description: the first time someone builds a cmake generated makefile, using -j yields a broken build because somehow the download of the external projects isn't complete the dependencies should be set correctly such as make waits for that target to complete ? https://github.com/facebook/wdt/issues/12 Steps to Reproduce: git clone https://github.com/facebook/wdt.git mkdir build; cd build cmake ../wdt -G "Unix Makefiles" -DBUILD_TESTING=on make -j this isn't mac specific - same issue with Ubuntu - could be a bug in our cmakelist.txt https://github.com/facebook/wdt/blob/master/CMakeLists.txt#L212 is where we add gmock ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-23 13:50 Laurent DemaillyNew Issue ====================================================================== From d2gp at telus.net Fri Jul 24 01:04:20 2015 From: d2gp at telus.net (David Powell) Date: Thu, 23 Jul 2015 22:04:20 -0700 Subject: [cmake-developers] malware? Message-ID: hi I downloaded cmake an hour ago from cmake.org and found myself with an unwanted piece of software called ?advanced mac cleaner?, an app that was hard to get rid of. I?m not certain it came from your site but it happened at the same time and I can?t think of any other explanation.. The download file from cmake.org (supposedly the latest stable dmg for mac) was much bigger (30MB) than the cmake file I subsequently downloaded from github. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at ensslin.cc Fri Jul 24 01:18:39 2015 From: michael at ensslin.cc (=?windows-1252?Q?Michael_En=DFlin?=) Date: Fri, 24 Jul 2015 07:18:39 +0200 Subject: [cmake-developers] malware? In-Reply-To: References: Message-ID: <55B1CAAF.6040507@ensslin.cc> On 24/07/15 07:04, David Powell wrote: > hi > > I downloaded cmake an hour ago from cmake.org and found myself with an unwanted piece of software called ?advanced mac cleaner?, an app that was hard to get rid of. I?m not certain it came from your site but it happened at the same time and I can?t think of any other explanation.. The download file from cmake.org (supposedly the latest stable dmg for mac) was much bigger (30MB) than the cmake file I subsequently downloaded from github. > > > I don't know about that, but I just noticed that cmake.org allows HTTP (non-HTTPS) downloads. HTTP has no form of cryptographic authentication or verification, and it's incredibly easy for a MitM to attach malware to your downloads. IMO, the HTTP downloads should be removed ASAP. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From konstantin at podsvirov.pro Fri Jul 24 03:46:11 2015 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Fri, 24 Jul 2015 10:46:11 +0300 Subject: [cmake-developers] [MODERN] CMake 3.3 vs Qt 5.5 vs MSVC2015 In-Reply-To: <35881437659256@web4h.yandex.ru> References: <1821991437643934@web22o.yandex.ru> <55B0E831.7070603@yahoo.com> <35881437659256@web4h.yandex.ru> Message-ID: <1975171437723971@web22h.yandex.ru> Hi dear CMake developers! Modern CMake requires modern platform! To solve the problem you run cmake-gui is now possible with the following changes: [PATCH] CMake: Added option CMake_INSTALL_DEPENDENCIES By default this option is ON Turn OFF to disable installing runtime 3th dependencie Addition QtDialog now installing on Windows platform plugin for Qt5 http://git.podsvirov.pro/?p=kitware/cmake.git;a=commitdiff;h=e955bd6783abdc1bf30a9e7c3d88bac3eb0acd60 Dear Brad, please consider the possibility of applying these changes. Check out the work of these changes can on earlier installers. cmake-gui should work now, but if not, then update your system and install >Visual C++ Redistributable for Visual Studio 2015 from the link below: > > http://www.microsoft.com/en-us/download/details.aspx?id=48145 23.07.2015, 16:47, "Konstantin Podsvirov" : > Hi Ruslan and other developers! > > 23.07.2015, 16:12, Ruslan Baratov" : >> On 23-Jul-15 12:32, Konstantin Podsvirov wrote: >>> Hi dear CMake developers! >>> >>> Meet modern CMake built on MSVC2015 c QtDialog based on Qt 5.5 from today :-) >>> >>> Windows 32bit: >>> >>> http://ifw.podsvirov.pro/cmake/cmake-master-win32-online.exe >>> >>> Windows 64bit: >>> >>> http://ifw.podsvirov.pro/cmake/cmake-master-win64-online.exe >>> >>> As always, questions and suggestions are welcome. >>> >>> -- >>> Regards, >>> Konstantin Podsvirov >> >> Both versions can't start because dll is missing: >> api-ms-win-crt-runtime-l1-1-0.dll >> Win 7 x64 >> >> Ruslan > > To solve the problem quickly, you need to install Visual C++ Redistributable for Visual Studio 2015 from the link below: > > http://www.microsoft.com/en-us/download/details.aspx?id=48145 > > Now more interesting :-) > > Outdoor platforms may not be Universal CRT: > > http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx > > CMake uses the module "InstallRequiredSystemLibraries" to install dependencies. > Who is in charge here on this module? Should this module to install Universal CRT > (api-ms-win-crt-runtime-xxx.dll library) for MSVC14 ? > > -- > Regards, > Konstantin Podsvirov Regards, Konstantin Podsvirov From chuck.atkins at kitware.com Fri Jul 24 11:40:09 2015 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Fri, 24 Jul 2015 11:40:09 -0400 Subject: [cmake-developers] malware? In-Reply-To: References: Message-ID: Hi David, I just checked the cmake.org download and was able to verify the following: cmake-3.2.3-Darwin-x86_64.dmg - 27949121 Bytes - MD5 97c26048e9b3e242951bb5b1ff88da9e cmake-3.3.0-Darwin-x86_64.dmg - 22628082 Bytes - MD5 232ae38586f3e6b665f9b7ac281167a0 I checked from both inside and outside Kitware's network as to verify internal and external were the same. Are these the same for the files you downloaded from cmake.org? Can you try to download from a different machine to verify it's not a local problem? Thanks - Chuck On Fri, Jul 24, 2015 at 1:04 AM, David Powell wrote: > hi > > I downloaded cmake an hour ago from cmake.org and found myself with an > unwanted piece of software called ?advanced mac cleaner?, an app that was > hard to get rid of. I?m not certain it came from your site but it happened > at the same time and I can?t think of any other explanation.. The download > file from cmake.org (supposedly the latest stable dmg for mac) was much > bigger (30MB) than the cmake file I subsequently downloaded from github. > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/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-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From JamesJ at motionview3d.com Fri Jul 24 12:24:43 2015 From: JamesJ at motionview3d.com (James Johnston) Date: Fri, 24 Jul 2015 16:24:43 -0000 Subject: [cmake-developers] malware? In-Reply-To: <55B1CAAF.6040507@ensslin.cc> References: <55B1CAAF.6040507@ensslin.cc> Message-ID: <036801d0c62d$400790d0$c016b270$@motionview3d.com> > -----Original Message----- > From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] > On 24/07/15 07:04, David Powell wrote: > > hi > > > > I downloaded cmake an hour ago from cmake.org and > found myself with an unwanted piece of software called "advanced mac > cleaner", an app that was hard to get rid of. I'm not certain it came from your > site but it happened at the same time and I can't think of any other > explanation.. The download file from cmake.org > (supposedly the latest stable dmg for mac) was much bigger (30MB) than the > cmake file I subsequently downloaded from github. > > > > > > > > I don't know about that, but I just noticed that cmake.org allows HTTP > (non-HTTPS) downloads. > > HTTP has no form of cryptographic authentication or verification, and it's > incredibly easy for a MitM to attach malware to your downloads. > > IMO, the HTTP downloads should be removed ASAP. Two other ideas that don't require HTTPS hosting of large binary files: * On Windows, cryptographically sign the setup program using Authenticode. When the UAC prompts for elevation, Windows will show it signed by "Kitware" instead of a yellow warning "Unknown". Probably the other operating systems have a first-class way of doing something like this as well. Downside: certificates cost some modest amount of money to renew every year. * Post SHA-1 hashes of the EXEs/DMGs/tarballs on the CMake web site, and post them over HTTPS. But downside here is that many users won't bother to check this (e.g. Windows has no well-known in-built utility for calculating a file hash). I agree the current situation of unsigned files available over HTTP only is not really ideal. Perhaps this would be a good opportunity for looking at enhancements to CMake itself in the area of code signing (e.g. code signing of individual target EXEs/DLLs, and code signing of the final setup EXE package by CPack) that hides the various operating-system-specific ways of doing this? Then, CMake itself can be modified to be built with these new features, if available. A quick Google search of cmake.org for code signing didn't yield much in the way of previous discussion or existing features... Best regards, James Johnston From sean at rogue-research.com Fri Jul 24 12:28:49 2015 From: sean at rogue-research.com (Sean McBride) Date: Fri, 24 Jul 2015 12:28:49 -0400 Subject: [cmake-developers] malware? In-Reply-To: References: Message-ID: <20150724162850.2057312478@mail.rogue-research.com> On Fri, 24 Jul 2015 11:40:09 -0400, Chuck Atkins said: >I just checked the cmake.org download and was able to verify the following: > >cmake-3.2.3-Darwin-x86_64.dmg - 27949121 Bytes - MD5 >97c26048e9b3e242951bb5b1ff88da9e >cmake-3.3.0-Darwin-x86_64.dmg - 22628082 Bytes - MD5 >232ae38586f3e6b665f9b7ac281167a0 > >I checked from both inside and outside Kitware's network as to verify >internal and external were the same. Are these the same for the files you >downloaded from cmake.org? Can you try to download from a different >machine to verify it's not a local problem? If you're trying to detect imposter binaries, don't use md5. In fact, don't use md5 ever for anything: I get the following for my cmake download: $ shasum -a 256 /Users/sean/Downloads/cmake-3.3.0-Darwin-x86_64.dmg 0282d6f139f5292c2bb9b3d600df6b7db242d8f53c4ab8d1e6ddff76402e0eab /Users/sean/Downloads/cmake-3.3.0-Darwin-x86_64.dmg 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 chuck.atkins at kitware.com Fri Jul 24 12:37:27 2015 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Fri, 24 Jul 2015 12:37:27 -0400 Subject: [cmake-developers] malware? In-Reply-To: <20150724162850.2057312478@mail.rogue-research.com> References: <20150724162850.2057312478@mail.rogue-research.com> Message-ID: > If you're trying to detect imposter binaries, don't use md5. > Fair enough, it was more force of habit than anything. Regardless, the file size seems way off > I get the following for my cmake download: > > $ shasum -a 256 /Users/sean/Downloads/cmake-3.3.0-Darwin-x86_64.dmg > 0282d6f139f5292c2bb9b3d600df6b7db242d8f53c4ab8d1e6ddff76402e0eab > /Users/sean/Downloads/cmake-3.3.0-Darwin-x86_64.dmg > Confirmed: [chuck.atkins at hal9000 tmp]$ shasum -a 256 cmake-3.3.0-Darwin-x86_64.dmg 0282d6f139f5292c2bb9b3d600df6b7db242d8f53c4ab8d1e6ddff76402e0eab cmake-3.3.0-Darwin-x86_64.dmg -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Fri Jul 24 12:54:07 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Fri, 24 Jul 2015 09:54:07 -0700 (PDT) Subject: [cmake-developers] malware? In-Reply-To: <55B1CAAF.6040507@ensslin.cc> References: <55B1CAAF.6040507@ensslin.cc> Message-ID: An additional and obvious security measure is to cryptographically sign each file release with a detached armored signature, e.g., gpg --default-key --detach-sign --armor cmake-3.3.0.tar.gz where keyid is a CMake release manager identification key (also created and distributed by gpg). The above command creates a small file called cmake-3.3.0.tar.gz.asc which security-conscious users download along with the tarball itself. They can then verify every byte of both downloads and that the correct crytographic signature from the CMake release manager was applied using gpg --verify cmake-3.3.0.tar.gz.asc Most important open-source projects (and even many unimportant ones like PLplot, :-) ) routinely apply this security measure for release tarballs, but for some reason up to now, Kitware has not. 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 eike at sf-mail.de Fri Jul 24 13:05:53 2015 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 24 Jul 2015 19:05:53 +0200 Subject: [cmake-developers] malware? In-Reply-To: References: <55B1CAAF.6040507@ensslin.cc> Message-ID: <3518593.C5N4AkmA0J@caliban.sf-tec.de> Am Freitag, 24. Juli 2015, 09:54:07 schrieb Alan W. Irwin: > An additional and obvious security measure is to cryptographically > sign each file release with a detached armored signature, e.g., > > gpg --default-key --detach-sign --armor cmake-3.3.0.tar.gz > > where keyid is a CMake release manager identification key (also created > and distributed by gpg). While at it, one could use the same key to sign the tags in git at the same time ;) Greetings, Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From ben.boeckel at kitware.com Fri Jul 24 14:34:25 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 24 Jul 2015 14:34:25 -0400 Subject: [cmake-developers] trace-expand and ctest-add_subdirectory-crash Message-ID: <20150724183425.GA21190@megas.kitware.com> Hi, I've pushed two new branches to stage (and merged to next): - trace-expand: adds --trace-expand option to cmake which expands variable references in --trace output. - ctest-add_subdirectory-crash: fixes a crash present since 2008(!) when using add_subdirectory from TEST_INCLUDE_FILE for CTestTestfile.cmake. I can rebase the second onto release if it makes sense to put into 3.3.1. I don't think making a point release just for it makes sense since "no one" has used it?ever (and subdirs is actually more powerful in CTest anyways[1])? --Ben [1]subdirs() detects absolute paths and handles them accordingly. add_subdirectory() always prepends the current working directory. From aleixpol at kde.org Sat Jul 25 12:20:03 2015 From: aleixpol at kde.org (Aleix Pol) Date: Sat, 25 Jul 2015 18:20:03 +0200 Subject: [cmake-developers] Generating buildsystem metadata from CMake In-Reply-To: References: Message-ID: On Sat, Apr 18, 2015 at 11:56 AM, Stephen Kelly wrote: > Stephen Kelly wrote: > >> The aim is to generate a structured file containing metadata relating the >> buildsystem. > > > I've been quiet on this thread for a while, so I think it is time for an > update. > > I became more ambitious in mid March and started prototyping a more-complete > design for CMake IDE integration. > > Instead of teaching CMake to generate a metadata file, I want to add a > server mode to CMake, so that IDEs can run the server in the build directory > and query it for buildsystem metadata, code completion, etc. It can be > implemented efficiently and it doesn't have to re-configure the build from > the beginning each time. A lot of things become possible with such a design, > but I'm being economic with details because I don't want to make promises I > don't deliver in the end, even though I have high confidence that I actually > can :). > > The good news is that I have done some proof of concept work on all aspects > of this, but I don't yet have one branch which contains all of the > individual proof of concepts combined. Doing this properly requires > refactoring CMake quite a bit, which I've already been doing for a while to > create a cmState class. > > The bad news is that because this is more ambitious, it will take more time > and will not be part of the CMake 3.3 release early this summer. I do > believe it can be implemented for the following release 3 months later > though. > > Here's some prior art in other tools: > > http://thread.gmane.org/gmane.comp.compilers.clang.devel/21780 > https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI.html > http://thread.gmane.org/gmane.comp.lib.boost.build/26905 > > We can use JSON as the wire protocol, and we can talk about exactly what the > protocol will be once the refactoring of CMake is done (that will take some > more weeks). I'll post a more complete design proposal and my prototype at > that point too. > > Thanks, > > Steve. > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/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-developers Hi Stephen, Is there any news on the subject? Aleix From steveire at gmail.com Sat Jul 25 14:33:46 2015 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 25 Jul 2015 20:33:46 +0200 Subject: [cmake-developers] Generating buildsystem metadata from CMake References: Message-ID: Aleix Pol wrote: > On Sat, Apr 18, 2015 at 11:56 AM, Stephen Kelly > wrote: >> Stephen Kelly wrote: >> >>> The aim is to generate a structured file containing metadata relating >>> the buildsystem. >> >> >> I've been quiet on this thread for a while, so I think it is time for an >> update. >> >> I became more ambitious in mid March and started prototyping a >> more-complete design for CMake IDE integration. >> > Hi Stephen, > Is there any news on the subject? I have been working on cleaning up cmake $ git log --oneline --author=steveire --since="April 1" | wc -l 472 I've made lots of progress toward separating the configure and generation steps (required prerequisite for server features), but no working prototype ready to show yet I'm afraid. Thanks, Steve. From mantis at public.kitware.com Sun Jul 26 13:21:16 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 26 Jul 2015 13:21:16 -0400 Subject: [cmake-developers] [CMake 0015664]: CMake detects the wrong version for the C and C++ Cray Compiler Message-ID: <42458c8b49e709bd8dcd8d027b60093b@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15664 ====================================================================== Reported By: jcook Assigned To: ====================================================================== Project: CMake Issue ID: 15664 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-26 13:21 EDT Last Modified: 2015-07-26 13:21 EDT ====================================================================== Summary: CMake detects the wrong version for the C and C++ Cray Compiler Description: This is because CMake is using the _RELEASE macro instead of _RELEASE_MAJOR in Modules/Compiler/Cray-DetermineCompiler.cmake. Steps to Reproduce: cmake --system-information | grep CMAKE_C_COMPILER_VERSION Additional Information: None at this time. Please let me know if you need more info. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-26 13:21 jcook New Issue ====================================================================== From roman.wueger at gmx.at Mon Jul 27 01:34:34 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Mon, 27 Jul 2015 07:34:34 +0200 Subject: [cmake-developers] check_cxx_source_compiles and include directories Message-ID: <419A5EC7-E63B-4691-9643-07A34EB376C1@gmx.at> Hello, I've a small code example to test if the header file exists (with check_cxx_source_compiles), which sets my variable successfully to TRUE. When I compile the real code then I got an error message saying 'mutex' file not found. I checked the compile flags for both situations and these are equal. So I thought that the include directories could be the problem. Any hints? Best Regards Roman From mantis at public.kitware.com Mon Jul 27 08:34:16 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 27 Jul 2015 08:34:16 -0400 Subject: [cmake-developers] [CMake 0015665]: CPack and absolute paths Message-ID: <62b1bae1fdf055ef3f268e2a385df5ed@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15665 ====================================================================== Reported By: Lectem Assigned To: ====================================================================== Project: CMake Issue ID: 15665 Category: CPack Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-27 08:34 EDT Last Modified: 2015-07-27 08:34 EDT ====================================================================== Summary: CPack and absolute paths Description: When running make package (or cpack), with a target having an absolute path as its destination, it will try to install it there instead of using the temporary folder. When using this script : add_library(mylib foo.cpp) install(TARGETS mylib DESTINATION /some/custom/dir) include(CPack) cpack will install mylib to /some/custom/dir which is obviously not what we want. Plus, generators such as TGZ will not include those files, while they actually support absolute paths. What I suggest is 1. Do not make the install, or redirect it in a temp directory 2. Trigger a Warning/Error ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-27 08:34 Lectem New Issue ====================================================================== From brad.king at kitware.com Mon Jul 27 11:52:36 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 27 Jul 2015 11:52:36 -0400 Subject: [cmake-developers] CTest threshold exceeds 1024 bytes In-Reply-To: References: <26A7A5F1-8B9C-40A1-85B0-40AD29A0FF54@gmx.at> <55AE4EC3.8050607@kitware.com> <015401d0c402$ea609040$bf21b0c0$@gmx.at>, <55AFB35D.4000004@kitware.com> Message-ID: <55B653C4.7090205@kitware.com> On 07/23/2015 03:23 AM, "Roman W?ger" wrote: > I don't know how to use the -check.cmake scripts to check the > length of the output. My advice to use Tests/RunCMake/CTestCommandLine turns out to be incorrect. Use Tests/RunCMake/ctest_test instead because that one actually produces the .xml file. See the TestChangeId case for another example that checks the .xml file content. Also please change from "atoi" to StringToLong and issue a warning if the conversion of the specified value fails (see --test-load for an example). Then add a test covering this warning for each option. Thanks, -Brad From brad.king at kitware.com Mon Jul 27 11:52:48 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 27 Jul 2015 11:52:48 -0400 Subject: [cmake-developers] [MODERN] CMake 3.3 vs Qt 5.5 vs MSVC2015 In-Reply-To: <1975171437723971@web22h.yandex.ru> References: <1821991437643934@web22o.yandex.ru> <55B0E831.7070603@yahoo.com> <35881437659256@web4h.yandex.ru> <1975171437723971@web22h.yandex.ru> Message-ID: <55B653D0.4020001@kitware.com> On 07/24/2015 03:46 AM, Konstantin Podsvirov wrote: > To solve the problem you run cmake-gui is now possible with the > following changes: Applied as two separate commits with minor tweaks: cmake-gui: Install Qt5 Windows platform plugin http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=42f0155b CMake: Add CMake_INSTALL_DEPENDENCIES option http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=068e7962 Thanks, -Brad From alex.merry at kde.org Mon Jul 27 13:39:58 2015 From: alex.merry at kde.org (Alex Merry) Date: Mon, 27 Jul 2015 19:39:58 +0200 Subject: [cmake-developers] Strange behaviour with install(EXPORT) Message-ID: <3416337.j2rKvQmFrk@roku> Suppose you have a CMakeLists.txt file like ================================= cmake_minimum_required(VERSION 2.8.12) project(Foo) add_library(Ext::Imported SHARED IMPORTED) add_library(FooDep SHARED main.cpp) install(TARGETS FooDep ARCHIVE DESTINATION "lib" LIBRARY DESTINATION "lib" ) add_library(FooMain SHARED main.cpp) target_link_libraries(FooMain PUBLIC Ext::Imported PRIVATE FooDep ) install(TARGETS FooMain EXPORT FooTargets ARCHIVE DESTINATION "lib" LIBRARY DESTINATION "lib" ) install(EXPORT FooTargets NAMESPACE Foo:: DESTINATION "lib/cmake/Foo" FILE FooTargets.cmake) ================================= This fails with the error CMake Error: install(EXPORT "FooTargets" ...) includes target "FooMain" which requires target "FooDep" that is not in the export set. It is not obvious from what I have read of the documentation that this should happen, but (looking at the CMake code), this seems to be deliberate - the issue is in trying to populate IMPORTED_LINK_DEPENDENT_LIBRARIES for the exported target, it wants the private dependencies as well as the interface ones. So it wants FooDep to be EXPORTed, even though this may be a private internal library. However, removing the PUBLIC dependencies of FooMain suppresses this error, presumably because the INTERFACE_LINK_LIBRARIES property is not set, so cmTargetInternals::ComputeLinkInterfaceLibraries does not set iface.ExplicitLibraries for the target, so cmTargetInternals::ComputeLinkInterface does not add anything to iface.SharedDeps, which is what is used to populate IMPORTED_LINK_DEPENDENT_LIBRARIES. This difference in behaviour does not make sense. So either neither case should be an error, or both cases should be. However, I don't know which it is. Alex From brad.king at kitware.com Mon Jul 27 14:56:26 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 27 Jul 2015 14:56:26 -0400 Subject: [cmake-developers] Strange behaviour with install(EXPORT) In-Reply-To: <3416337.j2rKvQmFrk@roku> References: <3416337.j2rKvQmFrk@roku> Message-ID: <55B67EDA.9070707@kitware.com> On 07/27/2015 01:39 PM, Alex Merry wrote: > issue is in trying to populate IMPORTED_LINK_DEPENDENT_LIBRARIES for the > exported target, it wants the private dependencies as well as the interface > ones. So it wants FooDep to be EXPORTed, even though this may be a private > internal library. Yes, this is needed for the -rpath-link linker flag to be populated correctly. > However, removing the PUBLIC dependencies of FooMain suppresses this error, > presumably because the INTERFACE_LINK_LIBRARIES property is not set, so > cmTargetInternals::ComputeLinkInterfaceLibraries does not set > iface.ExplicitLibraries for the target, so > cmTargetInternals::ComputeLinkInterface does not add anything to > iface.SharedDeps, which is what is used to populate > IMPORTED_LINK_DEPENDENT_LIBRARIES. > > This difference in behaviour does not make sense. So either neither > case should be an error, or both cases should be. Interesting. IMPORTED_LINK_DEPENDENT_LIBRARIES was first created along with IMPORTED_LINK_INTERFACE_LIBRARIES, the predecessor to the modern INTERFACE_LINK_LIBRARIES. At the time the only two choices for shared library dependencies were: * Everything is listed in IMPORTED_LINK_INTERFACE_LIBRARIES, or * The public subset is listed in IMPORTED_LINK_INTERFACE_LIBRARIES and the rest (private subset) in IMPORTED_LINK_DEPENDENT_LIBRARIES. The distinction between these cases was whether the shared library target had the LINK_INTERFACE_LIBRARIES property set. Therefore iface.ExplicitLibraries and iface.SharedDeps always went together. With the transition to INTERFACE_LINK_LIBRARIES and the tll() PUBLIC/PRIVATE/INTERFACE keywords more combinations are now possible but the code for IMPORTED_LINK_DEPENDENT_LIBRARIES does not account for them. ------------------------------------------------------------------- The error on not exporting private dependencies has received complaints before. Technically it is necessary to properly populate the -rpath-link flag when a shared library has dependencies that are not next to it and not in a standard location, but often it is not necessary in practice. I think we once discussed dropping the error and populating the IMPORTED_LINK_DEPENDENT_LIBRARIES property only with private dependencies that happen to be available in the export set. The discussion may be in the dev list archives but I don't recall when/where. -Brad From roman.wueger at gmx.at Mon Jul 27 15:26:18 2015 From: roman.wueger at gmx.at (=?iso-8859-1?Q?Roman_W=FCger?=) Date: Mon, 27 Jul 2015 21:26:18 +0200 Subject: [cmake-developers] check_cxx_source_compiles and include directories In-Reply-To: <419A5EC7-E63B-4691-9643-07A34EB376C1@gmx.at> References: <419A5EC7-E63B-4691-9643-07A34EB376C1@gmx.at> Message-ID: <050101d0c8a2$1df05050$59d0f0f0$@gmx.at> So, here is the piece of code which works Main CMakeLists.txt: project(MyProject) list(APPEND CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake) if (APPLE) set(CMAKE_CXX_EXTENSIONS OFF) # Use -std=c++11 instead of -std=gnu++11 endif() set(CMAKE_CXX_STANDARD 11) include(CheckCXXCompilerFlag) # Required for check_cxx_source_cmopiles check_cxx_compiler_flag("-std=c++11" CXX11_FLAG) if (CXX11_FLAG) set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") endif() include(CheckMyCXX11Features.cmake) . . . add_subdirectory(SubProj1) add_subdirectory(SubProj2) . . . CheckMyCXX11Features.cmake: include(CheckCXXSourceCompiles) # C++11 Unique Lock and Mutex set(CMAKE_REQUIRED_FLAGS "${CMAKE_CXX_FLAGS}") check_cxx_source_compiles( "#include // std::mutex, std::unique_lock std::mutex mtx; // mutex for critical section void print_block (int n, char c) { // critical section (exclusive access to std::cout signaled by lifetime of lck): std::unique_lock lck (mtx); for (int i=0; i, but check_cxx_source_compiles succeeds. Did I miss configure something here? Best Regards Roman > -----Urspr?ngliche Nachricht----- > Von: cmake-developers [mailto:cmake-developers-bounces at cmake.org] Im > Auftrag von Roman W?ger > Gesendet: Montag, 27. Juli 2015 07:35 > An: CMake MailingList ; CMake Developer MailingList > > Betreff: [cmake-developers] check_cxx_source_compiles and include > directories > > Hello, > > I've a small code example to test if the header file exists (with > check_cxx_source_compiles), which sets my variable successfully to TRUE. > > When I compile the real code then I got an error message saying 'mutex' file > not found. > > I checked the compile flags for both situations and these are equal. So I > thought that the include directories could be the problem. > > Any hints? > > Best Regards > Roman > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/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-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Mon Jul 27 15:07:05 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Mon, 27 Jul 2015 12:07:05 -0700 (PDT) Subject: [cmake-developers] What is the difference between "Unix Makefiles" and "MSYS Makefiles" on MSYS2? Message-ID: I got no response on the CMake list to the question below so I thought I had better ask instead the CMake developers here just what are the actual differences (if any) between the "Unix Makefiles" and "MSYS Makefiles" generators? The point is that if both openwalnut builds on MSYS2 succeed with "Unix Makefiles" and allegro builds on MSYS2 succeed with "MSYS Makefiles", then the differences between the two generators might be minimal/unimportant so I could just recommend to PLplot users that they can use either generator on MSYS2. But I would appreciate your comments on that possibility before I made such a recommendation. Alan ---------- Forwarded message ---------- Date: Fri, 24 Jul 2015 19:25:21 -0700 (PDT) From: Alan W. Irwin To: cmake at cmake.org Subject: [CMake] Using cmake on the MSYS2 platform(s) Recently, I have found two useful resources () and ) giving advice on how to use cmake with MSYS2 and its collection of packages compiled with either the the mingw-w64-i686 or mingw-w64-x86_64 toolchains. (For further background on MSYS2, its tool chains, and it's pacman package repositories see .) The cmake advice from the openwalnut and allegro sites is essentially consistent except for one issue which is what generator to use? The openwalnut site recommends "Unix Makefiles" to build openwalnut while the allegro site recommends "MSYS Makefiles" to build allegro. Although I am sure those two generators work for their own peculiar build needs on the MSYS2 platforms is there a general recommendation that anyone here has for the recommended generator to use for the MSYS2 platforms? Note this question and the openwalnut and allegro comments are concerned with the case where you are using MSYS2 build tools (e.g., make, pkg-config, grep, sed, gzip, and tar) and not the case where you are building using either of the mingw-w64-i686 or mingw-w64-x86_64 toolchains without the MSYS2 build tools. Also note that although the MSYS2 project is a similar concept to classical MSYS (which is an ancient spin-off from Cygwin), the details can be quite different because MSYS2 is a modern spin-off from Cygwin. Therefore, recommending a MinGW/MSYS solution e.g., "MSYS Makefiles" for the MSYS2 case may or may not be more appropriate than recommending a Cygwin solution, e.g., "Unix Makefiles" for the MSYS2 case. So what I need here is a recommendation based on actual experience with MSYS2 and not MSYS. 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 __________________________ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/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 brad.king at kitware.com Mon Jul 27 16:26:11 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 27 Jul 2015 16:26:11 -0400 Subject: [cmake-developers] What is the difference between "Unix Makefiles" and "MSYS Makefiles" on MSYS2? In-Reply-To: References: Message-ID: <55B693E3.8010805@kitware.com> On 07/27/2015 03:07 PM, Alan W. Irwin wrote: > I got no response on the CMake list to the question below so I thought > I had better ask instead the CMake developers here just what are the > actual differences (if any) between the "Unix Makefiles" and "MSYS > Makefiles" generators? > > The point is that if both openwalnut builds on MSYS2 succeed with > "Unix Makefiles" and allegro builds on MSYS2 succeed with "MSYS > Makefiles", then the differences between the two generators might be > minimal/unimportant so I could just recommend to PLplot users that > they can use either generator on MSYS2. But I would appreciate your > comments on that possibility before I made such a recommendation. Looking at the source for the "MSYS Makefiles" generator the differences are: - Defines "MSYS" variable to "1" for use by CMake project code. - Selects "gcc", "g++", and "windres" as the default compilers for C, CXX, and RC languages (instead of just "cc" and "c++"). - When writing commands to the makefiles to be executed in the shell, explicitly converts "c:/path" to "/c/path" in a few cases. I'm not particularly familiar with MSYS2 so I can't say off the top of my head which generator is best for it. If "Unix Makefiles" works well I don't think there is a reason not to use it. -Brad From ben.boeckel at kitware.com Mon Jul 27 17:04:55 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 27 Jul 2015 17:04:55 -0400 Subject: [cmake-developers] Strange behaviour with install(EXPORT) In-Reply-To: <55B67EDA.9070707@kitware.com> References: <3416337.j2rKvQmFrk@roku> <55B67EDA.9070707@kitware.com> Message-ID: <20150727210455.GA2787@megas.kitware.com> On Mon, Jul 27, 2015 at 14:56:26 -0400, Brad King wrote: > The error on not exporting private dependencies has received > complaints before. Technically it is necessary to properly > populate the -rpath-link flag when a shared library has > dependencies that are not next to it and not in a standard > location, but often it is not necessary in practice. I think > we once discussed dropping the error and populating the > IMPORTED_LINK_DEPENDENT_LIBRARIES property only with private > dependencies that happen to be available in the export set. > The discussion may be in the dev list archives but I don't > recall when/where. Wouldn't an exported static library still need to inform others about its private non-exported static library dependencies though? For a shared library, ignoring static libraries in the private set would make sense. --Ben From michael.scott250 at gmail.com Mon Jul 27 19:07:03 2015 From: michael.scott250 at gmail.com (Michael Scott) Date: Tue, 28 Jul 2015 00:07:03 +0100 Subject: [cmake-developers] Add command line options for deprecation message control Message-ID: <55B6B997.90205@gmail.com> Hi, After the last feedback, I've made some changes which should address the points that were talked about. I've changed the -W dev options to affect the deprecated warnings/errors as well, but only if the user hasn't used one of the options that control deprecated warnings (-Wdeprecated, -Wno-deprecated, -Werror=deprecated, -Wno-error=deprecated), if they have then the -W dev options won't affect the CMAKE_WARN_DEPRECATED or CMAKE_ERROR_DEPRECATED variables. I've also added the two -W dev options, "-Werror=dev" and "-Wno-error=dev", to bring this set of options in line with the deprecated set of options. For this I've added a new variable, CMAKE_SUPPRESS_DEVELOPER_ERRORS, which controls whether or not author warnings are treated as fatal errors. By default it's set to TRUE as this seemed more sensible. I've added some more cases to the run CMake tests and updated the documentation to contain the new options and variable, I've also added a document to the dev release notes in case these additional changes merited one. Please let me know if there are any mistakes/issues with the attached commit or if I've missed out anything. I've started some changes to the QT GUI to allow it to use these changes, but I thought it'd be best to commit the given changes now, and then do a separate chunk of work for the QT GUI changes, as the changes for all this have grown larger than expected. Cheers, Michael Scott -------------- next part -------------- From 3ed09142ec81861670ca2fe27e28ca782ad60e9f Mon Sep 17 00:00:00 2001 From: Michael Scott Date: Sat, 13 Jun 2015 18:34:31 +0100 Subject: [PATCH] Refactored the -Wdev and -Wno-dev to use a generic -W parser, which follows the GCC pattern. Included support for setting CMAKE_ERROR_DEPRECATED and CMAKE_WARN_DEPRECATED via the deprecated warning. Added -Werror=dev and -Wno-error=dev options, so that dev warning options are in line with deprecated warning options. Added a new variable CMAKE_SUPPRESS_DEVELOPER_ERRORS, which is set using the above new dev options. Added tests for new options and updated cmake documentation and release notes to list new options. --- Help/manual/OPTIONS_BUILD.txt | 40 +++- Help/manual/cmake-variables.7.rst | 2 + Help/release/dev/cmake-Wdeprecated.rst | 9 + Help/release/dev/cmake-Wdev.rst | 7 + Help/variable/CMAKE_ERROR_DEPRECATED.rst | 4 + Help/variable/CMAKE_SUPPRESS_DEVELOPER_ERRORS.rst | 12 ++ Help/variable/CMAKE_WARN_DEPRECATED.rst | 4 + Source/cmMessageCommand.cxx | 14 +- Source/cmake.cxx | 239 ++++++++++++++++++--- Source/cmake.h | 27 ++- Tests/RunCMake/CommandLine/RunCMakeTest.cmake | 63 ++++++ Tests/RunCMake/CommandLine/W_bad-arg1-result.txt | 1 + Tests/RunCMake/CommandLine/W_bad-arg1-stderr.txt | 2 + Tests/RunCMake/CommandLine/W_bad-arg2-result.txt | 1 + Tests/RunCMake/CommandLine/W_bad-arg2-stderr.txt | 2 + Tests/RunCMake/CommandLine/W_bad-arg3-result.txt | 1 + Tests/RunCMake/CommandLine/W_bad-arg3-stderr.txt | 2 + Tests/RunCMake/CommandLine/Wdeprecated-stderr.txt | 4 + Tests/RunCMake/CommandLine/Wdeprecated.cmake | 1 + .../CommandLine/Werror_deprecated-result.txt | 1 + .../CommandLine/Werror_deprecated-stderr.txt | 4 + Tests/RunCMake/CommandLine/Werror_deprecated.cmake | 1 + Tests/RunCMake/CommandLine/Werror_dev-result.txt | 1 + Tests/RunCMake/CommandLine/Werror_dev-stderr.txt | 5 + Tests/RunCMake/CommandLine/Werror_dev.cmake | 1 + Tests/RunCMake/CommandLine/Wno-deprecated.cmake | 1 + .../CommandLine/Wno-error_deprecated.cmake | 1 + Tests/RunCMake/CommandLine/Wno-error_dev.cmake | 1 + 28 files changed, 408 insertions(+), 43 deletions(-) create mode 100644 Help/release/dev/cmake-Wdeprecated.rst create mode 100644 Help/release/dev/cmake-Wdev.rst create mode 100644 Help/variable/CMAKE_SUPPRESS_DEVELOPER_ERRORS.rst create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg1-result.txt create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg1-stderr.txt create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg2-result.txt create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg2-stderr.txt create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg3-result.txt create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg3-stderr.txt create mode 100644 Tests/RunCMake/CommandLine/Wdeprecated-stderr.txt create mode 100644 Tests/RunCMake/CommandLine/Wdeprecated.cmake create mode 100644 Tests/RunCMake/CommandLine/Werror_deprecated-result.txt create mode 100644 Tests/RunCMake/CommandLine/Werror_deprecated-stderr.txt create mode 100644 Tests/RunCMake/CommandLine/Werror_deprecated.cmake create mode 100644 Tests/RunCMake/CommandLine/Werror_dev-result.txt create mode 100644 Tests/RunCMake/CommandLine/Werror_dev-stderr.txt create mode 100644 Tests/RunCMake/CommandLine/Werror_dev.cmake create mode 100644 Tests/RunCMake/CommandLine/Wno-deprecated.cmake create mode 100644 Tests/RunCMake/CommandLine/Wno-error_deprecated.cmake create mode 100644 Tests/RunCMake/CommandLine/Wno-error_dev.cmake diff --git a/Help/manual/OPTIONS_BUILD.txt b/Help/manual/OPTIONS_BUILD.txt index 4207db4..34e890f 100644 --- a/Help/manual/OPTIONS_BUILD.txt +++ b/Help/manual/OPTIONS_BUILD.txt @@ -77,10 +77,46 @@ Suppress developer warnings. Suppress warnings that are meant for the author of the - CMakeLists.txt files. + CMakeLists.txt files. By default this will also turn off deprecated warnings. ``-Wdev`` Enable developer warnings. Enable warnings that are meant for the author of the CMakeLists.txt - files. + files. By default this will also turn on deprecated warnings. + +``-Werror=dev`` + Make developer warnings errors. + + Make warnings that are meant for the author of the CMakeLists.txt files + errors. By default this will also turn on deprecated warnings as errors. + +``-Wno-error=dev`` + Make developer warnings not errors. + + Make warnings that are meant for the author of the CMakeLists.txt files not + errors. By default this will also turn off deprecated warnings as errors. + +``-Wdeprecated`` + Enable deprecated macro and function warnings. + + Enable warnings for usage of deprecated macros and functions, that are meant + for the author of the CMakeLists.txt files. + +``-Wno-deprecated`` + Suppress deprecated macro and function warnings. + + Suppress warnings for usage of deprecated macros and functions, that are meant + for the author of the CMakeLists.txt files. + +``-Werror=deprecated`` + Make deprecated macro and function warnings errors. + + Make warnings for usage of deprecated macros and functions, that are meant + for the author of the CMakeLists.txt files, errors. + +``-Wno-error=deprecated`` + Make deprecated macro and function warnings not errors. + + Make warnings for usage of deprecated macros and functions, that are meant + for the author of the CMakeLists.txt files, not errors. diff --git a/Help/manual/cmake-variables.7.rst b/Help/manual/cmake-variables.7.rst index f010d28..3e4c39b 100644 --- a/Help/manual/cmake-variables.7.rst +++ b/Help/manual/cmake-variables.7.rst @@ -149,6 +149,7 @@ Variables that Change Behavior /variable/CMAKE_PROJECT_PROJECT-NAME_INCLUDE /variable/CMAKE_SKIP_INSTALL_ALL_DEPENDENCY /variable/CMAKE_STAGING_PREFIX + /variable/CMAKE_SUPPRESS_DEVELOPER_ERRORS /variable/CMAKE_SYSTEM_APPBUNDLE_PATH /variable/CMAKE_SYSTEM_FRAMEWORK_PATH /variable/CMAKE_SYSTEM_IGNORE_PATH @@ -239,6 +240,7 @@ Variables that Control the Build /variable/CMAKE_INSTALL_NAME_DIR /variable/CMAKE_INSTALL_RPATH /variable/CMAKE_INSTALL_RPATH_USE_LINK_PATH + /variable/CMAKE_LANG_COMPILER_LAUNCHER /variable/CMAKE_LANG_INCLUDE_WHAT_YOU_USE /variable/CMAKE_LANG_VISIBILITY_PRESET /variable/CMAKE_LIBRARY_OUTPUT_DIRECTORY diff --git a/Help/release/dev/cmake-Wdeprecated.rst b/Help/release/dev/cmake-Wdeprecated.rst new file mode 100644 index 0000000..7b89fc3 --- /dev/null +++ b/Help/release/dev/cmake-Wdeprecated.rst @@ -0,0 +1,9 @@ +cmake-Wdeprecated +----------------- + +The :variable:`CMAKE_ERROR_DEPRECATED` variable can now be set using the +``-Werror=deprecated`` and ``-Wno-error=deprecated`` :manual:`cmake(1)` +options. + +The :variable:`CMAKE_WARN_DEPRECATED` variable can now be set using the +``-Wdeprecated`` and ``-Wno-deprecated`` :manual:`cmake(1)` options. diff --git a/Help/release/dev/cmake-Wdev.rst b/Help/release/dev/cmake-Wdev.rst new file mode 100644 index 0000000..9daf057 --- /dev/null +++ b/Help/release/dev/cmake-Wdev.rst @@ -0,0 +1,7 @@ +cmake-Wdev +---------- + +CMake learned the new :variable:`CMAKE_SUPPRESS_DEVELOPER_ERRORS` variable +to supress developer errors intended for CMake authors. This variable is +TRUE by default and can now be set using the ``-Werror=dev`` and +``-Wno-error=dev`` :manual:`cmake(1)` options. diff --git a/Help/variable/CMAKE_ERROR_DEPRECATED.rst b/Help/variable/CMAKE_ERROR_DEPRECATED.rst index 43ab282..68befc2 100644 --- a/Help/variable/CMAKE_ERROR_DEPRECATED.rst +++ b/Help/variable/CMAKE_ERROR_DEPRECATED.rst @@ -6,3 +6,7 @@ Whether to issue deprecation errors for macros and functions. If TRUE, this can be used by macros and functions to issue fatal errors when deprecated macros or functions are used. This variable is FALSE by default. + +These errors can be enabled with the ``-Werror=deprecated`` option, or +disabled with the ``-Wno-error=deprecated`` option, when running +:manual:`cmake(1)`. diff --git a/Help/variable/CMAKE_SUPPRESS_DEVELOPER_ERRORS.rst b/Help/variable/CMAKE_SUPPRESS_DEVELOPER_ERRORS.rst new file mode 100644 index 0000000..34a8087 --- /dev/null +++ b/Help/variable/CMAKE_SUPPRESS_DEVELOPER_ERRORS.rst @@ -0,0 +1,12 @@ +CMAKE_SUPPRESS_DEVELOPER_ERRORS +------------------------------- + +Whether to supress developer errors intended for authors of CMakeLists.txt +files. + +If TRUE, developer warnings issued by macros and functions will not be +treated as fatal erors. This variable is TRUE by default. Setting this +variable will not affect the suppression of developer warnings. + +These errors can be enabled with the ``-Werror=dev`` option, or disabled +with the ``-Wno-error=dev`` option, when running :manual:`cmake(1)`. diff --git a/Help/variable/CMAKE_WARN_DEPRECATED.rst b/Help/variable/CMAKE_WARN_DEPRECATED.rst index 7b2510b..2a13895 100644 --- a/Help/variable/CMAKE_WARN_DEPRECATED.rst +++ b/Help/variable/CMAKE_WARN_DEPRECATED.rst @@ -5,3 +5,7 @@ Whether to issue deprecation warnings for macros and functions. If TRUE, this can be used by macros and functions to issue deprecation warnings. This variable is FALSE by default. + +These warnings can be enabled with the ``-Wdeprecated`` option, or +disabled with the ``-Wno-deprecated`` option, when running +:manual:`cmake(1)`. diff --git a/Source/cmMessageCommand.cxx b/Source/cmMessageCommand.cxx index 0449c50..219a70c 100644 --- a/Source/cmMessageCommand.cxx +++ b/Source/cmMessageCommand.cxx @@ -43,7 +43,19 @@ bool cmMessageCommand } else if (*i == "AUTHOR_WARNING") { - type = cmake::AUTHOR_WARNING; + if (!this->Makefile->IsOn("CMAKE_SUPPRESS_DEVELOPER_ERRORS")) + { + fatal = true; + type = cmake::AUTHOR_ERROR; + } + else if (!this->Makefile->IsOn("CMAKE_SUPPRESS_DEVELOPER_WARNINGS")) + { + type = cmake::AUTHOR_WARNING; + } + else + { + return true; + } ++i; } else if (*i == "STATUS") diff --git a/Source/cmake.cxx b/Source/cmake.cxx index eeb6575..2905db0 100644 --- a/Source/cmake.cxx +++ b/Source/cmake.cxx @@ -125,8 +125,6 @@ cmake::cmake() this->WarnUnused = false; this->WarnUnusedCli = true; this->CheckSystemVars = false; - this->SuppressDevWarnings = false; - this->DoSuppressDevWarnings = false; this->DebugOutput = false; this->DebugTryCompile = false; this->ClearBuildSystem = false; @@ -186,7 +184,7 @@ cmake::~cmake() void cmake::CleanupCommandsAndMacros() { - this->State->Reset(); + this->CurrentSnapshot = this->State->Reset(); this->State->RemoveUserDefinedCommands(); } @@ -251,15 +249,69 @@ bool cmake::SetCacheArgs(const std::vector& args) return false; } } - else if(arg.find("-Wno-dev",0) == 0) + else if(cmHasLiteralPrefix(arg, "-W")) { - this->SuppressDevWarnings = true; - this->DoSuppressDevWarnings = true; + std::string entry = arg.substr(2); + if (entry.empty()) + { + ++i; + if (i < args.size()) + { + entry = args[i]; + } + else + { + cmSystemTools::Error("-W must be followed with [no-][error=]."); + return false; + } } - else if(arg.find("-Wdev",0) == 0) - { - this->SuppressDevWarnings = false; - this->DoSuppressDevWarnings = true; + + std::string name; + bool foundNo = false; + bool foundError = false; + unsigned int nameStartPosition = 0; + + if (entry.find("no-", nameStartPosition) == 0) + { + foundNo = true; + nameStartPosition += 3; + } + + if (entry.find("error=", nameStartPosition) == 0) + { + foundError = true; + nameStartPosition += 6; + } + + name = entry.substr(nameStartPosition); + if (name.empty()) + { + cmSystemTools::Error("No warning name provided."); + return false; + } + + if (!foundNo && !foundError) + { + // -W + this->WarningLevels[name] = std::max(this->WarningLevels[name], + WARNING_LEVEL); + } + else if (foundNo && !foundError) + { + // -Wno + this->WarningLevels[name] = IGNORE_LEVEL; + } + else if (!foundNo && foundError) + { + // -Werror= + this->WarningLevels[name] = ERROR_LEVEL; + } + else + { + // -Wno-error= + this->WarningLevels[name] = std::min(this->WarningLevels[name], + WARNING_LEVEL); + } } else if(arg.find("-U",0) == 0) { @@ -370,6 +422,7 @@ void cmake::ReadListFile(const std::vector& args, // read in the list file to fill the cache if(path) { + this->CurrentSnapshot = this->State->Reset(); std::string homeDir = this->GetHomeDirectory(); std::string homeOutputDir = this->GetHomeOutputDirectory(); this->SetHomeDirectory(cmSystemTools::GetCurrentWorkingDirectory()); @@ -482,7 +535,7 @@ bool cmake::FindPackage(const std::vector& args) std::string linkPath; std::string flags; std::string linkFlags; - gg->CreateGeneratorTargets(mf); + gg->CreateGeneratorTargets(lg.get()); cmGeneratorTarget *gtgt = gg->GetGeneratorTarget(tgt); lg->GetTargetFlags(linkLibs, frameworkPath, linkPath, flags, linkFlags, gtgt, false); @@ -587,11 +640,7 @@ void cmake::SetArgs(const std::vector& args, // skip for now i++; } - else if(arg.find("-Wno-dev",0) == 0) - { - // skip for now - } - else if(arg.find("-Wdev",0) == 0) + else if(arg.find("-W",0) == 0) { // skip for now } @@ -1171,25 +1220,121 @@ int cmake::HandleDeleteCacheVariables(const std::string& var) int cmake::Configure() { - if(this->DoSuppressDevWarnings) + WarningLevel warningLevel; + + if (this->WarningLevels.count("deprecated") == 1) + { + warningLevel = this->WarningLevels["deprecated"]; + if (warningLevel == IGNORE_LEVEL) + { + this->CacheManager-> + AddCacheEntry("CMAKE_WARN_DEPRECATED", "FALSE", + "Whether to issue deprecation warnings for" + " macros and functions.", + cmState::BOOL); + this->CacheManager-> + AddCacheEntry("CMAKE_ERROR_DEPRECATED", "FALSE", + "Whether to issue deprecation errors for macros" + " and functions.", + cmState::BOOL); + } + if (warningLevel == WARNING_LEVEL) + { + this->CacheManager-> + AddCacheEntry("CMAKE_WARN_DEPRECATED", "TRUE", + "Whether to issue deprecation warnings for" + " macros and functions.", + cmState::BOOL); + } + else if (warningLevel == ERROR_LEVEL) + { + this->CacheManager-> + AddCacheEntry("CMAKE_ERROR_DEPRECATED", "TRUE", + "Whether to issue deprecation errors for macros" + " and functions.", + cmState::BOOL); + } + } + + if (this->WarningLevels.count("dev") == 1) { - if(this->SuppressDevWarnings) + bool setDeprecatedVariables = false; + + const char* cachedWarnDeprecated = + this->State->GetCacheEntryValue("CMAKE_WARN_DEPRECATED"); + const char* cachedErrorDeprecated = + this->State->GetCacheEntryValue("CMAKE_ERROR_DEPRECATED"); + + // don't overwrite deprecated warning setting from a previous invocation + if (!cachedWarnDeprecated && !cachedErrorDeprecated) + { + setDeprecatedVariables = true; + } + + warningLevel = this->WarningLevels["dev"]; + if (warningLevel == IGNORE_LEVEL) { this->CacheManager-> AddCacheEntry("CMAKE_SUPPRESS_DEVELOPER_WARNINGS", "TRUE", "Suppress Warnings that are meant for" " the author of the CMakeLists.txt files.", cmState::INTERNAL); + this->CacheManager-> + AddCacheEntry("CMAKE_SUPPRESS_DEVELOPER_ERRORS", "TRUE", + "Suppress errors that are meant for" + " the author of the CMakeLists.txt files.", + cmState::INTERNAL); + + if (setDeprecatedVariables) + { + this->CacheManager-> + AddCacheEntry("CMAKE_WARN_DEPRECATED", "FALSE", + "Whether to issue deprecation warnings for" + " macros and functions.", + cmState::BOOL); + this->CacheManager-> + AddCacheEntry("CMAKE_ERROR_DEPRECATED", "FALSE", + "Whether to issue deprecation errors for macros" + " and functions.", + cmState::BOOL); + } } - else + else if (warningLevel == WARNING_LEVEL) { this->CacheManager-> AddCacheEntry("CMAKE_SUPPRESS_DEVELOPER_WARNINGS", "FALSE", "Suppress Warnings that are meant for" " the author of the CMakeLists.txt files.", cmState::INTERNAL); + + if (setDeprecatedVariables) + { + this->CacheManager-> + AddCacheEntry("CMAKE_WARN_DEPRECATED", "TRUE", + "Whether to issue deprecation warnings for" + " macros and functions.", + cmState::BOOL); + } + } + else if (warningLevel == ERROR_LEVEL) + { + this->CacheManager-> + AddCacheEntry("CMAKE_SUPPRESS_DEVELOPER_ERRORS", "FALSE", + "Suppress errors that are meant for" + " the author of the CMakeLists.txt files.", + cmState::INTERNAL); + + if (setDeprecatedVariables) + { + this->CacheManager-> + AddCacheEntry("CMAKE_ERROR_DEPRECATED", "TRUE", + "Whether to issue deprecation errors for macros" + " and functions.", + cmState::BOOL); + } } } + int ret = this->ActualConfigure(); const char* delCacheVars = this->State ->GetGlobalProperty("__CMAKE_DELETE_CACHE_CHANGE_VARS_"); @@ -1533,6 +1678,18 @@ int cmake::Run(const std::vector& args, bool noconfigure) { this->AddCMakePaths(); } + + // don't turn dev warnings into errors by default, if no value has been + // specified for the flag, enable it + if (!this->State->GetCacheEntryValue("CMAKE_SUPPRESS_DEVELOPER_ERRORS")) + { + this->CacheManager-> + AddCacheEntry("CMAKE_SUPPRESS_DEVELOPER_ERRORS", "TRUE", + "Suppress errors that are meant for" + " the author of the CMakeLists.txt files.", + cmState::INTERNAL); + } + // Add any cache args if ( !this->SetCacheArgs(args) ) { @@ -2431,20 +2588,17 @@ bool cmake::PrintMessagePreamble(cmake::MessageType t, std::ostream& msg) { msg << "CMake Deprecation Warning"; } + else if (t == cmake::AUTHOR_WARNING) + { + msg << "CMake Warning (dev)"; + } + else if (t == cmake::AUTHOR_ERROR) + { + msg << "CMake Error (dev)"; + } else { msg << "CMake Warning"; - if(t == cmake::AUTHOR_WARNING) - { - // Allow suppression of these warnings. - const char* suppress = this->State->GetCacheEntryValue( - "CMAKE_SUPPRESS_DEVELOPER_WARNINGS"); - if(suppress && cmSystemTools::IsOn(suppress)) - { - return false; - } - msg << " (dev)"; - } } return true; } @@ -2466,6 +2620,12 @@ void displayMessage(cmake::MessageType t, std::ostringstream& msg) msg << "This warning is for project developers. Use -Wno-dev to suppress it."; } + else if (t == cmake::AUTHOR_ERROR) + { + msg << + "This error is for project developers. Use -Wno-error=dev to suppress " + "it."; + } // Add a terminating blank line. msg << "\n"; @@ -2489,7 +2649,8 @@ void displayMessage(cmake::MessageType t, std::ostringstream& msg) // Output the message. if(t == cmake::FATAL_ERROR || t == cmake::INTERNAL_ERROR - || t == cmake::DEPRECATION_ERROR) + || t == cmake::DEPRECATION_ERROR + || t == cmake::AUTHOR_ERROR) { cmSystemTools::SetErrorOccured(); cmSystemTools::Message(msg.str().c_str(), "Error"); @@ -2667,3 +2828,19 @@ void cmake::RunCheckForUnusedVariables() } #endif } + +void cmake::SetSuppressDevWarnings(bool b) +{ + // equivalent to -Wno-dev + if (b) + { + this->WarningLevels["dev"] = IGNORE_LEVEL; + } + // equivalent to -Wdev + else + { + this->WarningLevels["dev"] = std::max(this->WarningLevels["dev"], + WARNING_LEVEL); + } +} + diff --git a/Source/cmake.h b/Source/cmake.h index f0f9411..7b679d3 100644 --- a/Source/cmake.h +++ b/Source/cmake.h @@ -60,6 +60,7 @@ class cmake public: enum MessageType { AUTHOR_WARNING, + AUTHOR_ERROR, FATAL_ERROR, INTERNAL_ERROR, MESSAGE, @@ -69,6 +70,12 @@ class cmake DEPRECATION_WARNING }; + enum WarningLevel + { + IGNORE_LEVEL, + WARNING_LEVEL, + ERROR_LEVEL + }; /** \brief Describes the working modes of cmake */ enum WorkingMode @@ -270,6 +277,7 @@ class cmake // Do we want trace output during the cmake run. bool GetTrace() { return this->Trace;} void SetTrace(bool b) { this->Trace = b;} + void SetSuppressDevWarnings(bool b); bool GetWarnUninitialized() { return this->WarnUninitialized;} void SetWarnUninitialized(bool b) { this->WarnUninitialized = b;} bool GetWarnUnused() { return this->WarnUnused;} @@ -290,12 +298,6 @@ class cmake std::string const& GetCMakeEditCommand() const { return this->CMakeEditCommand; } - void SetSuppressDevWarnings(bool v) - { - this->SuppressDevWarnings = v; - this->DoSuppressDevWarnings = true; - } - /** Display a message to the user. */ void IssueMessage(cmake::MessageType t, std::string const& text, cmListFileBacktrace const& backtrace = cmListFileBacktrace()); @@ -339,8 +341,7 @@ protected: cmPolicies *Policies; cmGlobalGenerator *GlobalGenerator; cmCacheManager *CacheManager; - bool SuppressDevWarnings; - bool DoSuppressDevWarnings; + std::map WarningLevels; std::string GeneratorPlatform; std::string GeneratorToolset; @@ -415,7 +416,15 @@ private: {"-T ", "Specify toolset name if supported by generator."}, \ {"-A ", "Specify platform name if supported by generator."}, \ {"-Wno-dev", "Suppress developer warnings."},\ - {"-Wdev", "Enable developer warnings."} + {"-Wdev", "Enable developer warnings."},\ + {"-Werror=dev", "Make developer warnings errors."},\ + {"-Wno-error=dev", "Make developer warnings not errors."},\ + {"-Wdeprecated", "Enable deprecated macro and function warnings."},\ + {"-Wno-deprecated", "Suppress deprecated macro and function warnings."},\ + {"-Werror=deprecated", "Make deprecated macro and function warnings " \ + "errors."},\ + {"-Wno-error=deprecated", "Make deprecated macro and function warnings " \ + "not errors."} #define FOR_EACH_C_FEATURE(F) \ F(c_function_prototypes) \ diff --git a/Tests/RunCMake/CommandLine/RunCMakeTest.cmake b/Tests/RunCMake/CommandLine/RunCMakeTest.cmake index 69beed9..40b560c 100644 --- a/Tests/RunCMake/CommandLine/RunCMakeTest.cmake +++ b/Tests/RunCMake/CommandLine/RunCMakeTest.cmake @@ -22,13 +22,30 @@ run_cmake_command(G_bad-arg ${CMAKE_COMMAND} -G NoSuchGenerator) run_cmake_command(P_no-arg ${CMAKE_COMMAND} -P) run_cmake_command(P_no-file ${CMAKE_COMMAND} -P nosuchscriptfile.cmake) +run_cmake_command(build-no-dir + ${CMAKE_COMMAND} --build) run_cmake_command(build-no-cache ${CMAKE_COMMAND} --build ${RunCMake_SOURCE_DIR}) run_cmake_command(build-no-generator ${CMAKE_COMMAND} --build ${RunCMake_SOURCE_DIR}/cache-no-generator) +run_cmake_command(build-bad-dir + ${CMAKE_COMMAND} --build dir-does-not-exist) run_cmake_command(build-bad-generator ${CMAKE_COMMAND} --build ${RunCMake_SOURCE_DIR}/cache-bad-generator) +function(run_BuildDir) + # Use a single build tree for a few tests without cleaning. + set(RunCMake_TEST_BINARY_DIR ${RunCMake_BINARY_DIR}/BuildDir-build) + set(RunCMake_TEST_NO_CLEAN 1) + file(REMOVE_RECURSE "${RunCMake_TEST_BINARY_DIR}") + file(MAKE_DIRECTORY "${RunCMake_TEST_BINARY_DIR}") + + run_cmake(BuildDir) + run_cmake_command(BuildDir--build ${CMAKE_COMMAND} -E chdir .. + ${CMAKE_COMMAND} --build BuildDir-build --target CustomTarget) +endfunction() +run_BuildDir() + if(RunCMake_GENERATOR STREQUAL "Ninja") # Use a single build tree for a few tests without cleaning. set(RunCMake_TEST_BINARY_DIR ${RunCMake_BINARY_DIR}/Build-build) @@ -115,6 +132,52 @@ set(RunCMake_TEST_OPTIONS -Wno-dev -Wdev) run_cmake(Wdev) unset(RunCMake_TEST_OPTIONS) +set(RunCMake_TEST_OPTIONS -Werror=dev) +run_cmake(Werror_dev) +unset(RunCMake_TEST_OPTIONS) + +set(RunCMake_TEST_OPTIONS -Wno-error=dev) +run_cmake(Wno-error_deprecated) +unset(RunCMake_TEST_OPTIONS) + +# -Wdev should not override deprecated options if specified +set(RunCMake_TEST_OPTIONS -Wdev -Wno-deprecated) +run_cmake(Wno-deprecated) +unset(RunCMake_TEST_OPTIONS) +set(RunCMake_TEST_OPTIONS -Wno-deprecated -Wdev) +run_cmake(Wno-deprecated) +unset(RunCMake_TEST_OPTIONS) + +# -Wdev should enable deprecated warnings as well +set(RunCMake_TEST_OPTIONS -Wdev) +run_cmake(Wdeprecated) +unset(RunCMake_TEST_OPTIONS) + +# -Werror=dev should enable deprecated errors as well +set(RunCMake_TEST_OPTIONS -Werror=dev) +run_cmake(Werror_deprecated) +unset(RunCMake_TEST_OPTIONS) + +set(RunCMake_TEST_OPTIONS -Wdeprecated) +run_cmake(Wdeprecated) +unset(RunCMake_TEST_OPTIONS) + +set(RunCMake_TEST_OPTIONS -Wno-deprecated) +run_cmake(Wno-deprecated) +unset(RunCMake_TEST_OPTIONS) + +set(RunCMake_TEST_OPTIONS -Werror=deprecated) +run_cmake(Werror_deprecated) +unset(RunCMake_TEST_OPTIONS) + +set(RunCMake_TEST_OPTIONS -Wno-error=deprecated) +run_cmake(Wno-error_deprecated) +unset(RunCMake_TEST_OPTIONS) + +run_cmake_command(W_bad-arg1 ${CMAKE_COMMAND} -W) +run_cmake_command(W_bad-arg2 ${CMAKE_COMMAND} -Wno-) +run_cmake_command(W_bad-arg3 ${CMAKE_COMMAND} -Werror=) + set(RunCMake_TEST_OPTIONS --debug-output) run_cmake(debug-output) unset(RunCMake_TEST_OPTIONS) diff --git a/Tests/RunCMake/CommandLine/W_bad-arg1-result.txt b/Tests/RunCMake/CommandLine/W_bad-arg1-result.txt new file mode 100644 index 0000000..d00491f --- /dev/null +++ b/Tests/RunCMake/CommandLine/W_bad-arg1-result.txt @@ -0,0 +1 @@ +1 diff --git a/Tests/RunCMake/CommandLine/W_bad-arg1-stderr.txt b/Tests/RunCMake/CommandLine/W_bad-arg1-stderr.txt new file mode 100644 index 0000000..e912728 --- /dev/null +++ b/Tests/RunCMake/CommandLine/W_bad-arg1-stderr.txt @@ -0,0 +1,2 @@ +CMake Error: -W must be followed with \[no-\]\[error=\]. +CMake Error: Problem processing arguments. Aborting. diff --git a/Tests/RunCMake/CommandLine/W_bad-arg2-result.txt b/Tests/RunCMake/CommandLine/W_bad-arg2-result.txt new file mode 100644 index 0000000..d00491f --- /dev/null +++ b/Tests/RunCMake/CommandLine/W_bad-arg2-result.txt @@ -0,0 +1 @@ +1 diff --git a/Tests/RunCMake/CommandLine/W_bad-arg2-stderr.txt b/Tests/RunCMake/CommandLine/W_bad-arg2-stderr.txt new file mode 100644 index 0000000..cc643df --- /dev/null +++ b/Tests/RunCMake/CommandLine/W_bad-arg2-stderr.txt @@ -0,0 +1,2 @@ +CMake Error: No warning name provided. +CMake Error: Problem processing arguments. Aborting. diff --git a/Tests/RunCMake/CommandLine/W_bad-arg3-result.txt b/Tests/RunCMake/CommandLine/W_bad-arg3-result.txt new file mode 100644 index 0000000..d00491f --- /dev/null +++ b/Tests/RunCMake/CommandLine/W_bad-arg3-result.txt @@ -0,0 +1 @@ +1 diff --git a/Tests/RunCMake/CommandLine/W_bad-arg3-stderr.txt b/Tests/RunCMake/CommandLine/W_bad-arg3-stderr.txt new file mode 100644 index 0000000..cc643df --- /dev/null +++ b/Tests/RunCMake/CommandLine/W_bad-arg3-stderr.txt @@ -0,0 +1,2 @@ +CMake Error: No warning name provided. +CMake Error: Problem processing arguments. Aborting. diff --git a/Tests/RunCMake/CommandLine/Wdeprecated-stderr.txt b/Tests/RunCMake/CommandLine/Wdeprecated-stderr.txt new file mode 100644 index 0000000..e9be1dc --- /dev/null +++ b/Tests/RunCMake/CommandLine/Wdeprecated-stderr.txt @@ -0,0 +1,4 @@ +^CMake Deprecation Warning at Wdeprecated.cmake:1 \(message\): + Some deprecated warning +Call Stack \(most recent call first\): + CMakeLists.txt:3 \(include\) diff --git a/Tests/RunCMake/CommandLine/Wdeprecated.cmake b/Tests/RunCMake/CommandLine/Wdeprecated.cmake new file mode 100644 index 0000000..3142b42 --- /dev/null +++ b/Tests/RunCMake/CommandLine/Wdeprecated.cmake @@ -0,0 +1 @@ +message(DEPRECATION "Some deprecated warning") diff --git a/Tests/RunCMake/CommandLine/Werror_deprecated-result.txt b/Tests/RunCMake/CommandLine/Werror_deprecated-result.txt new file mode 100644 index 0000000..d00491f --- /dev/null +++ b/Tests/RunCMake/CommandLine/Werror_deprecated-result.txt @@ -0,0 +1 @@ +1 diff --git a/Tests/RunCMake/CommandLine/Werror_deprecated-stderr.txt b/Tests/RunCMake/CommandLine/Werror_deprecated-stderr.txt new file mode 100644 index 0000000..6acdc73 --- /dev/null +++ b/Tests/RunCMake/CommandLine/Werror_deprecated-stderr.txt @@ -0,0 +1,4 @@ +^CMake Deprecation Error at Werror_deprecated.cmake:1 \(message\): + Some deprecated warning +Call Stack \(most recent call first\): + CMakeLists.txt:3 \(include\) diff --git a/Tests/RunCMake/CommandLine/Werror_deprecated.cmake b/Tests/RunCMake/CommandLine/Werror_deprecated.cmake new file mode 100644 index 0000000..3142b42 --- /dev/null +++ b/Tests/RunCMake/CommandLine/Werror_deprecated.cmake @@ -0,0 +1 @@ +message(DEPRECATION "Some deprecated warning") diff --git a/Tests/RunCMake/CommandLine/Werror_dev-result.txt b/Tests/RunCMake/CommandLine/Werror_dev-result.txt new file mode 100644 index 0000000..d00491f --- /dev/null +++ b/Tests/RunCMake/CommandLine/Werror_dev-result.txt @@ -0,0 +1 @@ +1 diff --git a/Tests/RunCMake/CommandLine/Werror_dev-stderr.txt b/Tests/RunCMake/CommandLine/Werror_dev-stderr.txt new file mode 100644 index 0000000..c6b4e74 --- /dev/null +++ b/Tests/RunCMake/CommandLine/Werror_dev-stderr.txt @@ -0,0 +1,5 @@ +^CMake Error \(dev\) at Werror_dev.cmake:1 \(message\): + Some author warning +Call Stack \(most recent call first\): + CMakeLists.txt:3 \(include\) +This error is for project developers. Use -Wno-error=dev to suppress it.$ diff --git a/Tests/RunCMake/CommandLine/Werror_dev.cmake b/Tests/RunCMake/CommandLine/Werror_dev.cmake new file mode 100644 index 0000000..e05cf9d --- /dev/null +++ b/Tests/RunCMake/CommandLine/Werror_dev.cmake @@ -0,0 +1 @@ +message(AUTHOR_WARNING "Some author warning") diff --git a/Tests/RunCMake/CommandLine/Wno-deprecated.cmake b/Tests/RunCMake/CommandLine/Wno-deprecated.cmake new file mode 100644 index 0000000..3142b42 --- /dev/null +++ b/Tests/RunCMake/CommandLine/Wno-deprecated.cmake @@ -0,0 +1 @@ +message(DEPRECATION "Some deprecated warning") diff --git a/Tests/RunCMake/CommandLine/Wno-error_deprecated.cmake b/Tests/RunCMake/CommandLine/Wno-error_deprecated.cmake new file mode 100644 index 0000000..3142b42 --- /dev/null +++ b/Tests/RunCMake/CommandLine/Wno-error_deprecated.cmake @@ -0,0 +1 @@ +message(DEPRECATION "Some deprecated warning") diff --git a/Tests/RunCMake/CommandLine/Wno-error_dev.cmake b/Tests/RunCMake/CommandLine/Wno-error_dev.cmake new file mode 100644 index 0000000..e05cf9d --- /dev/null +++ b/Tests/RunCMake/CommandLine/Wno-error_dev.cmake @@ -0,0 +1 @@ +message(AUTHOR_WARNING "Some author warning") -- 2.1.4 From marc.chevrier at sap.com Tue Jul 28 04:15:01 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Tue, 28 Jul 2015 08:15:01 +0000 Subject: [cmake-developers] Java support Message-ID: <53C8DDC8-829D-4532-9F6D-B5391EF69208@sap.com> Hi, Here are some patches to enhance Java support. 0001 (FindJava.cmake): Defines now two new variables for idlj and jar signer tools: Java_IDLJ_EXECUTABLE and Java_JARSIGNER_EXECUTABLE 0002 (UseJava.cmake): Extends add_jar command to support @file syntax for java sources specification. 0003 (UseJava.cmake): Extends install_jar and install_jni_symlink commands to support options DESTINATION and COMPONENT as alternative to actual syntax. 0004 (UseJava.cmake): Add new command create_javah to wrap java tool javah. I also extends tests to support these extensions. This is my first contribution, so be indulgent if something is wrong? ;) Marc Chevrier -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-support-for-idlj-and-jarsigner-tools.patch Type: application/octet-stream Size: 3616 bytes Desc: 0001-Add-support-for-idlj-and-jarsigner-tools.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-add_jar-now-supports-file-syntax-for-sources.patch Type: application/octet-stream Size: 6088 bytes Desc: 0002-add_jar-now-supports-file-syntax-for-sources.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-install_jar-Add-options-DESTINATION-and-COMPONENT.patch Type: application/octet-stream Size: 3564 bytes Desc: 0003-install_jar-Add-options-DESTINATION-and-COMPONENT.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Add-support-for-javah-tool.patch Type: application/octet-stream Size: 9598 bytes Desc: 0004-Add-support-for-javah-tool.patch URL: From mantis at public.kitware.com Tue Jul 28 05:56:06 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 28 Jul 2015 05:56:06 -0400 Subject: [cmake-developers] [CMake 0015666]: Ninja may unnecessarily relink on windows Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15666 ====================================================================== Reported By: Nils Gladitz Assigned To: ====================================================================== Project: CMake Issue ID: 15666 Category: (No Category) Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-28 05:56 EDT Last Modified: 2015-07-28 05:56 EDT ====================================================================== Summary: Ninja may unnecessarily relink on windows Description: I have the following windows specific test case: cmake_minimum_required(VERSION 3.3) project(Foo CXX) if(NOT EXISTS test.cpp) file(WRITE test.cpp "__declspec(dllexport) void foo() {}") endif() add_custom_target(touch COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_SOURCE_DIR}/test.cpp ) add_library(foo SHARED test.cpp) Steps to Reproduce: I configured the given test project with the "Ninja" generator from a "Visual Studio 2013 (x64)" environment. 1. ninja # builds the project as expected 2. ninja # outputs "ninja: no work to do." as expected 3. ninja touch # touches test.cpp 4. ninja # recompiles and relinks as expected 5-n. ninja # unexpectedly relinks; expected is "ninja: no work to do." Additional Information: It looks like the relink happens because the linker updates foo.dll but does not touch foo.lib. Which leads to (ninja -d explain): ninja explain: output foo.lib older than most recent input CMakeFiles/foo.dir/test.cpp.obj (459779794 vs 459780205) ninja explain: foo.dll is dirty [1/1] Linking CXX shared library foo.dll ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-28 05:56 Nils Gladitz New Issue ====================================================================== From brad.king at kitware.com Tue Jul 28 08:41:41 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 28 Jul 2015 08:41:41 -0400 Subject: [cmake-developers] Strange behaviour with install(EXPORT) In-Reply-To: <20150727210455.GA2787@megas.kitware.com> References: <3416337.j2rKvQmFrk@roku> <55B67EDA.9070707@kitware.com> <20150727210455.GA2787@megas.kitware.com> Message-ID: <55B77885.5070108@kitware.com> On 07/27/2015 05:04 PM, Ben Boeckel wrote: > Wouldn't an exported static library still need to inform others about > its private non-exported static library dependencies though? For a > shared library, ignoring static libraries in the private set would make > sense. All the logic discussed in this thread is already conditioned on SHARED_LIBRARY targets. -Brad From konstantin at podsvirov.pro Tue Jul 28 10:49:38 2015 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Tue, 28 Jul 2015 17:49:38 +0300 Subject: [cmake-developers] [MODERN] CMake 3.3 vs Qt 5.5 vs MSVC2015 In-Reply-To: <55B653D0.4020001@kitware.com> References: <1821991437643934@web22o.yandex.ru> <55B0E831.7070603@yahoo.com> <35881437659256@web4h.yandex.ru> <1975171437723971@web22h.yandex.ru> <55B653D0.4020001@kitware.com> Message-ID: <198581438094978@web29o.yandex.ru> Hi dear CMake developers! 27.07.2015, 18:52, "Brad King" : > On 07/24/2015 03:46 AM, Konstantin Podsvirov wrote: >> ?To solve the problem you run cmake-gui is now possible with the >> ?following changes: > > Applied as two separate commits with minor tweaks: > > ?cmake-gui: Install Qt5 Windows platform plugin > ?http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=42f0155b > > ?CMake: Add CMake_INSTALL_DEPENDENCIES option > ?http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=068e7962 > Code now in 'master' branch. Thanks, Brad! Meet/install/update modern CMake built on MSVC2015 c QtDialog based on Qt 5.5 from today :-) Windows 32bit: http://ifw.podsvirov.pro/cmake/cmake-master-win32-online.exe Windows 64bit: http://ifw.podsvirov.pro/cmake/cmake-master-win64-online.exe cmake-gui should work now, but if not, then update your system and install Visual C++ Redistributable for Visual Studio 2015 from the link below: http://www.microsoft.com/en-us/download/details.aspx?id=48145 As always, questions and suggestions are welcome. -- Regards, Konstantin Podsvirov From brad.king at kitware.com Tue Jul 28 10:55:16 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 28 Jul 2015 10:55:16 -0400 Subject: [cmake-developers] check_cxx_source_compiles and include directories In-Reply-To: <050101d0c8a2$1df05050$59d0f0f0$@gmx.at> References: <419A5EC7-E63B-4691-9643-07A34EB376C1@gmx.at> <050101d0c8a2$1df05050$59d0f0f0$@gmx.at> Message-ID: <55B797D4.7000605@kitware.com> On 07/27/2015 03:26 PM, Roman W?ger wrote: > SubProj1 and SubProj2 does not find , but > check_cxx_source_compiles succeeds. > > Did I miss configure something here? The posted example works for me on Linux with g++ 4.9.3. The check succeeds and an executable I create in SubProj1 can #include . I have "/usr/include/c++/4.9.3/mutex" right next to all the other C++ headers. -Brad From roman.wueger at gmx.at Tue Jul 28 12:23:12 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Tue, 28 Jul 2015 18:23:12 +0200 Subject: [cmake-developers] check_cxx_source_compiles and include directories In-Reply-To: <55B797D4.7000605@kitware.com> References: <419A5EC7-E63B-4691-9643-07A34EB376C1@gmx.at> <050101d0c8a2$1df05050$59d0f0f0$@gmx.at> <55B797D4.7000605@kitware.com> Message-ID: <8A118920-48E3-4263-B7FB-2992F0A0A467@gmx.at> Hi Brad, thanks for your investigation. I've tried it on Mac OS 10.10.4 with clang 6.1.0.6020053 from XCode 6 using "Unix Makefiles" as the generator. Best Regards Roman > Am 28.07.2015 um 16:55 schrieb Brad King : > >> On 07/27/2015 03:26 PM, Roman W?ger wrote: >> SubProj1 and SubProj2 does not find , but >> check_cxx_source_compiles succeeds. >> >> Did I miss configure something here? > > The posted example works for me on Linux with g++ 4.9.3. > The check succeeds and an executable I create in SubProj1 > can #include . I have "/usr/include/c++/4.9.3/mutex" > right next to all the other C++ headers. > > -Brad > From brad.king at kitware.com Tue Jul 28 12:50:05 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 28 Jul 2015 12:50:05 -0400 Subject: [cmake-developers] check_cxx_source_compiles and include directories In-Reply-To: <8A118920-48E3-4263-B7FB-2992F0A0A467@gmx.at> References: <419A5EC7-E63B-4691-9643-07A34EB376C1@gmx.at> <050101d0c8a2$1df05050$59d0f0f0$@gmx.at> <55B797D4.7000605@kitware.com> <8A118920-48E3-4263-B7FB-2992F0A0A467@gmx.at> Message-ID: <55B7B2BD.8090109@kitware.com> On 07/28/2015 12:23 PM, Roman W?ger wrote: > I've tried it on Mac OS 10.10.4 with clang 6.1.0.6020053 from > XCode 6 using "Unix Makefiles" as the generator. Is that using the Xcode Command Line Tools or the /usr/bin/c++ stub that uses the /Applications/Xcode.app/.../bin/clang++ compiler underneath? Is CMAKE_OSX_SYSROOT set? Does -isysroot appear on the compilation command line? Thanks, -Brad From roman.wueger at gmx.at Tue Jul 28 15:38:36 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Tue, 28 Jul 2015 21:38:36 +0200 Subject: [cmake-developers] check_cxx_source_compiles and include directories In-Reply-To: <55B7B2BD.8090109@kitware.com> References: <419A5EC7-E63B-4691-9643-07A34EB376C1@gmx.at> <050101d0c8a2$1df05050$59d0f0f0$@gmx.at> <55B797D4.7000605@kitware.com> <8A118920-48E3-4263-B7FB-2992F0A0A467@gmx.at> <55B7B2BD.8090109@kitware.com> Message-ID: <00fd01d0c96d$00e59ad0$02b0d070$@gmx.at> Thanks Brad yes, and that's the point. I've found my mistake, I had set the CMAKE_OSX_DEPLOYMENT_TARGET and CMAKE_OSX_SYSROOT between the check_cxx_source_compiles() calls and the add_subdirectory() calls. I moved the CMAKE_OSX_DEPLOYMENT_TARGET and CMAKE_OSX_SYSROOT initialization on top of the check_cxx_source_compiles() calls and everthing is working as expected. So, in my situation the order is: 1.) CMAKE_OSX_DEPLOYMENT_TARGET and CMAKE_OSX_SYSROOT 2.) check_cxx_source_compiles() and other platform checks 3.) add_subdirectory() and other stuff Best Regards Roman > -----Urspr?ngliche Nachricht----- > Von: Brad King [mailto:brad.king at kitware.com] > Gesendet: Dienstag, 28. Juli 2015 18:50 > An: Roman W?ger > Cc: CMake MailingList ; CMake Developer MailingList > > Betreff: Re: [cmake-developers] check_cxx_source_compiles and include > directories > > On 07/28/2015 12:23 PM, Roman W?ger wrote: > > I've tried it on Mac OS 10.10.4 with clang 6.1.0.6020053 from XCode 6 > > using "Unix Makefiles" as the generator. > > Is that using the Xcode Command Line Tools or the /usr/bin/c++ stub that > uses the /Applications/Xcode.app/.../bin/clang++ compiler underneath? > Is CMAKE_OSX_SYSROOT set? Does -isysroot appear on the compilation > command line? > > Thanks, > -Brad From bill at classdesign.com Tue Jul 28 18:02:07 2015 From: bill at classdesign.com (Bill Somerville) Date: Tue, 28 Jul 2015 23:02:07 +0100 Subject: [cmake-developers] Modules/GetPrequisites.cmake issues Message-ID: <55B7FBDF.6020504@classdesign.com> Hi All, attached is a patch that addresses some issues recently discussed on the users list. I'm no CMake expert so I don't know if I have done things in the best way. One area I do not fully understand is how to detect MinGW, If I could then objdump could be chosen as the preferred library dependency walker over MS dumpbin.exe. See the patch description for details. Regards Bill Somerville. -------------- next part -------------- From 203848c099026c23b5f70d395d0469887f099d23 Mon Sep 17 00:00:00 2001 From: Bill Somerville Date: Tue, 28 Jul 2015 22:40:36 +0100 Subject: [PATCH] For MinGW pre-filter objdump output for performance As dumpbin.exe is no longer reliable for gcc libraries on MinGW because it crashes on many common libraries like libgcc_s and libgfortran it is now necessary too resort to using objdump for DLL dependency walking. Using objdump has a secondary problem in that it generates a lot of output for large libraries and causes fixup_bundle() to take many minutes to process what took fractions of a second with dumpbin.exe /dependents. This patch includes a grep pre-filter in the execute_process() command pipeline to reduce this output to a minimum for a several orders of magnitude speed up. If grep isn't available the full output is used. As there doesn't seem to be a reliable way of detecting MinGW callers of fixup_bundle() may have to set the variable gp_tool to "objdump" if dumpbin.exe is installed on the build machine to stop it using dumpbin.exe for library dependency walking. This patch also adds command status checking to the various execute_process() invocations in GetPrerequisites.cmake so that they don't fail silently producing invalid install packages. --- Modules/GetPrerequisites.cmake | 53 ++++++++++++++++++++++++++++++++++++++---- 1 file changed, 49 insertions(+), 4 deletions(-) diff --git a/Modules/GetPrerequisites.cmake b/Modules/GetPrerequisites.cmake index 23d486e..bbc1232 100644 --- a/Modules/GetPrerequisites.cmake +++ b/Modules/GetPrerequisites.cmake @@ -229,9 +229,14 @@ function(is_file_executable file result_var) if(file_cmd) execute_process(COMMAND "${file_cmd}" "${file_full}" + RESULT_VARIABLE file_rv OUTPUT_VARIABLE file_ov + ERROR_VARIABLE file_ev OUTPUT_STRIP_TRAILING_WHITESPACE ) + if(NOT file_rv STREQUAL "0") + message(FATAL_ERROR "${file_cmd} failed: ${file_rv}\n${file_ev}") + endif() # Replace the name of the file in the output with a placeholder token # (the string " _file_full_ ") so that just in case the path name of @@ -543,11 +548,21 @@ function(gp_resolved_file_type original_file file exepath dirs type_var) if(CYGPATH_EXECUTABLE) execute_process(COMMAND ${CYGPATH_EXECUTABLE} -W + RESULT_VARIABLE env_rv OUTPUT_VARIABLE env_windir + ERROR_VARIABLE env_ev OUTPUT_STRIP_TRAILING_WHITESPACE) + if(NOT env_rv STREQUAL "0") + message(FATAL_ERROR "${CYGPATH_EXECUTABLE} -W failed: ${env_rv}\n${env_ev}") + endif() execute_process(COMMAND ${CYGPATH_EXECUTABLE} -S + RESULT_VARIABLE env_rv OUTPUT_VARIABLE env_sysdir + ERROR_VARIABLE env_ev OUTPUT_STRIP_TRAILING_WHITESPACE) + if(NOT env_rv STREQUAL "0") + message(FATAL_ERROR "${CYGPATH_EXECUTABLE} -S failed: ${env_rv}\n${env_ev}") + endif() string(TOLOWER "${env_windir}" windir) string(TOLOWER "${env_sysdir}" sysroot) @@ -709,6 +724,11 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa set(gp_regex_error "") set(gp_regex_fallback "") set(gp_regex_cmp_count 1) + # objdump generaates copious output so we create a grep filter to pre-filter results + find_program(gp_grep_cmd grep) + if(gp_grep_cmd) + set(gp_cmd_filter "^[[:blank:]]*DLL Name: ") + endif() else() message(STATUS "warning: gp_tool='${gp_tool}' is an unknown tool...") message(STATUS "CMake function get_prerequisites needs more code to handle '${gp_tool}'") @@ -763,10 +783,30 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa # Run gp_cmd on the target: # - execute_process( - COMMAND ${gp_cmd} ${gp_cmd_args} ${target} - OUTPUT_VARIABLE gp_cmd_ov - ) + if(gp_cmd_filter) # filter is for performance + execute_process( + COMMAND ${gp_cmd} ${gp_cmd_args} ${target} + COMMAND ${gp_grep_cmd} ${gp_cmd_filter} + RESULT_VARIABLE gp_rv + OUTPUT_VARIABLE gp_cmd_ov + ERROR_VARIABLE gp_ev + ) + else() + execute_process( + COMMAND ${gp_cmd} ${gp_cmd_args} ${target} + RESULT_VARIABLE gp_rv + OUTPUT_VARIABLE gp_cmd_ov + ERROR_VARIABLE gp_ev + ) + endif() + if(NOT gp_rv STREQUAL "0") + if(gp_tool STREQUAL "dumpbin") + # dumpbin error messages seem to go to stdout + message(FATAL_ERROR "${gp_cmd} failed: ${gp_rv}\n${gp_ev}\n${gp_cmd_ov}") + else() + message(FATAL_ERROR "${gp_cmd} failed: ${gp_rv}\n${gp_ev}") + endif() + endif() if(gp_tool STREQUAL "ldd") set(ENV{LD_LIBRARY_PATH} "${old_ld_env}") @@ -791,8 +831,13 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if(gp_tool STREQUAL "otool") execute_process( COMMAND otool -D ${target} + RESULT_VARIABLE otool_rv OUTPUT_VARIABLE gp_install_id_ov + ERROR_VARIABLE otool_ev ) + if(NOT otool_rv STREQUAL "0") + message(FATAL_ERROR "otool -D failed: ${otool_rv}\n${otool_ev}") + endif() # second line is install name string(REGEX REPLACE ".*:\n" "" gp_install_id "${gp_install_id_ov}") if(gp_install_id) -- 1.9.5.msysgit.0 From mantis at public.kitware.com Wed Jul 29 02:47:03 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 29 Jul 2015 02:47:03 -0400 Subject: [cmake-developers] [CMake 0015667]: XCTest CocoaExample crashes Xcode GUI Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15667 ====================================================================== Reported By: Seppo Tomperi Assigned To: ====================================================================== Project: CMake Issue ID: 15667 Category: Modules Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-29 02:47 EDT Last Modified: 2015-07-29 02:47 EDT ====================================================================== Summary: XCTest CocoaExample crashes Xcode GUI Description: cmake version 3.3.0 from homebrew Starting XCTest CocoaExample test from Xcode GUI crashes Xcode 6.4 and 7. XCTest FrameworkExample test works from Xcode GUI. However from command line CocoaExample passes. Steps to Reproduce: cd Tests/XCTest/ mkdir target cd target/ cmake -G Xcode .. open XCTest.xcodeproj # running CocoaExample from GUI crashes Xcode #however: xcodebuild -project XCTest.xcodeproj/ -scheme CocoaExample -destination 'platform=OS X,arch=x86_64' build xcodebuild -project XCTest.xcodeproj/ -scheme CocoaExample -destination 'platform=OS X,arch=x86_64' test # passes: Test Suite 'All tests' started at 2015-07-29 06:41:31 +0000 Test Suite 'CocoaExampleTests.xctest' started at 2015-07-29 06:41:31 +0000 Test Suite 'CocoaExampleTests' started at 2015-07-29 06:41:31 +0000 Test Case '-[CocoaExampleTests testExample]' started. Test Case '-[CocoaExampleTests testExample]' passed (0.000 seconds). Test Suite 'CocoaExampleTests' passed at 2015-07-29 06:41:31 +0000. Executed 1 test, with 0 failures (0 unexpected) in 0.000 (0.000) seconds Test Suite 'CocoaExampleTests.xctest' passed at 2015-07-29 06:41:31 +0000. Executed 1 test, with 0 failures (0 unexpected) in 0.000 (0.001) seconds Test Suite 'All tests' passed at 2015-07-29 06:41:31 +0000. Executed 1 test, with 0 failures (0 unexpected) in 0.000 (0.001) seconds ** TEST SUCCEEDED ** Additional Information: Process: Xcode [74137] Path: /Applications/Xcode.app/Contents/MacOS/Xcode Identifier: com.apple.dt.Xcode Version: 6.4 (7720) Build Info: IDEFrameworks-7720000000000000~8 App Item ID: 497799835 App External ID: 812725084 Code Type: X86-64 (Native) Parent Process: ??? [1] Responsible: Xcode [74137] User ID: 501 Date/Time: 2015-07-29 09:36:46.399 +0300 OS Version: Mac OS X 10.10.4 (14E46) Report Version: 11 Anonymous UUID: 6FE1E47C-AE8D-AA50-F104-3C3169AD118E Sleep/Wake UUID: E9A90012-D49D-45CD-8E55-F5314FA4C435 Time Awake Since Boot: 55000 seconds Time Since Wake: 2700 seconds Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Application Specific Information: ProductBuildVersion: 6E35b ASSERTION FAILURE in /SourceCache/IDEXcode3ProjectSupport/IDEXcode3ProjectSupport-7709/Xcode3Core/LegacyProjects/Frameworks/DevToolsCore/DevToolsCore/ProjectModel/Xcode3Model/Xcode3TargetBuildable.m:181 Details: string should be a non-empty string, but it's an empty string Object: Method: -stringByEvaluatingBuildSettingExpressionString:withBuildParameters: Thread: {number = 1, name = main} Hints: None Backtrace: 0 0x000000010d8a4fda -[IDEAssertionHandler handleFailureInMethod:object:fileName:lineNumber:assertionSignature:messageFormat:arguments:] (in IDEKit) 1 0x000000010c5fa65f _DVTAssertionHandler (in DVTFoundation) 2 0x000000010c5fa94e _DVTAssertionFailureHandler (in DVTFoundation) 3 0x0000000116fbdbf3 -[Xcode3TargetBuildable stringByEvaluatingBuildSettingExpressionString:withBuildParameters:] (in DevToolsCore) 4 0x000000010d103333 -[IDESchemeAction bundleIdentifierFromBuildableProduct:withBuildParameters:] (in IDEFoundation) 5 0x000000010d1f38bc __192-[IDETestSchemeAction testOperationWithTestManager:executionEnvironment:withBuildOperation:buildParameters:schemeCommand:actionRecord:overridingTestingSpecifiers:outError:actionCallbackBlock:]_block_invoke (in IDEFoundation) 6 0x000000010d0af6ae -[IDEOCUnitTestRunner testOperationsForExecutionEnvironment:withBuildOperation:buildParameters:runDestination:workspace:error:launchParametersBlock:] (in IDEFoundation) 7 0x0000000116fe24a8 -[Xcode3OCUnitTestRunner testOperationsForExecutionEnvironment:withBuildOperation:buildParameters:runDestination:workspace:error:launchParametersBlock:] (in DevToolsCore) 8 0x000000010d27cad0 -[IDETestManager testOperationForTestingSpecification:executionEnvironment:withBuildOperation:buildParameters:runDestination:workspace:actionRecord:schemeIdentifier:outSchemeActionResultOperation:error:launchParametersBlock:actionCallbackBlock:] (in IDEFoundation) 9 0x000000010d1f231d -[IDETestSchemeAction testOperationWithTestManager:executionEnvironment:withBuildOperation:buildParameters:schemeCommand:actionRecord:overridingTestingSpecifiers:outError:actionCallbackBlock:] (in IDEFoundation) 10 0x000000010d16c9bd -[IDEScheme _executionOperationForExecutionEnvironment:build:onlyBuild:buildPurpose:buildCommand:schemeCommand:title:overridingProperties:destination:buildLog:filePath:overridingBuildConfiguration:dontActuallyRunCommands:restorePersistedBuildResults:invocationRecord:overridingTestingSpecifiers:error:actionCallbackBlock:] (in IDEFoundation) 11 0x000000010d16a144 -[IDEScheme testOperationWithExecutionContext:buildIfNeeded:onlyBuild:destination:overridingProperties:overridingTestingSpecifiers:schemeCommand:buildLog:overridingBuildConfiguration:restorePersistedBuildResults:invocationRecord:name:title:error:actionCallbackBlock:] (in IDEFoundation) 12 0x000000010d16a4c4 -[IDEScheme testWithExecutionContext:buildIfNeeded:onlyBuild:destination:overridingProperties:schemeCommand:commandName:overridingTestingSpecifiers:buildLog:invocationRecord:error:completionBlock:] (in IDEFoundation) 13 0x000000010d847342 -[IDEWorkspaceTabController _actuallyPerformSchemeTask:onScheme:runDestination:command:commandName:buildCommand:filePath:overridingTestingSpecifiers:invocationRecord:completionBlock:] (in IDEKit) 14 0x000000010d84bae7 __175-[IDEWorkspaceTabController _performSchemeTask:onScheme:runDestination:command:commandName:buildCommand:filePath:overridingTestingSpecifiers:invocationRecord:completionBlock:]_block_invoke (in IDEKit) 15 0x000000010d84a61a -[IDEWorkspaceTabController _performSchemeTask:onScheme:runDestination:command:commandName:buildCommand:filePath:overridingTestingSpecifiers:invocationRecord:completionBlock:] (in IDEKit) 16 0x000000010d84c883 __185-[IDEWorkspaceTabController _performDebuggableSchemeTask:onScheme:runDestination:command:commandName:buildCommand:filePath:overridingTestingSpecifiers:invocationRecord:completionBlock:]_block_invoke_2 (in IDEKit) 17 0x000000010f3a228c -[DVTDeveloperModeAlertHelper askToEnableDeveloperModeIfNecessaryWithCompletionHandler:] (in DVTDeveloperModeHelper) 18 0x000000010d84c767 __185-[IDEWorkspaceTabController _performDebuggableSchemeTask:onScheme:runDestination:command:commandName:buildCommand:filePath:overridingTestingSpecifiers:invocationRecord:completionBlock:]_block_invoke (in IDEKit) 19 0x000000010d852c23 -[IDEWorkspaceTabController showAppChooserIfNecessaryForScheme:runDestination:command:onCompletion:] (in IDEKit) 20 0x000000010d84c3cc -[IDEWorkspaceTabController _performDebuggableSchemeTask:onScheme:runDestination:command:commandName:buildCommand:filePath:overridingTestingSpecifiers:invocationRecord:completionBlock:] (in IDEKit) 21 0x000000010d84eae8 -[IDEWorkspaceTabController testUsingActiveRunContextWithOverridingTestingSpecifiers:] (in IDEKit) 22 0x000000010dae1bb0 +[IDETestingHelper _executeTestsAndTestables:forWorkspaceTabController:withBlock:] (in IDEKit) 23 0x000000010dae1d5b +[IDETestingHelper runTestsAndTestables:forWorkspaceTabController:] (in IDEKit) 24 0x000000010dced5f0 -[IDETestingCommands contextMenu_runTest:] (in IDEKit) 25 0x00007fff90eeccd7 _os_activity_initiate (in libsystem_trace.dylib) 26 0x00007fff8ed8beb1 -[NSApplication sendAction:to:from:] (in AppKit) 27 0x000000010cb7b4dd __37-[DVTApplication sendAction:to:from:]_block_invoke (in DVTKit) 28 0x000000010ca43c28 -[DVTApplication sendAction:to:from:] (in DVTKit) 29 0x000000010d8a06c3 +[IDECommandManager sendActionForCommandWithIdentifier:from:] (in IDEKit) 30 0x000000010dae76f6 __28-[IDETestNavigator loadView]_block_invoke (in IDEKit) 31 0x000000010dae6bf9 -[IDETestNavigatorOutlineView mouseDown:] (in IDEKit) 32 0x00007fff8f3082dc -[NSWindow _reallySendEvent:isDelayedEvent:] (in AppKit) 33 0x00007fff8ec97c86 -[NSWindow sendEvent:] (in AppKit) 34 0x000000010d8ca5d8 -[IDEWorkspaceWindow sendEvent:] (in IDEKit) 35 0x00007fff8ec94212 -[NSApplication sendEvent:] (in AppKit) 36 0x000000010d674064 -[IDEApplication sendEvent:] (in IDEKit) 37 0x00007fff8ebbdb68 -[NSApplication run] (in AppKit) 38 0x00007fff8eb3a244 NSApplicationMain (in AppKit) 39 0x00007fff874ed5c9 start (in libdyld.dylib) 40 0x0000000000000001 Performing @selector(contextMenu_runTest:) from sender IDETestNavigator 0x7fc577cf39b0 abort() called Application Specific Signatures: ![@"" isEqualToString:(string)] Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff8ca6a286 __pthread_kill + 10 1 libsystem_c.dylib 0x00007fff84ba8b53 abort + 129 2 com.apple.dt.IDEKit 0x000000010d8a4bc3 +[IDEAssertionHandler _handleAssertionWithLogString:assertionSignature:assertionReason:extraBacktrace:] + 1507 3 com.apple.dt.IDEKit 0x000000010d8a5190 -[IDEAssertionHandler handleFailureInMethod:object:fileName:lineNumber:assertionSignature:messageFormat:arguments:] + 1169 4 com.apple.dt.DVTFoundation 0x000000010c5fa65f _DVTAssertionHandler + 367 5 com.apple.dt.DVTFoundation 0x000000010c5fa94e _DVTAssertionFailureHandler + 407 6 com.apple.Xcode.DevToolsCore 0x0000000116fbdbf3 -[Xcode3TargetBuildable stringByEvaluatingBuildSettingExpressionString:withBuildParameters:] + 681 7 com.apple.dt.IDEFoundation 0x000000010d103333 -[IDESchemeAction bundleIdentifierFromBuildableProduct:withBuildParameters:] + 136 8 com.apple.dt.IDEFoundation 0x000000010d1f38bc __192-[IDETestSchemeAction testOperationWithTestManager:executionEnvironment:withBuildOperation:buildParameters:schemeCommand:actionRecord:overridingTestingSpecifiers:outError:actionCallbackBlock:]_block_invoke + 3645 9 com.apple.dt.IDEFoundation 0x000000010d0af6ae -[IDEOCUnitTestRunner testOperationsForExecutionEnvironment:withBuildOperation:buildParameters:runDestination:workspace:error:launchParametersBlock:] + 1905 10 com.apple.Xcode.DevToolsCore 0x0000000116fe24a8 -[Xcode3OCUnitTestRunner testOperationsForExecutionEnvironment:withBuildOperation:buildParameters:runDestination:workspace:error:launchParametersBlock:] + 254 11 com.apple.dt.IDEFoundation 0x000000010d27cad0 -[IDETestManager testOperationForTestingSpecification:executionEnvironment:withBuildOperation:buildParameters:runDestination:workspace:actionRecord:schemeIdentifier:outSchemeActionResultOperation:error:launchParametersBlock:actionCallbackBlock:] + 3119 12 com.apple.dt.IDEFoundation 0x000000010d1f231d -[IDETestSchemeAction testOperationWithTestManager:executionEnvironment:withBuildOperation:buildParameters:schemeCommand:actionRecord:overridingTestingSpecifiers:outError:actionCallbackBlock:] + 1084 13 com.apple.dt.IDEFoundation 0x000000010d16c9bd -[IDEScheme _executionOperationForExecutionEnvironment:build:onlyBuild:buildPurpose:buildCommand:schemeCommand:title:overridingProperties:destination:buildLog:filePath:overridingBuildConfiguration:dontActuallyRunCommands:restorePersistedBuildResults:invocationRecord:overridingTestingSpecifiers:error:actionCallbackBlock:] + 3461 14 com.apple.dt.IDEFoundation 0x000000010d16a144 -[IDEScheme testOperationWithExecutionContext:buildIfNeeded:onlyBuild:destination:overridingProperties:overridingTestingSpecifiers:schemeCommand:buildLog:overridingBuildConfiguration:restorePersistedBuildResults:invocationRecord:name:title:error:actionCallbackBlock:] + 636 15 com.apple.dt.IDEFoundation 0x000000010d16a4c4 -[IDEScheme testWithExecutionContext:buildIfNeeded:onlyBuild:destination:overridingProperties:schemeCommand:commandName:overridingTestingSpecifiers:buildLog:invocationRecord:error:completionBlock:] + 610 16 com.apple.dt.IDEKit 0x000000010d847342 -[IDEWorkspaceTabController _actuallyPerformSchemeTask:onScheme:runDestination:command:commandName:buildCommand:filePath:overridingTestingSpecifiers:invocationRecord:completionBlock:] + 2615 17 com.apple.dt.IDEKit 0x000000010d84bae7 __175-[IDEWorkspaceTabController _performSchemeTask:onScheme:runDestination:command:commandName:buildCommand:filePath:overridingTestingSpecifiers:invocationRecord:completionBlock:]_block_invoke + 174 18 com.apple.dt.IDEKit 0x000000010d84a61a -[IDEWorkspaceTabController _performSchemeTask:onScheme:runDestination:command:commandName:buildCommand:filePath:overridingTestingSpecifiers:invocationRecord:completionBlock:] + 4172 19 com.apple.dt.IDEKit 0x000000010d84c883 __185-[IDEWorkspaceTabController _performDebuggableSchemeTask:onScheme:runDestination:command:commandName:buildCommand:filePath:overridingTestingSpecifiers:invocationRecord:completionBlock:]_block_invoke_2 + 101 20 com.apple.dt.DVTDeveloperModeHelper 0x000000010f3a228c -[DVTDeveloperModeAlertHelper askToEnableDeveloperModeIfNecessaryWithCompletionHandler:] + 261 21 com.apple.dt.IDEKit 0x000000010d84c767 __185-[IDEWorkspaceTabController _performDebuggableSchemeTask:onScheme:runDestination:command:commandName:buildCommand:filePath:overridingTestingSpecifiers:invocationRecord:completionBlock:]_block_invoke + 773 22 com.apple.dt.IDEKit 0x000000010d852c23 -[IDEWorkspaceTabController showAppChooserIfNecessaryForScheme:runDestination:command:onCompletion:] + 497 23 com.apple.dt.IDEKit 0x000000010d84c3cc -[IDEWorkspaceTabController _performDebuggableSchemeTask:onScheme:runDestination:command:commandName:buildCommand:filePath:overridingTestingSpecifiers:invocationRecord:completionBlock:] + 529 24 com.apple.dt.IDEKit 0x000000010d84eae8 -[IDEWorkspaceTabController testUsingActiveRunContextWithOverridingTestingSpecifiers:] + 381 25 com.apple.dt.IDEKit 0x000000010dae1bb0 +[IDETestingHelper _executeTestsAndTestables:forWorkspaceTabController:withBlock:] + 139 26 com.apple.dt.IDEKit 0x000000010dae1d5b +[IDETestingHelper runTestsAndTestables:forWorkspaceTabController:] + 307 27 com.apple.dt.IDEKit 0x000000010dced5f0 -[IDETestingCommands contextMenu_runTest:] + 134 28 libsystem_trace.dylib 0x00007fff90eeccd7 _os_activity_initiate + 75 29 com.apple.AppKit 0x00007fff8ed8beb1 -[NSApplication sendAction:to:from:] + 452 30 com.apple.dt.DVTKit 0x000000010cb7b4dd __37-[DVTApplication sendAction:to:from:]_block_invoke + 379 31 com.apple.dt.DVTKit 0x000000010ca43c28 -[DVTApplication sendAction:to:from:] + 377 32 com.apple.dt.IDEKit 0x000000010d8a06c3 +[IDECommandManager sendActionForCommandWithIdentifier:from:] + 109 33 com.apple.dt.IDEKit 0x000000010dae76f6 __28-[IDETestNavigator loadView]_block_invoke + 188 34 com.apple.dt.IDEKit 0x000000010dae6bf9 -[IDETestNavigatorOutlineView mouseDown:] + 369 35 com.apple.AppKit 0x00007fff8f3082dc -[NSWindow _reallySendEvent:isDelayedEvent:] + 14125 36 com.apple.AppKit 0x00007fff8ec97c86 -[NSWindow sendEvent:] + 470 37 com.apple.dt.IDEKit 0x000000010d8ca5d8 -[IDEWorkspaceWindow sendEvent:] + 156 38 com.apple.AppKit 0x00007fff8ec94212 -[NSApplication sendEvent:] + 2504 39 com.apple.dt.IDEKit 0x000000010d674064 -[IDEApplication sendEvent:] + 924 40 com.apple.AppKit 0x00007fff8ebbdb68 -[NSApplication run] + 711 41 com.apple.AppKit 0x00007fff8eb3a244 NSApplicationMain + 1832 42 libdyld.dylib 0x00007fff874ed5c9 start + 1 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-29 02:47 Seppo Tomperi New Issue ====================================================================== From eike at sf-mail.de Wed Jul 29 03:25:19 2015 From: eike at sf-mail.de (Rolf Eike Beer) Date: Wed, 29 Jul 2015 09:25:19 +0200 Subject: [cmake-developers] Java support In-Reply-To: <53C8DDC8-829D-4532-9F6D-B5391EF69208@sap.com> References: <53C8DDC8-829D-4532-9F6D-B5391EF69208@sap.com> Message-ID: <3518298.4AC594tU3M@caliban.sf-tec.de> Am Dienstag, 28. Juli 2015, 08:15:01 schrieb CHEVRIER, Marc: > Hi, > > 0002 (UseJava.cmake): Extends add_jar command to support @file syntax for > java sources specification. You do not need leading or trailing .* in regular expressions. In fact I think your expression should simply be "^@", otherwise you would match an @ at any position in the argument name, which does not look intended. Greetings, Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From marc.chevrier at sap.com Wed Jul 29 04:01:20 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Wed, 29 Jul 2015 08:01:20 +0000 Subject: [cmake-developers] Java support In-Reply-To: <3518298.4AC594tU3M@caliban.sf-tec.de> References: <53C8DDC8-829D-4532-9F6D-B5391EF69208@sap.com> <3518298.4AC594tU3M@caliban.sf-tec.de> Message-ID: <6B37BC37-0442-492E-905A-8A184A04B587@sap.com> Hi, You are right. @ must be matching at the beginning of the item. But I need .* in the expression because I use regex matching group to retrieve filename. Anyway, here is an updated list of patches. Marc On 29/07/15 09:25, "cmake-developers on behalf of Rolf Eike Beer" wrote: >Am Dienstag, 28. Juli 2015, 08:15:01 schrieb CHEVRIER, Marc: >> Hi, >> >> 0002 (UseJava.cmake): Extends add_jar command to support @file syntax for >> java sources specification. > >You do not need leading or trailing .* in regular expressions. In fact I think >your expression should simply be "^@", otherwise you would match an @ at any >position in the argument name, which does not look intended. > >Greetings, > >Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-support-for-idlj-and-jarsigner-tools.patch Type: application/octet-stream Size: 3616 bytes Desc: 0001-Add-support-for-idlj-and-jarsigner-tools.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-add_jar-now-supports-file-syntax-for-sources.patch Type: application/octet-stream Size: 6090 bytes Desc: 0002-add_jar-now-supports-file-syntax-for-sources.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-install_jar-Add-options-DESTINATION-and-COMPONENT.patch Type: application/octet-stream Size: 3564 bytes Desc: 0003-install_jar-Add-options-DESTINATION-and-COMPONENT.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Add-support-for-javah-tool.patch Type: application/octet-stream Size: 9598 bytes Desc: 0004-Add-support-for-javah-tool.patch URL: From mantis at public.kitware.com Wed Jul 29 04:26:30 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 29 Jul 2015 04:26:30 -0400 Subject: [cmake-developers] [CMake 0015668]: Create debuginfo package Message-ID: <6c786ce5ff5ad29864243e639fef92ce@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15668 ====================================================================== Reported By: Egor Assigned To: ====================================================================== Project: CMake Issue ID: 15668 Category: CPack Reproducibility: always Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-29 04:26 EDT Last Modified: 2015-07-29 04:26 EDT ====================================================================== Summary: Create debuginfo package Description: CPack allows us to create rpm-packages through CPackRPM module, but there is no chance to ask him for building correspondent debuginfo rpm package. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-29 04:26 Egor New Issue ====================================================================== From mantis at public.kitware.com Wed Jul 29 08:07:08 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 29 Jul 2015 08:07:08 -0400 Subject: [cmake-developers] [CMake 0015669]: XCTest for iOS target has incorrect TEST_HOST Message-ID: <72ecaccafc8e24ee21f44c347aa7e5bc@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15669 ====================================================================== Reported By: Seppo Tomperi Assigned To: ====================================================================== Project: CMake Issue ID: 15669 Category: Modules Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-29 08:07 EDT Last Modified: 2015-07-29 08:07 EDT ====================================================================== Summary: XCTest for iOS target has incorrect TEST_HOST Description: Path to executable in TEST_HOST is not correct when targeting iOS device. Steps to Reproduce: unzip iOSNavAppXCTest.zip cd iOSNavAppXCTest mkdir build cd build cmake -G Xcode .. grep TEST_HOST NavApp3.xcodeproj/project.pbxproj #### TEST_HOST variable has extra directory: "Contents/MacOS", which is not there. Executable is in NavApp3.app-directory. If "Contents/MacOS" is edited away from project file then project works and XCTests can be run in simulator and on iPhone. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-29 08:07 Seppo Tomperi New Issue 2015-07-29 08:07 Seppo Tomperi File Added: iOSNavAppXCTest.zip ====================================================================== From pascal.bach at siemens.com Wed Jul 29 08:32:46 2015 From: pascal.bach at siemens.com (Pascal Bach) Date: Wed, 29 Jul 2015 14:32:46 +0200 Subject: [cmake-developers] [PATCH 1/3] FindQt4: support OpenEmbedded Qt4 tool binary names In-Reply-To: <1438173168-24640-1-git-send-email-pascal.bach@siemens.com> References: <1438173168-24640-1-git-send-email-pascal.bach@siemens.com> Message-ID: <1438173168-24640-2-git-send-email-pascal.bach@siemens.com> The FindQt4 module looks for Qt4 binaries to be able to gather the paths used for compilation and also to be using during other processes (translation update, translation binary generating and like) however OpenEmbedded has renamed those to allow old QMake to be used in parallel with the current one. This patch adds support for the OpenEmbedded specific binary names. This patch was maintained as part of OpenEmbedded. Signed-off-by: Otavio Salvador Signed-off-by: Moritz Blume Signed-off-by: Pascal Bach --- Modules/FindQt4.cmake | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake index 11091b5..14404fa 100644 --- a/Modules/FindQt4.cmake +++ b/Modules/FindQt4.cmake @@ -522,7 +522,7 @@ endfunction() set(QT4_INSTALLED_VERSION_TOO_OLD FALSE) -set(_QT4_QMAKE_NAMES qmake qmake4 qmake-qt4 qmake-mac) +set(_QT4_QMAKE_NAMES qmake qmake2 qmake4 qmake-qt4 qmake-mac) _qt4_find_qmake("${_QT4_QMAKE_NAMES}" QT_QMAKE_EXECUTABLE QTVERSION) if (QT_QMAKE_EXECUTABLE AND @@ -1148,12 +1148,12 @@ if (QT_QMAKE_EXECUTABLE AND _find_qt4_program(QT_MOC_EXECUTABLE Qt4::moc moc-qt4 moc4 moc) _find_qt4_program(QT_UIC_EXECUTABLE Qt4::uic uic-qt4 uic4 uic) _find_qt4_program(QT_UIC3_EXECUTABLE Qt4::uic3 uic3) - _find_qt4_program(QT_RCC_EXECUTABLE Qt4::rcc rcc) - _find_qt4_program(QT_DBUSCPP2XML_EXECUTABLE Qt4::qdbuscpp2xml qdbuscpp2xml) - _find_qt4_program(QT_DBUSXML2CPP_EXECUTABLE Qt4::qdbusxml2cpp qdbusxml2cpp) + _find_qt4_program(QT_RCC_EXECUTABLE Qt4::rcc rcc4 rcc) + _find_qt4_program(QT_DBUSCPP2XML_EXECUTABLE Qt4::qdbuscpp2xml qdbuscpp2xml4 qdbuscpp2xml) + _find_qt4_program(QT_DBUSXML2CPP_EXECUTABLE Qt4::qdbusxml2cpp qdbusxml2cpp4 qdbusxml2cpp) _find_qt4_program(QT_LUPDATE_EXECUTABLE Qt4::lupdate lupdate-qt4 lupdate4 lupdate) _find_qt4_program(QT_LRELEASE_EXECUTABLE Qt4::lrelease lrelease-qt4 lrelease4 lrelease) - _find_qt4_program(QT_QCOLLECTIONGENERATOR_EXECUTABLE Qt4::qcollectiongenerator qcollectiongenerator-qt4 qcollectiongenerator) + _find_qt4_program(QT_QCOLLECTIONGENERATOR_EXECUTABLE Qt4::qcollectiongenerator qcollectiongenerator-qt4 qcollectiongenerator4 qcollectiongenerator) _find_qt4_program(QT_DESIGNER_EXECUTABLE Qt4::designer designer-qt4 designer4 designer) _find_qt4_program(QT_LINGUIST_EXECUTABLE Qt4::linguist linguist-qt4 linguist4 linguist) -- 1.9.1 From pascal.bach at siemens.com Wed Jul 29 08:32:47 2015 From: pascal.bach at siemens.com (Pascal Bach) Date: Wed, 29 Jul 2015 14:32:47 +0200 Subject: [cmake-developers] [PATCH 2/3] FindQt4: improve cross compile support In-Reply-To: <1438173168-24640-1-git-send-email-pascal.bach@siemens.com> References: <1438173168-24640-1-git-send-email-pascal.bach@siemens.com> Message-ID: <1438173168-24640-3-git-send-email-pascal.bach@siemens.com> FindQt4 depends a lot on QMake for finding the correct Qt path. This doesn't work well in cross compile environments as qmake reports the location of the native library. This patch allows to do cross compilation by setting the following variables for example in the toolchain file. QT_BINARY_DIR => Path to native Qt binary directory QT_LIBRARY_DIR => Path to target Qt library directory QT_INCLUDE_DIR => Path to target Qt include directory QT_MKSPECS_DIR => Path to target Qt mkspecs directory Signed-off-by: Pascal Bach --- Modules/FindQt4.cmake | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake index 14404fa..9d03378 100644 --- a/Modules/FindQt4.cmake +++ b/Modules/FindQt4.cmake @@ -583,23 +583,23 @@ if (QT_QMAKE_EXECUTABLE AND set(QT_QTCORE_LIBRARY_DEBUG NOTFOUND) find_library(QT_QTCORE_LIBRARY_RELEASE NAMES QtCore${QT_LIBINFIX} QtCore${QT_LIBINFIX}4 - HINTS ${QT_LIBRARY_DIR_TMP} + HINTS ${QT_LIBRARY_DIR} ${QT_LIBRARY_DIR_TMP} NO_DEFAULT_PATH ) find_library(QT_QTCORE_LIBRARY_DEBUG NAMES QtCore${QT_LIBINFIX}_debug QtCore${QT_LIBINFIX}d QtCore${QT_LIBINFIX}d4 - HINTS ${QT_LIBRARY_DIR_TMP} + HINTS ${QT_LIBRARY_DIR} ${QT_LIBRARY_DIR_TMP} NO_DEFAULT_PATH ) if(NOT QT_QTCORE_LIBRARY_RELEASE AND NOT QT_QTCORE_LIBRARY_DEBUG) find_library(QT_QTCORE_LIBRARY_RELEASE NAMES QtCore${QT_LIBINFIX} QtCore${QT_LIBINFIX}4 - HINTS ${QT_LIBRARY_DIR_TMP} + HINTS ${QT_LIBRARY_DIR} ${QT_LIBRARY_DIR_TMP} ) find_library(QT_QTCORE_LIBRARY_DEBUG NAMES QtCore${QT_LIBINFIX}_debug QtCore${QT_LIBINFIX}d QtCore${QT_LIBINFIX}d4 - HINTS ${QT_LIBRARY_DIR_TMP} + HINTS ${QT_LIBRARY_DIR} ${QT_LIBRARY_DIR_TMP} ) endif() @@ -659,13 +659,13 @@ if (QT_QMAKE_EXECUTABLE AND _qt4_query_qmake(QT_INSTALL_HEADERS qt_headers) set(QT_QTCORE_INCLUDE_DIR NOTFOUND) find_path(QT_QTCORE_INCLUDE_DIR QtCore - HINTS ${qt_headers} ${QT_LIBRARY_DIR} + HINTS ${QT_INCLUDE_DIR} ${qt_headers} ${QT_LIBRARY_DIR} PATH_SUFFIXES QtCore qt4/QtCore NO_DEFAULT_PATH ) if(NOT QT_QTCORE_INCLUDE_DIR) find_path(QT_QTCORE_INCLUDE_DIR QtCore - HINTS ${qt_headers} ${QT_LIBRARY_DIR} + HINTS ${QT_INCLUDE_DIR} ${qt_headers} ${QT_LIBRARY_DIR} PATH_SUFFIXES QtCore qt4/QtCore ) endif() -- 1.9.1 From pascal.bach at siemens.com Wed Jul 29 08:32:45 2015 From: pascal.bach at siemens.com (Pascal Bach) Date: Wed, 29 Jul 2015 14:32:45 +0200 Subject: [cmake-developers] [PATCH 0/3] improve FindQt4 and crosscompilation Message-ID: <1438173168-24640-1-git-send-email-pascal.bach@siemens.com> This patch set tries to improve how FindQt4 works in a cross compilation environment. In this case OpenEmbedded/Yoctor, but others should benefit from this too. Pascal Bach (3): FindQt4: support OpenEmbedded Qt4 tool binary names FindQt4: improve cross compile support FindQt4: document cross compilation Modules/FindQt4.cmake | 42 +++++++++++++++++++++++++++++++----------- 1 file changed, 31 insertions(+), 11 deletions(-) -- 1.9.1 From pascal.bach at siemens.com Wed Jul 29 08:32:48 2015 From: pascal.bach at siemens.com (Pascal Bach) Date: Wed, 29 Jul 2015 14:32:48 +0200 Subject: [cmake-developers] [PATCH 3/3] FindQt4: document cross compilation In-Reply-To: <1438173168-24640-1-git-send-email-pascal.bach@siemens.com> References: <1438173168-24640-1-git-send-email-pascal.bach@siemens.com> Message-ID: <1438173168-24640-4-git-send-email-pascal.bach@siemens.com> --- Modules/FindQt4.cmake | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake index 9d03378..64c06e1 100644 --- a/Modules/FindQt4.cmake +++ b/Modules/FindQt4.cmake @@ -29,6 +29,26 @@ # for a particular executable, set the ``QT4_NO_LINK_QTMAIN`` target # property to ``TRUE`` on the executable. # +# Cross Compile +# ^^^^^^^^^^^^^ +# +# To find Qt in a cross compile environment set the following variables in your toolchain file: +# +# +# ``QT_BINARY_DIR`` => Path to native Qt binary directory +# ``QT_LIBRARY_DIR`` => Path to target Qt library directory +# ``QT_INCLUDE_DIR`` => Path to target Qt include directory +# ``QT_MKSPECS_DIR`` => Path to target Qt mkspecs directory + +# example +# +# :: +# set( QT_BINARY_DIR /sysroots/x86_64-linux/usr/bin ) +# set( QT_LIBRARY_DIR /sysroots/arm/usr/lib ) +# set( QT_INCLUDE_DIR /sysroots/arm/usr/include/qtopia ) +# set( QT_MKSPECS_DIR /sysroots/arm/usr/share/qtopia/mkspecs ) +# +# # Qt Build Tools # ^^^^^^^^^^^^^^ # -- 1.9.1 From brad.king at kitware.com Wed Jul 29 09:26:10 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 29 Jul 2015 09:26:10 -0400 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: <55B6B997.90205@gmail.com> References: <55B6B997.90205@gmail.com> Message-ID: <55B8D472.2090209@kitware.com> On 07/27/2015 07:07 PM, Michael Scott wrote: > I've changed the -W dev options to affect the deprecated warnings/errors > as well, but only if the user hasn't used one of the options that > control deprecated warnings (-Wdeprecated, -Wno-deprecated, > -Werror=deprecated, -Wno-error=deprecated), if they have then the -W dev > options won't affect the CMAKE_WARN_DEPRECATED or CMAKE_ERROR_DEPRECATED > variables. > > I've also added the two -W dev options, "-Werror=dev" and > "-Wno-error=dev", to bring this set of options in line with the > deprecated set of options. Great! I've applied the patch with a few tweaks: cmake: Add -W options to control deprecation warnings and errors http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c96fe0b4 The largest change is that I hid CMAKE_SUPPRESS_DEVELOPER_ERRORS from public documentation since it is just an implementation detail to store the corresponding options persistently. Thanks, -Brad From brad.king at kitware.com Wed Jul 29 09:37:14 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 29 Jul 2015 09:37:14 -0400 Subject: [cmake-developers] Modules/GetPrequisites.cmake issues In-Reply-To: <55B7FBDF.6020504@classdesign.com> References: <55B7FBDF.6020504@classdesign.com> Message-ID: <55B8D70A.6000304@kitware.com> On 07/28/2015 06:02 PM, Bill Somerville wrote: > attached is a patch that addresses some issues recently discussed on the > users list. Thanks for working on this! > As there doesn't seem to be a reliable way of detecting MinGW callers > of fixup_bundle() may have to set the variable gp_tool to "objdump" if > dumpbin.exe is installed on the build machine to stop it using > dumpbin.exe for library dependency walking. Is there a reason not to look for objdump before dumpbin? > This patch also adds command status checking to the various > execute_process() invocations in GetPrerequisites.cmake so that they > don't fail silently producing invalid install packages. If you're comfortable enough with Git, please split this part out into a preceding patch with its own explanation in its commit message. That will clarify which hunks in the patch belong to which change. > + if(gp_cmd_filter) # filter is for performance > + execute_process( > + COMMAND ${gp_cmd} ${gp_cmd_args} ${target} > + COMMAND ${gp_grep_cmd} ${gp_cmd_filter} > + RESULT_VARIABLE gp_rv > + OUTPUT_VARIABLE gp_cmd_ov > + ERROR_VARIABLE gp_ev > + ) > + else() > + execute_process( > + COMMAND ${gp_cmd} ${gp_cmd_args} ${target} > + RESULT_VARIABLE gp_rv > + OUTPUT_VARIABLE gp_cmd_ov > + ERROR_VARIABLE gp_ev > + ) > + endif() This can be simplified as: execute_process( COMMAND ${gp_cmd} ${gp_cmd_args} ${target} ${gp_cmd_maybe_filter} RESULT_VARIABLE gp_rv OUTPUT_VARIABLE gp_cmd_ov ERROR_VARIABLE gp_ev ) where ``gp_cmd_maybe_filter`` is initialized to empty and later possibly set as: if(gp_grep_cmd) set(gp_cmd_maybe_filter COMMAND ${gp_grep_cmd} "^[[:blank:]]*DLL Name: " ) endif() Thanks, -Brad From brad.king at kitware.com Wed Jul 29 09:47:48 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 29 Jul 2015 09:47:48 -0400 Subject: [cmake-developers] Java support In-Reply-To: <6B37BC37-0442-492E-905A-8A184A04B587@sap.com> References: <53C8DDC8-829D-4532-9F6D-B5391EF69208@sap.com> <3518298.4AC594tU3M@caliban.sf-tec.de> <6B37BC37-0442-492E-905A-8A184A04B587@sap.com> Message-ID: <55B8D984.20800@kitware.com> On 07/29/2015 04:01 AM, CHEVRIER, Marc wrote: > here is an updated list of patches. Great. > find_package_handle_standard_args(Java > REQUIRED_VARS Java_JAVA_EXECUTABLE Java_JAR_EXECUTABLE Java_JAVAC_EXECUTABLE > Java_JAVAH_EXECUTABLE Java_JAVADOC_EXECUTABLE > + Java_IDLJ_EXECUTABLE Java_JARSIGNER_EXECUTABLE > VERSION_VAR Java_VERSION > ) Are idlj and jarsigner reliably available whenever the other tools are? Even for older versions? Do these need to be REQUIRED_VARS? I'm concerned this could make a case that previously found java not report it found anymore. > - --build-project hello > + --build-target hello The tests should still have --build-project as this corresponds to the .sln file name in Visual Studio builds. The --build-target option can be added in addition to it. Thanks, -Brad From marc.chevrier at sap.com Wed Jul 29 10:03:33 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Wed, 29 Jul 2015 14:03:33 +0000 Subject: [cmake-developers] Java support In-Reply-To: <55B8D984.20800@kitware.com> References: <53C8DDC8-829D-4532-9F6D-B5391EF69208@sap.com> <3518298.4AC594tU3M@caliban.sf-tec.de> <6B37BC37-0442-492E-905A-8A184A04B587@sap.com> <55B8D984.20800@kitware.com> Message-ID: <121853DE-2251-48A0-93F1-E660B508BA79@sap.com> Thanks for your comments. To address your first remark, I propose to introduce a new component (?Extra', for example) to manage these new tools. For example: find_package (Java COMPONENTS Development Extra) I think it is better than removing new variables as required because this approach will require some explicit check to ensure these tools are found before usage. Regarding your second remark, I will update my patches. Marc On 29/07/15 15:47, "Brad King" wrote: >On 07/29/2015 04:01 AM, CHEVRIER, Marc wrote: >> here is an updated list of patches. > >Great. > >> find_package_handle_standard_args(Java >> REQUIRED_VARS Java_JAVA_EXECUTABLE Java_JAR_EXECUTABLE Java_JAVAC_EXECUTABLE >> Java_JAVAH_EXECUTABLE Java_JAVADOC_EXECUTABLE >> + Java_IDLJ_EXECUTABLE Java_JARSIGNER_EXECUTABLE >> VERSION_VAR Java_VERSION >> ) > >Are idlj and jarsigner reliably available whenever the other tools are? >Even for older versions? Do these need to be REQUIRED_VARS? I'm >concerned this could make a case that previously found java not report >it found anymore. > >> - --build-project hello >> + --build-target hello > >The tests should still have --build-project as this corresponds to >the .sln file name in Visual Studio builds. The --build-target >option can be added in addition to it. > >Thanks, >-Brad > From pascal.bach at siemens.com Wed Jul 29 10:05:41 2015 From: pascal.bach at siemens.com (Pascal Bach) Date: Wed, 29 Jul 2015 16:05:41 +0200 Subject: [cmake-developers] [PATCH 3/3] FindQt4: document cross compilation In-Reply-To: <2879047.BI1Bn9cdff@stryke> References: <1438173168-24640-1-git-send-email-pascal.bach@siemens.com> <1438173168-24640-4-git-send-email-pascal.bach@siemens.com> <2879047.BI1Bn9cdff@stryke> Message-ID: <55B8DDB5.40406@siemens.com> Hi Clint Am 29.07.2015 um 15:45 schrieb Clinton Stimpson: > Hi Pascal, > > Thanks for the patches. > > Can you share with us why setting CMAKE_FIND_ROOT_PATH does not work, or how > this new method compares? > > For example, in the toolchain file: > SET(CMAKE_FIND_ROOT_PATH /path/to/Qt ...) The problem is how FindQt4 does find the locations using qmake. let's assume there are two sysroots one is /sysroots/x86_64 which contains binaries usable on the host machine, and there is /sysroots/arm which contains libraries for the target system. this are both set via: set( CMAKE_FIND_ROOT_PATH /sysroots/arm /sysroots/x86_64 ) set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY ) set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY ) set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY ) set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY ) Here is what happens when only setting CMAKE_FIND_ROOT_PATH: 1. FindQt4 is trying to find the qmake executable. As there is no qmake in /sysroots/arm (it would not be runnable on the host) it will find qmake from the /sysroots/x86_64 directory. 2. FindQt4 is asking qmake for the path to the Qt installation. As the qmake found is the one from /sysroots/x86_64 it will point to the libraries from /sysroots/x86_64 which will obviously not run on arm! Currently I didn't find a way to override this behaviour of FindQt4, except by setting all the variables usually set by FindQt4 manually. It is usually accepted to set some variables manually when doing cross compilation. With this patchset I tried to reduce this variable to a minumum and let FindQt4 figure out the rest. The minimum variables required with the patch are: QT_BINARY_DIR is necessary to find the correct qmake QT_LIBRARY_DIR is necessary to find the library directory QT_INCLUDE_DIR is necessary to find the include directory (might be possible to figure this out from QT_INCLUDE_DIR if some assumptions are made) QT_MKSPECS_DIR necessary to have the correct prefixes (E in the case of qt4-embedded). I hope my explanation is clear. If there is a better way to achive this I'm all ears. Pascal > > Clint > > On Wednesday, July 29, 2015 02:32:48 PM Pascal Bach wrote: >> --- >> Modules/FindQt4.cmake | 20 ++++++++++++++++++++ >> 1 file changed, 20 insertions(+) >> >> diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake >> index 9d03378..64c06e1 100644 >> --- a/Modules/FindQt4.cmake >> +++ b/Modules/FindQt4.cmake >> @@ -29,6 +29,26 @@ >> # for a particular executable, set the ``QT4_NO_LINK_QTMAIN`` target >> # property to ``TRUE`` on the executable. >> # >> +# Cross Compile >> +# ^^^^^^^^^^^^^ >> +# >> +# To find Qt in a cross compile environment set the following variables in >> your toolchain file: +# >> +# >> +# ``QT_BINARY_DIR`` => Path to native Qt binary directory >> +# ``QT_LIBRARY_DIR`` => Path to target Qt library directory >> +# ``QT_INCLUDE_DIR`` => Path to target Qt include directory >> +# ``QT_MKSPECS_DIR`` => Path to target Qt mkspecs directory >> + >> +# example >> +# >> +# :: >> +# set( QT_BINARY_DIR /sysroots/x86_64-linux/usr/bin ) >> +# set( QT_LIBRARY_DIR /sysroots/arm/usr/lib ) >> +# set( QT_INCLUDE_DIR /sysroots/arm/usr/include/qtopia ) >> +# set( QT_MKSPECS_DIR /sysroots/arm/usr/share/qtopia/mkspecs ) >> +# >> +# >> # Qt Build Tools >> # ^^^^^^^^^^^^^^ >> # From clinton at elemtech.com Wed Jul 29 09:45:43 2015 From: clinton at elemtech.com (Clinton Stimpson) Date: Wed, 29 Jul 2015 07:45:43 -0600 Subject: [cmake-developers] [PATCH 3/3] FindQt4: document cross compilation In-Reply-To: <1438173168-24640-4-git-send-email-pascal.bach@siemens.com> References: <1438173168-24640-1-git-send-email-pascal.bach@siemens.com> <1438173168-24640-4-git-send-email-pascal.bach@siemens.com> Message-ID: <2879047.BI1Bn9cdff@stryke> Hi Pascal, Thanks for the patches. Can you share with us why setting CMAKE_FIND_ROOT_PATH does not work, or how this new method compares? For example, in the toolchain file: SET(CMAKE_FIND_ROOT_PATH /path/to/Qt ...) Clint On Wednesday, July 29, 2015 02:32:48 PM Pascal Bach wrote: > --- > Modules/FindQt4.cmake | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake > index 9d03378..64c06e1 100644 > --- a/Modules/FindQt4.cmake > +++ b/Modules/FindQt4.cmake > @@ -29,6 +29,26 @@ > # for a particular executable, set the ``QT4_NO_LINK_QTMAIN`` target > # property to ``TRUE`` on the executable. > # > +# Cross Compile > +# ^^^^^^^^^^^^^ > +# > +# To find Qt in a cross compile environment set the following variables in > your toolchain file: +# > +# > +# ``QT_BINARY_DIR`` => Path to native Qt binary directory > +# ``QT_LIBRARY_DIR`` => Path to target Qt library directory > +# ``QT_INCLUDE_DIR`` => Path to target Qt include directory > +# ``QT_MKSPECS_DIR`` => Path to target Qt mkspecs directory > + > +# example > +# > +# :: > +# set( QT_BINARY_DIR /sysroots/x86_64-linux/usr/bin ) > +# set( QT_LIBRARY_DIR /sysroots/arm/usr/lib ) > +# set( QT_INCLUDE_DIR /sysroots/arm/usr/include/qtopia ) > +# set( QT_MKSPECS_DIR /sysroots/arm/usr/share/qtopia/mkspecs ) > +# > +# > # Qt Build Tools > # ^^^^^^^^^^^^^^ > # From bill at classdesign.com Wed Jul 29 10:17:24 2015 From: bill at classdesign.com (Bill Somerville) Date: Wed, 29 Jul 2015 15:17:24 +0100 Subject: [cmake-developers] Modules/GetPrequisites.cmake issues In-Reply-To: <55B8D70A.6000304@kitware.com> References: <55B7FBDF.6020504@classdesign.com> <55B8D70A.6000304@kitware.com> Message-ID: <55B8E074.1070907@classdesign.com> On 29/07/2015 14:37, Brad King wrote: Hi Brad, > On 07/28/2015 06:02 PM, Bill Somerville wrote: ... >> As there doesn't seem to be a reliable way of detecting MinGW callers >> of fixup_bundle() may have to set the variable gp_tool to "objdump" if >> dumpbin.exe is installed on the build machine to stop it using >> dumpbin.exe for library dependency walking. > Is there a reason not to look for objdump before dumpbin? I was under the impression that dumpbin was selected first for non-MinGW Windows builds, I have no idea if objdump works with binaries produced by compilers other than GNU/CLang. This is why I commented about detecting MinGW, there are mentions of a MINGW CMake system variable but it doesn't seem to exist. > >> This patch also adds command status checking to the various >> execute_process() invocations in GetPrerequisites.cmake so that they >> don't fail silently producing invalid install packages. > If you're comfortable enough with Git, please split this part out into > a preceding patch with its own explanation in its commit message. That > will clarify which hunks in the patch belong to which change. No problem with that, I will do that shortly. > >> + if(gp_cmd_filter) # filter is for performance >> + execute_process( >> + COMMAND ${gp_cmd} ${gp_cmd_args} ${target} >> + COMMAND ${gp_grep_cmd} ${gp_cmd_filter} >> + RESULT_VARIABLE gp_rv >> + OUTPUT_VARIABLE gp_cmd_ov >> + ERROR_VARIABLE gp_ev >> + ) >> + else() >> + execute_process( >> + COMMAND ${gp_cmd} ${gp_cmd_args} ${target} >> + RESULT_VARIABLE gp_rv >> + OUTPUT_VARIABLE gp_cmd_ov >> + ERROR_VARIABLE gp_ev >> + ) >> + endif() > This can be simplified as: > > execute_process( > COMMAND ${gp_cmd} ${gp_cmd_args} ${target} > ${gp_cmd_maybe_filter} > RESULT_VARIABLE gp_rv > OUTPUT_VARIABLE gp_cmd_ov > ERROR_VARIABLE gp_ev > ) > > where ``gp_cmd_maybe_filter`` is initialized to empty and later > possibly set as: > > if(gp_grep_cmd) > set(gp_cmd_maybe_filter > COMMAND ${gp_grep_cmd} "^[[:blank:]]*DLL Name: " > ) > endif() I tried that first but couldn't get it to work, maybe because I didn't initialize it to empty, I will try again. > > Thanks, > -Brad > Thanks for the review, regards Bill Somerville. From clinton at elemtech.com Wed Jul 29 10:47:16 2015 From: clinton at elemtech.com (Clinton Stimpson) Date: Wed, 29 Jul 2015 08:47:16 -0600 Subject: [cmake-developers] [PATCH 3/3] FindQt4: document cross compilation In-Reply-To: <55B8DDB5.40406@siemens.com> References: <1438173168-24640-1-git-send-email-pascal.bach@siemens.com> <2879047.BI1Bn9cdff@stryke> <55B8DDB5.40406@siemens.com> Message-ID: <2329846.pno7VYBYh8@stryke> On Wednesday, July 29, 2015 04:05:41 PM Pascal Bach wrote: > Hi Clint > > Am 29.07.2015 um 15:45 schrieb Clinton Stimpson: > > Hi Pascal, > > > > Thanks for the patches. > > > > Can you share with us why setting CMAKE_FIND_ROOT_PATH does not work, or > > how this new method compares? > > > > For example, in the toolchain file: > > SET(CMAKE_FIND_ROOT_PATH /path/to/Qt ...) > > The problem is how FindQt4 does find the locations using qmake. > > let's assume there are two sysroots one is /sysroots/x86_64 which contains > binaries usable on the host machine, and there is /sysroots/arm which > contains libraries for the target system. this are both set via: > set( CMAKE_FIND_ROOT_PATH /sysroots/arm /sysroots/x86_64 ) > set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY ) > set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY ) > set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY ) > set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY ) Yes, this concern of 2 sysroots has been brought up before. Thanks for addressing this. > > Here is what happens when only setting CMAKE_FIND_ROOT_PATH: > > 1. FindQt4 is trying to find the qmake executable. As there is no qmake in > /sysroots/arm (it would not be runnable on the host) it will find qmake > from the /sysroots/x86_64 directory. 2. FindQt4 is asking qmake for the > path to the Qt installation. As the qmake found is the one from > /sysroots/x86_64 it will point to the libraries from /sysroots/x86_64 which > will obviously not run on arm! > > Currently I didn't find a way to override this behaviour of FindQt4, except > by setting all the variables usually set by FindQt4 manually. It is usually > accepted to set some variables manually when doing cross compilation. With > this patchset I tried to reduce this variable to a minumum and let FindQt4 > figure out the rest. > > The minimum variables required with the patch are: > > QT_BINARY_DIR is necessary to find the correct qmake > QT_LIBRARY_DIR is necessary to find the library directory > QT_INCLUDE_DIR is necessary to find the include directory (might be possible > to figure this out from QT_INCLUDE_DIR if some assumptions are made) > QT_MKSPECS_DIR necessary to have the correct prefixes (E in the case of > qt4-embedded). > > > I hope my explanation is clear. If there is a better way to achive this I'm > all ears. > I'm fine with this, and don't think it'll conflict with any other use cases. However, I do think we should first document setting CMAKE_FIND_ROOT_PATH, then afterwards document the other variables for those users which need more control. Does that sound reasonable? Clint > Pascal > > > Clint > > > > On Wednesday, July 29, 2015 02:32:48 PM Pascal Bach wrote: > >> --- > >> > >> Modules/FindQt4.cmake | 20 ++++++++++++++++++++ > >> 1 file changed, 20 insertions(+) > >> > >> diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake > >> index 9d03378..64c06e1 100644 > >> --- a/Modules/FindQt4.cmake > >> +++ b/Modules/FindQt4.cmake > >> @@ -29,6 +29,26 @@ > >> > >> # for a particular executable, set the ``QT4_NO_LINK_QTMAIN`` target > >> # property to ``TRUE`` on the executable. > >> # > >> > >> +# Cross Compile > >> +# ^^^^^^^^^^^^^ > >> +# > >> +# To find Qt in a cross compile environment set the following variables > >> in > >> your toolchain file: +# > >> +# > >> +# ``QT_BINARY_DIR`` => Path to native Qt binary directory > >> +# ``QT_LIBRARY_DIR`` => Path to target Qt library directory > >> +# ``QT_INCLUDE_DIR`` => Path to target Qt include directory > >> +# ``QT_MKSPECS_DIR`` => Path to target Qt mkspecs directory > >> + > >> +# example > >> +# > >> +# :: > >> +# set( QT_BINARY_DIR /sysroots/x86_64-linux/usr/bin ) > >> +# set( QT_LIBRARY_DIR /sysroots/arm/usr/lib ) > >> +# set( QT_INCLUDE_DIR /sysroots/arm/usr/include/qtopia ) > >> +# set( QT_MKSPECS_DIR /sysroots/arm/usr/share/qtopia/mkspecs ) > >> +# > >> +# > >> > >> # Qt Build Tools > >> # ^^^^^^^^^^^^^^ > >> # From pascal.bach at siemens.com Wed Jul 29 10:59:57 2015 From: pascal.bach at siemens.com (Pascal Bach) Date: Wed, 29 Jul 2015 16:59:57 +0200 Subject: [cmake-developers] [PATCH 3/3] FindQt4: document cross compilation In-Reply-To: <2329846.pno7VYBYh8@stryke> References: <1438173168-24640-1-git-send-email-pascal.bach@siemens.com> <2879047.BI1Bn9cdff@stryke> <55B8DDB5.40406@siemens.com> <2329846.pno7VYBYh8@stryke> Message-ID: <55B8EA6D.5030705@siemens.com> Hi Clint Am 29.07.2015 um 16:47 schrieb Clinton Stimpson: > On Wednesday, July 29, 2015 04:05:41 PM Pascal Bach wrote: >> Hi Clint >> >> Am 29.07.2015 um 15:45 schrieb Clinton Stimpson: >>> Hi Pascal, >>> >>> Thanks for the patches. >>> >>> Can you share with us why setting CMAKE_FIND_ROOT_PATH does not work, or >>> how this new method compares? >>> >>> For example, in the toolchain file: >>> SET(CMAKE_FIND_ROOT_PATH /path/to/Qt ...) >> The problem is how FindQt4 does find the locations using qmake. >> >> let's assume there are two sysroots one is /sysroots/x86_64 which contains >> binaries usable on the host machine, and there is /sysroots/arm which >> contains libraries for the target system. this are both set via: >> set( CMAKE_FIND_ROOT_PATH /sysroots/arm /sysroots/x86_64 ) >> set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY ) >> set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY ) >> set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY ) >> set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY ) > Yes, this concern of 2 sysroots has been brought up before. Thanks for > addressing this. > >> Here is what happens when only setting CMAKE_FIND_ROOT_PATH: >> >> 1. FindQt4 is trying to find the qmake executable. As there is no qmake in >> /sysroots/arm (it would not be runnable on the host) it will find qmake >> from the /sysroots/x86_64 directory. 2. FindQt4 is asking qmake for the >> path to the Qt installation. As the qmake found is the one from >> /sysroots/x86_64 it will point to the libraries from /sysroots/x86_64 which >> will obviously not run on arm! >> >> Currently I didn't find a way to override this behaviour of FindQt4, except >> by setting all the variables usually set by FindQt4 manually. It is usually >> accepted to set some variables manually when doing cross compilation. With >> this patchset I tried to reduce this variable to a minumum and let FindQt4 >> figure out the rest. >> >> The minimum variables required with the patch are: >> >> QT_BINARY_DIR is necessary to find the correct qmake >> QT_LIBRARY_DIR is necessary to find the library directory >> QT_INCLUDE_DIR is necessary to find the include directory (might be possible >> to figure this out from QT_INCLUDE_DIR if some assumptions are made) >> QT_MKSPECS_DIR necessary to have the correct prefixes (E in the case of >> qt4-embedded). >> >> >> I hope my explanation is clear. If there is a better way to achive this I'm >> all ears. >> > I'm fine with this, and don't think it'll conflict with any other use cases. I don't see a conflict either. > > However, I do think we should first document setting CMAKE_FIND_ROOT_PATH, then > afterwards document the other variables for those users which need more > control. Does that sound reasonable? I'm not sure I understand what you mean. I think how to set CMAKE_FIND_ROOT_PATH is already documented in cmake. Are you suggesting extending the docuemntation of FindQt4below with a paragraph documenting how to work with two sysroots? With an example like this? set( CMAKE_FIND_ROOT_PATH /sysroots/arm /sysroots/x86_64 ) set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY ) set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY ) set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY ) set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY ) Pascal > > Clint > >> Pascal >> >>> Clint >>> >>> On Wednesday, July 29, 2015 02:32:48 PM Pascal Bach wrote: >>>> --- >>>> >>>> Modules/FindQt4.cmake | 20 ++++++++++++++++++++ >>>> 1 file changed, 20 insertions(+) >>>> >>>> diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake >>>> index 9d03378..64c06e1 100644 >>>> --- a/Modules/FindQt4.cmake >>>> +++ b/Modules/FindQt4.cmake >>>> @@ -29,6 +29,26 @@ >>>> >>>> # for a particular executable, set the ``QT4_NO_LINK_QTMAIN`` target >>>> # property to ``TRUE`` on the executable. >>>> # >>>> >>>> +# Cross Compile >>>> +# ^^^^^^^^^^^^^ >>>> +# >>>> +# To find Qt in a cross compile environment set the following variables >>>> in >>>> your toolchain file: +# >>>> +# >>>> +# ``QT_BINARY_DIR`` => Path to native Qt binary directory >>>> +# ``QT_LIBRARY_DIR`` => Path to target Qt library directory >>>> +# ``QT_INCLUDE_DIR`` => Path to target Qt include directory >>>> +# ``QT_MKSPECS_DIR`` => Path to target Qt mkspecs directory >>>> + >>>> +# example >>>> +# >>>> +# :: >>>> +# set( QT_BINARY_DIR /sysroots/x86_64-linux/usr/bin ) >>>> +# set( QT_LIBRARY_DIR /sysroots/arm/usr/lib ) >>>> +# set( QT_INCLUDE_DIR /sysroots/arm/usr/include/qtopia ) >>>> +# set( QT_MKSPECS_DIR /sysroots/arm/usr/share/qtopia/mkspecs ) >>>> +# >>>> +# >>>> >>>> # Qt Build Tools >>>> # ^^^^^^^^^^^^^^ >>>> # From bill.hoffman at kitware.com Wed Jul 29 11:07:37 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Wed, 29 Jul 2015 11:07:37 -0400 Subject: [cmake-developers] Modules/GetPrequisites.cmake issues In-Reply-To: <55B8E074.1070907@classdesign.com> References: <55B7FBDF.6020504@classdesign.com> <55B8D70A.6000304@kitware.com> <55B8E074.1070907@classdesign.com> Message-ID: <55B8EC39.1090001@kitware.com> On 7/29/2015 10:17 AM, Bill Somerville wrote: >> Is there a reason not to look for objdump before dumpbin? > I was under the impression that dumpbin was selected first for non-MinGW > Windows builds, I have no idea if objdump works with binaries produced > by compilers other than GNU/CLang. This is why I commented about > detecting MinGW, there are mentions of a MINGW CMake system variable but > it doesn't seem to exist. Yes, that is the problem. This is a standalone script that is run at install time, so it does not have any information about the build toolchain. In retrospect it should have been passed more information about the build tool chain that was used. This is what we want: # dumpbin (Windows) # objdump (MinGW on Windows) # ldd (Linux/Unix) # otool (Mac OSX) Trouble is dumpbin and objdump might both be in the PATH on Windows. You don't really know which one to use. I wonder if you found both if you could call something on each of them with one of the binaries, if you could figure out what tool would work better with it. -Bill From brad.king at kitware.com Wed Jul 29 11:08:42 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 29 Jul 2015 11:08:42 -0400 Subject: [cmake-developers] [PATCH 3/3] FindQt4: document cross compilation In-Reply-To: <55B8EA6D.5030705@siemens.com> References: <1438173168-24640-1-git-send-email-pascal.bach@siemens.com> <2879047.BI1Bn9cdff@stryke> <55B8DDB5.40406@siemens.com> <2329846.pno7VYBYh8@stryke> <55B8EA6D.5030705@siemens.com> Message-ID: <55B8EC7A.5000009@kitware.com> On 07/29/2015 10:59 AM, Pascal Bach wrote: > set( CMAKE_FIND_ROOT_PATH /sysroots/arm /sysroots/x86_64 ) > set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY ) > set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY ) > set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY ) > set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY ) If this is not sufficient to convince FindQt4 to find the right qmake and libraries then FindQt4 should be fixed to do so rather than asking the user to set more package-specific variables. > QT_BINARY_DIR is necessary to find the correct qmake If the user knows this information then s/he might as well just set QT_QMAKE_EXECUTABLE directly. -Brad From bill at classdesign.com Wed Jul 29 12:47:14 2015 From: bill at classdesign.com (Bill Somerville) Date: Wed, 29 Jul 2015 17:47:14 +0100 Subject: [cmake-developers] Modules/GetPrequisites.cmake issues In-Reply-To: <55B8EC39.1090001@kitware.com> References: <55B7FBDF.6020504@classdesign.com> <55B8D70A.6000304@kitware.com> <55B8E074.1070907@classdesign.com> <55B8EC39.1090001@kitware.com> Message-ID: <55B90392.90104@classdesign.com> On 29/07/2015 16:07, Bill Hoffman wrote: Hi Bill, > On 7/29/2015 10:17 AM, Bill Somerville wrote: >>> Is there a reason not to look for objdump before dumpbin? >> I was under the impression that dumpbin was selected first for non-MinGW >> Windows builds, I have no idea if objdump works with binaries produced >> by compilers other than GNU/CLang. This is why I commented about >> detecting MinGW, there are mentions of a MINGW CMake system variable but >> it doesn't seem to exist. > Yes, that is the problem. This is a standalone script that is run at > install time, so it does not have any information about the build > toolchain. In retrospect it should have been passed more information > about the build tool chain that was used. > > This is what we want: > > # dumpbin (Windows) > # objdump (MinGW on Windows) > # ldd (Linux/Unix) > # otool (Mac OSX) There is already a documented override by setting the gp_tool variable, that's what we do in our project since we only support MinGW on Windows (at the moment). > > Trouble is dumpbin and objdump might both be in the PATH on Windows. > You don't really know which one to use. I wonder if you found both > if you could call something on each of them with one of the binaries, > if you could figure out what tool would work better with it. You can't decide based on one executable since dumpbin works on some and not others, I believe the problem is with DLLs that export exactly zero symbols which is true of the GCC support libraries. It may be that if objdump is available it can always be used but I don't know that for sure, also it is still slower than dumpbin even with the patch I am proposing. > > -Bill Regards Bill Somerville. From bill at classdesign.com Wed Jul 29 12:51:45 2015 From: bill at classdesign.com (Bill Somerville) Date: Wed, 29 Jul 2015 17:51:45 +0100 Subject: [cmake-developers] Modules/GetPrequisites.cmake issues In-Reply-To: <55B8D70A.6000304@kitware.com> References: <55B7FBDF.6020504@classdesign.com> <55B8D70A.6000304@kitware.com> Message-ID: <55B904A1.5030001@classdesign.com> On 29/07/2015 14:37, Brad King wrote: Hi Brad, > On 07/28/2015 06:02 PM, Bill Somerville wrote: >> attached is a patch that addresses some issues recently discussed on the >> users list. ... > If you're comfortable enough with Git, please split this part out into > a preceding patch with its own explanation in its commit message. That > will clarify which hunks in the patch belong to which change. ... > > This can be simplified as: > > execute_process( > COMMAND ${gp_cmd} ${gp_cmd_args} ${target} > ${gp_cmd_maybe_filter} > RESULT_VARIABLE gp_rv > OUTPUT_VARIABLE gp_cmd_ov > ERROR_VARIABLE gp_ev > ) > > where ``gp_cmd_maybe_filter`` is initialized to empty and later > possibly set as: > > if(gp_grep_cmd) > set(gp_cmd_maybe_filter > COMMAND ${gp_grep_cmd} "^[[:blank:]]*DLL Name: " > ) > endif() Revised patches attached. > > Thanks, > -Brad > Regards Bill Somerville. -------------- next part -------------- >From 0332d20411f62d865b5a84d8e0f78f68a49d1a0b Mon Sep 17 00:00:00 2001 From: Bill Somerville Date: Wed, 29 Jul 2015 17:05:51 +0100 Subject: [PATCH 1/2] Add error checks for execute_process() calls Return status checks added to external command invocations so that they do not fail silently producing incomplete install packages. --- Modules/GetPrerequisites.cmake | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/Modules/GetPrerequisites.cmake b/Modules/GetPrerequisites.cmake index 23d486e..a359d2c 100644 --- a/Modules/GetPrerequisites.cmake +++ b/Modules/GetPrerequisites.cmake @@ -229,9 +229,14 @@ function(is_file_executable file result_var) if(file_cmd) execute_process(COMMAND "${file_cmd}" "${file_full}" + RESULT_VARIABLE file_rv OUTPUT_VARIABLE file_ov + ERROR_VARIABLE file_ev OUTPUT_STRIP_TRAILING_WHITESPACE ) + if(NOT file_rv STREQUAL "0") + message(FATAL_ERROR "${file_cmd} failed: ${file_rv}\n${file_ev}") + endif() # Replace the name of the file in the output with a placeholder token # (the string " _file_full_ ") so that just in case the path name of @@ -543,11 +548,21 @@ function(gp_resolved_file_type original_file file exepath dirs type_var) if(CYGPATH_EXECUTABLE) execute_process(COMMAND ${CYGPATH_EXECUTABLE} -W + RESULT_VARIABLE env_rv OUTPUT_VARIABLE env_windir + ERROR_VARIABLE env_ev OUTPUT_STRIP_TRAILING_WHITESPACE) + if(NOT env_rv STREQUAL "0") + message(FATAL_ERROR "${CYGPATH_EXECUTABLE} -W failed: ${env_rv}\n${env_ev}") + endif() execute_process(COMMAND ${CYGPATH_EXECUTABLE} -S + RESULT_VARIABLE env_rv OUTPUT_VARIABLE env_sysdir + ERROR_VARIABLE env_ev OUTPUT_STRIP_TRAILING_WHITESPACE) + if(NOT env_rv STREQUAL "0") + message(FATAL_ERROR "${CYGPATH_EXECUTABLE} -S failed: ${env_rv}\n${env_ev}") + endif() string(TOLOWER "${env_windir}" windir) string(TOLOWER "${env_sysdir}" sysroot) @@ -765,8 +780,18 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa # execute_process( COMMAND ${gp_cmd} ${gp_cmd_args} ${target} + RESULT_VARIABLE gp_rv OUTPUT_VARIABLE gp_cmd_ov + ERROR_VARIABLE gp_ev ) + if(NOT gp_rv STREQUAL "0") + if(gp_tool STREQUAL "dumpbin") + # dumpbin error messages seem to go to stdout + message(FATAL_ERROR "${gp_cmd} failed: ${gp_rv}\n${gp_ev}\n${gp_cmd_ov}") + else() + message(FATAL_ERROR "${gp_cmd} failed: ${gp_rv}\n${gp_ev}") + endif() + endif() if(gp_tool STREQUAL "ldd") set(ENV{LD_LIBRARY_PATH} "${old_ld_env}") @@ -791,8 +816,13 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa if(gp_tool STREQUAL "otool") execute_process( COMMAND otool -D ${target} + RESULT_VARIABLE otool_rv OUTPUT_VARIABLE gp_install_id_ov + ERROR_VARIABLE otool_ev ) + if(NOT otool_rv STREQUAL "0") + message(FATAL_ERROR "otool -D failed: ${otool_rv}\n${otool_ev}") + endif() # second line is install name string(REGEX REPLACE ".*:\n" "" gp_install_id "${gp_install_id_ov}") if(gp_install_id) -- 1.9.5.msysgit.0 -------------- next part -------------- >From 85c1785af125f18581e69b492409339d074ec18e Mon Sep 17 00:00:00 2001 From: Bill Somerville Date: Wed, 29 Jul 2015 17:36:38 +0100 Subject: [PATCH 2/2] Optional filter for dependency walker & use it for objdump on MinGW As dumpbin.exe is no longer reliable for gcc libraries on MinGW because it crashes on many common libraries like libgcc_s and libgfortran it is now necessary too resort to using objdump for DLL dependency walking. Using objdump has a secondary problem in that it generates a lot of output for large libraries and causes fixup_bundle() to take many minutes to process what took fractions of a second with dumpbin.exe /dependents. This patch includes a grep pre-filter in the execute_process() command pipeline to reduce this output to a minimum for a several orders of magnitude speed up. If grep isn't available the full output is used. As there does not seem to be a reliable way of detecting MinGW, callers of fixup_bundle() may have to set the variable gp_tool to "objdump" if dumpbin.exe is installed on the build machine to stop it using the broken MS dumpbin.exe for library dependency walking. --- Modules/GetPrerequisites.cmake | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/Modules/GetPrerequisites.cmake b/Modules/GetPrerequisites.cmake index a359d2c..e4018b6 100644 --- a/Modules/GetPrerequisites.cmake +++ b/Modules/GetPrerequisites.cmake @@ -700,6 +700,8 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa return() endif() + set(gp_cmd_maybe_filter) # optional command to pre-filter gp_tool results + if(gp_tool STREQUAL "ldd") set(gp_cmd_args "") set(gp_regex "^[\t ]*[^\t ]+ => ([^\t\(]+) .*${eol_char}$") @@ -724,6 +726,11 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa set(gp_regex_error "") set(gp_regex_fallback "") set(gp_regex_cmp_count 1) + # objdump generaates copious output so we create a grep filter to pre-filter results + find_program(gp_grep_cmd grep) + if(gp_grep_cmd) + set(gp_cmd_maybe_filter COMMAND ${gp_grep_cmd} "^[[:blank:]]*DLL Name: ") + endif() else() message(STATUS "warning: gp_tool='${gp_tool}' is an unknown tool...") message(STATUS "CMake function get_prerequisites needs more code to handle '${gp_tool}'") @@ -780,6 +787,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa # execute_process( COMMAND ${gp_cmd} ${gp_cmd_args} ${target} + ${gp_cmd_maybe_filter} RESULT_VARIABLE gp_rv OUTPUT_VARIABLE gp_cmd_ov ERROR_VARIABLE gp_ev -- 1.9.5.msysgit.0 From clinton at elemtech.com Wed Jul 29 14:39:07 2015 From: clinton at elemtech.com (Clinton Stimpson) Date: Wed, 29 Jul 2015 12:39:07 -0600 Subject: [cmake-developers] [PATCH 3/3] FindQt4: document cross compilation In-Reply-To: <55B8EA6D.5030705@siemens.com> References: <1438173168-24640-1-git-send-email-pascal.bach@siemens.com> <2329846.pno7VYBYh8@stryke> <55B8EA6D.5030705@siemens.com> Message-ID: <1479278.oGgGttUGG9@stryke> On Wednesday, July 29, 2015 04:59:57 PM Pascal Bach wrote: > Hi Clint > > Am 29.07.2015 um 16:47 schrieb Clinton Stimpson: > > On Wednesday, July 29, 2015 04:05:41 PM Pascal Bach wrote: > >> Hi Clint > >> > >> Am 29.07.2015 um 15:45 schrieb Clinton Stimpson: > >>> Hi Pascal, > >>> > >>> Thanks for the patches. > >>> > >>> Can you share with us why setting CMAKE_FIND_ROOT_PATH does not work, or > >>> how this new method compares? > >>> > >>> For example, in the toolchain file: > >>> SET(CMAKE_FIND_ROOT_PATH /path/to/Qt ...) > >> > >> The problem is how FindQt4 does find the locations using qmake. > >> > >> let's assume there are two sysroots one is /sysroots/x86_64 which > >> contains > >> binaries usable on the host machine, and there is /sysroots/arm which > >> contains libraries for the target system. this are both set via: > >> set( CMAKE_FIND_ROOT_PATH /sysroots/arm /sysroots/x86_64 ) > >> set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY ) > >> set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY ) > >> set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY ) > >> set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY ) > > > > Yes, this concern of 2 sysroots has been brought up before. Thanks for > > addressing this. > > > >> Here is what happens when only setting CMAKE_FIND_ROOT_PATH: > >> > >> 1. FindQt4 is trying to find the qmake executable. As there is no qmake > >> in > >> /sysroots/arm (it would not be runnable on the host) it will find qmake > >> from the /sysroots/x86_64 directory. 2. FindQt4 is asking qmake for the > >> path to the Qt installation. As the qmake found is the one from > >> /sysroots/x86_64 it will point to the libraries from /sysroots/x86_64 > >> which > >> will obviously not run on arm! > >> > >> Currently I didn't find a way to override this behaviour of FindQt4, > >> except > >> by setting all the variables usually set by FindQt4 manually. It is > >> usually > >> accepted to set some variables manually when doing cross compilation. > >> With > >> this patchset I tried to reduce this variable to a minumum and let > >> FindQt4 > >> figure out the rest. > >> > >> The minimum variables required with the patch are: > >> > >> QT_BINARY_DIR is necessary to find the correct qmake > >> QT_LIBRARY_DIR is necessary to find the library directory > >> QT_INCLUDE_DIR is necessary to find the include directory (might be > >> possible to figure this out from QT_INCLUDE_DIR if some assumptions are > >> made) QT_MKSPECS_DIR necessary to have the correct prefixes (E in the > >> case of qt4-embedded). > >> > >> > >> I hope my explanation is clear. If there is a better way to achive this > >> I'm > >> all ears. > > > > I'm fine with this, and don't think it'll conflict with any other use > > cases. > I don't see a conflict either. > > > However, I do think we should first document setting CMAKE_FIND_ROOT_PATH, > > then afterwards document the other variables for those users which need > > more control. Does that sound reasonable? > > I'm not sure I understand what you mean. > I think how to set CMAKE_FIND_ROOT_PATH is already documented in cmake. > Are you suggesting extending the docuemntation of FindQt4below with a > paragraph documenting how to work with two sysroots? With an example like > this? > > set( CMAKE_FIND_ROOT_PATH /sysroots/arm /sysroots/x86_64 ) > set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY ) > set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY ) > set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY ) > set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY ) What I want to avoid is users thinking that what you are proposing overrides any other way of finding Qt when cross compiling. The wording you propose is "To find Qt in a cross compile environment set the following variables" However there are users for which setting only CMAKE_FIND_ROOT_PATH is enough. Or setting CMAKE_FIND_ROOT_PATH plus QT_QMAKE_EXECUTABLE is enough. Brad had a good question in another email. Can't you set QT_QMAKE_EXECUTABLE? My guess, is no, because that qmake returns paths under one sysroot. I just realized something. Your use case is similar or the same to one I had tested FindQt4 with. Your Qt appears to be prefixed under /sysroot/arm/usr, not /sysroot/arm. Can you include /sysroot/arm/usr in CMAKE_FIND_ROOT_PATH, then see if FindQt4 can find your libraries under /sysroot/arm/usr. Clint From alex.merry at kde.org Wed Jul 29 15:58:46 2015 From: alex.merry at kde.org (Alex Merry) Date: Wed, 29 Jul 2015 21:58:46 +0200 Subject: [cmake-developers] [PATCH] cmCMakePolicyCommand: New PARENT_SCOPE argument Message-ID: <12318436.qfJba0PCz6@roku> Add a PARENT_SCOPE argument to cmake_policy(SET) that makes the policy apply to the parent (strong) scope - it will break out of exactly one level of the policy stack. This is intended to be used from a "settings file" which is applied to a group of CMake projects. This allows the file to control which policies apply only within the file and which apply to the project. It also means that users of the settings file are not forced to use NO_POLICY_SCOPE (particularly important if the settings file did not originally have any policy settings in it, but later acquired some). --- Source/cmCMakePolicyCommand.cxx | 19 +++++- Source/cmMakefile.cxx | 14 +++-- Source/cmMakefile.h | 4 +- Tests/PolicyScope/CMakeLists.txt | 73 +++++++++++++++++++++- Tests/PolicyScope/FindFoo.cmake | 1 + Tests/PolicyScope/IncludesUsesParentScope.cmake | 1 + .../IncludesUsesParentScopeWithCMP0011New.cmake | 2 + .../IncludesUsesParentScopeWithCMP0011Old.cmake | 2 + Tests/PolicyScope/UsesParentScope.cmake | 3 + 9 files changed, 109 insertions(+), 10 deletions(-) create mode 100644 Tests/PolicyScope/IncludesUsesParentScope.cmake create mode 100644 Tests/PolicyScope/IncludesUsesParentScopeWithCMP0011New.cmake create mode 100644 Tests/PolicyScope/IncludesUsesParentScopeWithCMP0011Old.cmake create mode 100644 Tests/PolicyScope/UsesParentScope.cmake diff --git a/Source/cmCMakePolicyCommand.cxx b/Source/cmCMakePolicyCommand.cxx index 3ef6d35..5e249a5 100644 --- a/Source/cmCMakePolicyCommand.cxx +++ b/Source/cmCMakePolicyCommand.cxx @@ -65,9 +65,9 @@ bool cmCMakePolicyCommand //---------------------------------------------------------------------------- bool cmCMakePolicyCommand::HandleSetMode(std::vector const& args) { - if(args.size() != 3) + if(args.size() != 3 && args.size() != 4) { - this->SetError("SET must be given exactly 2 additional arguments."); + this->SetError("SET must be given 2-3 additional arguments."); return false; } @@ -88,7 +88,20 @@ bool cmCMakePolicyCommand::HandleSetMode(std::vector const& args) return false; } - if(!this->Makefile->SetPolicy(args[1].c_str(), status)) + bool include_parent = false; + if(args.size() == 4) + { + include_parent = true; + if (args[3] != "PARENT_SCOPE") + { + std::ostringstream e; + e << "SET given unexpected third argument \"" << args[3] << "\""; + this->SetError(e.str()); + return false; + } + } + + if(!this->Makefile->SetPolicy(args[1].c_str(), status, include_parent)) { this->SetError("SET failed to set policy."); return false; diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx index 57e33df..3859938 100644 --- a/Source/cmMakefile.cxx +++ b/Source/cmMakefile.cxx @@ -4791,7 +4791,8 @@ bool cmMakefile::PolicyOptionalWarningEnabled(std::string const& var) } bool cmMakefile::SetPolicy(const char *id, - cmPolicies::PolicyStatus status) + cmPolicies::PolicyStatus status, + bool include_parent) { cmPolicies::PolicyID pid; if (!cmPolicies::GetPolicyID(id, /* out */ pid)) @@ -4801,12 +4802,13 @@ bool cmMakefile::SetPolicy(const char *id, this->IssueMessage(cmake::FATAL_ERROR, e.str()); return false; } - return this->SetPolicy(pid,status); + return this->SetPolicy(pid,status,include_parent); } //---------------------------------------------------------------------------- bool cmMakefile::SetPolicy(cmPolicies::PolicyID id, - cmPolicies::PolicyStatus status) + cmPolicies::PolicyStatus status, + bool include_parent) { // A REQUIRED_ALWAYS policy may be set only to NEW. if(status != cmPolicies::NEW && @@ -4822,9 +4824,13 @@ bool cmMakefile::SetPolicy(cmPolicies::PolicyID id, // Update the policy stack from the top to the top-most strong entry. bool previous_was_weak = true; for(PolicyStackType::reverse_iterator psi = this->PolicyStack.rbegin(); - previous_was_weak && psi != this->PolicyStack.rend(); ++psi) + (previous_was_weak || include_parent) && psi != this->PolicyStack.rend(); ++psi) { psi->Set(id, status); + if (!previous_was_weak) + { + include_parent = false; + } previous_was_weak = psi->Weak; } diff --git a/Source/cmMakefile.h b/Source/cmMakefile.h index 7938fcc..44a47f5 100644 --- a/Source/cmMakefile.h +++ b/Source/cmMakefile.h @@ -318,8 +318,8 @@ public: /** * Set, Push, Pop policy values for CMake. */ - bool SetPolicy(cmPolicies::PolicyID id, cmPolicies::PolicyStatus status); - bool SetPolicy(const char *id, cmPolicies::PolicyStatus status); + bool SetPolicy(cmPolicies::PolicyID id, cmPolicies::PolicyStatus status, bool include_parent = false); + bool SetPolicy(const char *id, cmPolicies::PolicyStatus status, bool include_parent = false); cmPolicies::PolicyStatus GetPolicyStatus(cmPolicies::PolicyID id) const; bool SetPolicyVersion(const char *version); void RecordPolicies(cmPolicies::PolicyMap& pm); diff --git a/Tests/PolicyScope/CMakeLists.txt b/Tests/PolicyScope/CMakeLists.txt index 413195a..277b7cc 100644 --- a/Tests/PolicyScope/CMakeLists.txt +++ b/Tests/PolicyScope/CMakeLists.txt @@ -27,10 +27,12 @@ cmake_policy(GET CMP0003 cmp) check(CMP0003 "OLD" "${cmp}") cmake_policy(GET CMP0002 cmp) check(CMP0002 "NEW" "${cmp}") +cmake_policy(GET CMP0005 cmp) +check(CMP0005 "OLD" "${cmp}") cmake_policy(GET CMP0011 cmp) check(CMP0011 "NEW" "${cmp}") -# Make sure an included file cannot change policies. +# Make sure an included file does not change policies. include(Bar) cmake_policy(GET CMP0003 cmp) check(CMP0003 "OLD" "${cmp}") @@ -40,6 +42,75 @@ include(Bar NO_POLICY_SCOPE) cmake_policy(GET CMP0003 cmp) check(CMP0003 "NEW" "${cmp}") +cmake_policy(SET CMP0011 NEW) + +# NO_POLICY_SCOPE has no restrictions +cmake_policy(SET CMP0003 OLD) +cmake_policy(SET CMP0005 OLD) +include(UsesParentScope NO_POLICY_SCOPE) +cmake_policy(GET CMP0003 cmp) +check(CMP0003 "NEW" "${cmp}") +cmake_policy(GET CMP0005 cmp) +check(CMP0005 "NEW" "${cmp}") + +# Only PARENT_SCOPE changes propagate +cmake_policy(SET CMP0003 OLD) +cmake_policy(SET CMP0005 OLD) +include(UsesParentScope) +cmake_policy(GET CMP0003 cmp) +check(CMP0003 "OLD" "${cmp}") +cmake_policy(GET CMP0005 cmp) +check(CMP0005 "NEW" "${cmp}") + +# NO_POLICY_SCOPE allows PARENT_SCOPE changes from the inner include to propagate +cmake_policy(SET CMP0003 OLD) +cmake_policy(SET CMP0005 OLD) +include(IncludesUsesParentScope NO_POLICY_SCOPE) +cmake_policy(GET CMP0003 cmp) +check(CMP0003 "OLD" "${cmp}") +cmake_policy(GET CMP0005 cmp) +check(CMP0005 "NEW" "${cmp}") + +# No changes from the inner include to propagate +cmake_policy(SET CMP0003 OLD) +cmake_policy(SET CMP0005 OLD) +include(IncludesUsesParentScope) +cmake_policy(GET CMP0003 cmp) +check(CMP0003 "OLD" "${cmp}") +cmake_policy(GET CMP0005 cmp) +check(CMP0005 "OLD" "${cmp}") + +cmake_policy(SET CMP0011 OLD) + +# As if NO_POLICY_SCOPE was set (also applies to children) +cmake_policy(SET CMP0003 OLD) +cmake_policy(SET CMP0005 OLD) +include(IncludesUsesParentScope) +cmake_policy(GET CMP0003 cmp) +check(CMP0003 "NEW" "${cmp}") +cmake_policy(GET CMP0005 cmp) +check(CMP0005 "NEW" "${cmp}") + +# As if NO_POLICY_SCOPE was set (does not apply to children) +cmake_policy(SET CMP0003 OLD) +cmake_policy(SET CMP0005 OLD) +include(IncludesUsesParentScopeWithCMP0011New) +cmake_policy(GET CMP0003 cmp) +check(CMP0003 "OLD" "${cmp}") +cmake_policy(GET CMP0005 cmp) +check(CMP0005 "NEW" "${cmp}") + +cmake_policy(SET CMP0011 NEW) + +# As if NO_POLICY_SCOPE was set in child-level include +cmake_policy(SET CMP0003 OLD) +cmake_policy(SET CMP0005 OLD) +include(IncludesUsesParentScopeWithCMP0011Old) +cmake_policy(GET CMP0003 cmp) +check(CMP0003 "OLD" "${cmp}") +cmake_policy(GET CMP0005 cmp) +check(CMP0005 "NEW" "${cmp}") + #----------------------------------------------------------------------------- # Test function and macro policy recording. diff --git a/Tests/PolicyScope/FindFoo.cmake b/Tests/PolicyScope/FindFoo.cmake index 5b441e2..e7f8f9c 100644 --- a/Tests/PolicyScope/FindFoo.cmake +++ b/Tests/PolicyScope/FindFoo.cmake @@ -1,2 +1,3 @@ cmake_minimum_required(VERSION 2.6.3) cmake_policy(SET CMP0003 OLD) +cmake_policy(SET CMP0005 OLD PARENT_SCOPE) diff --git a/Tests/PolicyScope/IncludesUsesParentScope.cmake b/Tests/PolicyScope/IncludesUsesParentScope.cmake new file mode 100644 index 0000000..97a6d4c --- /dev/null +++ b/Tests/PolicyScope/IncludesUsesParentScope.cmake @@ -0,0 +1 @@ +include(UsesParentScope) diff --git a/Tests/PolicyScope/IncludesUsesParentScopeWithCMP0011New.cmake b/Tests/PolicyScope/IncludesUsesParentScopeWithCMP0011New.cmake new file mode 100644 index 0000000..5900c12 --- /dev/null +++ b/Tests/PolicyScope/IncludesUsesParentScopeWithCMP0011New.cmake @@ -0,0 +1,2 @@ +cmake_policy(SET CMP0011 NEW) +include(UsesParentScope) diff --git a/Tests/PolicyScope/IncludesUsesParentScopeWithCMP0011Old.cmake b/Tests/PolicyScope/IncludesUsesParentScopeWithCMP0011Old.cmake new file mode 100644 index 0000000..6b63d36 --- /dev/null +++ b/Tests/PolicyScope/IncludesUsesParentScopeWithCMP0011Old.cmake @@ -0,0 +1,2 @@ +cmake_policy(SET CMP0011 OLD) +include(UsesParentScope) diff --git a/Tests/PolicyScope/UsesParentScope.cmake b/Tests/PolicyScope/UsesParentScope.cmake new file mode 100644 index 0000000..4748033 --- /dev/null +++ b/Tests/PolicyScope/UsesParentScope.cmake @@ -0,0 +1,3 @@ +cmake_policy(SET CMP0003 NEW) +cmake_policy(SET CMP0005 NEW PARENT_SCOPE) + -- 2.4.6 From mantis at public.kitware.com Wed Jul 29 18:34:49 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 29 Jul 2015 18:34:49 -0400 Subject: [cmake-developers] [CMake 0015670]: Add support for setting "Windows target platform version" in VS2015 Message-ID: <8bb54f72cda03b946c4989ca4cfa955d@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15670 ====================================================================== Reported By: Christian Maaser Assigned To: ====================================================================== Project: CMake Issue ID: 15670 Category: CMake Reproducibility: always Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-29 18:34 EDT Last Modified: 2015-07-29 18:34 EDT ====================================================================== Summary: Add support for setting "Windows target platform version" in VS2015 Description: The MSVS generator currently does not support setting a new property introduced with MSVS2015: The "Windows target platform version". This property effectively selects the platform SDK to use, which is independent from the selected compiler/platform toolset. Steps to Reproduce: Use "Visual Studio 14 2015 [Win64]" generator and see how tag is missing in the generated .vcxproj files Additional Information: See attached screenshot showing the new setting. Here is a subset from a regular .vcxproj file which selects the recently released Windows 10 platform SDK version. ... MultiByte v140 10.0.10240.0 ... ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-29 18:34 Christian MaaserNew Issue 2015-07-29 18:34 Christian MaaserFile Added: targetplatformversion.png ====================================================================== From pascal.bach at siemens.com Thu Jul 30 04:54:01 2015 From: pascal.bach at siemens.com (Pascal Bach) Date: Thu, 30 Jul 2015 10:54:01 +0200 Subject: [cmake-developers] [PATCH 3/3] FindQt4: document cross compilation In-Reply-To: <1479278.oGgGttUGG9@stryke> References: <1438173168-24640-1-git-send-email-pascal.bach@siemens.com> <2329846.pno7VYBYh8@stryke> <55B8EA6D.5030705@siemens.com> <1479278.oGgGttUGG9@stryke> Message-ID: <55B9E629.2070403@siemens.com> Hi Clint, Hi Brad > What I want to avoid is users thinking that what you are proposing overrides > any other way of finding Qt when cross compiling. > > The wording you propose is "To find Qt in a cross compile environment set the > following variables" > However there are users for which setting only CMAKE_FIND_ROOT_PATH is enough. > Or setting CMAKE_FIND_ROOT_PATH plus QT_QMAKE_EXECUTABLE is enough. That sounds reasonable. > > Brad had a good question in another email. Can't you set QT_QMAKE_EXECUTABLE? > My guess, is no, because that qmake returns paths under one sysroot. Brads suggestion doesn't work as it again finds the native Qt version. I think the proper way might be for CMake to be aware of that one sysroot is native and the other one is for the target. so find_program would look in the native one and the other find_* functions would look in the target sysroot. I'm not sure how this could be achived? > I just realized something. Your use case is similar or the same to one I had > tested FindQt4 with. > > Your Qt appears to be prefixed under /sysroot/arm/usr, not /sysroot/arm. > > Can you include /sysroot/arm/usr in CMAKE_FIND_ROOT_PATH, then see if FindQt4 > can find your libraries under /sysroot/arm/usr. This doesn't seem to work it still only finds the native Qt Pascal From marc.chevrier at sap.com Thu Jul 30 05:32:22 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Thu, 30 Jul 2015 09:32:22 +0000 Subject: [cmake-developers] Java support In-Reply-To: <55B8D984.20800@kitware.com> References: <53C8DDC8-829D-4532-9F6D-B5391EF69208@sap.com> <3518298.4AC594tU3M@caliban.sf-tec.de> <6B37BC37-0442-492E-905A-8A184A04B587@sap.com> <55B8D984.20800@kitware.com> Message-ID: <56F5FC20-5B44-4000-8CFA-9CB6C4E7A122@sap.com> New version of patches taking into account Brad? remarks. Marc On 29/07/15 15:47, "Brad King" wrote: >On 07/29/2015 04:01 AM, CHEVRIER, Marc wrote: >> here is an updated list of patches. > >Great. > >> find_package_handle_standard_args(Java >> REQUIRED_VARS Java_JAVA_EXECUTABLE Java_JAR_EXECUTABLE Java_JAVAC_EXECUTABLE >> Java_JAVAH_EXECUTABLE Java_JAVADOC_EXECUTABLE >> + Java_IDLJ_EXECUTABLE Java_JARSIGNER_EXECUTABLE >> VERSION_VAR Java_VERSION >> ) > >Are idlj and jarsigner reliably available whenever the other tools are? >Even for older versions? Do these need to be REQUIRED_VARS? I'm >concerned this could make a case that previously found java not report >it found anymore. > >> - --build-project hello >> + --build-target hello > >The tests should still have --build-project as this corresponds to >the .sln file name in Visual Studio builds. The --build-target >option can be added in addition to it. > >Thanks, >-Brad > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-support-for-idlj-and-jarsigner-tools.patch Type: application/octet-stream Size: 5623 bytes Desc: 0001-Add-support-for-idlj-and-jarsigner-tools.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-add_jar-now-supports-file-syntax-for-sources.patch Type: application/octet-stream Size: 6120 bytes Desc: 0002-add_jar-now-supports-file-syntax-for-sources.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-install_jar-add-options-DESTINATION-and-COMPONENT.patch Type: application/octet-stream Size: 3564 bytes Desc: 0003-install_jar-add-options-DESTINATION-and-COMPONENT.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Add-support-for-javah-tool.patch Type: application/octet-stream Size: 9631 bytes Desc: 0004-Add-support-for-javah-tool.patch URL: From mantis at public.kitware.com Thu Jul 30 07:01:32 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 30 Jul 2015 07:01:32 -0400 Subject: [cmake-developers] [CMake 0015671]: cmake does not find _vsnprintf Message-ID: <7695f1e5cdec0aef1d5863404a3db918@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15671 ====================================================================== Reported By: beckmi Assigned To: ====================================================================== Project: CMake Issue ID: 15671 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-30 07:01 EDT Last Modified: 2015-07-30 07:01 EDT ====================================================================== Summary: cmake does not find _vsnprintf Description: I am using Visual Studio 2015 cmake 3.3 freetds-0.95.19 running cmake -G "NMake Makefiles" . does not find vsnprintf nor _vsnprintf Steps to Reproduce: Install Visual Studio 2015 Download freetds run cmake run nmake ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-30 07:01 beckmi New Issue ====================================================================== From gjasny at googlemail.com Thu Jul 30 07:38:55 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Thu, 30 Jul 2015 13:38:55 +0200 Subject: [cmake-developers] [CMake 0015669]: XCTest for iOS target has incorrect TEST_HOST In-Reply-To: <72ecaccafc8e24ee21f44c347aa7e5bc@www.cmake.org> References: <72ecaccafc8e24ee21f44c347aa7e5bc@www.cmake.org> Message-ID: <55BA0CCF.1040200@googlemail.com> Hello, On 29/07/15 14:07, Mantis Bug Tracker wrote: > ====================================================================== > http://www.cmake.org/Bug/view.php?id=15669 > ====================================================================== this bug caused by different App Bundle layout in MacOSX and iOS. Attached you'll find my proposed patch. Do you have a better idea to detect the usage of iphone/simulator SDK? Maybe we should handle this in the platform Darwin modules? Thanks, Gregor -------------- next part -------------- >From fdbef203172af5d5603de9383077fbb503661f3f Mon Sep 17 00:00:00 2001 From: Gregor Jasny Date: Thu, 30 Jul 2015 13:26:10 +0200 Subject: [PATCH] Fix iOS App Bundle layout In contrast to Mac OS X App bundle layout the iOS one lacks the Contents/MacOSX structure. See also the Bundle Structures documentation in Mac Developer Library: https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html --- Source/cmTarget.cxx | 26 +++++++++++++++++++++++--- Source/cmTarget.h | 3 +++ 2 files changed, 26 insertions(+), 3 deletions(-) diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx index cf33791..c39f9c0 100644 --- a/Source/cmTarget.cxx +++ b/Source/cmTarget.cxx @@ -632,6 +632,22 @@ bool cmTarget::IsBundleOnApple() const } //---------------------------------------------------------------------------- +bool cmTarget::IsIosSdkOnApple() const +{ + if (!this->IsApple) + { + return false; + } + + std::string sdkRoot; + sdkRoot = this->GetMakefile()->GetSafeDefinition("CMAKE_OSX_SYSROOT"); + sdkRoot = cmSystemTools::LowerCase(sdkRoot); + + return sdkRoot.find("iphoneos") == 0 || + sdkRoot.find("/iphoneos") != std::string::npos; +} + +//---------------------------------------------------------------------------- static bool processSources(cmTarget const* tgt, const std::vector &entries, std::vector &srcs, @@ -6707,9 +6723,13 @@ std::string cmTarget::GetAppBundleDirectory(const std::string& config, bool contentOnly) const { std::string fpath = this->GetFullName(config, false); - fpath += ".app/Contents"; - if(!contentOnly) - fpath += "/MacOS"; + fpath += ".app"; + if(!this->IsIosSdkOnApple()) + { + fpath += "/Contents"; + if(!contentOnly) + fpath += "/MacOS"; + } return fpath; } diff --git a/Source/cmTarget.h b/Source/cmTarget.h index f567d50..d383219 100644 --- a/Source/cmTarget.h +++ b/Source/cmTarget.h @@ -524,6 +524,9 @@ public: or CFBundle on Apple. */ bool IsBundleOnApple() const; + /** Return whether this target uses iOS SDK on Apple */ + bool IsIosSdkOnApple() const; + /** Return the framework version string. Undefined if IsFrameworkOnApple returns false. */ std::string GetFrameworkVersion() const; -- 2.4.3 From nilsgladitz at gmail.com Thu Jul 30 08:45:41 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 30 Jul 2015 14:45:41 +0200 Subject: [cmake-developers] CMAKE_MAP_IMPORTED_CONFIG_* missing implementation? Message-ID: <55BA1C75.4030208@gmail.com> I tried using http://www.cmake.org/cmake/help/v3.3/variable/CMAKE_MAP_IMPORTED_CONFIG_CONFIG.html in the following example: cmake_minimum_required(VERSION 3.3) project(Foo CXX) set(CMAKE_MAP_IMPORTED_CONFIG_RELWITHDEBINFO "Release") add_library(foo SHARED IMPORTED) get_property(VAR TARGET foo PROPERTY MAP_IMPORTED_CONFIG_RELWITHDEBINFO) message("[${VAR}]") When configuring this produces the output "[]" where I would expect "[Release]". Am I missing something obvious? Nils From brad.king at kitware.com Thu Jul 30 09:28:12 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 30 Jul 2015 09:28:12 -0400 Subject: [cmake-developers] [PATCH] cmCMakePolicyCommand: New PARENT_SCOPE argument In-Reply-To: <12318436.qfJba0PCz6@roku> References: <12318436.qfJba0PCz6@roku> Message-ID: <55BA266C.7040904@kitware.com> On 07/29/2015 03:58 PM, Alex Merry wrote: > This is intended to be used from a "settings file" which is applied to a > group of CMake projects. This allows the file to control which policies > means that users of the settings file are not forced to use NO_POLICY_SCOPE > (particularly important if the settings file did not originally have any > policy settings in it, but later acquired some). Policies should not be set from a central hub, especially without the explicit permission of the including project (via NO_POLICY_SCOPE). Setting policies centrally breaks their compatibility model. The whole point is that the old behavior is preserved (possibly with a warning) until the project whose code triggers the policy is modified to address it. By setting a policy on behalf of the project calling include() you could silence warnings about behavior changes or even introduce errors. Each project author needs a chance to see their own policy warnings and address them accordingly. -Brad From brad.king at kitware.com Thu Jul 30 09:28:20 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 30 Jul 2015 09:28:20 -0400 Subject: [cmake-developers] CMAKE_MAP_IMPORTED_CONFIG_* missing implementation? In-Reply-To: <55BA1C75.4030208@gmail.com> References: <55BA1C75.4030208@gmail.com> Message-ID: <55BA2674.90607@kitware.com> On 07/30/2015 08:45 AM, Nils Gladitz wrote: > Am I missing something obvious? It can only work for the configurations that CMake knows about. For single-config generators (Makefiles, Ninja) this is the value of CMAKE_BUILD_TYPE. For multi-config generators they are listed in CMAKE_CONFIGURATION_TYPES. -Brad From pascal.bach at siemens.com Thu Jul 30 09:29:03 2015 From: pascal.bach at siemens.com (Pascal Bach) Date: Thu, 30 Jul 2015 15:29:03 +0200 Subject: [cmake-developers] [PATCH 3/3] FindQt4: document cross compilation In-Reply-To: <55B9E629.2070403@siemens.com> References: <1438173168-24640-1-git-send-email-pascal.bach@siemens.com> <2329846.pno7VYBYh8@stryke> <55B8EA6D.5030705@siemens.com> <1479278.oGgGttUGG9@stryke> <55B9E629.2070403@siemens.com> Message-ID: <55BA269F.1030704@siemens.com> Hi again Am 30.07.2015 um 10:54 schrieb Pascal Bach: > Hi Clint, Hi Brad >> What I want to avoid is users thinking that what you are proposing overrides >> any other way of finding Qt when cross compiling. >> >> The wording you propose is "To find Qt in a cross compile environment set the >> following variables" >> However there are users for which setting only CMAKE_FIND_ROOT_PATH is enough. >> Or setting CMAKE_FIND_ROOT_PATH plus QT_QMAKE_EXECUTABLE is enough. > That sounds reasonable. >> Brad had a good question in another email. Can't you set QT_QMAKE_EXECUTABLE? >> My guess, is no, because that qmake returns paths under one sysroot. > Brads suggestion doesn't work as it again finds the native Qt version. > > I think the proper way might be for CMake to be aware of that one sysroot is native and the other one is for the target. > so find_program would look in the native one and the other find_* functions would look in the target sysroot. > > I'm not sure how this could be achived? I gave this some additional tought and maybe the soltuion would be to solve this on a lower level within CMake. Here is an idea: In additiona to CMAKE_SYSROOT we could add a CMAKE_HOST_SYSROOT. CMAKE_HOST_SYSROOT is by default set to the normal host path but could be changed in a case like we have for FindQt4. CMAKE_FIND_ROOT_PATH_MODE would then need to be extended to support something like NATIVE and TARGET that one could use to choose where to look for files. This way every find_* call could explicitly tell if it wants a host or a target version. find_program by defaul would prefer NATIVE while find_library etc. would prefer TARGET, but this could be changed per call if necessary. With this changes I think the implementation for FindQt4 and maybe others could be simplified. Also CMakeLists.txt for cross compiled projects would be easier. Would this be a feasible extension? PS: It looks kind of similar to what was done with CMAKE_APPBUNDLE_PATH for Mac OS X, but I haven't look deeper into how this works. Pascal From csiga.biga at aol.com Wed Jul 29 03:49:07 2015 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Wed, 29 Jul 2015 07:49:07 +0000 Subject: [cmake-developers] =?utf-8?q?CMake_IR?= Message-ID: Dear CMake devs/users, I wanted to ask your opinion on something that has been troubling me since? well, ever since I started using CMake. I have not found a single person alive who would have said: ?The script language of CMake is nice, intuitive and productive. Authoring scripts is easy, and writing custom macros is not difficult either.? There are gazillions of scripting languages one could have chosen for CMake (Python, Perl, Ruby, Powershell, Bash, etc.) that would allow developers to reuse existing skills, or learn one that is useful elsewhere, not just in terms of CMake. These languages have a lot of thought put into them. They are superior to CMake?s own in just about every regard. I came up with an idea presented here: http://1drv.ms/1MsufbF Enhancements such a change could bring about: The big selling point would be the ability to introduce arbitrary front-ends to CMake, not just CMakelists.txt. Every developer could choose an input language that suits their project/needs/skills. (It would also ease the custom implementations of cmake.exe itself in any language, but that is just a side-effect.) It would modularize the internals of CMake in a cleaner fashion Facilitate the introduction of new languages understood by CMake (such as work put into C# and Swift currently) Would allow for configure-time validating of compiler-specific options Use deferred makefile generation by default (making the implementation of tools like Cotire for precompiled headers trivial to implement, as well NMake batch mode, or detecting multiple/cyclic linkage, by making use of global information about the build process) Many features could automatically be reused by all generators. (Imagine Swift, and Fortran libraries being compiled as NuGet packages and publishing them without any hassle on user side, or having to implement anything in the XCode generator.) SIGNIFICANTLY increase interoperability with other tools. Implementing GUI front-ends (such as in CLion, or Visual Studio (work in progress)) are orders of magnitude simpler by generating a stateless IR, as opposed to generating a stateful script. While it is a refactor of the entire toolchain, it is something that could be done incrementally, with the existing parts functioning normally. I believe CMake is an invaluable tool, but it could do far better. 0/10 CMake users I?ve met say they are ?happy? CMake users. The learning curve is steep, and the skills gained are not reusable. CMake could gain even greater momentum (not by ditching, but) by offering alternate input languages with entities (classes, functions, macros, etc.) that feel natural in the given context. Initial feedback in my vicinity was favorable, even those with zealous CMake opposition aggreed this were something awesome to pull off (though they expressed their disbelief in Kitware and the community approving such a radical change). This mail along with the document only intends to get the ball rolling and hopefully manifest in something similar, starting with CMake 4.0 perhaps. Eagerly await the rolling ball. With all due respect, M?t? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Thu Jul 30 09:50:46 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 30 Jul 2015 15:50:46 +0200 Subject: [cmake-developers] CMAKE_MAP_IMPORTED_CONFIG_* missing implementation? In-Reply-To: <55BA2674.90607@kitware.com> References: <55BA1C75.4030208@gmail.com> <55BA2674.90607@kitware.com> Message-ID: <55BA2BB6.9030200@gmail.com> On 07/30/2015 03:28 PM, Brad King wrote: > On 07/30/2015 08:45 AM, Nils Gladitz wrote: >> Am I missing something obvious? > > It can only work for the configurations that CMake knows about. > For single-config generators (Makefiles, Ninja) this is the > value of CMAKE_BUILD_TYPE. For multi-config generators they > are listed in CMAKE_CONFIGURATION_TYPES. That makes perfect sense, thanks! Nils From marc.chevrier at sap.com Thu Jul 30 09:55:51 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Thu, 30 Jul 2015 13:55:51 +0000 Subject: [cmake-developers] Java support In-Reply-To: <56F5FC20-5B44-4000-8CFA-9CB6C4E7A122@sap.com> References: <53C8DDC8-829D-4532-9F6D-B5391EF69208@sap.com> <3518298.4AC594tU3M@caliban.sf-tec.de> <6B37BC37-0442-492E-905A-8A184A04B587@sap.com> <55B8D984.20800@kitware.com> <56F5FC20-5B44-4000-8CFA-9CB6C4E7A122@sap.com> Message-ID: I just detected a small error introduced in patch 0001, here is the correct version. Sorry for the noise... On 30/07/15 11:32, "cmake-developers on behalf of CHEVRIER, Marc" wrote: > >New version of patches taking into account Brad? remarks. > >Marc > > > > >On 29/07/15 15:47, "Brad King" wrote: > >>On 07/29/2015 04:01 AM, CHEVRIER, Marc wrote: >>> here is an updated list of patches. >> >>Great. >> >>> find_package_handle_standard_args(Java >>> REQUIRED_VARS Java_JAVA_EXECUTABLE Java_JAR_EXECUTABLE Java_JAVAC_EXECUTABLE >>> Java_JAVAH_EXECUTABLE Java_JAVADOC_EXECUTABLE >>> + Java_IDLJ_EXECUTABLE Java_JARSIGNER_EXECUTABLE >>> VERSION_VAR Java_VERSION >>> ) >> >>Are idlj and jarsigner reliably available whenever the other tools are? >>Even for older versions? Do these need to be REQUIRED_VARS? I'm >>concerned this could make a case that previously found java not report >>it found anymore. >> >>> - --build-project hello >>> + --build-target hello >> >>The tests should still have --build-project as this corresponds to >>the .sln file name in Visual Studio builds. The --build-target >>option can be added in addition to it. >> >>Thanks, >>-Brad >> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-support-for-idlj-and-jarsigner-tools.patch Type: application/octet-stream Size: 5618 bytes Desc: 0001-Add-support-for-idlj-and-jarsigner-tools.patch URL: From brad.king at kitware.com Thu Jul 30 10:03:41 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 30 Jul 2015 10:03:41 -0400 Subject: [cmake-developers] [CMake 0015669]: XCTest for iOS target has incorrect TEST_HOST In-Reply-To: <55BA0CCF.1040200@googlemail.com> References: <72ecaccafc8e24ee21f44c347aa7e5bc@www.cmake.org> <55BA0CCF.1040200@googlemail.com> Message-ID: <55BA2EBD.6000707@kitware.com> On 07/30/2015 07:38 AM, Gregor Jasny via cmake-developers wrote: > Do you have a better idea to detect the usage of iphone/simulator SDK? > Maybe we should handle this in the platform Darwin modules? This occurs when cross-compiling to iOS, so should we check for CMAKE_SYSTEM_NAME set to "iOS"? There is already code to do this for Android. -Brad From brad.king at kitware.com Thu Jul 30 10:49:07 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 30 Jul 2015 10:49:07 -0400 Subject: [cmake-developers] Java support In-Reply-To: References: <53C8DDC8-829D-4532-9F6D-B5391EF69208@sap.com> <3518298.4AC594tU3M@caliban.sf-tec.de> <6B37BC37-0442-492E-905A-8A184A04B587@sap.com> <55B8D984.20800@kitware.com> <56F5FC20-5B44-4000-8CFA-9CB6C4E7A122@sap.com> Message-ID: <55BA3963.9080909@kitware.com> On 07/30/2015 09:55 AM, CHEVRIER, Marc wrote: > here is the correct version. Thanks. The component name "Extra" sounds too generic and we won't be able to extend it in the future with other "extra" parts for the same reason these tools could not be made part of Development. Perhaps instead we should have components named IdlJ and JarSigner that applications can use to enforce that they are found. Thanks, -Brad From brad.king at kitware.com Thu Jul 30 10:56:02 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 30 Jul 2015 10:56:02 -0400 Subject: [cmake-developers] [PATCH 3/3] FindQt4: document cross compilation In-Reply-To: <55BA269F.1030704@siemens.com> References: <1438173168-24640-1-git-send-email-pascal.bach@siemens.com> <2329846.pno7VYBYh8@stryke> <55B8EA6D.5030705@siemens.com> <1479278.oGgGttUGG9@stryke> <55B9E629.2070403@siemens.com> <55BA269F.1030704@siemens.com> Message-ID: <55BA3B02.4020306@kitware.com> On 07/30/2015 09:29 AM, Pascal Bach wrote: > CMAKE_FIND_ROOT_PATH_MODE would then need to be extended to support > something like NATIVE and TARGET that one could use to choose where > to look for files. > This way every find_* call could explicitly tell if it wants a host > or a target version. Are you proposing new keyword arguments to find_* commands to specify this? The problem is that find modules don't necessarily know which kind of binary the application wants. That is why we have the CMAKE_FIND_ROOT_PATH_MODE_ variables. The existing CMAKE_FIND_ROOT_PATH* and CMAKE_SYSROOT options have been sufficient for most packages for a long time. We regularly get complaints that FindPythonLibs does not ask the python executable where to get its libraries, and our answer every time is that it is wrong to do that for cross compiling. FindQt4 is making that mistake, and that is the cause of these troubles. FindQt4 should be taught not to ask qmake for anything when cross compiling. -Brad From brad.king at kitware.com Thu Jul 30 10:56:18 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 30 Jul 2015 10:56:18 -0400 Subject: [cmake-developers] Modules/GetPrequisites.cmake issues In-Reply-To: <55B904A1.5030001@classdesign.com> References: <55B7FBDF.6020504@classdesign.com> <55B8D70A.6000304@kitware.com> <55B904A1.5030001@classdesign.com> Message-ID: <55BA3B12.5030707@kitware.com> On 07/29/2015 12:51 PM, Bill Somerville wrote: > Revised patches attached. Thanks! Applied: GetPrerequisites: Add error checks for execute_process() calls http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=35626e57 GetPrerequisites: Optionally filter "objdump" output for speed http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f01a8823 -Brad From mantis at public.kitware.com Thu Jul 30 10:59:35 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 30 Jul 2015 10:59:35 -0400 Subject: [cmake-developers] [CMake 0015672]: XCode project broken since cmake 3.3.0 Message-ID: <28369fe95c8170aab5d6b59a3a0e2655@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15672 ====================================================================== Reported By: A. Klitzing Assigned To: ====================================================================== Project: CMake Issue ID: 15672 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-30 10:59 EDT Last Modified: 2015-07-30 10:59 EDT ====================================================================== Summary: XCode project broken since cmake 3.3.0 Description: We use cmake to build our application for iOS. If we try the same workflow with cmake 3.3.0 we get this error: $ cmakexbuild -target install 2015-07-30 16:41:03.453 xcodebuild[47660:18383918] CFPropertyListCreateFromXMLData(): Old-style plist parser: missing semicolon in dictionary on line 1381. Parsing will be abandoned. Break on _CFPropertyListMissingSemicolon to debug. 2015-07-30 16:41:03.458 xcodebuild[47660:18383918] CFPropertyListCreateFromXMLData(): Old-style plist parser: missing semicolon in dictionary on line 1381. Parsing will be abandoned. Break on _CFPropertyListMissingSemicolon to debug. 2015-07-30 16:41:03.459 xcodebuild[47660:18383918] The data couldn?t be read because it isn?t in the correct format. xcodebuild: error: Unable to read project 'XXX.xcodeproj'. Reason: Project /tmp/build/XXX.xcodeproj cannot be opened because the project file cannot be parsed. The same workflow works with cmake 3.0.x - 3.2.x! Steps to Reproduce: 1. cmake ../XXX/ -DCMAKE_PREFIX_PATH=/tmp/thirdparty -DCMAKE_TOOLCHAIN_FILE=../XXX/cmake/iOS.toolchain.cmake -GXcode 2. cmakexbuild -target install Toolchain file: https://code.google.com/p/ios-cmake/source/browse/toolchain/iOS.cmake Additional Information: Line 1380 - 1382 of project.pbxproj 1380 2525E3626D4B43E89F8019E3 /* /tmp/XXX/resources/images/iOS/appIcons/icon29x29 at 2x.png */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = image; na me = "icon29x29 at 2x.png"; path = "resources/images/iOS/appIcons/icon29x29 at 2x.png"; sourceTree = SOURCE_ROOT; }; 1381 254B9DCBBC4947269D39ACED /* /tmp/XXX/resources/images/iOS/appIcons/icon29x29~ipad.png */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = image; name = icon29x29~ipad.png; path = resources/images/iOS/appIcons/icon29x29~ipad.png; sourceTree = SOURCE_ROOT; }; 1382 268D04D278914C12AE277A44 /* /tmp/XXX/resources/images/iOS/appIcons/icon40x40 at 2x~ipad.png */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = imag e; name = "icon40x40 at 2x~ipad.png"; path = "resources/images/iOS/appIcons/icon40x40 at 2x~ipad.png"; sourceTree = SOURCE_ROOT; }; ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-30 10:59 A. Klitzing New Issue ====================================================================== From clinton at elemtech.com Thu Jul 30 11:20:54 2015 From: clinton at elemtech.com (Clinton Stimpson) Date: Thu, 30 Jul 2015 09:20:54 -0600 Subject: [cmake-developers] [PATCH 3/3] FindQt4: document cross compilation In-Reply-To: <55BA3B02.4020306@kitware.com> References: <1438173168-24640-1-git-send-email-pascal.bach@siemens.com> <55BA269F.1030704@siemens.com> <55BA3B02.4020306@kitware.com> Message-ID: <1470314.NGWSVPbsZv@stryke> On Thursday, July 30, 2015 10:56:02 AM Brad King wrote: > On 07/30/2015 09:29 AM, Pascal Bach wrote: > > CMAKE_FIND_ROOT_PATH_MODE would then need to be extended to support > > something like NATIVE and TARGET that one could use to choose where > > to look for files. > > This way every find_* call could explicitly tell if it wants a host > > or a target version. > > Are you proposing new keyword arguments to find_* commands to specify > this? The problem is that find modules don't necessarily know which > kind of binary the application wants. That is why we have the > CMAKE_FIND_ROOT_PATH_MODE_ variables. > > The existing CMAKE_FIND_ROOT_PATH* and CMAKE_SYSROOT options have been > sufficient for most packages for a long time. We regularly get > complaints that FindPythonLibs does not ask the python executable > where to get its libraries, and our answer every time is that it is > wrong to do that for cross compiling. FindQt4 is making that mistake, > and that is the cause of these troubles. > > FindQt4 should be taught not to ask qmake for anything when cross > compiling. FindQt4 supports 2 use cases when cross compiling. 1. One Qt installation with a mix of native and non-native files. 2. Two Qt installations, one native and one non-native. In this case, qmake may still be queried to find other tools, but CMAKE_FIND_ROOT_PATH is used to find the non-native includes and libraries. The second case is what you are asking for, right? This why I previously suggested changing from SET(CMAKE_FIND_ROOT_PATH /sysroot/arm ...) to SET(CMAKE_FIND_ROOT_PATH /sysroot/arm/usr ...) Because its a find root, not a sysroot. Clint From JamesJ at motionview3d.com Thu Jul 30 11:57:34 2015 From: JamesJ at motionview3d.com (James Johnston) Date: Thu, 30 Jul 2015 15:57:34 -0000 Subject: [cmake-developers] [PATCH] string: State return value if string(FIND) doesn't find a match Message-ID: <07b501d0cae0$73515720$59f40560$@motionview3d.com> Very minor documentation update clarifying what happens if string(FIND) doesn't find a match. I had to make a CMake test script and/or check CMake source code to find the answer. Best regards, James Johnston -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-string-State-return-value-if-string-FIND-doesn-t-fin.patch Type: application/octet-stream Size: 916 bytes Desc: not available URL: From mantis at public.kitware.com Thu Jul 30 11:58:40 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 30 Jul 2015 11:58:40 -0400 Subject: [cmake-developers] [CMake 0015673]: CMAKE_C_COMPILER is used to link a CXX shared library on Solaris Message-ID: <784127324bb683c25f9c993c5e50a6f0@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15673 ====================================================================== Reported By: Xan L?pez Assigned To: ====================================================================== Project: CMake Issue ID: 15673 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-07-30 11:58 EDT Last Modified: 2015-07-30 11:58 EDT ====================================================================== Summary: CMAKE_C_COMPILER is used to link a CXX shared library on Solaris Description: The SunOS.cmake file has the following: if(CMAKE_COMPILER_IS_GNUCXX) if(CMAKE_COMPILER_IS_GNUCC) set(CMAKE_CXX_CREATE_SHARED_LIBRARY " -o ") The end result is that CMAKE_C_COMPILER (gcc) is used to link C++ shared libraries in Solaris. This results in numerous errors. I assume this is just a typo, and the attached patch just fixes things for me. This can be reproduced 100% of the time trying to compile LLVM/clang from SVN HEAD, LTO and clang libs will fail to compile. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-30 11:58 Xan L?pez New Issue 2015-07-30 11:58 Xan L?pez File Added: 0001-SunOS-use-CXX-compiler-to-link-CXX-shared-libraries.patch ====================================================================== From aleixpol at kde.org Thu Jul 30 11:59:50 2015 From: aleixpol at kde.org (Aleix Pol) Date: Thu, 30 Jul 2015 17:59:50 +0200 Subject: [cmake-developers] Linked library paths Message-ID: Hi, I need to get the linked libraries of a target. I was moving the code away from get_target_property to generator expressions that should get into a generated file, although I haven't managed yet. Is there any possibility to do that already? I've been thinking of adding something like a map function, so we can turn the target name we get from INTERFACE_LINK_LIBRARIES into a path, using the LOCATION property. Would that make sense? Otherwise, is it possible to properly get a function called right before cmake generation? Thanks, Aleix From rleigh at codelibre.net Thu Jul 30 11:23:03 2015 From: rleigh at codelibre.net (Roger Leigh) Date: Thu, 30 Jul 2015 16:23:03 +0100 Subject: [cmake-developers] [patch] Export template instantiations with GenerateExportHeader Message-ID: <55BA4157.3060406@codelibre.net> See attached patch. This is following the recommendations here: https://support.microsoft.com/en-us/kb/168958 While the existing foo_EXPORT provided by GenerateExportHeader is fine for use in exporting functions and classes, it isn't apparently sufficient for template export. This is needed, for example, if you wish to use templated types in exported classes as members. In this case you need to use "extern" when importing the exported template, and this requires a second macro. For example, to export std::string and std::vector: foo_EXPORT_TEMPLATE template class foo_EXPORT std::allocator; foo_EXPORT_TEMPLATE template class foo_EXPORT std::basic_string, std::allocator >; foo_EXPORT_TEMPLATE template class foo_EXPORT std::allocator, std::allocator > >; foo_EXPORT_TEMPLATE template class foo_EXPORT std::vector, std::allocator >, std::allocator, std::allocator > > >; With this done, it can then be used in an exported class: class foo_EXPORT foo { std::vector val; public: foo(); std::vector const& getval() const; }; Note that I'm by no means a Windows C++ or DLL expert--I'm primarily a C++ UNIX developer--this is just from reading the docs and experimenting. An example project making use of this is here: https://github.com/rleigh-dundee/dlltest (with unpatched cmake--I create the macros after using the generated export header) Regards, Roger -------------- next part -------------- From 19b63c2b3f89c44ccfe5f0b7e7ef8aa2ea6377a1 Mon Sep 17 00:00:00 2001 From: Roger Leigh Date: Thu, 30 Jul 2015 15:47:38 +0100 Subject: [PATCH] GenerateExportHeader: Add EXPORT_TEMPLATE macro In addition to the foo_EXPORT macro, a foo_EXPORT_TEMPLATE macro is also generated. This is to allow for explicit export of templates in Windows DLLs following Microsoft's guidance here: https://support.microsoft.com/en-us/kb/168958 --- Modules/exportheader.cmake.in | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Modules/exportheader.cmake.in b/Modules/exportheader.cmake.in index 118de16..f442e98 100644 --- a/Modules/exportheader.cmake.in +++ b/Modules/exportheader.cmake.in @@ -4,15 +4,18 @@ #ifdef @STATIC_DEFINE@ # define @EXPORT_MACRO_NAME@ +# define @EXPORT_MACRO_NAME at _TEMPLATE # define @NO_EXPORT_MACRO_NAME@ #else # ifndef @EXPORT_MACRO_NAME@ # ifdef @EXPORT_IMPORT_CONDITION@ /* We are building this library */ # define @EXPORT_MACRO_NAME@ @DEFINE_EXPORT@ +# define @EXPORT_MACRO_NAME at _TEMPLATE # else /* We are using this library */ # define @EXPORT_MACRO_NAME@ @DEFINE_IMPORT@ +# define @EXPORT_MACRO_NAME at _TEMPLATE extern # endif # endif -- 2.5.0 From mantis at public.kitware.com Thu Jul 30 12:36:02 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 30 Jul 2015 12:36:02 -0400 Subject: [cmake-developers] [CMake 0015674]: Windows: Correctly determine Windows version for CMAKE_HOST_SYSTEM_VERSION Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15674 ====================================================================== Reported By: Christian Maaser Assigned To: ====================================================================== Project: CMake Issue ID: 15674 Category: CMake Reproducibility: always Severity: minor Priority: low Status: new ====================================================================== Date Submitted: 2015-07-30 12:36 EDT Last Modified: 2015-07-30 12:36 EDT ====================================================================== Summary: Windows: Correctly determine Windows version for CMAKE_HOST_SYSTEM_VERSION Description: cmake is currently using the deprecated Windows API function GetVersionEx, which reports wrong information for versions later than WindowsXP. Instead, cmake should make use of RtlGetVersion, which works as expected on all versions of Windows (since Windows 2000). Steps to Reproduce: Compare ${CMAKE_HOST_SYSTEM_VERSION} with the output of the "ver" console command. Additional Information: https://msdn.microsoft.com/en-us/library/windows/desktop/ms724451(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/hardware/ff561910(v=vs.85).aspx ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-07-30 12:36 Christian MaaserNew Issue ====================================================================== From brad.king at kitware.com Thu Jul 30 13:34:27 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 30 Jul 2015 13:34:27 -0400 Subject: [cmake-developers] [patch] Export template instantiations with GenerateExportHeader In-Reply-To: <55BA4157.3060406@codelibre.net> References: <55BA4157.3060406@codelibre.net> Message-ID: <55BA6023.7080400@kitware.com> On 07/30/2015 11:23 AM, Roger Leigh wrote: > foo_EXPORT_TEMPLATE template class foo_EXPORT std::allocator; [snip] > # ifdef @EXPORT_IMPORT_CONDITION@ > /* We are building this library */ > # define @EXPORT_MACRO_NAME@ @DEFINE_EXPORT@ > +# define @EXPORT_MACRO_NAME at _TEMPLATE > # else > /* We are using this library */ > # define @EXPORT_MACRO_NAME@ @DEFINE_IMPORT@ > +# define @EXPORT_MACRO_NAME at _TEMPLATE extern > # endif [snip] > Note that I'm by no means a Windows C++ or DLL expert--I'm primarily a > C++ UNIX developer--this is just from reading the docs and experimenting. The problem with this approach is that the non-extern explicit template instantiation should not be done in the header file because if more than one source file in a single library includes the header then each of those object files will provide the explicit instantiation. Only one source should provide the symbols. So, one actually wants the "extern" to appear in the header file in all cases except when included in *one* specific source file within the library. For this there needs to be an identifying macro associated with the source file. Therefore it does not make sense for this macro to be defined as part of GenerateExportHeader because that generates macros that switch off of library-level conditions. -Brad From brad.king at kitware.com Thu Jul 30 13:35:40 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 30 Jul 2015 13:35:40 -0400 Subject: [cmake-developers] [PATCH] string: State return value if string(FIND) doesn't find a match In-Reply-To: <07b501d0cae0$73515720$59f40560$@motionview3d.com> References: <07b501d0cae0$73515720$59f40560$@motionview3d.com> Message-ID: <55BA606C.2080803@kitware.com> On 07/30/2015 11:57 AM, James Johnston wrote: > Very minor documentation update clarifying what happens if string(FIND) > doesn't find a match. I had to make a CMake test script and/or check CMake > source code to find the answer. Applied, thanks: Help: Document string(FIND) return value when no match is found http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe2e503e -Brad From rleigh at codelibre.net Thu Jul 30 17:17:49 2015 From: rleigh at codelibre.net (Roger Leigh) Date: Thu, 30 Jul 2015 22:17:49 +0100 Subject: [cmake-developers] [patch] Export template instantiations with GenerateExportHeader In-Reply-To: <55BA6023.7080400@kitware.com> References: <55BA4157.3060406@codelibre.net> <55BA6023.7080400@kitware.com> Message-ID: <55BA947D.5000409@codelibre.net> On 30/07/2015 18:34, Brad King wrote: > On 07/30/2015 11:23 AM, Roger Leigh wrote: >> foo_EXPORT_TEMPLATE template class foo_EXPORT std::allocator; > [snip] >> # ifdef @EXPORT_IMPORT_CONDITION@ >> /* We are building this library */ >> # define @EXPORT_MACRO_NAME@ @DEFINE_EXPORT@ >> +# define @EXPORT_MACRO_NAME at _TEMPLATE >> # else >> /* We are using this library */ >> # define @EXPORT_MACRO_NAME@ @DEFINE_IMPORT@ >> +# define @EXPORT_MACRO_NAME at _TEMPLATE extern >> # endif > [snip] >> Note that I'm by no means a Windows C++ or DLL expert--I'm primarily a >> C++ UNIX developer--this is just from reading the docs and experimenting. > > The problem with this approach is that the non-extern explicit > template instantiation should not be done in the header file > because if more than one source file in a single library includes > the header then each of those object files will provide the > explicit instantiation. Only one source should provide the symbols. > > So, one actually wants the "extern" to appear in the header > file in all cases except when included in *one* specific > source file within the library. For this there needs to > be an identifying macro associated with the source file. > Therefore it does not make sense for this macro to be defined > as part of GenerateExportHeader because that generates macros > that switch off of library-level conditions. This is where my knowledge of Windows linking falls short. Are the duplicated template exports here at the level of the translation unit not elided when linking the DLL? In the dlltest git repo, I specifically create DLLs with duplicate template exports in different translation units to make sure it doesn't error out, and it appears to cope. I haven't checked on whether it removed duplicates from the linked objects though--is this even possible? I thought all current toolchains were able to eliminate duplicate instantiations, or else you'd have massive explosions of duplicate templates common across all translation units. Given the backwardness of the Windows linker, it wouldn't surprise me if it were true though... Regards, Roger From marc.chevrier at sap.com Fri Jul 31 04:08:47 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Fri, 31 Jul 2015 08:08:47 +0000 Subject: [cmake-developers] Java support In-Reply-To: <55BA3963.9080909@kitware.com> References: <53C8DDC8-829D-4532-9F6D-B5391EF69208@sap.com> <3518298.4AC594tU3M@caliban.sf-tec.de> <6B37BC37-0442-492E-905A-8A184A04B587@sap.com> <55B8D984.20800@kitware.com> <56F5FC20-5B44-4000-8CFA-9CB6C4E7A122@sap.com> <55BA3963.9080909@kitware.com> Message-ID: OK. New version of patches. There is now a component per extra tool (for now IdlJ and JarSigner as suggested by Brad) to ensure future extensibility. Marc On 30/07/15 16:49, "Brad King" wrote: >On 07/30/2015 09:55 AM, CHEVRIER, Marc wrote: >> here is the correct version. > >Thanks. The component name "Extra" sounds too generic and we won't >be able to extend it in the future with other "extra" parts for the >same reason these tools could not be made part of Development. >Perhaps instead we should have components named IdlJ and JarSigner >that applications can use to enforce that they are found. > >Thanks, >-Brad > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-support-for-idlj-and-jarsigner-tools.patch Type: application/octet-stream Size: 5650 bytes Desc: 0001-Add-support-for-idlj-and-jarsigner-tools.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-add_jar-now-supports-file-syntax-for-sources.patch Type: application/octet-stream Size: 6120 bytes Desc: 0002-add_jar-now-supports-file-syntax-for-sources.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-install_jar-add-options-DESTINATION-and-COMPONENT.patch Type: application/octet-stream Size: 3564 bytes Desc: 0003-install_jar-add-options-DESTINATION-and-COMPONENT.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Add-support-for-javah-tool.patch Type: application/octet-stream Size: 9631 bytes Desc: 0004-Add-support-for-javah-tool.patch URL: From pascal.bach at siemens.com Fri Jul 31 05:47:48 2015 From: pascal.bach at siemens.com (Pascal Bach) Date: Fri, 31 Jul 2015 11:47:48 +0200 Subject: [cmake-developers] [PATCH 3/3] FindQt4: document cross compilation In-Reply-To: <1470314.NGWSVPbsZv@stryke> References: <1438173168-24640-1-git-send-email-pascal.bach@siemens.com> <55BA269F.1030704@siemens.com> <55BA3B02.4020306@kitware.com> <1470314.NGWSVPbsZv@stryke> Message-ID: <55BB4444.4070207@siemens.com> Am 30.07.2015 um 17:20 schrieb Clinton Stimpson: > On Thursday, July 30, 2015 10:56:02 AM Brad King wrote: >> On 07/30/2015 09:29 AM, Pascal Bach wrote: >>> CMAKE_FIND_ROOT_PATH_MODE would then need to be extended to support >>> something like NATIVE and TARGET that one could use to choose where >>> to look for files. >>> This way every find_* call could explicitly tell if it wants a host >>> or a target version. >> Are you proposing new keyword arguments to find_* commands to specify >> this? The problem is that find modules don't necessarily know which >> kind of binary the application wants. That is why we have the >> CMAKE_FIND_ROOT_PATH_MODE_ variables. >> >> The existing CMAKE_FIND_ROOT_PATH* and CMAKE_SYSROOT options have been >> sufficient for most packages for a long time. We regularly get >> complaints that FindPythonLibs does not ask the python executable >> where to get its libraries, and our answer every time is that it is >> wrong to do that for cross compiling. FindQt4 is making that mistake, >> and that is the cause of these troubles. >> >> FindQt4 should be taught not to ask qmake for anything when cross >> compiling. > FindQt4 supports 2 use cases when cross compiling. > > 1. One Qt installation with a mix of native and non-native files. > > 2. Two Qt installations, one native and one non-native. In this case, qmake > may still be queried to find other tools, but CMAKE_FIND_ROOT_PATH is used to > find the non-native includes and libraries. > > The second case is what you are asking for, right? Yes case 2 is exactly what Yocto does, one qt-native and one qt-target. There might also be a third installation from the host machine (installed via apt-get for example). I need to check if I can modify FindQt4 to not use qmake for libary and header finding if CROSS_COMPILING is set. But just rely on plain find_* commands. > > This why I previously suggested changing > from > SET(CMAKE_FIND_ROOT_PATH /sysroot/arm ...) > to > SET(CMAKE_FIND_ROOT_PATH /sysroot/arm/usr ...) I could not get this to work. It seems that the variables returned by qmake take priority over everything else. Pascal > > Because its a find root, not a sysroot. > From radovan.bast at gmail.com Fri Jul 31 07:14:22 2015 From: radovan.bast at gmail.com (Radovan Bast) Date: Fri, 31 Jul 2015 11:14:22 +0000 Subject: [cmake-developers] cmake-3.3.0-Linux-x86_64.tar.gz on download page is not gzipped Message-ID: dear all, the cmake-3.3.0-Linux-x86_64.tar.gz on http://www.cmake.org/download/ is not gzipped. this confused me a bit since "tar xvzf" complained. of course it can be extracted still but i think it would be good to replace it by the compressed one. thank you and best wishes, radovan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Jul 31 09:09:20 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 31 Jul 2015 09:09:20 -0400 Subject: [cmake-developers] [patch] Export template instantiations with GenerateExportHeader In-Reply-To: <55BA947D.5000409@codelibre.net> References: <55BA4157.3060406@codelibre.net> <55BA6023.7080400@kitware.com> <55BA947D.5000409@codelibre.net> Message-ID: <55BB7380.9080309@kitware.com> On 07/30/2015 05:17 PM, Roger Leigh wrote: > Are the duplicated template exports here at the level of the translation > unit not elided when linking the DLL? In the dlltest git repo, I > specifically create DLLs with duplicate template exports in different > translation units to make sure it doesn't error out, and it appears to > cope. I haven't checked on whether it removed duplicates from the > linked objects though--is this even possible? I thought all current > toolchains were able to eliminate duplicate instantiations, or else > you'd have massive explosions of duplicate templates common across all > translation units. Given the backwardness of the Windows linker, it > wouldn't surprise me if it were true though... I'm not an expert on the MS linker, but at least some toolchains treat implicit template instantiations as weak (W) symbols and explicit template instantiations as normal (T) symbols. Linkers will resolve duplicate W symbols but allow only one T symbol. Regardless, it is inefficient to ask the compiler to repeatedly do an explicit instantiation when only one is needed. I've seen projects that keep each explicit instantiation in a dedicated translation unit so that when one .o is needed for its instantiation it doesn't force bringing in a bunch of other instantiations from the same object. With the instantiate-in-header approach then all the objects in your library will instantiate all the templates whose headers they include. If the header always does the "extern" explicit instantiation then the compiler does not need to do the instantiation in any of the objects except the dedicated one. -Brad From brad.king at kitware.com Fri Jul 31 09:09:56 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 31 Jul 2015 09:09:56 -0400 Subject: [cmake-developers] cmake-3.3.0-Linux-x86_64.tar.gz on download page is not gzipped In-Reply-To: References: Message-ID: <55BB73A4.70207@kitware.com> On 07/31/2015 07:14 AM, Radovan Bast wrote: > the cmake-3.3.0-Linux-x86_64.tar.gz > on http://www.cmake.org/download/ > is not gzipped. Yes, it is. From a shell on the hosting server: $ file cmake-3.3.0-Linux-x86_64.tar.gz cmake-3.3.0-Linux-x86_64.tar.gz: gzip compressed data, ... $ shasum -a 256 cmake-3.3.0-Linux-x86_64.tar.gz 25d1f60cec20c89d7a8d6aa608af8766bd2f7de978ae5f2ae1e67641bdd1b8ed cmake-3.3.0-Linux-x86_64.tar.gz I think some browsers or other download tools may automatically gunzip files during download. -Brad From radovan.bast at gmail.com Fri Jul 31 09:11:50 2015 From: radovan.bast at gmail.com (Radovan Bast) Date: Fri, 31 Jul 2015 13:11:50 +0000 Subject: [cmake-developers] cmake-3.3.0-Linux-x86_64.tar.gz on download page is not gzipped In-Reply-To: <55BB73A4.70207@kitware.com> References: <55BB73A4.70207@kitware.com> Message-ID: thanks Brad! interesting. sorry for the noise. best wishes, radovan On Fri, Jul 31, 2015 at 3:09 PM Brad King wrote: > On 07/31/2015 07:14 AM, Radovan Bast wrote: > > the cmake-3.3.0-Linux-x86_64.tar.gz > > on http://www.cmake.org/download/ > > is not gzipped. > > Yes, it is. From a shell on the hosting server: > > $ file cmake-3.3.0-Linux-x86_64.tar.gz > cmake-3.3.0-Linux-x86_64.tar.gz: gzip compressed data, ... > > $ shasum -a 256 cmake-3.3.0-Linux-x86_64.tar.gz > 25d1f60cec20c89d7a8d6aa608af8766bd2f7de978ae5f2ae1e67641bdd1b8ed > cmake-3.3.0-Linux-x86_64.tar.gz > > I think some browsers or other download tools may automatically > gunzip files during download. > > -Brad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From radovan.bast at gmail.com Fri Jul 31 09:51:14 2015 From: radovan.bast at gmail.com (Radovan Bast) Date: Fri, 31 Jul 2015 13:51:14 +0000 Subject: [cmake-developers] cmake-3.3.0-Linux-x86_64.tar.gz on download page is not gzipped In-Reply-To: References: <55BB73A4.70207@kitware.com> Message-ID: Indeed a Chrome version that I have installed today does that to my surprise. Auto-unpacks during download but keeps the suffix. I would like to ask why but this is not the right list :-) Thanks again for the clarification! radovan On Fri, Jul 31, 2015 at 3:11 PM Radovan Bast wrote: > thanks Brad! interesting. sorry for the noise. > best wishes, > radovan > > On Fri, Jul 31, 2015 at 3:09 PM Brad King wrote: > >> On 07/31/2015 07:14 AM, Radovan Bast wrote: >> > the cmake-3.3.0-Linux-x86_64.tar.gz >> > on http://www.cmake.org/download/ >> > is not gzipped. >> >> Yes, it is. From a shell on the hosting server: >> >> $ file cmake-3.3.0-Linux-x86_64.tar.gz >> cmake-3.3.0-Linux-x86_64.tar.gz: gzip compressed data, ... >> >> $ shasum -a 256 cmake-3.3.0-Linux-x86_64.tar.gz >> 25d1f60cec20c89d7a8d6aa608af8766bd2f7de978ae5f2ae1e67641bdd1b8ed >> cmake-3.3.0-Linux-x86_64.tar.gz >> >> I think some browsers or other download tools may automatically >> gunzip files during download. >> >> -Brad >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Fri Jul 31 09:54:45 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 31 Jul 2015 15:54:45 +0200 Subject: [cmake-developers] cmake-3.3.0-Linux-x86_64.tar.gz on download page is not gzipped In-Reply-To: <55BB73A4.70207@kitware.com> References: <55BB73A4.70207@kitware.com> Message-ID: <55BB7E25.7080905@gmail.com> On 07/31/2015 03:09 PM, Brad King wrote: > I think some browsers or other download tools may automatically > gunzip files during download. I seem to get that with Chromium too. The HTTP response for cmake-3.3.0.tar.gz does contain: Content-Encoding: x-gzip Which I think does tell clients that they should decompress to get the actual content which is declared to be of Content-Type:"application/x-gzip"; this is I think incorrect unless the HTTP server compresses the .tar.gz once more with gzip before delivery. For cmake-3.3.0.zip of "Content-Type: application/zip" there is no "Content-Encoding" field in the HTTP response. Maybe other clients have workarounds for these kinds of errors? Nils From brad.king at kitware.com Fri Jul 31 10:48:18 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 31 Jul 2015 10:48:18 -0400 Subject: [cmake-developers] Linked library paths In-Reply-To: References: Message-ID: <55BB8AB2.7060906@kitware.com> On 07/30/2015 11:59 AM, Aleix Pol wrote: > I need to get the linked libraries of a target. I was moving the code > away from get_target_property to generator expressions that should get > into a generated file, although I haven't managed yet. > > Is there any possibility to do that already? > > I've been thinking of adding something like a map function, so we can > turn the target name we get from INTERFACE_LINK_LIBRARIES into a path, > using the LOCATION property. Would that make sense? It is not possible to get this information during the configuration phase. The LOCATION property is not allowed since CMP0026 for a project's own targets. > Otherwise, is it possible to properly get a function called right > before cmake generation? No CMake language code can be executed during generation. That is the domain of generator expressions. It may be possible to add a genex to provide the needed info (e.g. through file(GENERATE)). What is your use case? -Brad From alex.merry at kde.org Fri Jul 31 12:54:33 2015 From: alex.merry at kde.org (Alex Merry) Date: Fri, 31 Jul 2015 18:54:33 +0200 Subject: [cmake-developers] [PATCH] cmCMakePolicyCommand: New PARENT_SCOPE argument In-Reply-To: <55BA266C.7040904@kitware.com> References: <12318436.qfJba0PCz6@roku> <55BA266C.7040904@kitware.com> Message-ID: <4147841.nnd0T5H1Qi@roku> On Thursday 30 July 2015 09:28:12 Brad King wrote: > On 07/29/2015 03:58 PM, Alex Merry wrote: > > This is intended to be used from a "settings file" which is applied to a > > group of CMake projects. This allows the file to control which policies > > means that users of the settings file are not forced to use > > NO_POLICY_SCOPE > > (particularly important if the settings file did not originally have any > > policy settings in it, but later acquired some). > > Policies should not be set from a central hub, especially without the > explicit permission of the including project (via NO_POLICY_SCOPE). > > Setting policies centrally breaks their compatibility model. The > whole point is that the old behavior is preserved (possibly with a > warning) until the project whose code triggers the policy is modified > to address it. By setting a policy on behalf of the project calling > include() you could silence warnings about behavior changes or even > introduce errors. Each project author needs a chance to see their > own policy warnings and address them accordingly. I should perhaps explain our use case: KDE provides the module "KDECompilerSettings", which set a bunch of default compiler settings we think are generally useful for KDE software projects (extra warnings, feature macros for libraries and so on). One of those settings is the compiler visibility stuff (CMAKE_CXX_VISIBILITY_PRESET is set to hidden and CMAKE_VISIBILITY_INLINES_HIDDEN is set to 1). CMP0063 now causes a whole bunch of warnings to appear across a load of projects where there are executable targets. These warnings are because of a setting in the KDECompilerSettings, so it is natual to want to resolve the issue there. We'd like to set the policy to NEW, because the new behaviour is sensible, and we'd consider any project that was broken by the change to already to be in need of fixing, because relying on the old behaviour is non-portable (due to DLL export behaviour). We'd rather have a hard error (even at build time instead of configure time) with a vanishingly small number of projects (hopefully none) than a warning on lots of projects that are almost certainly not affected. Now, sure, we could change every single project that includes this module to use NO_POLICY_SCOPE but, apart from that being an unwanted change in how we tell people to use this module, it seems a very clunky approach. It means the module is at risk of leaking policy settings it didn't mean to (if it were to set policies for its own internal use), but it also means that, conceptually, you are asking users to opt-in to this particular behavoural change (because it happens to be implemented as a policy), but not to the other behavioural changes we make in the module (because they are implemented with variables). Of course, ideally, we'd like to policy change to have the same scope as the variable settings it accompanies. That doesn't seem to be possible to acheive, though (at least, not in a clean way) because of the separate stacks for policy scopes and variable scopes. Alex From brad.king at kitware.com Fri Jul 31 13:30:03 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 31 Jul 2015 13:30:03 -0400 Subject: [cmake-developers] [PATCH] cmCMakePolicyCommand: New PARENT_SCOPE argument In-Reply-To: <4147841.nnd0T5H1Qi@roku> References: <12318436.qfJba0PCz6@roku> <55BA266C.7040904@kitware.com> <4147841.nnd0T5H1Qi@roku> Message-ID: <55BBB09B.5090406@kitware.com> On 07/31/2015 12:54 PM, Alex Merry wrote: >> Setting policies centrally breaks their compatibility model. > > I should perhaps explain our use case: My assertion stands regardless of the use case. > Now, sure, we could change every single project that includes this module to > use NO_POLICY_SCOPE but, apart from that being an unwanted change in how we > tell people to use this module, it seems a very clunky approach. That is the correct approach. If a project wants to opt-in to letting KDECompilerSettings set policies for it (and therefore accept the risk of the broken compatibility model) then it should state so explicitly by including the module with NO_POLICY_SCOPE. > It means the module is at risk of leaking policy settings it didn't mean to Use cmake_policy(PUSH/POP) around most of the module. Then set policies explicitly outside of that scope if they are intended to be set for includers that use NO_POLICY_SCOPE. > you are asking users to opt-in to this particular behavoural change Yes, because the behavior change comes from a CMake version update. The purpose of policies is to not change behavior for a project until it is modified to be aware of the CMake version that makes the change. For this compatibility model to work the modification must be made in the project itself, not in one of its dependencies. -Brad