From Tobias.Hunger at qt.io Wed Jun 1 05:04:55 2016 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Wed, 1 Jun 2016 09:04:55 +0000 Subject: [cmake-developers] Some trivial patches In-Reply-To: <1464709240.811.183.camel@qt.io> References: <1464709240.811.183.camel@qt.io> Message-ID: Hi CMake Developers! Attached you will find a couple of really small changes that add const to a method and fix a couple of typos in comments. Trivial stuff. This is mostly to figure out how to contribute code:-) Is this the preferred way you want your patches? Or do I need to inline them somehow? How can I create an account in the bug tracker? Best Regards, Tobias -- Tobias Hunger, Senior Software Engineer | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-cmGlobalGenerator-Make-IsMultiConfig-const.patch Type: text/x-patch Size: 2747 bytes Desc: 0001-cmGlobalGenerator-Make-IsMultiConfig-const.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fix-typo.patch Type: text/x-patch Size: 833 bytes Desc: 0002-Fix-typo.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Fix-typo.patch Type: text/x-patch Size: 810 bytes Desc: 0003-Fix-typo.patch URL: From dimitar.yordanov at sap.com Wed Jun 1 09:04:02 2016 From: dimitar.yordanov at sap.com (Yordanov, Dimitar) Date: Wed, 1 Jun 2016 13:04:02 +0000 Subject: [cmake-developers] CMake execute_process/signal_handler on Unix Message-ID: <20160601130401.GD22045@lu33953222.dhcp.wdf.sap.corp> Hey, I'm looking into an issue with a CMake build on Linux hanging in a select syscall, when using EXECUTE_PROCESS without any additional arguments. The subprocess executed is "chmod". The child finishes and is marked as a zombie, but CMake did not realize that. The only descriptors left open are the one of the signaling pipe. Looking through the code I couldn't see a place, where I could prove that is directly related to the problem. Nevertheless I have a question about the signal handler used. The function kwsysProcessesSignalHandler in ProcessUnix.c. The problem that I see is the use of a shared variable "kwsysProcesses" in the signal handler. I think the usage of non volatile shared objects should be avoided in signal handlers and we should just do as less as we can in there. So my proposal would be: 1. Use just one SignalPipe for all subprocess 2. In the signal handler just write the one single byte into the w-end of the pipe 3. Do the rest of the processing in the normal workflow. A few more questions: Why do we need the "(void)pipeStatus;" lines. For debugging? Why do we need to read from the pipe in the signal handler? Please let me know what is your opinion. Best wishes Dimitar From brad.king at kitware.com Wed Jun 1 11:16:20 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 1 Jun 2016 11:16:20 -0400 Subject: [cmake-developers] CMake 3.6 feature freeze on 2016-06-01 In-Reply-To: <5748454B.7070701@kitware.com> References: <55F04ADB.1000003@kitware.com> <5733858F.4010808@kitware.com> <5748454B.7070701@kitware.com> Message-ID: <574EFC44.3000405@kitware.com> On 05/27/2016 09:02 AM, Brad King wrote: > I'll announce when post-3.6 development in 'next' is open. I've branched 'release' for 3.6. The repository is now open for post-3.6 development. Please rebase any open topics on 'master' before merging to 'next'. > * Documentation updates > * Regression fixes > * Fixes for bugs in features new to 3.6 These types of changes may still be accepted to 'release' during the 3.6 release candidate cycle. The 3.6 release is now closed to new features and general bug fixes. -Brad From brad.king at kitware.com Wed Jun 1 11:18:11 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 1 Jun 2016 11:18:11 -0400 Subject: [cmake-developers] Some trivial patches In-Reply-To: References: <1464709240.811.183.camel@qt.io> Message-ID: <574EFCB3.8080900@kitware.com> On 06/01/2016 05:04 AM, Tobias Hunger wrote: > Attached you will find a couple of really small changes that add const to a > method and fix a couple of typos in comments. Trivial stuff. Thanks. I've applied the changes: cmSearchPath: Fix typo in comment https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=814e774e cmSourceFileLocation: Fix typo in comment https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bd4fef64 cmGlobalGenerator: Make IsMultiConfig() const https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2175e5bf > This is mostly to figure out how to contribute code:-) Good job. For large changes (e.g. cmake-daemon work) feel free to publish your branch somewhere and post a link here. For most changes please post here. > Is this the preferred way you want your patches? > Or do I need to inline them somehow? Either attachments or inline is fine. > How can I create an account in the bug tracker? Unfortunately we had to turn off self-registration due to recent spam attacks (by human registrants). While we explore alternatives it is a manual process. I'll contact you privately. Thanks, -Brad From brad.king at kitware.com Wed Jun 1 11:18:20 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 1 Jun 2016 11:18:20 -0400 Subject: [cmake-developers] CMake execute_process/signal_handler on Unix In-Reply-To: <20160601130401.GD22045@lu33953222.dhcp.wdf.sap.corp> References: <20160601130401.GD22045@lu33953222.dhcp.wdf.sap.corp> Message-ID: <574EFCBC.2060805@kitware.com> On 06/01/2016 09:04 AM, Yordanov, Dimitar wrote: > I'm looking into an issue with a CMake build on Linux hanging in a > select syscall, when using EXECUTE_PROCESS without any additional > arguments. The subprocess executed is "chmod". The child finishes and > is marked as a zombie, but CMake did not realize that. The only > descriptors left open are the one of the signaling pipe. The code in question uses a well-known idiom to make SIGCHLD select()able. It has worked well for years on many platforms. Are you running inside some kind of virtualization or emulation environment? > is the use of a shared variable "kwsysProcesses" in the signal > handler. I think the usage of non volatile shared objects should be > avoided in signal handlers and we should just do as less as we > can in there. IIRC we suppress signals while updating the shared variables. CMake also doesn't use threads. > Why do we need the "(void)pipeStatus;" lines. For debugging? Some compilers complain we don't use the return value of write(). Therefore we must assign it to a variable. Then compilers complain that the variable is assigned a value that is never used. The cast suppresses this. > Why do we need to read from the pipe in the signal handler? If many signals are received in succession before the select() wakes up and reads from the pipe then it could fill the pipe and block in the handler. We do a non-blocking read to make sure the pipe never has more than one byte in it. All we care about is waking up any blocking select(). BTW, in the long run I'd like to drop this code completely and move to libuv. Meanwhile I'd rather not spend too much time updating the existing implementation. -Brad From brad.king at kitware.com Wed Jun 1 11:18:52 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 1 Jun 2016 11:18:52 -0400 Subject: [cmake-developers] Topic "add-opencl-imported-target" good to merge? In-Reply-To: <574DE32E.2010701@anteru.net> References: <574DE32E.2010701@anteru.net> Message-ID: <574EFCDC.5050801@kitware.com> On 05/31/2016 03:17 PM, Matth?us G. Chajdas wrote: > I've just pushed "add-opencl-imported-target" which adds an imported > target to FindOpenCL. The whole change is rather small: > > https://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=6c53137a19e482140db3dc97b626af38348f2c71 > > Good to merge this to next for testing? Please rebase on 'master' now that post-3.6 development is open. Thanks, -Brad From cmake at anteru.net Wed Jun 1 13:53:40 2016 From: cmake at anteru.net (=?UTF-8?Q?Matth=c3=a4us_G._Chajdas?=) Date: Wed, 1 Jun 2016 19:53:40 +0200 Subject: [cmake-developers] Topic "add-opencl-imported-target" good to merge? In-Reply-To: <574EFCDC.5050801@kitware.com> References: <574DE32E.2010701@anteru.net> <574EFCDC.5050801@kitware.com> Message-ID: <574F2124.1090408@anteru.net> Hi Brad, updated to latest master and pushed again (I merged latest master into this - is that fine or does it have to be a rebase? In that case I'll redo.) Cheers, Matth?us Am 01.06.2016 um 17:18 schrieb Brad King: > On 05/31/2016 03:17 PM, Matth?us G. Chajdas wrote: >> I've just pushed "add-opencl-imported-target" which adds an imported >> target to FindOpenCL. The whole change is rather small: >> >> https://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=6c53137a19e482140db3dc97b626af38348f2c71 >> >> Good to merge this to next for testing? > > Please rebase on 'master' now that post-3.6 development is open. > > Thanks, > -Brad > From brad.king at kitware.com Wed Jun 1 13:57:36 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 1 Jun 2016 13:57:36 -0400 Subject: [cmake-developers] Topic "add-opencl-imported-target" good to merge? In-Reply-To: <574F2124.1090408@anteru.net> References: <574DE32E.2010701@anteru.net> <574EFCDC.5050801@kitware.com> <574F2124.1090408@anteru.net> Message-ID: <574F2210.50003@kitware.com> On 06/01/2016 01:53 PM, Matth?us G. Chajdas wrote: > updated to latest master and pushed again (I merged latest master into > this - is that fine or does it have to be a rebase? In that case I'll redo.) Please rebase and force push. Thanks, -Brad From brad.king at kitware.com Wed Jun 1 14:10:48 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 1 Jun 2016 14:10:48 -0400 Subject: [cmake-developers] [PATCH] fix issue #0016076 Add a --bindir option to bootstrap and use it to install cmake in custom directory In-Reply-To: References: <57486D19.1060806@kitware.com> Message-ID: <574F2528.1040704@kitware.com> On 05/30/2016 10:50 AM, BUNEL Nicolas wrote: > Here, the new patch Thanks. I've applied the patches, squashed, and made some minor tweaks. It has been merged to 'next' for testing: Add option to control 'bin' directory of CMake's own installation (#16076) https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=18bfbc97 Please try out that version. Thanks, -Brad From cmake at anteru.net Wed Jun 1 14:15:25 2016 From: cmake at anteru.net (=?UTF-8?Q?Matth=c3=a4us_G._Chajdas?=) Date: Wed, 1 Jun 2016 20:15:25 +0200 Subject: [cmake-developers] Topic "add-opencl-imported-target" good to merge? In-Reply-To: <574F2210.50003@kitware.com> References: <574DE32E.2010701@anteru.net> <574EFCDC.5050801@kitware.com> <574F2124.1090408@anteru.net> <574F2210.50003@kitware.com> Message-ID: <574F263D.4040507@anteru.net> Hopefully done - I'm not the biggest git expert but the history looks like I'd expect it to look like :) Cheers, Matth?us Am 01.06.2016 um 19:57 schrieb Brad King: > On 06/01/2016 01:53 PM, Matth?us G. Chajdas wrote: >> updated to latest master and pushed again (I merged latest master into >> this - is that fine or does it have to be a rebase? In that case I'll redo.) > > Please rebase and force push. > > Thanks, > -Brad > From brad.king at kitware.com Wed Jun 1 14:22:29 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 1 Jun 2016 14:22:29 -0400 Subject: [cmake-developers] Topic "add-opencl-imported-target" good to merge? In-Reply-To: <574F263D.4040507@anteru.net> References: <574DE32E.2010701@anteru.net> <574EFCDC.5050801@kitware.com> <574F2124.1090408@anteru.net> <574F2210.50003@kitware.com> <574F263D.4040507@anteru.net> Message-ID: <574F27E5.1080803@kitware.com> On 06/01/2016 02:15 PM, Matth?us G. Chajdas wrote: > Hopefully done The revised history looks good. The change itself looks good. Please also add a `Help/release/dev/FindOpenCL-imported-target.rst` file with a release note for the feature. Look at other files in that directory for a sample. See Help/release/*.rst for other examples. As part of the modernization of find modules we're also trying to add better testing for them. Please see Tests/FindPNG and the CMake_TEST_FindPNG code path in Tests/CMakeLists.txt and construct a similar test for the FindOpenCL module. Thanks, -Brad From cmake at anteru.net Wed Jun 1 15:00:45 2016 From: cmake at anteru.net (=?UTF-8?Q?Matth=c3=a4us_G._Chajdas?=) Date: Wed, 1 Jun 2016 21:00:45 +0200 Subject: [cmake-developers] Topic "add-opencl-imported-target" good to merge? In-Reply-To: <574F27E5.1080803@kitware.com> References: <574DE32E.2010701@anteru.net> <574EFCDC.5050801@kitware.com> <574F2124.1090408@anteru.net> <574F2210.50003@kitware.com> <574F263D.4040507@anteru.net> <574F27E5.1080803@kitware.com> Message-ID: <574F30DD.80205@anteru.net> Hi Brad, done - I had to squash and force push once more, because I used the wrong author in the first commit. Everything is now in one commit here: https://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=e95b62110715c06fb76b57fdfb13ea493a94c0c4 Thanks for the timely feedback! Cheers, Matth?us Am 01.06.2016 um 20:22 schrieb Brad King: > On 06/01/2016 02:15 PM, Matth?us G. Chajdas wrote: >> Hopefully done > > The revised history looks good. The change itself looks good. > > Please also add a `Help/release/dev/FindOpenCL-imported-target.rst` > file with a release note for the feature. Look at other files > in that directory for a sample. See Help/release/*.rst for other > examples. > > As part of the modernization of find modules we're also trying > to add better testing for them. Please see Tests/FindPNG and the > CMake_TEST_FindPNG code path in Tests/CMakeLists.txt and construct > a similar test for the FindOpenCL module. > > Thanks, > -Brad > From mantis at public.kitware.com Wed Jun 1 23:58:19 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 1 Jun 2016 23:58:19 -0400 Subject: [cmake-developers] [CMake 0016134]: CMake crashes at generation stage Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=16134 ====================================================================== Reported By: Daniel Levin Assigned To: ====================================================================== Project: CMake Issue ID: 16134 Category: CMake Reproducibility: always Severity: crash Priority: high Status: new ====================================================================== Date Submitted: 2016-06-01 23:58 EDT Last Modified: 2016-06-01 23:58 EDT ====================================================================== Summary: CMake crashes at generation stage Description: Reproducibility 100% on my personal project using either Makefile or Ninja generator. Affected all CMake version after 3.4, earlier versions might contains this issue as well, did not check. Provided fixup patch is for CMake 3.4.0. Versions 3.5+ have different implementation of the same code, but bug is still there. Please see attached Git bundle with branch 'bug' inside that contains the fix. Copy of the patch message: cmGeneratorTarget: Fix tracing dependencies in local generator When looping over the generator targets they might become indirectly invalidated and recreated from cmGlobalGenerator::CreateGenerationObjects(). Thus targets container cmGeneratorTarget pointers will be deleted, dereferencing them leads to crashes at generation stage. To avoid this loop should iterate over cmTarget keys and look for cmGeneratorTarget pointers directly from Makefile instance each time. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-06-01 23:58 Daniel Levin New Issue 2016-06-01 23:58 Daniel Levin File Added: crash.bundle ====================================================================== From daniel at pfeifer-mail.de Thu Jun 2 04:03:55 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Thu, 2 Jun 2016 10:03:55 +0200 Subject: [cmake-developers] fixup! Simplify boolean expressions Message-ID: My "Simplify boolean expressions" refactoring caused C4800 warnings for MSVC builds. A fixup is attached, as I cannot ssh at the moment. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-fixup-Simplify-boolean-expressions.patch Type: text/x-patch Size: 2745 bytes Desc: not available URL: From alexander.stein at systec-electronic.com Thu Jun 2 04:53:51 2016 From: alexander.stein at systec-electronic.com (Alexander Stein) Date: Thu, 2 Jun 2016 10:53:51 +0200 Subject: [cmake-developers] [PATCH 1/1] Compiler/TI: Pass libraries as last part to linker Message-ID: <1464857631-11942-1-git-send-email-alexander.stein@systec-electronic.com> If e.g. libc.a is passed before any objects the linker raises the follwing warning: cannot resolve archive libc.a to a compatible library, as no input files have been encountered In the end the library is skipped and missing symbols occur. Signed-off-by: Alexander Stein --- Modules/Compiler/TI-C.cmake | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Modules/Compiler/TI-C.cmake b/Modules/Compiler/TI-C.cmake index 479666c..ebc79f4 100644 --- a/Modules/Compiler/TI-C.cmake +++ b/Modules/Compiler/TI-C.cmake @@ -7,4 +7,4 @@ set(CMAKE_C_CREATE_PREPROCESSED_SOURCE " --preproc_only --c_fi set(CMAKE_C_COMPILE_OBJECT " --compile_only --c_file= --output_file=") set(CMAKE_C_ARCHIVE_CREATE " -r ") -set(CMAKE_C_LINK_EXECUTABLE " --run_linker --output_file= --map_file=.map ") +set(CMAKE_C_LINK_EXECUTABLE " --run_linker --output_file= --map_file=.map ") -- 2.7.3 From Tobias.Hunger at qt.io Thu Jun 2 05:15:27 2016 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Thu, 2 Jun 2016 09:15:27 +0000 Subject: [cmake-developers] Some trivial patches In-Reply-To: <574EFCB3.8080900@kitware.com> References: <1464709240.811.183.camel@qt.io> <574EFCB3.8080900@kitware.com> Message-ID: <1464858926.811.192.camel@qt.io> On Mi, 2016-06-01 at 11:18 -0400, Brad King wrote: > On 06/01/2016 05:04 AM, Tobias Hunger wrote: > > Attached you will find a couple of really small changes that add const to a > > method and fix a couple of typos in comments. Trivial stuff. > > Thanks.??I've applied the changes: > > ?cmSearchPath: Fix typo in comment > ?https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=814e774e > > ?cmSourceFileLocation: Fix typo in comment > ?https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bd4fef64 > > ?cmGlobalGenerator: Make IsMultiConfig() const > ?https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2175e5bf > > > This is mostly to figure out how to contribute code:-) > > Good job.??For large changes (e.g. cmake-daemon work) feel free > to publish your branch somewhere and post a link here.??For most > changes please post here. Why did the typo fixes end up in the master branch and the const fix in the next branch? Do I need to do something to get it from next to master at some point? Best Regards, Tobias -- Tobias Hunger,?Senior?Software Engineer?| The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From daniel at pfeifer-mail.de Thu Jun 2 06:54:42 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Thu, 2 Jun 2016 12:54:42 +0200 Subject: [cmake-developers] Some trivial patches In-Reply-To: <1464858926.811.192.camel@qt.io> References: <1464709240.811.183.camel@qt.io> <574EFCB3.8080900@kitware.com> <1464858926.811.192.camel@qt.io> Message-ID: On Thu, Jun 2, 2016 at 11:15 AM, Tobias Hunger wrote: > On Mi, 2016-06-01 at 11:18 -0400, Brad King wrote: >> On 06/01/2016 05:04 AM, Tobias Hunger wrote: >> > Attached you will find a couple of really small changes that add const to a >> > method and fix a couple of typos in comments. Trivial stuff. >> >> Thanks. I've applied the changes: >> >> cmSearchPath: Fix typo in comment >> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=814e774e >> >> cmSourceFileLocation: Fix typo in comment >> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bd4fef64 >> >> cmGlobalGenerator: Make IsMultiConfig() const >> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2175e5bf >> >> > This is mostly to figure out how to contribute code:-) >> >> Good job. For large changes (e.g. cmake-daemon work) feel free >> to publish your branch somewhere and post a link here. For most >> changes please post here. > > Why did the typo fixes end up in the master branch and the const fix in the next > branch? Because of the code freeze for CMake 3.6: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/16479 > Do I need to do something to get it from next to master at some point? No. From Harry at codexdigital.com Thu Jun 2 08:21:42 2016 From: Harry at codexdigital.com (Harry Mallon) Date: Thu, 2 Jun 2016 12:21:42 +0000 Subject: [cmake-developers] Productbuild CPack generator Message-ID: <42976E66-C80C-4B8E-A452-6F59D79FD54A@codexdigital.com> I found this on the other mailing list but it isn't getting much love. Is anyone out there who can tell me how far from being merged in it is? It would really reduce the hackery in our cmake scripts here and I am happy to contribute to it's testing and development if I get some time. http://public.kitware.com/pipermail/cmake/2016-May/063493.html Harry Harry Mallon CODEX | Software Engineer 60 Poland Street | London | England | W1F 7NT E harry at codexdigital.com | T +44 203 7000 989 Website | Facebook | Twitter [http://www.codexdigital.com/?action=asset&id=E55D8A6F-AF62-4978-8FF1-435A85AFADBF] -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Jun 2 09:44:29 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 2 Jun 2016 09:44:29 -0400 Subject: [cmake-developers] Topic "add-opencl-imported-target" good to merge? In-Reply-To: <574F30DD.80205@anteru.net> References: <574DE32E.2010701@anteru.net> <574EFCDC.5050801@kitware.com> <574F2124.1090408@anteru.net> <574F2210.50003@kitware.com> <574F263D.4040507@anteru.net> <574F27E5.1080803@kitware.com> <574F30DD.80205@anteru.net> Message-ID: <5750383D.6060903@kitware.com> On 06/01/2016 03:00 PM, Matth?us G. Chajdas wrote: > done - I had to squash and force push once more, because I used the > wrong author in the first commit. > > Everything is now in one commit here: > https://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=e95b62110715c06fb76b57fdfb13ea493a94c0c4 > > Thanks for the timely feedback! I renamed the topic to 'FindOpenCL-imported-target', added some minor tweaks, and merged to 'next' for testing: FindOpenCL: Add an imported target https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b66d4739 If any fixes are needed please extend the topic and merge to 'next' again. Thanks, -Brad From brad.king at kitware.com Thu Jun 2 09:44:33 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 2 Jun 2016 09:44:33 -0400 Subject: [cmake-developers] [PATCH 1/1] Compiler/TI: Pass libraries as last part to linker In-Reply-To: <1464857631-11942-1-git-send-email-alexander.stein@systec-electronic.com> References: <1464857631-11942-1-git-send-email-alexander.stein@systec-electronic.com> Message-ID: <57503841.4080606@kitware.com> On 06/02/2016 04:53 AM, Alexander Stein wrote: > If e.g. libc.a is passed before any objects the linker raises the follwing > warning: cannot resolve archive libc.a to a compatible library, as no > input files have been encountered > In the end the library is skipped and missing symbols occur. > > Signed-off-by: Alexander Stein Thanks, applied: Compiler/TI: Pass libraries as last part to linker https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=89317915 -Brad From konstantin at podsvirov.pro Thu Jun 2 11:45:42 2016 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Thu, 02 Jun 2016 18:45:42 +0300 Subject: [cmake-developers] [MODERN] CMake 3.6+ vs Qt 5.6 vs MSVC2015 In-Reply-To: <476621464710287@web16g.yandex.ru> References: <1821991437643934@web22o.yandex.ru> <55B0E831.7070603@yahoo.com> <35881437659256@web4h.yandex.ru> <1975171437723971@web22h.yandex.ru> <55B653D0.4020001@kitware.com> <198581438094978@web29o.yandex.ru> <825181443680946@web21o.yandex.ru> <56451463763913@web25o.yandex.ru> <476621464710287@web16g.yandex.ru> Message-ID: <4434461464882342@web5o.yandex.ru> Hi all! Modern master updated! :-) It's time to upgrade: CMake 3.6.20160602 now available! Let me remind you of the link. Windows 32bit: http://ifw.podsvirov.pro/cmake/cmake-master-win32-online.exe Windows 64bit: http://ifw.podsvirov.pro/cmake/cmake-master-win64-online.exe If you have used it before, you can update via "CMake Maintenance Tool" I used Windows 7, but it should work for Windows Vista and Windows 8 and Windows 10. I ask those wishing to test the functionality. And new: Linux (Debian) amd64: http://ifw.podsvirov.pro/cmake/cmake-master-amd64-online.run Please test it :-) >> ?01.10.2015, 09:29, Konstantin Podsvirov" : >>> ??Hi all! Modern master alive! :-) >>> >>> ??It's been almost a month and it's time to upgrade: >>> >>> ??3.3.20150901 CMake => CMake 3.3.20151001 >>> >>> ??Dear friends, I have a question and call for help. >>> >>> ??With my assistance the project has an option for component installation project: >>> >>> ??CMake_INSTALL_COMPONENTS >>> >>> ??Unfortunately not all files found your component. >>> ??The files to be installed without specifying a component fall into 'Unspecified' component. >>> ??Need to parse them out and assign them to the component context. >>> >>> ??Now have the components: >>> >>> ??- cmake; >>> ??- ctest; >>> ??- cpack; >>> ??- cmake-gui; >>> ??- sphinx-man; >>> ??- sphinx-html; >>> ??- sphinx singlehtml; >>> ??- sphinx-qthelp >>> >>> ??and General for everything else >>> >>> ??Is Unspecified; >>> >>> ??A list of unaccounted for 'Unspecified' of files to install on the Window is attached. >>> >>> ??Links to the installers were specified earlier (see below). >>> >>> ??On 28.07.2015, 17:49, "Konstantin Podsvirov" : >>>> ??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 >>>>>> ??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 option CMake_INSTALL_DEPENDENCIES >>>>> ??http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=068e7962 >>>> >>>> ??Code now in 'master' branch. >>>> >>>> ??Thanks, Brad! >>>> >>>> ??Meet/install/CMake built modern update 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 >>>> >>>> ??The 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 >>> ??,-- >>> >>> ??Powered by www.kitware.com >>> >>> ??Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>> >>> ??Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>> >>> ??CMake Support: http://cmake.org/cmake/help/support.html >>> ??CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> ??CMake Training Courses: http://cmake.org/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 >> >> ?Regards, >> ?Konstantin Podsvirov Regards, Konstantin Podsvirov From nicolas.bunel at thalesgroup.com Thu Jun 2 11:46:06 2016 From: nicolas.bunel at thalesgroup.com (BUNEL Nicolas) Date: Thu, 2 Jun 2016 17:46:06 +0200 Subject: [cmake-developers] [PATCH] fix issue #0016076 Add a --bindir option to bootstrap and use it to install cmake in custom directory In-Reply-To: <574F2528.1040704@kitware.com> References: <57486D19.1060806@kitware.com> <574F2528.1040704@kitware.com> Message-ID: Hi, Thanks for applying this patch. I tried to use --bindir option with a clone of 'next' branch, and it's OK. Cmake is correctly installed in the PREFIX/BIN_DIR directory. Thanks Nicolas -----Message d'origine----- De?: Brad King Envoy??: mercredi 1 juin 2016 20:11 On 05/30/2016 10:50 AM, BUNEL Nicolas wrote: > Here, the new patch Thanks. I've applied the patches, squashed, and made some minor tweaks. It has been merged to 'next' for testing: Add option to control 'bin' directory of CMake's own installation (#16076) https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=18bfbc97 Please try out that version. Thanks, -Brad From clinton at elemtech.com Thu Jun 2 12:03:32 2016 From: clinton at elemtech.com (clinton at elemtech.com) Date: Thu, 2 Jun 2016 10:03:32 -0600 (MDT) Subject: [cmake-developers] Productbuild CPack generator In-Reply-To: <42976E66-C80C-4B8E-A452-6F59D79FD54A@codexdigital.com> References: <42976E66-C80C-4B8E-A452-6F59D79FD54A@codexdigital.com> Message-ID: <1290594528.41531867.1464883412262.JavaMail.zimbra@elemtech.com> Hi Harry, I have submitted a productbuild generator this morning. https://cmake.org/gitweb?p=cmake.git;a=commit;h=b746bd5c Its capabilities should be about equal to the PackageMaker generator. The code for distribution.xml is shared between PackageMaker and productbuild. The preflight/postflight script support should be better with this new generator than with PackageMaker. Please do help with testing and development. >From your other email with suggestions, I have implemented the --version parameter for pkgbuild and product build, and fixed finding the pkgutil and productbuild exectuables. I tried a user controlled setting for --install-location but ran into some difficulty getting cmCPackGenerator to cooperate. I decided to leave --install-location as '/' and do not see any negative effects of that. That can be revisited, of course. Does anyone here know if we have test coverage already for some cpack generators where we create a package, then unpack it to verify the results? Clint ----- On Jun 2, 2016, at 6:21 AM, Harry Mallon wrote: > I found this on the other mailing list but it isn't getting much love. Is anyone > out there who can tell me how far from being merged in it is? It would really > reduce the hackery in our cmake scripts here and I am happy to contribute to > it's testing and development if I get some time. > http://public.kitware.com/pipermail/cmake/2016-May/063493.html > Harry > Harry Mallon > CODEX | Software Engineer > 60 Poland Street | London | England | W1F 7NT > E harry at codexdigital.com | T +44 203 7000 989 > Website | Facebook | Twitter > -- > Powered by www.kitware.com > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/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 cmake at anteru.net Thu Jun 2 12:43:04 2016 From: cmake at anteru.net (=?UTF-8?Q?Matth=c3=a4us_G._Chajdas?=) Date: Thu, 2 Jun 2016 18:43:04 +0200 Subject: [cmake-developers] Topic "add-opencl-imported-target" good to merge? In-Reply-To: <5750383D.6060903@kitware.com> References: <574DE32E.2010701@anteru.net> <574EFCDC.5050801@kitware.com> <574F2124.1090408@anteru.net> <574F2210.50003@kitware.com> <574F263D.4040507@anteru.net> <574F27E5.1080803@kitware.com> <574F30DD.80205@anteru.net> <5750383D.6060903@kitware.com> Message-ID: <57506218.3010101@anteru.net> Thanks! Cheers, Matth?us Am 02.06.2016 um 15:44 schrieb Brad King: > On 06/01/2016 03:00 PM, Matth?us G. Chajdas wrote: >> done - I had to squash and force push once more, because I used the >> wrong author in the first commit. >> >> Everything is now in one commit here: >> https://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=e95b62110715c06fb76b57fdfb13ea493a94c0c4 >> >> Thanks for the timely feedback! > > I renamed the topic to 'FindOpenCL-imported-target', added some minor > tweaks, and merged to 'next' for testing: > > FindOpenCL: Add an imported target > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b66d4739 > > If any fixes are needed please extend the topic and merge to 'next' > again. > > Thanks, > -Brad > From domen.vrankar at gmail.com Fri Jun 3 02:02:15 2016 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Fri, 3 Jun 2016 08:02:15 +0200 Subject: [cmake-developers] Productbuild CPack generator In-Reply-To: <1290594528.41531867.1464883412262.JavaMail.zimbra@elemtech.com> References: <42976E66-C80C-4B8E-A452-6F59D79FD54A@codexdigital.com> <1290594528.41531867.1464883412262.JavaMail.zimbra@elemtech.com> Message-ID: > Does anyone here know if we have test coverage already for some cpack > generators where we create a package, then unpack it to verify the results? > Tests/CPackComponentsDEB (Deb), Tests/CPackComponentsForAll (RPM) and tests in Tests/RunCMake/CPack (at the moment Deb, RPM, TGZ) all verify content of generated packages. I intended for Tests/RunCMake/CPack to be the location of all tests for CPack generated packages that can be verified with command line tools in a way that you specify the type of test and if other generators have the same capabilities they should use the same test with additional generator specific variables in a separate file. Unfortunately atm there are still some issues with those tests with the most annoying being the verbosity because of: - test should automatically cover different packaging styles [monolithic, components, ...], - for most tests files count and content should be the same with each generator's Helpers.cmake providing the format (at the moment each test has to provide special ExpectedFiles cmake script so it's too complicated to write tests) It's on my TODO list to extend Tests/RunCMake/CPack so hopefully I'll get to it in the following week or two. If you'd like to add your tests to it there is a README.txt file there that explains how it works and how to add your own tests to it. Regards, Domen -------------- next part -------------- An HTML attachment was scrubbed... URL: From dimitar.yordanov at sap.com Fri Jun 3 02:05:35 2016 From: dimitar.yordanov at sap.com (Yordanov, Dimitar) Date: Fri, 3 Jun 2016 06:05:35 +0000 Subject: [cmake-developers] CMake execute_process/signal_handler on Unix In-Reply-To: <574EFCBC.2060805@kitware.com> References: <20160601130401.GD22045@lu33953222.dhcp.wdf.sap.corp> <574EFCBC.2060805@kitware.com> Message-ID: <20160603060534.GA123185@lu33953222.dhcp.wdf.sap.corp> Hi Brad, thanks for responding! * Brad King [16-06-01 17:18 CEST]: > On 06/01/2016 09:04 AM, Yordanov, Dimitar wrote: > > I'm looking into an issue with a CMake build on Linux hanging in a > > select syscall, when using EXECUTE_PROCESS without any additional > > arguments. The subprocess executed is "chmod". The child finishes and > > is marked as a zombie, but CMake did not realize that. The only > > descriptors left open are the one of the signaling pipe. > > The code in question uses a well-known idiom to make SIGCHLD > select()able. It has worked well for years on many platforms. > Are you running inside some kind of virtualization or emulation > environment? Actually not. The server is maybe under heavy load, but should it matter? > > > is the use of a shared variable "kwsysProcesses" in the signal > > handler. I think the usage of non volatile shared objects should be > > avoided in signal handlers and we should just do as less as we > > can in there. > > IIRC we suppress signals while updating the shared variables. > CMake also doesn't use threads. Possibly I'm on the wrong track, but couldn't the compiler reorder the code where kwsysProcess is set, and move it out of the blocked section? Should it be volatile to avoid such scenario? > > Why do we need the "(void)pipeStatus;" lines. For debugging? > > Some compilers complain we don't use the return value of write(). > Therefore we must assign it to a variable. Then compilers > complain that the variable is assigned a value that is never > used. The cast suppresses this. I thought (void)write(...); is a portable way to say that we are not interested in the return value. Not that I would change running code for that. > > Why do we need to read from the pipe in the signal handler? > > If many signals are received in succession before the select() > wakes up and reads from the pipe then it could fill the pipe > and block in the handler. We do a non-blocking read to make > sure the pipe never has more than one byte in it. All we care > about is waking up any blocking select(). The write end is also non-blocking so it would not block the signal handler. I was just trying to understand the implementation and if I'm not misunderstanding something. > > BTW, in the long run I'd like to drop this code completely and > move to libuv. Meanwhile I'd rather not spend too much time > updating the existing implementation. Thanks for sharing. Best wishes Dimitar > > -Brad > From brad.king at kitware.com Fri Jun 3 11:00:36 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 3 Jun 2016 11:00:36 -0400 Subject: [cmake-developers] CMake execute_process/signal_handler on Unix In-Reply-To: <20160603060534.GA123185@lu33953222.dhcp.wdf.sap.corp> References: <20160601130401.GD22045@lu33953222.dhcp.wdf.sap.corp> <574EFCBC.2060805@kitware.com> <20160603060534.GA123185@lu33953222.dhcp.wdf.sap.corp> Message-ID: <57519B94.2050805@kitware.com> On 06/03/2016 02:05 AM, Yordanov, Dimitar wrote: >> Are you running inside some kind of virtualization or emulation >> environment? > > Actually not. The server is maybe under heavy load, but should it > matter? See discussion here: https://cmake.org/Bug/view.php?id=15873 > Possibly I'm on the wrong track, but couldn't the compiler reorder the > code where kwsysProcess is set, and move it out of the blocked > section? Should it be volatile to avoid such scenario? I think further investigation/debugging would be needed to answer that. > I thought (void)write(...); is a portable way to say that we are not > interested in the return value. Not that I would change running code > for that. I think we used to have that and some compilers warned anyway. -Brad From dimitar.yordanov at sap.com Fri Jun 3 11:13:06 2016 From: dimitar.yordanov at sap.com (Yordanov, Dimitar) Date: Fri, 3 Jun 2016 15:13:06 +0000 Subject: [cmake-developers] CMake execute_process/signal_handler on Unix In-Reply-To: <57519B94.2050805@kitware.com> References: <20160601130401.GD22045@lu33953222.dhcp.wdf.sap.corp> <574EFCBC.2060805@kitware.com> <20160603060534.GA123185@lu33953222.dhcp.wdf.sap.corp> <57519B94.2050805@kitware.com> Message-ID: <20160603151306.GA5106@lu33953222.dhcp.wdf.sap.corp> Hi Brad, thanks for pointing me to the report. I should have searched myself:) The POSIX alternative to the self pipe trick is using a pselect In [1] is an article on LWN about it. Best Dimitar 1 - https://lwn.net/Articles/176911/ * Brad King [16-06-03 17:00 CEST]: > On 06/03/2016 02:05 AM, Yordanov, Dimitar wrote: > >> Are you running inside some kind of virtualization or emulation > >> environment? > > > > Actually not. The server is maybe under heavy load, but should it > > matter? > > See discussion here: > > https://cmake.org/Bug/view.php?id=15873 > > > Possibly I'm on the wrong track, but couldn't the compiler reorder the > > code where kwsysProcess is set, and move it out of the blocked > > section? Should it be volatile to avoid such scenario? > > I think further investigation/debugging would be needed to answer that. > > > I thought (void)write(...); is a portable way to say that we are not > > interested in the return value. Not that I would change running code > > for that. > > I think we used to have that and some compilers warned anyway. > > -Brad > From orion at cora.nwra.com Fri Jun 3 11:39:52 2016 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 3 Jun 2016 09:39:52 -0600 Subject: [cmake-developers] Support libarchive 3.2 Message-ID: <5751A4C8.2010901@cora.nwra.com> libarchive 3.2 changed the version string format. The attached patch fixes. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Support-libarchive-3.2-version-string-format.patch Type: text/x-patch Size: 1851 bytes Desc: not available URL: From mantis at public.kitware.com Fri Jun 3 12:47:29 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 3 Jun 2016 12:47:29 -0400 Subject: [cmake-developers] [CMake 0016135]: RPATH linker flags no longer set correctly for SunOS PathScale compiler since cmake 3.1 Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=16135 ====================================================================== Reported By: Micha? G?rny Assigned To: ====================================================================== Project: CMake Issue ID: 16135 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-06-03 12:47 EDT Last Modified: 2016-06-03 12:47 EDT ====================================================================== Summary: RPATH linker flags no longer set correctly for SunOS PathScale compiler since cmake 3.1 Description: We've recently upgraded CMake and noticed that our project stopped building correctly. After timesome debugging, I've found out that after CMake upgrade, CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG is no longer set correctly. This happens on SunOS-5 system with PathScale compiler in use, and it started to happen in cmake-3.1. It looks that the correct linker flags are being set in two modules: Platform/SunOS.cmake and Platform/SunOS-GNU.cmake. The former of the files does not apply the linker flags since it is restricted to apply to SunOS-4 only. The latter of the files used to apply before cmake-3.1. However, since cmake-3.1 it is no longer used when PathScale compiler is in use. Steps to Reproduce: 1. Download PathScale compiler (http://www.pathscale.com/ekopath-compiler-suite), 2. echo 'message(FATAL_ERROR "${CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG}")' > CMakeLists.txt 3. cmake . -DCMAKE_C_COMPILER=/opt/ekopath/bin/pathcc With cmake-3.0.2 and older, it will print: -Wl,-R With cmake-3.1.3 and newer, it will print an empty string Additional Information: This probably could be fixed two ways: either by applying the 'GNU' rules for PathScale compiler, or by extending the SunOS rules to SunOS-5. I don't know which one is more correct here. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-06-03 12:47 Micha? G?rny New Issue ====================================================================== From brad.king at kitware.com Fri Jun 3 13:28:34 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 3 Jun 2016 13:28:34 -0400 Subject: [cmake-developers] Support libarchive 3.2 In-Reply-To: <5751A4C8.2010901@cora.nwra.com> References: <5751A4C8.2010901@cora.nwra.com> Message-ID: <5751BE42.3050201@kitware.com> On 06/03/2016 11:39 AM, Orion Poplawski wrote: > libarchive 3.2 changed the version string format. The attached patch fixes. Thanks, applied: FindLibArchive: Support libarchive 3.2 version string format https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=38d18bab I've queued this for merge to 'release' for 3.6.0 since it is an environmental regression. However, it won't be in 3.6.0-rc1 because we've already started building that. -Brad From robert.maynard at kitware.com Fri Jun 3 15:46:16 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 3 Jun 2016 15:46:16 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.6.0-rc1 now ready for testing! Message-ID: I am proud to announce the first CMake 3.6 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.6 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.6/release/3.6.html Some of the more significant features of CMake 3.6 are: * The "Visual Studio 14 2015" generator learned to support the Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This feature is experimental. * The "list()" command gained a "FILTER" sub-command to filter list elements by regular expression. * A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally tell the "try_compile()" command to build a static library instead of an executable. This is useful for cross-compiling toolchains that cannot link binaries without custom flags or scripts. * A "_CLANG_TIDY" target property and supporting "CMAKE__CLANG_TIDY" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "clang-tidy" along with the compiler for "C" and "CXX" languages. * The "ExternalProject" module leared the "GIT_SHALLOW 1" option to perform a shallow clone of a Git repository. * The "ExternalProject" module learned to initialize Git submodules recursively and also to initialize new submodules on updates. Use the "GIT_SUBMODULES" option to restrict which submodules are initalized and updated. * The "InstallRequiredSystemLibraries" module learned a new "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment of the Windows Universal CRT libraries with Visual Studio 2015. * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX platforms. Deprecated and Removed Features =============================== * The "CMakeForceCompiler" module and its macros are now deprecated. See module documentation for an explanation. * The "Visual Studio 7 .NET 2003" generator is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 7" generator (for VS .NET 2002) has been removed. It had been deprecated since CMake 3.3. * The "Visual Studio 6" generator has been removed. It had been deprecated since CMake 3.3. CMake 3.6 Release Notes *********************** Changes made since CMake 3.5 include the following. New Features ============ Generators ---------- * The "Ninja" generator learned to produce phony targets of the form "sub/dir/all" to drive the build of a subdirectory. This is equivalent to "cd sub/dir; make all" with Makefile Generators. * The "Ninja" generator now includes system header files in build dependencies to ensure correct re-builds when system packages are updated. * The "Visual Studio 14 2015" generator learned to support the Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This feature is experimental. Commands -------- * The "add_custom_command()" and "add_custom_target()" commands learned how to use the "CROSSCOMPILING_EMULATOR" executable target property. * The "install()" command learned a new "EXCLUDE_FROM_ALL" option to leave installation rules out of the default installation. * The "list()" command gained a "FILTER" sub-command to filter list elements by regular expression. * The "string(TIMESTAMP)" and "file(TIMESTAMP)" commands gained support for the "%s" placeholder. This is the number of seconds since the UNIX Epoch. * The "try_compile()" command source file signature now honors configuration-specific flags (e.g. "CMAKE__FLAGS_DEBUG") in the generated test project. Previously only the default such flags for the current toolchain were used. Variables --------- * A "CMAKE_DEPENDS_IN_PROJECT_ONLY" variable was introduced to tell Makefile Generators to limit dependency scanning only to files in the project source and build trees. * A new "CMAKE_HOST_SOLARIS" variable was introduced to indicate when CMake is running on an Oracle Solaris host. * A "CMAKE__STANDARD_INCLUDE_DIRECTORIES" variable was added for use by toolchain files to specify system include directories to be appended to all compiler command lines. * The "CMAKE__STANDARD_LIBRARIES" variable is now documented. It is intended for use by toolchain files to specify system libraries to be added to all linker command lines. * A "CMAKE_NINJA_OUTPUT_PATH_PREFIX" variable was introduced to tell the "Ninja" generator to configure the generated "build.ninja" file for use as a "subninja". * A "CMAKE_TRY_COMPILE_PLATFORM_VARIABLES" variable was added for use by toolchain files to specify platform-specific variables that must be propagated by the "try_compile()" command into test projects. * A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally tell the "try_compile()" command to build a static library instead of an executable. This is useful for cross-compiling toolchains that cannot link binaries without custom flags or scripts. Properties ---------- * A "DEPLOYMENT_REMOTE_DIRECTORY" target property was introduced to tell the "Visual Studio 9 2008" and "Visual Studio 8 2005" generators to generate the "remote directory" for WinCE project deployment and debugger settings. * A "_CLANG_TIDY" target property and supporting "CMAKE__CLANG_TIDY" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "clang-tidy" along with the compiler for "C" and "CXX" languages. * A "TIMEOUT_AFTER_MATCH" test property was introduced to optionally tell CTest to enforce a secondary timeout after matching certain output from a test. * A "VS_CONFIGURATION_TYPE" target property was introduced to specify a custom project file type for Visual Studio Generators supporting VS 2010 and above. * A "VS_STARTUP_PROJECT" directory property was introduced to specify for Visual Studio Generators the default startup project for generated solutions (".sln" files). Modules ------- * The "CMakePushCheckState" module now pushes/pops/resets the variable "CMAKE_EXTRA_INCLUDE_FILE" used in "CheckTypeSize". * The "ExternalProject" module leared the "GIT_SHALLOW 1" option to perform a shallow clone of a Git repository. * The "ExternalProject" module learned to initialize Git submodules recursively and also to initialize new submodules on updates. Use the "GIT_SUBMODULES" option to restrict which submodules are initalized and updated. * The "ExternalProject" module leared the "DOWNLOAD_NO_EXTRACT 1" argument to skip extracting the file that is downloaded (e.g., for self-extracting shell installers or ".msi" files). * The "ExternalProject" module now uses "TLS_VERIFY" when fetching from git repositories. * The "FindBLAS" and "FindLAPACK" modules learned to support OpenBLAS. * The "FindCUDA" module learned to find the "cublas_device" library. * The "FindGTest" module "gtest_add_tests" function now causes CMake to automatically re-run when test sources change so that they can be re-scanned. * The "FindLTTngUST" module was introduced to find the LTTng-UST library. * The "FindPkgConfig" module learned to optionally create imported targets for the libraries it has found. * The "FindProtobuf" module learned to provide a "Protobuf_VERSION" variable and check the version number requested in a "find_package()" call. * The "InstallRequiredSystemLibraries" module learned a new "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment of the Windows Universal CRT libraries with Visual Studio 2015. Platforms --------- * The Clang compiler is now supported on CYGWIN. * Support was added for the Bruce C Compiler with compiler id "Bruce". CTest ----- * The "ctest_update()" command now looks at the "CTEST_GIT_INIT_SUBMODULES" variable to determine whether submodules should be updated or not before updating. * The "ctest_update()" command will now synchronize submodules on an update. Updates which add submodules or change a submodule's URL will now be pulled properly. CPack ----- * The "CPackDeb" module learned how to handle "$ORIGIN" in "CMAKE_INSTALL_RPATH" when "CPACK_DEBIAN_PACKAGE_SHLIBDEPS" is used for dependency auto detection. * The "CPackDeb" module learned how to generate "DEBIAN/shlibs" contorl file when package contains shared libraries. * The "CPackDeb" module learned how to generate "DEBIAN/postinst" and "DEBIAN/postrm" files if the package installs libraries in ldconfig- controlled locations (e.g. "/lib/", "/usr/lib/"). * The "CPackDeb" module learned how to generate dependencies between Debian packages if multi-component setup is used and "CPACK_COMPONENT__DEPENDS" variables are set. For backward compatibility this feature is disabled by default. See "CPACK_DEBIAN_ENABLE_COMPONENT_DEPENDS". * The "CPackDeb" module learned how to set custom package file names including how to generate properly-named Debian packages: _-_.deb For backward compatibility this feature is disabled by default. See "CPACK_DEBIAN_FILE_NAME" and "CPACK_DEBIAN__FILE_NAME". * The "CPackDeb" module learned how to set the package release number ("DebianRevisionNumber" in package file name when used in combination with "DEB-DEFAULT" value set by "CPACK_DEBIAN_FILE_NAME"). See "CPACK_DEBIAN_PACKAGE_RELEASE". * The "CPackDeb" module learned how to set the package architecture per-component. See "CPACK_DEBIAN__PACKAGE_ARCHITECTURE". * The "CPackDMG" module learned a new option to tell the CPack "DragNDrop" generaor to skip the "/Applications" symlink. See the "CPACK_DMG_DISABLE_APPLICATIONS_SYMLINK" variable. * The "CPackIFW" module gained a new "cpack_ifw_update_repository()" command to update a QtIFW-specific repository from a remote repository. * The "CPackRPM" module learned how to set RPM "dist" tag as part of RPM "Release:" tag when enabled (mandatory on some Linux distributions for e.g. on Fedora). See "CPACK_RPM_PACKAGE_RELEASE_DIST". * The "CPackRPM" module learned how to set default values for owning user/group and file/directory permissions of package content. See "CPACK_RPM_DEFAULT_USER", "CPACK_RPM_DEFAULT_GROUP", "CPACK_RPM_DEFAULT_FILE_PERMISSIONS", "CPACK_RPM_DEFAULT_DIR_PERMISSIONS" and their per component counterparts. * The "CPackRPM" module learned how to set user defined package file names, how to specify that rpmbuild should decide on file name format as well as handling of multiple rpm packages generated by a single user defined spec file. See "CPACK_RPM_PACKAGE_NAME" and "CPACK_RPM__PACKAGE_NAME". * The "CPackRPM" module learned how to correctly handle symlinks that are pointing outside generated packages. Other ----- * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX platforms. Deprecated and Removed Features =============================== * The "CMakeForceCompiler" module and its macros are now deprecated. See module documentation for an explanation. * The "find_library()", "find_path()", and "find_file()" commands no longer search in installation prefixes derived from the "PATH" environment variable on non-Windows platforms. This behavior was added in CMake 3.3 to support Windows hosts but has proven problematic on UNIX hosts. Users that keep some "/bin" directories in the "PATH" just for their tools do not necessarily want any supporting "/lib" directories searched. One may set the "CMAKE_PREFIX_PATH" environment variable with a ;-list of prefixes that are to be searched. * The "Visual Studio 7 .NET 2003" generator is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 7" generator (for VS .NET 2002) has been removed. It had been deprecated since CMake 3.3. * The "Visual Studio 6" generator has been removed. It had been deprecated since CMake 3.3. Other Changes ============= * The precompiled OS X binary provided on "cmake.org" now requires OS X 10.7 or newer. * On Linux and FreeBSD platforms, when building CMake itself from source and not using a system-provided libcurl, OpenSSL is now used by default if it is found on the system. This enables SSL/TLS support for commands supporting network communication via "https", such as "file(DOWNLOAD)", "file(UPLOAD)", and "ctest_submit()". * The "cmake(1)" "--build" command-line tool now rejects multiple "-- target" options with an error instead of silently ignoring all but the last one. * "AUTOMOC" now diagnoses name collisions when multiple source files in different directories use "#include " with the same name (because the generated "moc_foo.cpp" files would collide). * The "FindBISON" module "BISON_TARGET" macro now supports special characters by passing the "VERBATIM" option to internal "add_custom_command()" calls. This may break clients that added escaping manually to work around the bug. * The "FindFLEX" module "FLEX_TARGET" macro now supports special characters by passing the "VERBATIM" option to internal "add_custom_command()" calls. This may break clients that added escaping manually to work around the bug. * The "FindProtobuf" module input and output variables were all renamed from "PROTOBUF_" to "Protobuf_" for consistency with other find modules. Input variables of the old case will be honored if provided, and output variables of the old case are always provided. * The "CPackRPM" module now supports upper cased component names in per component CPackRPM specific variables. E.g. component named "foo" now expects component specific variable to be "CPACK_RPM_FOO_PACKAGE_NAME" while before it expected "CPACK_RPM_foo_PACKAGE_NAME". Upper cased component name part in variables is compatible with convention used for other CPack variables. For back compatibility old format of variables is still valid and preferred if both versions of variable are set, but the preferred future use is upper cased component names in variables. New variables that will be added to CPackRPM in later versions will only support upper cased component variable format. From cmake at anteru.net Sat Jun 4 14:54:58 2016 From: cmake at anteru.net (=?UTF-8?Q?Matth=c3=a4us_G._Chajdas?=) Date: Sat, 4 Jun 2016 20:54:58 +0200 Subject: [cmake-developers] FindVulkan.cmake Message-ID: <57532402.40007@anteru.net> Hi, I've pushed an add-FindVulkan topic branch which adds a module to search for the Vulkan graphics API (https://www.khronos.org/vulkan/). I'm also happy to maintain this going forward. The complete diff can be found here: https://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=276fa1497efd37872fdaa2f223ae71b5795f7ade Cheers, Matth?us From steveire at gmail.com Sun Jun 5 07:56:40 2016 From: steveire at gmail.com (Stephen Kelly) Date: Sun, 5 Jun 2016 13:56:40 +0200 Subject: [cmake-developers] Developer tasks - Refactoring In-Reply-To: References: Message-ID: <57541378.8010507@gmail.com> On 05/20/2016 12:06 AM, Daniel Pfeifer wrote: > On Thu, May 19, 2016 at 11:18 PM Daniel Pfeifer > > wrote: > > On Wed, Feb 10, 2016 at 12:15 AM Stephen Kelly > wrote: > > 1) Make cmLocalGenerator not inherit cmOutputConverter > * Change enums like cmLocalGenerator::START_OUTPUT with sed. See > > > Please see attached patch. > > > Revised patch attached. Please ignore the previous one. > This one also fully qualifies the enums that were used unqualified. Thanks for working on this! Looks good to me too. Steve. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Sun Jun 5 08:15:51 2016 From: steveire at gmail.com (Stephen Kelly) Date: Sun, 5 Jun 2016 14:15:51 +0200 Subject: [cmake-developers] Developer tasks - Refactoring In-Reply-To: References: Message-ID: <575417F7.8040901@gmail.com> On 05/19/2016 11:27 PM, Daniel Pfeifer wrote: > On Wed, Feb 10, 2016 at 12:12 AM, Stephen Kelly wrote: >> 1) Make cmLocalGenerator not inherit cmOutputConverter >> * Change enums like cmLocalGenerator::START_OUTPUT with sed. See >> >> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eac15298 >> >> for a similar sed command to achieve this. >> >> * Remove inheritance. Implement Convert() methods in cmLocalGenerator for >> source compatibility which instantiate and use a cmOutputConverter as in >> >> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4d8b79ad > That may change behavior because the LinkScriptShell member may have > the wrong value. > I am currently digging deeper. Yes, that looks like it requires deeper digging. In commit v3.3.0-rc1~29^2~1 (cmState: Host some state from the cmGlobalGenerator., 2015-05-24) I moved other things which are used by Convert() APIs to cmState, but the LinkScriptShell didn't seem to belong there. I was hoping the callers which need LinkScriptShell would manage that state themselves somehow, but it would take some deep digging and probably refactoring of the makefile generator to do that. Did your digging turn anything up? Thanks, Steve. From roman.wueger at gmx.at Sun Jun 5 16:20:29 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Sun, 5 Jun 2016 22:20:29 +0200 Subject: [cmake-developers] Productbuild CPack generator In-Reply-To: <1290594528.41531867.1464883412262.JavaMail.zimbra@elemtech.com> References: <42976E66-C80C-4B8E-A452-6F59D79FD54A@codexdigital.com> <1290594528.41531867.1464883412262.JavaMail.zimbra@elemtech.com> Message-ID: <0B89C9F0-C721-4573-9DF2-8A7807C7CCCD@gmx.at> Is it in CMake 3.6.x? Regards Roman > Am 02.06.2016 um 18:03 schrieb clinton at elemtech.com: > > Hi Harry, > > I have submitted a productbuild generator this morning. > https://cmake.org/gitweb?p=cmake.git;a=commit;h=b746bd5c > > Its capabilities should be about equal to the PackageMaker generator. The code for distribution.xml is shared between PackageMaker and productbuild. > The preflight/postflight script support should be better with this new generator than with PackageMaker. > > Please do help with testing and development. > > From your other email with suggestions, I have implemented the --version parameter for pkgbuild and product build, and fixed finding the pkgutil and productbuild exectuables. > > I tried a user controlled setting for --install-location but ran into some difficulty getting cmCPackGenerator to cooperate. > I decided to leave --install-location as '/' and do not see any negative effects of that. That can be revisited, of course. > > Does anyone here know if we have test coverage already for some cpack generators where we create a package, then unpack it to verify the results? > > Clint > > ----- On Jun 2, 2016, at 6:21 AM, Harry Mallon wrote: > I found this on the other mailing list but it isn't getting much love. Is anyone out there who can tell me how far from being merged in it is? It would really reduce the hackery in our cmake scripts here and I am happy to contribute to it's testing and development if I get some time. > http://public.kitware.com/pipermail/cmake/2016-May/063493.html > > Harry > Harry Mallon > CODEX | Software Engineer > > 60 Poland Street | London | England | W1F 7NT > E harry at codexdigital.com | T +44 203 7000 989 > Website | Facebook | Twitter > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/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 > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/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 mantis at public.kitware.com Mon Jun 6 08:29:31 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 6 Jun 2016 08:29:31 -0400 Subject: [cmake-developers] [CMake 0016136]: cmake --build can not build several targets Message-ID: <7a82e823e13f7cd89c20c8092b49daae@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=16136 ====================================================================== Reported By: Tobias Hunger Assigned To: ====================================================================== Project: CMake Issue ID: 16136 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-06-06 08:29 EDT Last Modified: 2016-06-06 08:29 EDT ====================================================================== Summary: cmake --build can not build several targets Description: I am using cmake --build in Qt Creator now and got feedback that all but the last target passed to cmake --build . --target a --target b are ignored. It would be really convenient to be able to build more than one target in one go using cmake --build. Steps to Reproduce: 1) Generate any cmake project with two targets defined called A and B. 2) try to build both targets at once using cmake --build . --target A --target B 3) Watch as only target B is built. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-06-06 08:29 Tobias Hunger New Issue ====================================================================== From brad.king at kitware.com Mon Jun 6 09:28:31 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 6 Jun 2016 09:28:31 -0400 Subject: [cmake-developers] Productbuild CPack generator In-Reply-To: <1290594528.41531867.1464883412262.JavaMail.zimbra@elemtech.com> References: <42976E66-C80C-4B8E-A452-6F59D79FD54A@codexdigital.com> <1290594528.41531867.1464883412262.JavaMail.zimbra@elemtech.com> Message-ID: <57557A7F.90002@kitware.com> On 06/02/2016 12:03 PM, clinton at elemtech.com wrote: > I have submitted a productbuild generator this morning. Clinton, I see you followed up with some fixups to the topic and have now squashed it down. I've extended the revised topic with release notes: Help: Add notes for 'productbuild' topic https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=63e5eb5f Is the topic ready for 'master' now? Thanks, -Brad From brad.king at kitware.com Mon Jun 6 09:29:48 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 6 Jun 2016 09:29:48 -0400 Subject: [cmake-developers] Productbuild CPack generator In-Reply-To: <0B89C9F0-C721-4573-9DF2-8A7807C7CCCD@gmx.at> References: <42976E66-C80C-4B8E-A452-6F59D79FD54A@codexdigital.com> <1290594528.41531867.1464883412262.JavaMail.zimbra@elemtech.com> <0B89C9F0-C721-4573-9DF2-8A7807C7CCCD@gmx.at> Message-ID: <57557ACC.4080804@kitware.com> On 06/05/2016 04:20 PM, Roman W?ger wrote: > Is it in CMake 3.6.x? No, this is brand new post-3.6 development. -Brad From brad.king at kitware.com Mon Jun 6 09:36:52 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 6 Jun 2016 09:36:52 -0400 Subject: [cmake-developers] FindVulkan.cmake In-Reply-To: <57532402.40007@anteru.net> References: <57532402.40007@anteru.net> Message-ID: <57557C74.30405@kitware.com> On 06/04/2016 02:54 PM, Matth?us G. Chajdas wrote: > I've pushed an add-FindVulkan topic branch which adds a module to search > for the Vulkan graphics API (https://www.khronos.org/vulkan/). > > I'm also happy to maintain this going forward. Thanks. Please run the CMake test suite and fix the ModuleNotices test failure. Then squash the topic back together and merge to 'next' for testing. -Brad From clinton at elemtech.com Mon Jun 6 09:57:12 2016 From: clinton at elemtech.com (clinton at elemtech.com) Date: Mon, 06 Jun 2016 07:57:12 -0600 Subject: [cmake-developers] Productbuild CPack generator Message-ID: <20160606135716.3E2B86001A1@mta2.zcs.xmission.com> An HTML attachment was scrubbed... URL: From Michael.Jaentsch at gmx.de Mon Jun 6 10:11:50 2016 From: Michael.Jaentsch at gmx.de (=?UTF-8?Q?=22Michael_J=C3=A4ntsch=22?=) Date: Mon, 6 Jun 2016 16:11:50 +0200 Subject: [cmake-developers] Bug in CMake 3.6.0-rc1: Generated Ninja files do not work on Windows Message-ID: An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Jun 6 11:00:49 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 6 Jun 2016 11:00:49 -0400 Subject: [cmake-developers] Bug in CMake: Generated Ninja files do not work on Windows In-Reply-To: References: Message-ID: <57559021.2000907@kitware.com> On 06/06/2016 10:11 AM, "Michael J?ntsch" wrote: > I would like to report a bug which I found in CMake 3.6.0-rc1. However, > it is also present in release 3.5.2 and probably earlier releases as well. > > Description: > The generated rule in rules.ninja for linking static libraries contains > the command for actual linking and an additional command ": $TARGET_FILE". > This works fine on linux but fails on windows (":" is not a valid command). I'm not able to see the behavior you describe. The Ninja generator is well-tested on Windows. The code that generates a ":" command is here: https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmLocalNinjaGenerator.cxx;hb=v3.6.0-rc1#l291 but is conditioned to generate "cd ." on Windows hosts instead. Where did you get the CMake binary you're running? What toolchain are you using to build? Can you provide a sample CMakeLists.txt file (or source tarball) that shows the problem? Thanks, -Brad From cmake at anteru.net Mon Jun 6 11:09:29 2016 From: cmake at anteru.net (=?UTF-8?Q?Matth=c3=a4us_G._Chajdas?=) Date: Mon, 6 Jun 2016 17:09:29 +0200 Subject: [cmake-developers] FindVulkan.cmake In-Reply-To: <57557C74.30405@kitware.com> References: <57532402.40007@anteru.net> <57557C74.30405@kitware.com> Message-ID: <57559229.2040104@anteru.net> Hi Brad, thanks a lot. Is this make test or is there something special needed to get the ModuleNotices? make test is super-slow, I wonder if there's a faster way to get to the relevant test. Cheers, Matth?us Am 06.06.2016 um 15:36 schrieb Brad King: > On 06/04/2016 02:54 PM, Matth?us G. Chajdas wrote: >> I've pushed an add-FindVulkan topic branch which adds a module to search >> for the Vulkan graphics API (https://www.khronos.org/vulkan/). >> >> I'm also happy to maintain this going forward. > > Thanks. Please run the CMake test suite and fix the ModuleNotices > test failure. Then squash the topic back together and merge to > 'next' for testing. > > -Brad > From brad.king at kitware.com Mon Jun 6 11:22:17 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 6 Jun 2016 11:22:17 -0400 Subject: [cmake-developers] FindVulkan.cmake In-Reply-To: <57559229.2040104@anteru.net> References: <57532402.40007@anteru.net> <57557C74.30405@kitware.com> <57559229.2040104@anteru.net> Message-ID: <57559529.2030208@kitware.com> On 06/06/2016 11:09 AM, Matth?us G. Chajdas wrote: > thanks a lot. Is this make test or is there something special needed to > get the ModuleNotices? make test is super-slow, I wonder if there's a > faster way to get to the relevant test. Just run: ctest -R ModuleNotices To run the whole test suite in parallel: ctest -j 8 or: make test ARGS='-j 8' -Brad From cmake at anteru.net Mon Jun 6 11:31:40 2016 From: cmake at anteru.net (=?UTF-8?Q?Matth=c3=a4us_G._Chajdas?=) Date: Mon, 6 Jun 2016 17:31:40 +0200 Subject: [cmake-developers] FindVulkan.cmake In-Reply-To: <57559529.2030208@kitware.com> References: <57532402.40007@anteru.net> <57557C74.30405@kitware.com> <57559229.2040104@anteru.net> <57559529.2030208@kitware.com> Message-ID: <5755975C.4020300@anteru.net> Thanks a lot! I've pushed a squashed commit which does everything in one go, and merged it into next. Cheers, Matth?us Am 06.06.2016 um 17:22 schrieb Brad King: > On 06/06/2016 11:09 AM, Matth?us G. Chajdas wrote: >> thanks a lot. Is this make test or is there something special needed to >> get the ModuleNotices? make test is super-slow, I wonder if there's a >> faster way to get to the relevant test. > > Just run: > > ctest -R ModuleNotices > > To run the whole test suite in parallel: > > ctest -j 8 > > or: > > make test ARGS='-j 8' > > -Brad > From Tobias.Hunger at qt.io Mon Jun 6 11:39:31 2016 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Mon, 6 Jun 2016 15:39:31 +0000 Subject: [cmake-developers] CMake daemon-mode Message-ID: <1465227569.811.38.camel@qt.io> Hi everybody, I want the cmake daemon mode Stephen Kelly proposed a while back. In my opinion this could become a game changer. Unfortunately Stephen told me that he did not have the resources to push this forward at this time. This is why I started working on making Stephen's code merge-able and more robust. I will also volunteer to help maintain this code going forward. My main interest is getting project structure reported out of cmake. So this is what I did start out with. The cool features Stephen demo-ed in his blog https://steveire.wordpress.com/2016/01/24/cmake-daemon-for-user-tools/ are definitely on my wish list though, but I need first class cmake project support first -- with all the information Qt Creator can currently not get its hands on. So I set up a branch over on github and did some hacking: https://github.com/hunger/CMake/commits/daemon-mode Status: =============== So far I copied over the daemon itself from Stephen. On top of that I added some nicer request/respond handling code (you get pretty similar messages from everything, you can set a cookie in a request, which will be handed back on response/error, there is a defined way to report a response or an error condition), progress reporting (directly hooked up to cmake), and a couple of basic commands to get started (reset, etc.), and some future-proofing by being able to support several versions of the daemon protocol. This infrastructure part is pretty solid by now, and has documentation and tests. On top of that I started to work towards loading a project and extracting the project structure from it. This part is still pretty much in flux as I learn where all the bits and pieces of data are stored in cmake. This part is without proper documentation and tests at this time. I do not consider this branch merge-worthy yet, but I would appreciate feedback on the patch set *A LOT*, ranging from coding style issues up to hints about things I should add to enable more use-cases, or hints on how to get to information currently missing from the output. A big chunk of Stephen's work has not even landed in my branch yet. Since cmake reformated all the source in the meantime it is a bit tedious to apply patches from his tree and I have simply not yet needed the changes as I did not venture where he went yet. It also leaves daemon-mode as a rather separate set of patches that is not changing core cmake components. I also hope this helps with review at this time. Run through: =============== Start "cmake -E daemon" (no additional parameters required). This will enable daemon-mode and allow you to send magic text via stdin to the daemon, who will respond with magic text on stdout. We will probably want to change that later to a channel that does not get interleaved with cmake output, but for now it works well enough and is really easy to test. A typical session will currently include the following messages sent to the cmake daemon: [== CMake MetaMagic ==[ {"protocolVersion":{"major":0,"minor":1},"type":"handshake"} ]== CMake MetaMagic ==] This needs to be the first thing sent as it establishes the protocol version, right after the daemon reports the available protocol versions on start-up. [== CMake MetaMagic ==[ {"type":"setGlobalSettings", "currentGenerator":"Ninja", "sourceDirectory":"/home/code/src/cmake", "buildDirectory":"/tmp/cmake-build- test"} ]== CMake MetaMagic ==] This sets up a new build directory /tmp/cmake-build-test for the sources found in /home/code/src/cmake, using the Ninja generator. You should be able to leave out the currentGenerator and the sourceDirectory if the buildDirectory already exists. [== CMake MetaMagic ==[ {"type":"configure"} ]== CMake MetaMagic ==] Configures the project. You can also try: [== CMake MetaMagic ==[ {"type":"configure", "cacheArguments":["-Dsomething=else"]} ]== CMake MetaMagic ==] to pass configure arguments along to cmake. Next step is: [== CMake MetaMagic ==[ {"type":"generate"} ]== CMake MetaMagic ==] which will generate the build system in the build directory. This and configure will produce progress output along the way. At this point you can query the project structure: [== CMake MetaMagic ==[ {"type":"project"} ]== CMake MetaMagic ==] This will dump a lot of output:-) You can trim down on that a bit by limiting target types, etc. Additional commands supported at this time: [== CMake MetaMagic ==[ {"type":"globalSettings"} ]== CMake MetaMagic ==] which lists the things you can set via "setGlobalSettings". [== CMake MetaMagic ==[ {"type":"reset"} ]== CMake MetaMagic ==] which will reset the daemon to its default state. Todo: =============== * Handle toolsets for generators * Get CMakeCache via the daemon (after configure?) * Get build system files from the daemon (after configure?) * Get missing information on the project: ???* Defines ???* Compiler flags ? ?* Information on linkage of targets * Group similar sources to shorten the output * Support cmake --build via the daemon (optional?) * Support cmake code completion * Support cmake debugging Help needed: =============== Please help to support your use-cases. Please report what information you would like to have available from your cmake projects via daemon-mode. Patches are of course welcome at any time! Any help in getting any interesting information out of cmake is highly appreciated, too. At this time I think I will need to duplicate a chunk of code from one of the generators to find the flags. Is that really necessary? If so: Which generator should I copy the code from? Best Regards, Tobias -- Tobias Hunger,?Senior?Software Engineer?| The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From brad.king at kitware.com Mon Jun 6 13:24:00 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 6 Jun 2016 13:24:00 -0400 Subject: [cmake-developers] CMake daemon-mode In-Reply-To: <1465227569.811.38.camel@qt.io> References: <1465227569.811.38.camel@qt.io> Message-ID: <5755B1AF.3000504@kitware.com> On 06/06/2016 11:39 AM, Tobias Hunger wrote: > This is why I started working on making Stephen's code merge-able and more > robust. I will also volunteer to help maintain this code going forward. Great, thanks! Hopefully I will have time to look at this in more detail soon. For now here are a few responses. > So far I copied over the daemon itself from Stephen. On top of that I added some > nicer request/respond handling code (you get pretty similar messages from > everything, you can set a cookie in a request, which will be handed back on > response/error, there is a defined way to report a response or an error > condition), progress reporting (directly hooked up to cmake), and a couple of > basic commands to get started (reset, etc.), and some future-proofing by being > able to support several versions of the daemon protocol. Good. I like the use of libuv. I've been meaning to add the infrastructure to make libuv available as something we can use in CMake upstream so that we can port process execution away from KWSys and to libuv. The daemon mode will be a great client for libuv too. > A big chunk of Stephen's work has not even landed in my branch yet. Since cmake > reformated all the source in the meantime it is a bit tedious to apply patches > from his tree and I have simply not yet needed the changes as I did not venture > where he went yet. See commit v3.6.0-rc1~54^2~2 (82df6deaaf). Its commit message explains how to rebase across the style transition. If you rebase the original "cmake-daemon" branch on that then we can rewrite the style to make cherry-picking later easier. > At this time I think I will need to duplicate a chunk of code from one of the > generators to find the flags. Is that really necessary? If so: Which generator > should I copy the code from? We should be able to refactor things to share the flags computation. Methods like cmLocalGenerator::GetTargetFlags cmLocalGenerator::GetIncludeDirectories are meant to be used across multiple generators. Due to historical evolution in generator design not everything has been refactored to cleanly share such infrastructure across all generators. Stephen made a lot of progress on that front, but there is still a way to go IIRC. -Brad From daniel at pfeifer-mail.de Mon Jun 6 17:14:56 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Mon, 6 Jun 2016 23:14:56 +0200 Subject: [cmake-developers] Developer tasks - Refactoring In-Reply-To: <575417F7.8040901@gmail.com> References: <575417F7.8040901@gmail.com> Message-ID: On Sun, Jun 5, 2016 at 2:15 PM, Stephen Kelly wrote: > On 05/19/2016 11:27 PM, Daniel Pfeifer wrote: >> On Wed, Feb 10, 2016 at 12:12 AM, Stephen Kelly wrote: >>> 1) Make cmLocalGenerator not inherit cmOutputConverter >>> * Change enums like cmLocalGenerator::START_OUTPUT with sed. See >>> >>> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eac15298 >>> >>> for a similar sed command to achieve this. >>> >>> * Remove inheritance. Implement Convert() methods in cmLocalGenerator for >>> source compatibility which instantiate and use a cmOutputConverter as in >>> >>> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4d8b79ad >> That may change behavior because the LinkScriptShell member may have >> the wrong value. >> I am currently digging deeper. > > Yes, that looks like it requires deeper digging. > > In commit v3.3.0-rc1~29^2~1 (cmState: Host some state from the > cmGlobalGenerator., 2015-05-24) I moved other things which are used by > Convert() APIs to cmState, but the LinkScriptShell didn't seem to belong > there. > > I was hoping the callers which need LinkScriptShell would manage that > state themselves somehow, but it would take some deep digging and > probably refactoring of the makefile generator to do that. > > Did your digging turn anything up? Here is what I found. * GetFortranFormat is called with an object, even though it is a static member function. (That is easy to refactor.) * SetLinkScriptShell is called from two places: cmMakefileExecutableTargetGenerator::WriteExecutableRule and cmMakefileLibraryTargetGenerator::WriteLibraryRules. * We can instantiate a cmOutputConverter in those places and then pass it along the call tree in all branches that contain calls to Convert. * Doxygen's call-graphs and caller-graphs are not reliable. Doxygen sometimes lies. From steveire at gmail.com Tue Jun 7 01:42:58 2016 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 7 Jun 2016 07:42:58 +0200 Subject: [cmake-developers] Developer tasks - Refactoring In-Reply-To: References: <575417F7.8040901@gmail.com> Message-ID: <57565EE2.2010505@gmail.com> On 06/06/2016 11:14 PM, Daniel Pfeifer wrote: > Here is what I found. > > * SetLinkScriptShell is called from two places: > cmMakefileExecutableTargetGenerator::WriteExecutableRule and > cmMakefileLibraryTargetGenerator::WriteLibraryRules. > * We can instantiate a cmOutputConverter in those places and then pass > it along the call tree in all branches that contain calls to Convert. I don't think that's the right approach. It just worsens spaghetti code and an antipattern in CMake which is already too widespread. Stepping back a bit to look at the more general problem in CMake: It is fairly common in CMake code to have methods used throughout the codebase which take parameters and then use the parameters in if() conditions to change the behavior of the method in significant ways. This is an anti-pattern and a code smell. It couples all code which calls the method and makes it harder to refactor, as you now see with Convert(). It violates: https://en.wikipedia.org/wiki/Interface_segregation_principle I fixed some of the instances of it in my 15-years-worth-of-cmake-clean-up-in-9-months last year. Unfortunately because it is so common in CMake, this pattern still grows in the codebase. See eg cmake::GetSuppressDeprecatedWarnings and related methods which take a cmMakefile which defaults to null. Those methods exist since v3.5.0-rc1~165^2 (Explicitly enable deprecated warnings by default., 2015-11-29). Notice how there is only ONE caller where the cmMakefile is not-null! So it makes sense to take the condition out of the inside of the method and put it in the call site. It simplifies everything: https://github.com/steveire/CMake/commit/86d13501f3253c5489b8f6abf21b6a983481a77c I didn't manage to get enough interest in that commit or the rest of the branch to get it merged: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15607 but I would like your review of the branch if you have time. Anyway, back to Convert()... The reason I listed this refactoring of removal of cmOutputConverter as a base of cmLocalGenerator in the OP of this thread is to create separation of compute-time code from generate-time code. So let's keep that in mind as a goal. Generate time should be just for generating. If we have that strict design, it benefits the daemon because that needs to configure and compute, and it benefits a multi-toolchain feature architecture because that needs to configure for multiple toolchains, compute across the result and then generate once (I'm talking about an idea evolved from http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7272 in case you never followed that). Notice that Convert() is called at configure time, compute time and generate time currently. In the very end: 1) It should only be called at configure and compute time 2) CMake should create some state at compute time using APIs similar to Convert() 3) Configure-time and compute-time Convert() behavior and APIs will not necessarily be the same because the needs are different - you will see that if you analyze the users of the Convert method and the OutputFormat enum. So, look into the Convert() methods. There are two overloads. Both do some computation, then call ConvertToOutputFormat(). What does ConvertToOutputFormat() do? It does nothing at all if the OutputFormat is UNCHANGED. What is the default value of OutputFormat? It is UNCHANGED! I guess you can see where this is going: 1) The parts of Convert() which come before the ConvertToOutputFormat() calls should be extracted into two new overloads, maybe called RawConvert(). The name is not great, but in the end the existing Convert() methods can probably be deleted and the Raw* ones renamed. 2) Convert() should call RawConvert() and pass the result to ConvertToOutputFormat(). 3) Callers of Convert() should be ported to RawConvert(). A quick way to do most of this is to find all callers of Convert() which pass only two arguments and change those to RawConvert(). Note that there are other callers which explicitly pass UNCHANGED! 4) Analyze remaining callers of Convert() and inspect the OutputFormat they pass. For example see the output of 'git grep -w RESPONSE'. That enum value can probably be removed and the EscapeForShell inlined into the callers. 5) Do the same analysis for the other enum values. SHELL is used a lot. In the end some new method might make sense for the SHELL case instead of that enum. 6) Look at the result and see if there is an obvious way to go from here, including for the LinkScriptShell case. The case where that condition is used might be the last remaining case when the above is done, and a different design can be considered. 7) The OutputFormat enum and the LinkScriptShell can probably be removed in the end, with their callers ported to more-purposeful methods. The whole point of this is to reach the essence of what all this Convert() stuff in CMake is really about. It's currently very confused and fixing that should be easy in part (such as porting to RawConvert()), and have an immediate positive effect. Does that make sense? Thanks, Steve. From steveire at gmail.com Tue Jun 7 02:10:22 2016 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 7 Jun 2016 08:10:22 +0200 Subject: [cmake-developers] CMake daemon-mode In-Reply-To: <1465227569.811.38.camel@qt.io> References: <1465227569.811.38.camel@qt.io> Message-ID: <5756654E.4060309@gmail.com> On 06/06/2016 05:39 PM, Tobias Hunger wrote: > Hi everybody, > > I want the cmake daemon mode Stephen Kelly proposed a while back. In my opinion > this could become a game changer. Unfortunately Stephen told me that he did not > have the resources to push this forward at this time. It is almost the case that you and Daniel are picking up where I left of in different areas. That's two resources :). Which is to say - I'm happy to give advice and guidance on this where I can, but I'm not currently spending my free time hacking on CMake. Thanks, Steve. From Michael.Jaentsch at gmx.de Tue Jun 7 02:07:55 2016 From: Michael.Jaentsch at gmx.de (Michael.Jaentsch at gmx.de) Date: Tue, 7 Jun 2016 08:07:55 +0200 Subject: [cmake-developers] Bug in CMake: Generated Ninja files do not work on Windows Message-ID: Hi, ? problem is not the POST_BUILD which is set to "cd ." as you said but the CMAKE_CXX_ARCHIVE_FINISH which is before the POST_BUILD ? I attached a small example which is using a cross toolchain for cross compiling mips24. ? On my windows host it generates a build rule which looks like this: rule CXX_STATIC_LIBRARY_LINKER__ctrl ? command = cmd.exe /C "$PRE_LINK && "C:\Program Files\CMake\bin\cmake.exe" -E remove $TARGET_FILE && D:\gcc\win32\mips-sde-elf\bin\mips-sde-elf-ar.exe qc $TARGET_FILE $LINK_FLAGS $in && : $TARGET_FILE && $POST_BUILD" ? description = Linking CXX static library $TARGET_FILE ? restat = $RESTAT ? You see the : command before the $POST_BUILD ? Michael ? Gesendet:?Montag, 06. Juni 2016 um 17:00 Uhr Von:?"Brad King" An:?"Michael J?ntsch" Cc:?cmake-developers at cmake.org Betreff:?Re: [cmake-developers] Bug in CMake: Generated Ninja files do not work on Windows On 06/06/2016 10:11 AM, "Michael J?ntsch" wrote: > I would like to report a bug which I found in CMake 3.6.0-rc1. However, > it is also present in release 3.5.2 and probably earlier releases as well. > > Description: > The generated rule in rules.ninja for linking static libraries contains > the command for actual linking and an additional command ": $TARGET_FILE". > This works fine on linux but fails on windows (":" is not a valid command). I'm not able to see the behavior you describe. The Ninja generator is well-tested on Windows. The code that generates a ":" command is here: https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmLocalNinjaGenerator.cxx;hb=v3.6.0-rc1#l291 but is conditioned to generate "cd ." on Windows hosts instead. Where did you get the CMake binary you're running? What toolchain are you using to build? Can you provide a sample CMakeLists.txt file (or source tarball) that shows the problem? Thanks, -Brad ? -------------- next part -------------- A non-text attachment was scrubbed... Name: ninjaTest.zip Type: application/zip Size: 1809 bytes Desc: not available URL: From daniel at pfeifer-mail.de Tue Jun 7 05:27:37 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Tue, 7 Jun 2016 11:27:37 +0200 Subject: [cmake-developers] CMake daemon-mode In-Reply-To: <1465227569.811.38.camel@qt.io> References: <1465227569.811.38.camel@qt.io> Message-ID: On Mon, Jun 6, 2016 at 5:39 PM, Tobias Hunger wrote: > Please help to support your use-cases. A while ago I wrote a graphical cache editor in GTK: https://github.com/purpleKarrot/cmake-gtk The tool reads the cache and provides a graphical view to modify it. It can then write the cache, run cmake, and read it back. I wanted to see how close we can get to ccmake or cmake-gui without linking against CMakeLib. Here is what I was *unable* to achieve: * Separating Configure from Generate (two buttons). * Progress bar. Quite a short list, right? If we have a daemon mode that provides this information (as your implementation already does), we could let ccmake and cmake-gui use the daemon instead of linking against CMakeLib. cheers, Daniel > Please report what information you would like to have available from your cmake > projects via daemon-mode. > > Patches are of course welcome at any time! > > Any help in getting any interesting information out of cmake is highly > appreciated, too. > > At this time I think I will need to duplicate a chunk of code from one of the > generators to find the flags. Is that really necessary? If so: Which generator > should I copy the code from? > > Best Regards, > Tobias > > -- > Tobias Hunger, Senior Software Engineer | The Qt Company > The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin > Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius, Mika Harjuaho. Sitz der > Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/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 daniel at pfeifer-mail.de Tue Jun 7 05:42:15 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Tue, 7 Jun 2016 11:42:15 +0200 Subject: [cmake-developers] CMake daemon-mode In-Reply-To: <5755B1AF.3000504@kitware.com> References: <1465227569.811.38.camel@qt.io> <5755B1AF.3000504@kitware.com> Message-ID: On Mon, Jun 6, 2016 at 7:24 PM, Brad King wrote: > On 06/06/2016 11:39 AM, Tobias Hunger wrote: > >> A big chunk of Stephen's work has not even landed in my branch yet. Since cmake >> reformated all the source in the meantime it is a bit tedious to apply patches >> from his tree and I have simply not yet needed the changes as I did not venture >> where he went yet. > > See commit v3.6.0-rc1~54^2~2 (82df6deaaf). Its commit message explains > how to rebase across the style transition. If you rebase the original > "cmake-daemon" branch on that then we can rewrite the style to make > cherry-picking later easier. When I rebased my own branches across the style transiton, I found the process quite straight forward. I can help with the style transition if someone rebases to 82df6deaaf. When I tried to rebase steve's work, it was not the style transition but changes like the following that I struggled with: https://github.com/Kitware/CMake/commit/563bf9dd8a207e04697a92d8bcd239f52400b355 cheers, Daniel From tobias.hunger at gmail.com Tue Jun 7 05:59:45 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Tue, 7 Jun 2016 11:59:45 +0200 Subject: [cmake-developers] CMake daemon-mode In-Reply-To: References: <1465227569.811.38.camel@qt.io> Message-ID: Hi Daniel, On Tue, Jun 7, 2016 at 11:27 AM, Daniel Pfeifer wrote: > On Mon, Jun 6, 2016 at 5:39 PM, Tobias Hunger wrote: >> Please help to support your use-cases. > > A while ago I wrote a graphical cache editor in GTK: > https://github.com/purpleKarrot/cmake-gtk > The tool reads the cache and provides a graphical view to modify it. > It can then write the cache, run cmake, and read it back. > > I wanted to see how close we can get to ccmake or cmake-gui without > linking against CMakeLib. > > Here is what I was *unable* to achieve: > * Separating Configure from Generate (two buttons). > * Progress bar. > > Quite a short list, right? > If we have a daemon mode that provides this information (as your > implementation already does), we could let ccmake and cmake-gui use > the daemon instead of linking against CMakeLib. If the daemon can expose the right information, then you could even be able to write a generator in e.g. python;-) Best Regards, Tobias From Harry at codexdigital.com Tue Jun 7 07:29:39 2016 From: Harry at codexdigital.com (Harry Mallon) Date: Tue, 7 Jun 2016 11:29:39 +0000 Subject: [cmake-developers] Problem with find_path and Frameworks Message-ID: I have updated my patch with new simplified logic and a test. Harry Mallon CODEX | Software Engineer 60 Poland Street | London | England | W1F 7NT E harry at codexdigital.com | T +44 203 7000 989 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-a-problem-where-using-find_path-to-find-a-header.patch Type: application/octet-stream Size: 2647 bytes Desc: 0001-Fix-a-problem-where-using-find_path-to-find-a-header.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: From tobias.hunger at gmail.com Tue Jun 7 09:07:19 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Tue, 7 Jun 2016 15:07:19 +0200 Subject: [cmake-developers] CMake daemon-mode In-Reply-To: <5755B1AF.3000504@kitware.com> References: <1465227569.811.38.camel@qt.io> <5755B1AF.3000504@kitware.com> Message-ID: Hi Brad! On Mon, Jun 6, 2016 at 7:24 PM, Brad King wrote: >> A big chunk of Stephen's work has not even landed in my branch yet. Since cmake >> reformated all the source in the meantime it is a bit tedious to apply patches >> from his tree and I have simply not yet needed the changes as I did not venture >> where he went yet. > > See commit v3.6.0-rc1~54^2~2 (82df6deaaf). Its commit message explains > how to rebase across the style transition. If you rebase the original > "cmake-daemon" branch on that then we can rewrite the style to make > cherry-picking later easier. Thanks, that might prove helpful. So far i basically picked the same sha, that worked surprisingly well. >> At this time I think I will need to duplicate a chunk of code from one of the >> generators to find the flags. Is that really necessary? If so: Which generator >> should I copy the code from? > > We should be able to refactor things to share the flags computation. > Methods like > > cmLocalGenerator::GetTargetFlags > cmLocalGenerator::GetIncludeDirectories > > are meant to be used across multiple generators. Due to historical > evolution in generator design not everything has been refactored to > cleanly share such infrastructure across all generators. Stephen made > a lot of progress on that front, but there is still a way to go IIRC. So is that the complete picture? You can override compile time flags on a per-file basis, based on the code I ran across in the ninja generator:-) Do I still need to add those per-source-file flags somehow? Best Regards, Tobias From brad.king at kitware.com Tue Jun 7 09:21:57 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 7 Jun 2016 09:21:57 -0400 Subject: [cmake-developers] CMake daemon-mode In-Reply-To: References: <1465227569.811.38.camel@qt.io> <5755B1AF.3000504@kitware.com> Message-ID: <5756CA75.1030104@kitware.com> On 06/07/2016 09:07 AM, Tobias Hunger wrote: >> We should be able to refactor things to share the flags computation. >> Methods like >> >> cmLocalGenerator::GetTargetFlags >> cmLocalGenerator::GetIncludeDirectories >> >> are meant to be used across multiple generators. > > So is that the complete picture? No, just a starting point. Note that we have no API to get all the flags for a source because all the generators collect target-wide and per-source flags separately. They are not combined until the native build tool constructs the final command line. The implementation of CMAKE_EXPORT_COMPILE_COMMANDS may already have some code to combine flags within CMake directly though. > You can override compile time flags on a per-file basis, based on the > code I ran across in the ninja generator:-) Do I still need to add > those per-source-file flags somehow? Yes. It looks like each generator currently does its own call to source->GetProperty("COMPILE_FLAGS") to get the per-source flags. The daemon would have to do something similar, possibly by factoring the logic out of the generators into a common helper. -Brad From brad.king at kitware.com Tue Jun 7 09:22:01 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 7 Jun 2016 09:22:01 -0400 Subject: [cmake-developers] CMake daemon-mode In-Reply-To: References: <1465227569.811.38.camel@qt.io> Message-ID: <5756CA79.9070001@kitware.com> On 06/07/2016 05:27 AM, Daniel Pfeifer wrote: > If we have a daemon mode that provides this information (as your > implementation already does), we could let ccmake and cmake-gui use > the daemon instead of linking against CMakeLib. That would be really nice. A lot of the state space in CMake's internal representation is muddled by historical evolution of the different ways we have to invoke it (command line, ccmake, cmake-gui, ctest internals, etc.). Separating the interactive modes would be a nice cleanup. -Brad From brad.king at kitware.com Tue Jun 7 09:22:04 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 7 Jun 2016 09:22:04 -0400 Subject: [cmake-developers] Problem with find_path and Frameworks In-Reply-To: References: Message-ID: <5756CA7C.5030602@kitware.com> On 06/07/2016 07:29 AM, Harry Mallon wrote: > I have updated my patch with new simplified logic and a test. Thanks. I revised the test to not depend on a specific framework path to exist on the system (it didn't on mine). Merged to 'next' for testing: find_path: Fix location of in a framework on OS X https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=188baef0 -Brad From brad.king at kitware.com Tue Jun 7 09:37:05 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 7 Jun 2016 09:37:05 -0400 Subject: [cmake-developers] Bug in CMake: Generated Ninja files do not work on Windows In-Reply-To: References: Message-ID: <5756CE01.1060108@kitware.com> On 06/07/2016 02:07 AM, Michael.Jaentsch at gmx.de wrote: > problem is not the POST_BUILD which is set to "cd ." as you said but the > CMAKE_CXX_ARCHIVE_FINISH which is before the POST_BUILD [snip] > command = ... D:\gcc\win32\mips-sde-elf\bin\mips-sde-elf-ar.exe qc $TARGET_FILE $LINK_FLAGS $in && : $TARGET_FILE && $POST_BUILD" That is meant to be the "ranlib" call. The only way I was able to get a ":" there was by setting -DCMAKE_RANLIB=: on the command line. What is its value? See CMakeFiles/${CMAKE_VERSION}/CMakeCCompiler.cmake for a set(CMAKE_RANLIB) call. Does the toolchain provide a "ranlib" tool? -Brad From mantis at public.kitware.com Tue Jun 7 09:56:42 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 7 Jun 2016 09:56:42 -0400 Subject: [cmake-developers] [CMake 0016137]: ExternalProject_Add: Can't escape ; character in CMAKE_ARGS Message-ID: <5d4b17f645161c36a227044100f7c409@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=16137 ====================================================================== Reported By: Andry81 Assigned To: ====================================================================== Project: CMake Issue ID: 16137 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-06-07 09:56 EDT Last Modified: 2016-06-07 09:56 EDT ====================================================================== Summary: ExternalProject_Add: Can't escape ; character in CMAKE_ARGS Description: Seems ExternalProject_Add became broken from some time ago. I could not figure out when, but from version 3.5.2 (including 3.5.2-rc1) it does not work anymore. All ";" characters does replace now by space whenever and not matter how you use the expression. Steps to Reproduce: ExternalProject_Add(MySubProject SOURCE_DIR ${SUBPROJECT_ROOT} CMAKE_ARGS -DMYPATH=c:/blabla1;c:/blabla1/blabla2;c:/blabla1/blabla3 INSTALL_COMMAND "" ) Additional Information: I Tried these to workaround it: 1. Quotes around the expression ("-DMYPATH=...") 2. Backlash escaping ("-DMYPATH=...\;...") 3. LIST APPEND instead SET 4. LIST_SEPARATOR in ExternalProject_Add 5. STRING REPLACE ^^ to ; Nothing works. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-06-07 09:56 Andry81 New Issue ====================================================================== From Harry at codexdigital.com Tue Jun 7 09:41:33 2016 From: Harry at codexdigital.com (Harry Mallon) Date: Tue, 7 Jun 2016 13:41:33 +0000 Subject: [cmake-developers] Problem with find_path and Frameworks Message-ID: <244D1770-D607-4DF0-B20E-00F7F14367E1@codexdigital.com> Thanks Brad. I haven't run into a mac without /System/Library/Frameworks/Kernel.framework before but maybe it comes from XCode or something. Thanks for merging. Harry. Harry Mallon CODEX | Software Engineer 60 Poland Street | London | England | W1F 7NT E harry at codexdigital.com | T +44 203 7000 989 From Tobias.Hunger at qt.io Tue Jun 7 10:42:24 2016 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Tue, 7 Jun 2016 14:42:24 +0000 Subject: [cmake-developers] CMake daemon-mode In-Reply-To: <5755B1AF.3000504@kitware.com> References: <1465227569.811.38.camel@qt.io> <5755B1AF.3000504@kitware.com> Message-ID: <1465310542.811.42.camel@qt.io> On Mo, 2016-06-06 at 13:24 -0400, Brad King wrote: > We should be able to refactor things to share the flags computation. > Methods like > > ? cmLocalGenerator::GetTargetFlags Does this patch here make sense: https://github.com/hunger/CMake/commit/124f8295bee0c228b79a5cf38f0b2581be308118 It passes the configuration to GetTargetFlags instead of forcing it to the build type. Since I may end up with different configurations in the project structure, I think this is necessary. Best Regards, Tobias -- Tobias Hunger,?Senior?Software Engineer?| The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From brad.king at kitware.com Tue Jun 7 10:48:48 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 7 Jun 2016 10:48:48 -0400 Subject: [cmake-developers] CMake daemon-mode In-Reply-To: <1465310542.811.42.camel@qt.io> References: <1465227569.811.38.camel@qt.io> <5755B1AF.3000504@kitware.com> <1465310542.811.42.camel@qt.io> Message-ID: <5756DED0.5010404@kitware.com> On 06/07/2016 10:42 AM, Tobias Hunger wrote: > On Mo, 2016-06-06 at 13:24 -0400, Brad King wrote: >> We should be able to refactor things to share the flags computation. >> Methods like >> >> cmLocalGenerator::GetTargetFlags > > Does this patch here make sense: > > https://github.com/hunger/CMake/commit/124f8295bee0c228b79a5cf38f0b2581be308118 > > It passes the configuration to GetTargetFlags instead of forcing it to the build > type. Since I may end up with different configurations in the project structure, > I think this is necessary. Yes. Previously that method was only called in single-configuration generators so it could look up the CMAKE_BUILD_TYPE directly. In multi-config generators that variable is meaningless and instead they iterate over CMAKE_CONFIGURATION_TYPES. When you have a few such independent refactoring changes done we can look at integrating them immediately to avoid holding them externally in your daemon topic for too long. Thanks, -Brad From tobias.hunger at gmail.com Tue Jun 7 12:16:31 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Tue, 7 Jun 2016 18:16:31 +0200 Subject: [cmake-developers] CMake daemon-mode In-Reply-To: <5756DED0.5010404@kitware.com> References: <1465227569.811.38.camel@qt.io> <5755B1AF.3000504@kitware.com> <1465310542.811.42.camel@qt.io> <5756DED0.5010404@kitware.com> Message-ID: Hi Am 07.06.2016 16:48 schrieb "Brad King" : > On 06/07/2016 10:42 AM, Tobias Hunger wrote: > > On Mo, 2016-06-06 at 13:24 -0400, Brad King wrote: > >> We should be able to refactor things to share the flags computation. > >> Methods like > >> > >> cmLocalGenerator::GetTargetFlags > > > > Does this patch here make sense: > > > > > https://github.com/hunger/CMake/commit/124f8295bee0c228b79a5cf38f0b2581be308118 > > > > It passes the configuration to GetTargetFlags instead of forcing it to > the build > > type. Since I may end up with different configurations in the project > structure, > > I think this is necessary. > > Yes. Previously that method was only called in single-configuration > generators so it could look up the CMAKE_BUILD_TYPE directly. In > multi-config generators that variable is meaningless and instead they > iterate over CMAKE_CONFIGURATION_TYPES. > > When you have a few such independent refactoring changes done > we can look at integrating them immediately to avoid holding > them externally in your daemon topic for too long. > > 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 -------------- An HTML attachment was scrubbed... URL: From tobias.hunger at gmail.com Tue Jun 7 12:18:36 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Tue, 7 Jun 2016 18:18:36 +0200 Subject: [cmake-developers] CMake daemon-mode In-Reply-To: <5756DED0.5010404@kitware.com> References: <1465227569.811.38.camel@qt.io> <5755B1AF.3000504@kitware.com> <1465310542.811.42.camel@qt.io> <5756DED0.5010404@kitware.com> Message-ID: Hi Brad, sorry for the empty mail, my phone acted up:-) Am 07.06.2016 16:48 schrieb "Brad King" : > > On 06/07/2016 10:42 AM, Tobias Hunger wrote: > > On Mo, 2016-06-06 at 13:24 -0400, Brad King wrote: > >> We should be able to refactor things to share the flags computation. > >> Methods like > >> > >> cmLocalGenerator::GetTargetFlags > > > > Does this patch here make sense: > > > > https://github.com/hunger/CMake/commit/124f8295bee0c228b79a5cf38f0b2581be308118 > > > > It passes the configuration to GetTargetFlags instead of forcing it to the build > > type. Since I may end up with different configurations in the project structure, > > I think this is necessary. > > Yes. Previously that method was only called in single-configuration > generators so it could look up the CMAKE_BUILD_TYPE directly. In > multi-config generators that variable is meaningless and instead they > iterate over CMAKE_CONFIGURATION_TYPES. > > When you have a few such independent refactoring changes done > we can look at integrating them immediately to avoid holding > them externally in your daemon topic for too long. Can you take that patch from github or do you want them sent here? Best Regards, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Jun 7 13:22:58 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 7 Jun 2016 13:22:58 -0400 Subject: [cmake-developers] CMake daemon-mode In-Reply-To: References: <1465227569.811.38.camel@qt.io> <5755B1AF.3000504@kitware.com> <1465310542.811.42.camel@qt.io> <5756DED0.5010404@kitware.com> Message-ID: <575702F2.6020502@kitware.com> On 06/07/2016 12:18 PM, Tobias Hunger wrote: >> When you have a few such independent refactoring changes done >> we can look at integrating them immediately to avoid holding >> them externally in your daemon topic for too long. > > Can you take that patch from github or do you want them sent here? If it doesn't conflict with 'master' too much I can take it directly. I've cherry-picked 124f8295bee0c228b79a5cf38f0b2581be308118 and merged to 'next' for testing: cmLocalGenerator: Pass configuration to GetTargetFlags https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe0d2241 Thanks, -Brad From rleigh at codelibre.net Tue Jun 7 17:54:42 2016 From: rleigh at codelibre.net (Roger Leigh) Date: Tue, 7 Jun 2016 21:54:42 +0000 Subject: [cmake-developers] [patch] FindBZip2: Add additional debug library name Message-ID: <3481e5d9-964c-8313-631a-4a9bb956e7ba@codelibre.net> I noticed that FindBZip2.cmake was searching for the bzip2d debug library but not bz2d (it uses bz2 and bzip2 for the release library names). While bzip2[d] is the common form on Windows, which is what the upstream nmake build creates, there are at least two CMake builds for bzip2 which use the bz2 form to match the Unix naming: https://gitlab.kitware.com/ben.boeckel/common-superbuild/blob/master/projects/patches/bzip2-add-cmake.patch https://github.com/ome/ome-cmake-superbuild/blob/develop/packages/bzip2/patches/cmake.diff I've merged this bzip2-debug-names branch into next for testing. Regards, Roger From Stuart_Mentzer at objexx.com Wed Jun 8 00:33:43 2016 From: Stuart_Mentzer at objexx.com (Stuart Mentzer) Date: Wed, 8 Jun 2016 00:33:43 -0400 Subject: [cmake-developers] FindFreetype patch for Windows debug lib naming Message-ID: <3a99b00d-a99b-da5d-5eea-1923cc145fc4@objexx.com> Hello, Here is a little patch that lets FindFreetype find the debug library on Windows, where it is named with a d suffix. Much thanks to Rolf Eike Beer for help on this. Cheers, Stuart -------------- next part -------------- From 93576b26f52017eb9b60705c123be1956a512a77 Mon Sep 17 00:00:00 2001 From: Stuart Mentzer Date: Wed, 8 Jun 2016 00:26:31 -0400 Subject: [PATCH] FindFreetype updates for debug library name on Windows with d suffix --- Help/release/dev/FindFreetype-debug-libs.rst | 5 +++ Modules/FindFreetype.cmake | 47 ++++++++++++++-------------- 2 files changed, 29 insertions(+), 23 deletions(-) create mode 100644 Help/release/dev/FindFreetype-debug-libs.rst diff --git a/Help/release/dev/FindFreetype-debug-libs.rst b/Help/release/dev/FindFreetype-debug-libs.rst new file mode 100644 index 0000000..2637fb0 --- /dev/null +++ b/Help/release/dev/FindFreetype-debug-libs.rst @@ -0,0 +1,5 @@ +FindFreetype-debug-libs +-------------------------- + +* The :module:`FindFreetype` module now finds the debug library on +Windows where it is named with a d suffix. diff --git a/Modules/FindFreetype.cmake b/Modules/FindFreetype.cmake index 7d46d15..9db34d5 100644 --- a/Modules/FindFreetype.cmake +++ b/Modules/FindFreetype.cmake @@ -51,9 +51,8 @@ # wants explicit full paths and this trickery doesn't work too well. # I'm going to attempt to cut out the middleman and hope # everything still works. -find_path( - FREETYPE_INCLUDE_DIR_ft2build - ft2build.h + +set(FREETYPE_FIND_ARGS HINTS ENV FREETYPE_DIR PATHS @@ -64,6 +63,12 @@ find_path( ENV GTKMM_BASEPATH [HKEY_CURRENT_USER\\SOFTWARE\\gtkmm\\2.4;Path] [HKEY_LOCAL_MACHINE\\SOFTWARE\\gtkmm\\2.4;Path] +) + +find_path( + FREETYPE_INCLUDE_DIR_ft2build + ft2build.h + ${FREETYPE_FIND_ARGS} PATH_SUFFIXES include/freetype2 include @@ -75,16 +80,7 @@ find_path( NAMES freetype/config/ftheader.h config/ftheader.h - HINTS - ENV FREETYPE_DIR - PATHS - /usr/X11R6 - /usr/local/X11R6 - /usr/local/X11 - /usr/freeware - ENV GTKMM_BASEPATH - [HKEY_CURRENT_USER\\SOFTWARE\\gtkmm\\2.4;Path] - [HKEY_LOCAL_MACHINE\\SOFTWARE\\gtkmm\\2.4;Path] + ${FREETYPE_FIND_ARGS} PATH_SUFFIXES include/freetype2 include @@ -96,19 +92,23 @@ find_library(FREETYPE_LIBRARY freetype libfreetype freetype219 - HINTS - ENV FREETYPE_DIR - PATHS - /usr/X11R6 - /usr/local/X11R6 - /usr/local/X11 - /usr/freeware - ENV GTKMM_BASEPATH - [HKEY_CURRENT_USER\\SOFTWARE\\gtkmm\\2.4;Path] - [HKEY_LOCAL_MACHINE\\SOFTWARE\\gtkmm\\2.4;Path] + ${FREETYPE_FIND_ARGS} + PATH_SUFFIXES + lib +) +find_library(FREETYPE_LIBRARY_DEBUG + NAMES + freetyped + libfreetyped + freetype219d + ${FREETYPE_FIND_ARGS} PATH_SUFFIXES lib ) +include(SelectLibraryConfigurations) +select_library_configurations(FREETYPE) + +unset(FREETYPE_FIND_ARGS) # set the user variables if(FREETYPE_INCLUDE_DIR_ft2build AND FREETYPE_INCLUDE_DIR_freetype2) @@ -159,6 +159,7 @@ find_package_handle_standard_args( mark_as_advanced( FREETYPE_LIBRARY + FREETYPE_LIBRARY_DEBUG FREETYPE_INCLUDE_DIR_freetype2 FREETYPE_INCLUDE_DIR_ft2build ) -- 2.8.3.windows.1 From tobias.hunger at gmail.com Wed Jun 8 01:24:13 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Wed, 8 Jun 2016 07:24:13 +0200 Subject: [cmake-developers] CMake daemon-mode In-Reply-To: <575702F2.6020502@kitware.com> References: <1465227569.811.38.camel@qt.io> <5755B1AF.3000504@kitware.com> <1465310542.811.42.camel@qt.io> <5756DED0.5010404@kitware.com> <575702F2.6020502@kitware.com> Message-ID: Hi Brad, Am 07.06.2016 19:23 schrieb "Brad King" : > If it doesn't conflict with 'master' too much I can take it directly. It should not. I regularly rebase my branch on top of master. > I've cherry-picked 124f8295bee0c228b79a5cf38f0b2581be308118 and merged > to 'next' for testing: > > cmLocalGenerator: Pass configuration to GetTargetFlags > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe0d2241 Great, thanks! I would love to keep my patch set as small as possible:) Best Regards, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Jaentsch at gmx.de Wed Jun 8 03:33:18 2016 From: Michael.Jaentsch at gmx.de (=?UTF-8?Q?=22Michael_J=C3=A4ntsch=22?=) Date: Wed, 8 Jun 2016 09:33:18 +0200 Subject: [cmake-developers] Bug in CMake: Generated Ninja files do not work on Windows In-Reply-To: <5756CE01.1060108@kitware.com> References: , <5756CE01.1060108@kitware.com> Message-ID: An HTML attachment was scrubbed... URL: From steveire at gmail.com Wed Jun 8 04:05:06 2016 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 8 Jun 2016 10:05:06 +0200 Subject: [cmake-developers] CMake daemon-mode In-Reply-To: References: <1465227569.811.38.camel@qt.io> <5755B1AF.3000504@kitware.com> Message-ID: <5757D1B2.1070309@gmail.com> On 06/07/2016 11:42 AM, Daniel Pfeifer wrote: > On Mon, Jun 6, 2016 at 7:24 PM, Brad King wrote: >> On 06/06/2016 11:39 AM, Tobias Hunger wrote: >> >>> A big chunk of Stephen's work has not even landed in my branch yet. Since cmake >>> reformated all the source in the meantime it is a bit tedious to apply patches >>> from his tree and I have simply not yet needed the changes as I did not venture >>> where he went yet. >> See commit v3.6.0-rc1~54^2~2 (82df6deaaf). Its commit message explains >> how to rebase across the style transition. If you rebase the original >> "cmake-daemon" branch on that then we can rewrite the style to make >> cherry-picking later easier. > When I rebased my own branches across the style transiton, I found the > process quite straight forward. > I can help with the style transition if someone rebases to 82df6deaaf. > > When I tried to rebase steve's work, it was not the style transition > but changes like the following that I struggled with: > https://github.com/Kitware/CMake/commit/563bf9dd8a207e04697a92d8bcd239f52400b355 I have rebased it and force pushed my github branch (there are a few rebasing mistakes which I'll remove later). We hit issues at work that different clang-format versions have different behavior. There we have the luxury of providing particular binaries that every developer uses to get identical results and no diff confusion. I don't know how to solve that in CMake though. It could become an issue in the future when some contributors use clang-3.9 and others 3.8. Maybe clang-format binaries should be in the repo. Also, it seems that clang-format is not run by CI. The ProductBuild stuff doesn't seem to be clang formatted. Thanks, Steve. From Tobias.Hunger at qt.io Wed Jun 8 04:23:44 2016 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Wed, 8 Jun 2016 08:23:44 +0000 Subject: [cmake-developers] cmLocalGenerator::GetTargetFlags Message-ID: <1465374222.811.67.camel@qt.io> Hi everybody, what use is the "flags" out-parameter in cmLocalGenerator::GetTargetFlags? It is only ever set for targets of type EXECUTABLE and is filled based on the *linker language* of the target. I really do not see any use for this information, and indeed the flag seems unused in the cmake code base, except for the Ninja generator, where that may or may not make sense (probably not). Can the flag get removed altogether and the method get renamed to GetTargetLinkerFlags? Maybe it could return the linker language instead, that is a piece of data that is more important in its context IMHO. While discussing this method: How about moving the method to cmTargetGenerator? That would get rid of the target parameter. That is where I would actually look for information on targets. Which brings me back to my original question: How can I find the compiler flags in use for a cmSourceFile/cmGeneratorTarget? The only place that I found that seems to do what I want is cmCommonTargetGenerator::GetFlags. Or is that concerned about cmake internal flags that need to get mapped to compiler flags later? Is there another copy of that code in a place more convenient to use or do I need to create that? cmCommonTargetGenerator does caching of results. Should this be also done for cmLocalGenerator::GetTargetFlags, etc? Best Regards, Tobias -- Tobias Hunger,?Senior?Software Engineer?| The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From brad.king at kitware.com Wed Jun 8 10:11:28 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 8 Jun 2016 10:11:28 -0400 Subject: [cmake-developers] CMake daemon-mode In-Reply-To: <5757D1B2.1070309@gmail.com> References: <1465227569.811.38.camel@qt.io> <5755B1AF.3000504@kitware.com> <5757D1B2.1070309@gmail.com> Message-ID: <57582790.3070504@kitware.com> On 06/08/2016 04:05 AM, Stephen Kelly wrote: > I have rebased it and force pushed my github branch (there are a few > rebasing mistakes which I'll remove later). Thanks. > We hit issues at work that different clang-format versions have > different behavior. There we have the luxury of providing particular > binaries that every developer uses to get identical results and no diff > confusion. > > I don't know how to solve that in CMake though. It could become an issue > in the future when some contributors use clang-3.9 and others 3.8. Maybe > clang-format binaries should be in the repo. Right now we're using clang-format 3.8. We'll worry about such differences when they become a problem. > Also, it seems that clang-format is not run by CI. The ProductBuild > stuff doesn't seem to be clang formatted. Yeah, we haven't gotten that set up yet. Yesterday I added a topic to 'next' to fix that formatting. -Brad From brad.king at kitware.com Wed Jun 8 10:11:40 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 8 Jun 2016 10:11:40 -0400 Subject: [cmake-developers] CMake daemon-mode In-Reply-To: References: <1465227569.811.38.camel@qt.io> <5755B1AF.3000504@kitware.com> <1465310542.811.42.camel@qt.io> <5756DED0.5010404@kitware.com> <575702F2.6020502@kitware.com> Message-ID: <5758279C.1020706@kitware.com> On 06/08/2016 01:24 AM, Tobias Hunger wrote: >> cmLocalGenerator: Pass configuration to GetTargetFlags >> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe0d2241 > > Great, thanks! I had to revert it from 'next' because it caused several LinkFlags test failures. The reason is that it dropped UpperCase() on the config name when called from the Ninja generator. Please revise accordingly in combination with the refactoring discussed in the thread you started dedicated to that method. Thanks, -Brad From brad.king at kitware.com Wed Jun 8 10:12:13 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 8 Jun 2016 10:12:13 -0400 Subject: [cmake-developers] cmLocalGenerator::GetTargetFlags In-Reply-To: <1465374222.811.67.camel@qt.io> References: <1465374222.811.67.camel@qt.io> Message-ID: <575827BD.8080402@kitware.com> Hi Tobias, So it looks like I was completely wrong in pointing you at GetTargetFlags to get compiler flags. It is indeed for linker flags. On 06/08/2016 04:23 AM, Tobias Hunger wrote: > what use is the "flags" out-parameter in cmLocalGenerator::GetTargetFlags? It is > only ever set for targets of type EXECUTABLE and is filled based on the *linker > language* of the target. > > I really do not see any use for this information, and indeed the flag seems > unused in the cmake code base, except for the Ninja generator, where that may or > may not make sense (probably not). That is because when we invoke the C compiler to drive linking we pass the compiler flags from CMAKE_C_FLAGS (and similarly for CXX). For non-executables the same thing is done in a different code path here: https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmNinjaNormalTargetGenerator.cxx;hb=v3.6.0-rc1#l471 I think the comment about a mistake in the Ninja generator is telling. The AddLanguageFlags is done there for non-executables and is done in GetTargetFlags for executables. This should be refactored and made consistent. > Can the flag get removed altogether and the method get renamed to > GetTargetLinkerFlags? +1 for renaming. The best place for AddLanguageFlags to be called needs to be determined. Note that the Makefile generators use cmCommonTargetGenerator::AddFeatureFlags to call AddLanguageFlags, and that follows up with some additional flags for IPO. That may be another case that is broken in the Ninja generator. > Maybe it could return the linker language instead, that is > a piece of data that is more important in its context IMHO. We already have cmGeneratorTarget::GetLinkerLanguage for that. > While discussing this method: How about moving the method to cmTargetGenerator? > That would get rid of the target parameter. That is where I would actually look > for information on targets. Yes, perhaps. What may be more important is to consolidate this with what the Makefile generator is doing. There is no reason the Ninja and Makefile generators to not share more code (and perhaps other generators too, but VS and Xcode do not necessarily generate the full command lines). Once there is a single clear place for this stuff to be computed then the daemon can use it with confidence. > Which brings me back to my original question: How can I find the compiler flags > in use for a cmSourceFile/cmGeneratorTarget? The only place that I found that > seems to do what I want is cmCommonTargetGenerator::GetFlags. Yes, GetFlags it the correct place to get target-wide flags. The Ninja generator has cmNinjaTargetGenerator::ComputeFlagsForObject to also add per-source flags. The Makefile generator factors out the target-wide flags into a make variable and then adds the same per-source flags elsewhere. The code that adds per-source flags should be factored into a common helper that the daemon can then use along with GetFlags. Side note: This is another thing that should be cleaned up in the Ninja generator. It should hold target-wide flags in the per-target rules.ninja entries instead of duplicating them for every object file in build.ninja. That would make the build.ninja files smaller. > cmCommonTargetGenerator does caching of results. Should this be also done for > cmLocalGenerator::GetTargetFlags, etc? Not sure. That is an optimization so may not be worth doing yet until the needed refactoring is done first. -Brad From brad.king at kitware.com Wed Jun 8 10:12:30 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 8 Jun 2016 10:12:30 -0400 Subject: [cmake-developers] [patch] FindBZip2: Add additional debug library name In-Reply-To: <3481e5d9-964c-8313-631a-4a9bb956e7ba@codelibre.net> References: <3481e5d9-964c-8313-631a-4a9bb956e7ba@codelibre.net> Message-ID: <575827CE.7010800@kitware.com> On 06/07/2016 05:54 PM, Roger Leigh wrote: > I've merged this bzip2-debug-names branch into next for testing. Looks good, thanks. -Brad From brad.king at kitware.com Wed Jun 8 12:24:29 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 8 Jun 2016 12:24:29 -0400 Subject: [cmake-developers] Bug in CMake: Generated Ninja files do not work on Windows In-Reply-To: References: <5756CE01.1060108@kitware.com> Message-ID: <575846BD.7060200@kitware.com> On 06/08/2016 03:33 AM, "Michael J?ntsch" wrote: > the : is obviously the default for noop which is correct for > Linux but not for Windows. My CMakeCache has the following entry: > //noop for ranlib > CMAKE_RANLIB:INTERNAL=: I see that here: https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeFindBinUtils.cmake;hb=v3.5.2#l55 if(NOT CMAKE_RANLIB) set(CMAKE_RANLIB : CACHE INTERNAL "noop for ranlib") endif() Here is a fix: Run ranlib on archives only if the tool is available https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ea598671 Thanks, -Brad From eike at sf-mail.de Wed Jun 8 12:43:47 2016 From: eike at sf-mail.de (Rolf Eike Beer) Date: Wed, 08 Jun 2016 18:43:47 +0200 Subject: [cmake-developers] Bug in CMake: Generated Ninja files do not work on Windows In-Reply-To: <575846BD.7060200@kitware.com> References: <575846BD.7060200@kitware.com> Message-ID: <8992628.OQDhaxqPvd@caliban.sf-tec.de> Am Mittwoch, 8. Juni 2016, 12:24:29 schrieb Brad King: > On 06/08/2016 03:33 AM, "Michael J?ntsch" wrote: > > the : is obviously the default for noop which is correct for > > Linux but not for Windows. My CMakeCache has the following entry: > > //noop for ranlib > > > CMAKE_RANLIB:INTERNAL=: > I see that here: > > > https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeFindBinUtils.cma > ke;hb=v3.5.2#l55 > > if(NOT CMAKE_RANLIB) > set(CMAKE_RANLIB : CACHE INTERNAL "noop for ranlib") > endif() > > Here is a fix: > > Run ranlib on archives only if the tool is available > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ea598671 Shouldn't the first check also be "cmd == ":" instead of only checking the first byte? 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 brad.king at kitware.com Wed Jun 8 12:46:50 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 8 Jun 2016 12:46:50 -0400 Subject: [cmake-developers] Bug in CMake: Generated Ninja files do not work on Windows In-Reply-To: <8992628.OQDhaxqPvd@caliban.sf-tec.de> References: <575846BD.7060200@kitware.com> <8992628.OQDhaxqPvd@caliban.sf-tec.de> Message-ID: <57584BFA.20901@kitware.com> On 06/08/2016 12:43 PM, Rolf Eike Beer wrote: >> Run ranlib on archives only if the tool is available >> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ea598671 > > Shouldn't the first check also be "cmd == ":" instead of only > checking the first byte? No, because the command in question is actually ": libfoo.a". No valid command can start in ":" on any platform. -Brad From michael.jaentsch at gmx.de Wed Jun 8 12:49:50 2016 From: michael.jaentsch at gmx.de (=?UTF-8?Q?Michael_J=c3=a4ntsch?=) Date: Wed, 8 Jun 2016 18:49:50 +0200 Subject: [cmake-developers] Bug in CMake: Generated Ninja files do not work on Windows In-Reply-To: <57584BFA.20901@kitware.com> References: <575846BD.7060200@kitware.com> <8992628.OQDhaxqPvd@caliban.sf-tec.de> <57584BFA.20901@kitware.com> Message-ID: <57584CAE.6010203@gmx.de> Hi, the code looks right to me. Thanks a lot for fixing that so quickly. Brad is also right about the first byte. The command has the argument already attached. Michael On 06/08/2016 06:46 PM, Brad King wrote: > On 06/08/2016 12:43 PM, Rolf Eike Beer wrote: >>> Run ranlib on archives only if the tool is available >>> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ea598671 >> Shouldn't the first check also be "cmd == ":" instead of only >> checking the first byte? > No, because the command in question is actually ": libfoo.a". > No valid command can start in ":" on any platform. > > -Brad > From daniel at pfeifer-mail.de Thu Jun 9 03:49:46 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Thu, 9 Jun 2016 09:49:46 +0200 Subject: [cmake-developers] Review request: extract-cmMessenger branch In-Reply-To: <56AA8B31.2010209@gmail.com> References: <56AA8B31.2010209@gmail.com> Message-ID: On Thu, Jan 28, 2016 at 10:42 PM, Stephen Kelly wrote: > > Hi, > > I have pushed a extract-cmMessenger branch to my clone: > > https://github.com/steveire/CMake/commits/extract-cmMessenger I have rebased it to master and cherry-picked some minor changes. Once those minor changes land in master, I will rebase again and then have a closer look at the individual commits. > The motivations are: > > * Decrease responsibilities of the cmake class. CMake uses too few > classes for too many things +1 > * Make it possible to make add first-class handling of messages about > missing packages (for example) to cmake-gui by making methods on > cmMessenger virtual and subclassing That sounds useful. But long term, I would rather base ccmake and cmake-gui on top of the daemon. What I would like to have, is separate subclasses for gcc-style and msvc-style messages. In gcc-style, messages look like this: :row:column: error: In msvc-style, messages look like this: (row,column): error: This would make it easier to jump to the location in IDEs (and powerful editors). > * Make it possible to emit messages through the daemon (also by > subclassing) together with backtrace and message type, relieving clients > from having to parse the text. +1 > I'm interested in what you think of the approach. Very useful overall. I'll write more once I had a closer look. From steveire at gmail.com Thu Jun 9 04:18:11 2016 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 9 Jun 2016 10:18:11 +0200 Subject: [cmake-developers] Review request: extract-cmMessenger branch In-Reply-To: References: <56AA8B31.2010209@gmail.com> Message-ID: <57592643.3090104@gmail.com> On 06/09/2016 09:49 AM, Daniel Pfeifer wrote: > On Thu, Jan 28, 2016 at 10:42 PM, Stephen Kelly wrote: >> Hi, >> >> I have pushed a extract-cmMessenger branch to my clone: >> >> https://github.com/steveire/CMake/commits/extract-cmMessenger > I have rebased it to master and cherry-picked some minor changes. > Once those minor changes land in master, I will rebase again and then > have a closer look at the individual commits. Cool. I did some work rebasing it yesterday too. It changed a bit due to the recent cmListFileBacktrace changes, and in the end the cmMessenger class is much simpler. >> * Make it possible to make add first-class handling of messages about >> missing packages (for example) to cmake-gui by making methods on >> cmMessenger virtual and subclassing > That sounds useful. But long term, I would rather base ccmake and > cmake-gui on top of the daemon. Sounds interesting. > What I would like to have, is separate subclasses for gcc-style and > msvc-style messages. In gcc-style, messages look like this: > > :row:column: error: > > In msvc-style, messages look like this: > > (row,column): error: > > This would make it easier to jump to the location in IDEs (and > powerful editors). Hmm, some existing clients (KDevelop) parse messages in the form they are already in. They would break if all message formats were changed substantially. Having the above behavior be dependent on some command line option or environment variable wouldn't be great either. The impact of this would need to be assessed. > Very useful overall. I'll write more once I had a closer look. Great, thanks for that! Steve. From Tobias.Hunger at qt.io Thu Jun 9 05:06:54 2016 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Thu, 9 Jun 2016 09:06:54 +0000 Subject: [cmake-developers] Review request: extract-cmMessenger branch In-Reply-To: <57592643.3090104@gmail.com> References: <56AA8B31.2010209@gmail.com> <57592643.3090104@gmail.com> Message-ID: <1465463211.811.89.camel@qt.io> On Do, 2016-06-09 at 10:18 +0200, Stephen Kelly wrote: > > What I would like to have, is separate subclasses for gcc-style and > > msvc-style messages. In gcc-style, messages look like this: > > > > :row:column: error: > > > > In msvc-style, messages look like this: > > > > (row,column): error: > > > > This would make it easier to jump to the location in IDEs (and > > powerful editors). I would really prefer cmake to decide on one format and to stick with that *consistently* for all messages. Preferably with some prefix so that the IDE can actually find out that the message is from cmake if they get dumped to stdout/stderr. Such a prefix is of course not important when messages are reported via an API of some kind. > Hmm, some existing clients (KDevelop) parse messages in the form they > are already in. They would break if all message formats were changed > substantially. Having the above behavior be dependent on some command > line option or environment variable wouldn't be great either. Forcing messages into one consistent format will be a pain, agreed, but continuing to add messages in whatever form the developer likes at the time of writing the code is even worse. CMake has a lot of different error message styles! Here are some of the different styles used to report various issues in cmake: CMake Error: Error in cmake code at /test/path/CMakeLists.txt:9: Parse error.??Expected "(", got newline with text " CMake Error at src/1/app/CMakeLists.txt:70 (add_custom_target): ? Cannot find source file: ? ? unknownFile.qml ? Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp CMake Error at src/1/CMakeLists.txt:8 (add_subdirectory): ? add_subdirectory given source "app1" which is not an existing directory. CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_MAKE_PROGRAM Syntax Warning in cmake code at /test/path/CMakeLists.txt:9:15 Argument not separated from preceding token by whitespace. Multi line messages are especially hard to parse correctly with the inconsistent reporting currently done by cmake. > The impact of this would need to be assessed. Almost anything will be an improvement over the status quo! If you were to unify on e.g. CMake Error at FILE:LINE (OPTIONAL_EXTRA_INFO): ? MULTILINE_MESSAGE_WITH_INDENT_ENDING_IN_TWO_NEWLINES then you will probably hit existing code paths in IDEs. Best Regards, Tobias -- Tobias Hunger,?Senior?Software Engineer?| The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From Tobias.Hunger at qt.io Thu Jun 9 05:47:44 2016 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Thu, 9 Jun 2016 09:47:44 +0000 Subject: [cmake-developers] daemon-mode: Project structure Message-ID: <1465465663.811.98.camel@qt.io> Hello everybody, I made some progress with extracting project structure from cmake via the daemon-mode. I am rather happy with the information and would love to get some feedback from other interested parties. Here is the format that is currently reported (with comments;-): [== CMake MetaMagic ==[ { ? # Reply header: ? "cookie":"", ? "type":"reply" ? "inReplyTo":"project", ?? ? # Data: ? "projects": ? [ ????{ ??????"configurations": ??????[ ????????{ ??????????"name":"", ??????????"targets": ??????????[ ????????????{ ??????????????"fullName":"test", ??????????????"name":"test", ??????????????"type":"GLOBAL_TARGET" ????????????}, ? ? ? ? ? ? # ????????????{ ??????????????"buildDirectory":"/tmp/cmake-build-test/Source/CursesDialog/form", ??????????????"fullName":"libcmForm.a", ??????????????"linkerLanguage":"C", ??????????????"name":"cmForm", ??????????????# "sysroot": "/some/path", if set... ??????????????"sourceGroups": # Just groups files with similar settings ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? # together to save space ??????????????[ ????????????????{ ??????????????????"compileFlags":"??-std=gnu11", ??????????????????"defines": ??????????????????[ ????????????????????"CURL_STATICLIB", ? ? ? ? ? ? ? ? ? ? # ????????????????????"LIBARCHIVE_STATIC" ??????????????????], ??????????????????"includePath": ??????????????????[ ????????????????????"/tmp/cmake-build-test/Utilities", ? ? ? ? ? ? ? ? ? ? # ????????????????????"/home/code/src/cmake/Source/CursesDialog/form" ??????????????????], ??????????????????"lanugage":"C", ??????????????????"sources": ??????????????????[ ????????????????????"fld_arg.c", ? ? ? ? ? ? ? ? ? ? # ????????????????????"fty_regex.c" ??????????????????] ????????????????} ??????????????], ??????????????"type":"STATIC_LIBRARY" ????????????}, ? ? ? ? ? ? # ????????????{ ??????????????"fullName":"install", ??????????????"name":"install", ??????????????"type":"GLOBAL_TARGET" ????????????} ??????????] # end of tragets list ????????} # end of one configuration object ??????], # end of configurations list ??????"currentBuildDirectory":"/tmp/cmake-build-test/Source/CursesDialog/form", ??????"currentSourceDirectory":"/home/code/src/cmake/Source/CursesDialog/form", ??????"name":"CMAKE_FORM" ????}, # end of one project object ? ? # ? ] # end of project list } ]== CMake MetaMagic ==] Is this the information you need for IDE integration? Do you cmake developers feel comfortable to expose this information? The total of the project data from the cmake project is ~102KiB of raw JSON data. What is not listed is the build system file list and the CMakeCache. I want to keep these two separate: I can think of some use cases where that information is not at all necessary:-) Best Regards, Tobias -- Tobias Hunger,?Senior?Software Engineer?| The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From mail at milianw.de Thu Jun 9 06:32:19 2016 From: mail at milianw.de (Milian Wolff) Date: Thu, 09 Jun 2016 12:32:19 +0200 Subject: [cmake-developers] daemon-mode: Project structure In-Reply-To: <1465465663.811.98.camel@qt.io> References: <1465465663.811.98.camel@qt.io> Message-ID: <25267446.k1QDeTQRl1@agathebauer> On Donnerstag, 9. Juni 2016 09:47:44 CEST Tobias Hunger wrote: > Hello everybody, Hey Tobias, > I made some progress with extracting project structure from cmake via the > daemon-mode. I am rather happy with the information and would love to get > some feedback from other interested parties. First of all, many thanks for stepping up and working on this. I for one greatly appreciate this! Sadly, I don't have the time to help you out :'( > Here is the format that is currently reported (with comments;-): > > [== CMake MetaMagic ==[ > { > # Reply header: > "cookie":"", > "type":"reply" > "inReplyTo":"project", > > # Data: > "projects": > [ > { > "configurations": > [ > { > "name":"", Can you enlighten me what these configurations are? Probably a CMake feature I haven't used. Maybe it's for Windows to have release and debug builds in one go? How would it look like there? > "targets": > [ > { > "fullName":"test", > "name":"test", > "type":"GLOBAL_TARGET" > }, A nice-to-have would be a pointer to where the target got created, is that feasible? That would allow an IDE to add a context menu to the target list to jump to the CMakeLists.txt to edit the target. > # > { > "buildDirectory":"/tmp/cmake-build-test/Source/CursesDialog/fo > rm", > "fullName":"libcmForm.a", > "linkerLanguage":"C", > "name":"cmForm", > # "sysroot": "/some/path", if set... > "sourceGroups": # Just groups files with similar settings > # together to save space good idea > [ > { > "compileFlags":" -std=gnu11", > "defines": > [ > "CURL_STATICLIB", > # > "LIBARCHIVE_STATIC" Setters with values would then look like `FOO=1` I assume? > ], > "includePath": > [ > "/tmp/cmake-build-test/Utilities", > # > "/home/code/src/cmake/Source/CursesDialog/form" > ], > "lanugage":"C", > "sources": > [ > "fld_arg.c", > # > "fty_regex.c" > ] > } > ], > "type":"STATIC_LIBRARY" > }, > # > { > "fullName":"install", > "name":"install", > "type":"GLOBAL_TARGET" > } > ] # end of tragets list > } # end of one configuration object > ], # end of configurations list > "currentBuildDirectory":"/tmp/cmake-build-test/Source/CursesDialog/for > m", > "currentSourceDirectory":"/home/code/src/cmake/Source/CursesDialog/form", why is this the "current" source director", shouldn't this be just "sourceDirectory"? The project's source directory cannot change by fiddling with the configuration after all, it's part of the source file structure? I know that in CMake you have ${CMAKE_CURRENT_SOURCE_DIR}, but we don't need to follow that naming for this purpose here, or? > "name":"CMAKE_FORM" > }, # end of one project object > # > ] # end of project list > } > ]== CMake MetaMagic ==] > > Is this the information you need for IDE integration? I think so, yes. We get all targets and their defines and includes with associated files. Additionally to what we where capably of before, we also get the project structure, which is nice. And your format is way more efficient by grouping sources with common include/define settings together, good choice. > Do you cmake developers feel comfortable to expose this information? > > The total of the project data from the cmake project is ~102KiB of raw JSON > data. > > What is not listed is the build system file list and the CMakeCache. I want > to keep these two separate: I can think of some use cases where that > information is not at all necessary:-) What do you mean by "build system file list" - generated source files? Or binary object files? Or CMakeLists.txt? Great work, thanks a lot! -- Milian Wolff mail at milianw.de http://milianw.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From brad.king at kitware.com Thu Jun 9 08:17:38 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 9 Jun 2016 08:17:38 -0400 Subject: [cmake-developers] Review request: extract-cmMessenger branch In-Reply-To: <1465463211.811.89.camel@qt.io> References: <56AA8B31.2010209@gmail.com> <57592643.3090104@gmail.com> <1465463211.811.89.camel@qt.io> Message-ID: <57595E62.1010901@kitware.com> On 06/09/2016 05:06 AM, Tobias Hunger wrote: > CMake Error at src/1/app/CMakeLists.txt:70 (add_custom_target): > Cannot find source file: > > unknownFile.qml > > Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp > > > CMake Error at src/1/CMakeLists.txt:8 (add_subdirectory): > add_subdirectory given source "app1" which is not an existing directory. This is meant to be the canonical style, and the IssueMessage infrastructure produces it. Not everything has been converted to use it though. -Brad From brad.king at kitware.com Thu Jun 9 08:43:48 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 9 Jun 2016 08:43:48 -0400 Subject: [cmake-developers] daemon-mode: Project structure In-Reply-To: <1465465663.811.98.camel@qt.io> References: <1465465663.811.98.camel@qt.io> Message-ID: <57596484.50702@kitware.com> On 06/09/2016 05:47 AM, Tobias Hunger wrote: > I made some progress with extracting project structure from cmake via the > daemon-mode. I am rather happy with the information and would love to get some > feedback from other interested parties. For reference, some design work on a format like this was discussed in another thread a couple years ago: Extracting target metadata, IDE integration, 2014-09-19 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11000 > # Data: > "projects": To what does each "projects" entry correspond? > [ > { > "configurations": > [ > { > "name":"", > "targets": Should "configurations" be an array or a map? A map would guarantee at most one configuration of a given name. > [ > { > "fullName":"test", > "name":"test", > "type":"GLOBAL_TARGET" I've never liked the name "GLOBAL_TARGET" because it does not really represent what the type of target is. I think we should avoid exposing the internal enum names through the protocol (we already do in the TYPE target property, but the GLOBAL_TARGET type is never available there). Unfortunately I've never come up with a better name, so I'd welcome suggestions. The target type is used for CMake-generated targets that get separately generated in each build (sub)directory, like "make install" and "make test". Their effects are localized to each directory in generators that support that. > }, > # > { > "buildDirectory":"/tmp/cmake-build-test/Source/CursesDialog/form", > "fullName":"libcmForm.a", The build directory and the location of the library file may not be the same. Also, there may be more than one artifact per target. A .dll has its .lib import library. A .so may have versioned symlinks. This field could be an "artifacts" array or map. > "linkerLanguage":"C", > "name":"cmForm", > # "sysroot": "/some/path", if set... > "sourceGroups": # Just groups files with similar settings > # together to save space The name "source groups" already has a meaning in CMake. If the goal is just to combine sources with the same settings, please use a different name. > [ > { > "compileFlags":" -std=gnu11", The format could use the same breakdown that CMake does internally to separate target-wide flags from per-source flags. That would also save space, and it will be easy for clients to combine the flags. > "defines": > [ > "CURL_STATICLIB", > # > "LIBARCHIVE_STATIC" > ], While not shown in this example, in general the defines can have "=value". > "includePath": > [ > "/tmp/cmake-build-test/Utilities", > # > "/home/code/src/cmake/Source/CursesDialog/form" > ], Do we need some indication of whether each path is a "system" include dir? > "lanugage":"C", > "sources": > [ > "fld_arg.c", > # > "fty_regex.c" > ] If we split target flags as mentioned above then we may need an object (map) for each source so that it can have fields for per-source flags, defines, etc. > "currentBuildDirectory":"/tmp/cmake-build-test/Source/CursesDialog/form", > "currentSourceDirectory":"/home/code/src/cmake/Source/CursesDialog/form", As Milian asked in a sibling response, why "current"? Thanks, -Brad From Tobias.Hunger at qt.io Thu Jun 9 08:59:40 2016 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Thu, 9 Jun 2016 12:59:40 +0000 Subject: [cmake-developers] daemon-mode: Project structure In-Reply-To: <25267446.k1QDeTQRl1@agathebauer> References: <1465465663.811.98.camel@qt.io> <25267446.k1QDeTQRl1@agathebauer> Message-ID: <1465477178.811.115.camel@qt.io> Hi Milian, great that you have found the time to look over this! It is greatly appreciated! On Do, 2016-06-09 at 12:32 +0200, Milian Wolff wrote: > > [== CMake MetaMagic ==[ > > { > > ? # Reply header: > > ? "cookie":"", > > ? "type":"reply" > > ? "inReplyTo":"project", > > ?? > > ? # Data: > > ? "projects": > > ? [ > > ????{ > > ??????"configurations": > > ??????[ > > ????????{ > > ??????????"name":"", > > Can you enlighten me what these configurations are? Probably a CMake feature > I? > haven't used. Maybe it's for Windows to have release and debug builds in one? > go? How would it look like there?? Apparently you can have build systems that can produce debug/release/whatnot builds in one one. In these systems you would get several entries here: One for each of the build configurations you can build. This seems to apply only to VisualStudio and XCode generators. All others should have just one configuration. > > ??????????"targets": > > ??????????[ > > ????????????{ > > ??????????????"fullName":"test", > > ??????????????"name":"test", > > ??????????????"type":"GLOBAL_TARGET" > > ????????????}, > > A nice-to-have would be a pointer to where the target got created, is that? > feasible? That would allow an IDE to add a context menu to the target list to? > jump to the CMakeLists.txt to edit the target. Stephen's work has lots of debugging features. It should be straight forward to figure out the location with those. So I am not sure it makes sense to add this here. Users sometimes define their targets in ways that are way too challenging to figure out with the little information available here (think macros and whatnot). > > ??????????????[ > > ????????????????{ > > ??????????????????"compileFlags":"??-std=gnu11", > > ??????????????????"defines": > > ??????????????????[ > > ????????????????????"CURL_STATICLIB", > > ????????????????????# > > ????????????????????"LIBARCHIVE_STATIC" > > Setters with values would then look like `FOO=1` I assume? Yes, exactly. > > ??????????] # end of tragets list > > ????????} # end of one configuration object > > ??????], # end of configurations list > > ??????"currentBuildDirectory":"/tmp/cmake-build-test/Source/CursesDialog/for > > m", > > "currentSourceDirectory":"/home/code/src/cmake/Source/CursesDialog/form", > > why is this the "current" source director", shouldn't this be just? > "sourceDirectory"? The project's source directory cannot change by fiddling? > with the configuration after all, it's part of the source file structure? I? > know that in CMake you have ${CMAKE_CURRENT_SOURCE_DIR}, but we don't need to? > follow that naming for this purpose here, or? Good point. I'll just use sourceDirectory and buildDirectory in the next push. > > Is this the information you need for IDE integration? > > I think so, yes. We get all targets and their defines and includes with? > associated files. Additionally to what we where capably of before, we also > get? > the project structure, which is nice. And your format is way more efficient > by? > grouping sources with common include/define settings together, good choice. Thanks! > > Do you cmake developers feel comfortable to expose this information? > > > > The total of the project data from the cmake project is ~102KiB of raw JSON > > data. > > > > What is not listed is the build system file list and the CMakeCache. I want > > to keep these two separate: I can think of some use cases where that > > information is not at all necessary:-) > > What do you mean by "build system file list" - generated source files? Or? > binary object files? Or CMakeLists.txt? I want a list of all the CMakeLists.txt files (and .cmake files and .in files and whatnot). All the files that would need watching to know when to ask the user to re-run cmake again since something might have changed. As an IDE you will want to list these files, too. Right now this can be? > Great work, thanks a lot! -- Tobias Hunger,?Senior?Software Engineer?| The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From brad.king at kitware.com Thu Jun 9 09:00:52 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 9 Jun 2016 09:00:52 -0400 Subject: [cmake-developers] FindFreetype patch for Windows debug lib naming In-Reply-To: <3a99b00d-a99b-da5d-5eea-1923cc145fc4@objexx.com> References: <3a99b00d-a99b-da5d-5eea-1923cc145fc4@objexx.com> Message-ID: <57596884.3000803@kitware.com> On 06/08/2016 12:33 AM, Stuart Mentzer wrote: > Here is a little patch that lets FindFreetype find the debug > library on Windows, where it is named with a d suffix. Thanks. I split the patch into two and applied: FindFreetype: Factor out common find command arguments https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=746a4245 FindFreetype: Search for a separate debug library https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6085b855 -Brad From brad.king at kitware.com Thu Jun 9 09:27:11 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 9 Jun 2016 09:27:11 -0400 Subject: [cmake-developers] CMake daemon-mode In-Reply-To: <5758279C.1020706@kitware.com> References: <1465227569.811.38.camel@qt.io> <5755B1AF.3000504@kitware.com> <1465310542.811.42.camel@qt.io> <5756DED0.5010404@kitware.com> <575702F2.6020502@kitware.com> <5758279C.1020706@kitware.com> Message-ID: <57596EAF.1020806@kitware.com> On 06/08/2016 10:11 AM, Brad King wrote: > I had to revert it from 'next' because it caused several LinkFlags > test failures. [snip] On 06/08/2016 12:02 PM, Tobias Hunger wrote: > https://github.com/hunger/CMake/commit/66acf05bc1737211f88b6ad13781c791f1a7bce4 > > has an update. None of the tests fail for me with that. Thanks. I applied that one and merged to 'next' yesterday for testing. It passed this time: cmLocalGenerator: Pass configuration to GetTargetFlags https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b0d3e693 > https://github.com/hunger/CMake/commit/bc060a44b6b2c2281ffe99815163ba02ec835dd6 > > Adds a method to retrieve compile flags from cmLocalGenerator. Good. I need to review that one more deeply but should be able to integrate it. Thanks, -Brad From Tobias.Hunger at qt.io Thu Jun 9 09:27:26 2016 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Thu, 9 Jun 2016 13:27:26 +0000 Subject: [cmake-developers] daemon-mode: Project structure In-Reply-To: <57596484.50702@kitware.com> References: <1465465663.811.98.camel@qt.io> <57596484.50702@kitware.com> Message-ID: <1465478844.811.137.camel@qt.io> On Do, 2016-06-09 at 08:43 -0400, Brad King wrote: > On 06/09/2016 05:47 AM, Tobias Hunger wrote: > > I made some progress with extracting project structure from cmake via the > > daemon-mode. I am rather happy with the information and would love to get > > some > > feedback from other interested parties. > > For reference, some design work on a format like this was discussed > in another thread a couple years ago: > > ? Extracting target metadata, IDE integration,??2014-09-19 > ? http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus > =11000 I know, I partitcipated in that discussion. > > ? # Data: > > ? "projects": > > To what does each "projects" entry correspond? This is basically a list of (sub)projects. They are not really ordered, but since they all have a sourceDirectory that should not be a problem. > > ? [ > > ????{ > > ??????"configurations": > > ??????[ > > ????????{ > > ??????????"name":"", > > ??????????"targets": > > Should "configurations" be an array or a map???A map would guarantee at most > one configuration of a given name. An array is IMHO easier to handle. A hope cmake already guarantees that the names of its configurations are unique, so I do not think this is an issue one way or another. > > ??????????[ > > ????????????{ > > ??????????????"fullName":"test", > > ??????????????"name":"test", > > ??????????????"type":"GLOBAL_TARGET" > > I've never liked the name "GLOBAL_TARGET" because it does not really represent > what the type of target is.??I think we should avoid exposing the internal > enum > names through the protocol (we already do in the TYPE target property, but the > GLOBAL_TARGET type is never available there).??Unfortunately I've never come > up with a better name, so I'd welcome suggestions.??The target type is used > for > CMake-generated targets that get separately generated in each build > (sub)directory, > like "make install" and "make test".??Their effects are localized to each > directory > in generators that support that. I am using the output of cmState::GetTargetTypeName. I do not want to map those names to something else if I can avoid it:-) > > ????????????}, > > ????????????# > > ????????????{ > > ??????????????"buildDirectory":"/tmp/cmake-build- > > test/Source/CursesDialog/form", > > ??????????????"fullName":"libcmForm.a", > > The build directory and the location of the library file may not be the same. > Also, there may be more than one artifact per target.??A .dll has its .lib > import library.??A .so may have versioned symlinks.??This field could be > an "artifacts" array or map. How can I get the directory a library/executable will be put into during the build? For libraries the directory should be enough -- that suffices to set up LD_LIBRARY_PATH or whatever is needed for the system to look up libraries. For executables (which I need the full path of), the fullName combined with an artifact directory is probably enough. I would also like to put the location after "make install", but so far I could not find how to get that. > > ??????????????"linkerLanguage":"C", > > ??????????????"name":"cmForm", > > ??????????????# "sysroot": "/some/path", if set... > > ??????????????"sourceGroups": # Just groups files with similar settings > > ??????????????????????????????# together to save space > > The name "source groups" already has a meaning in CMake.??If the goal is > just to combine sources with the same settings, please use a different name. > > > ??????????????[ > > ????????????????{ > > ??????????????????"compileFlags":"??-std=gnu11", > > The format could use the same breakdown that CMake does internally to separate > target-wide flags from per-source flags.??That would also save space, and it > will be easy for clients to combine the flags. That would force clients to figure out how to combine the two sets of flags. Let's keep this knowledge inside cmake, please. Per-file overrides are probably not as widely used that it makes sense to optimize for that. At least the difference in output size was not remarkable with any of the projects I experimented with. > > ??????????????????"defines": > > ??????????????????[ > > ????????????????????"CURL_STATICLIB", > > ????????????????????# > > ????????????????????"LIBARCHIVE_STATIC" > > ??????????????????], > > While not shown in this example, in general the defines can have "=value". Yes, that is correct and that works:-) > > ??????????????????"includePath": > > ??????????????????[ > > ????????????????????"/tmp/cmake-build-test/Utilities", > > ????????????????????# > > ????????????????????"/home/code/src/cmake/Source/CursesDialog/form" > > ??????????????????], > > Do we need some indication of whether each path is a "system" include dir? Having that information would not hurt, but is not really critical IMHO. > > ??????????????????"lanugage":"C", > > ??????????????????"sources": > > ??????????????????[ > > ????????????????????"fld_arg.c", > > ????????????????????# > > ????????????????????"fty_regex.c" > > ??????????????????] > > If we split target flags as mentioned above then we may need an object (map) > for each source so that it can have fields for per-source flags, defines, etc. I do not want to do that, see above. > > ??????"currentBuildDirectory":"/tmp/cmake-build- > > test/Source/CursesDialog/form", > > ??????"currentSourceDirectory":"/home/code/src/cmake/Source/CursesDialog/for > > m", > > As Milian asked in a sibling response, why "current"? I'll remove the "current" prefix. Thanks for the feedback! > Thanks, > -Brad > -- Tobias Hunger,?Senior?Software Engineer?| The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From eike at sf-mail.de Thu Jun 9 09:33:29 2016 From: eike at sf-mail.de (Rolf Eike Beer) Date: Thu, 09 Jun 2016 15:33:29 +0200 Subject: [cmake-developers] FindFreetype patch for Windows debug lib naming In-Reply-To: <57596884.3000803@kitware.com> References: <3a99b00d-a99b-da5d-5eea-1923cc145fc4@objexx.com> <57596884.3000803@kitware.com> Message-ID: <31235822f8e86ec246c37046fecff48d@sf-mail.de> Am 2016-06-09 15:00, schrieb Brad King: > On 06/08/2016 12:33 AM, Stuart Mentzer wrote: >> Here is a little patch that lets FindFreetype find the debug >> library on Windows, where it is named with a d suffix. > > Thanks. I split the patch into two and applied: > > FindFreetype: Factor out common find command arguments > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=746a4245 > > FindFreetype: Search for a separate debug library > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6085b855 This will probably not work: SLC will look for FREETYPE_LIBRARY_RELEASE, which is never set. So you will have to set(FREETYPE_LIBRARY_RELEASE ${FREETYPE_LIBRARY}) SLC() unset(FREETYPE_LIBRARY_RELEASE) or something like that. Greetings, Eike From brad.king at kitware.com Thu Jun 9 09:47:11 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 9 Jun 2016 09:47:11 -0400 Subject: [cmake-developers] daemon-mode: Project structure In-Reply-To: <1465478844.811.137.camel@qt.io> References: <1465465663.811.98.camel@qt.io> <57596484.50702@kitware.com> <1465478844.811.137.camel@qt.io> Message-ID: <5759735F.7070503@kitware.com> On 06/09/2016 09:27 AM, Tobias Hunger wrote: > I am using the output of cmState::GetTargetTypeName. Okay. We could consider excluding GLOBAL_TARGET targets from the output. They never have source files and are nebulously defined. > How can I get the directory a library/executable will be put into during the > build? See the cmGeneratorTarget::GetFullPath. That is one place that has been cleaned up to be consistent across generators. > For libraries the directory should be enough -- that suffices to set up > LD_LIBRARY_PATH or whatever is needed for the system to look up libraries. For > executables (which I need the full path of), the fullName combined with an > artifact directory is probably enough. For shared libraries there can be two separate directories on Windows. The .lib and .dll parts can be in different directories. I think it is simpler to enumerate the artifacts with some meta-data about the type of each one. The clients can compute from that the directories or runtime path information that they need. > I would also like to put the location after "make install" The information is not associated with cmTarget or cmGeneratorTarget. Each target may have more than one install rule, so the destinations are associated with the install rules generated by the install() command. See cmInstallTargetGenerator and cmExportInstallFileGenerator for some of that infrastructure. -Brad From brad.king at kitware.com Thu Jun 9 09:53:23 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 9 Jun 2016 09:53:23 -0400 Subject: [cmake-developers] FindFreetype patch for Windows debug lib naming In-Reply-To: <31235822f8e86ec246c37046fecff48d@sf-mail.de> References: <3a99b00d-a99b-da5d-5eea-1923cc145fc4@objexx.com> <57596884.3000803@kitware.com> <31235822f8e86ec246c37046fecff48d@sf-mail.de> Message-ID: <575974D3.3090907@kitware.com> On 06/09/2016 09:33 AM, Rolf Eike Beer wrote: >> FindFreetype: Factor out common find command arguments >> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=746a4245 >> >> FindFreetype: Search for a separate debug library >> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6085b855 > > This will probably not work: SLC will look for FREETYPE_LIBRARY_RELEASE, > which is never set. Thanks. I reverted the latter commit for now. Stuart, please base further work on the first commit above. -Brad From mail at milianw.de Thu Jun 9 10:07:39 2016 From: mail at milianw.de (Milian Wolff) Date: Thu, 09 Jun 2016 16:07:39 +0200 Subject: [cmake-developers] daemon-mode: Project structure In-Reply-To: <1465478844.811.137.camel@qt.io> References: <1465465663.811.98.camel@qt.io> <57596484.50702@kitware.com> <1465478844.811.137.camel@qt.io> Message-ID: <2776283.jsYiZ34Uqo@agathebauer> On Donnerstag, 9. Juni 2016 13:27:26 CEST Tobias Hunger wrote: > On Do, 2016-06-09 at 08:43 -0400, Brad King wrote: > > > "includePath": > > > [ > > > "/tmp/cmake-build-test/Utilities", > > > # > > > "/home/code/src/cmake/Source/CursesDialog/form" > > > ], > > > > > > Do we need some indication of whether each path is a "system" include > > dir? > > Having that information would not hurt, but is not really critical IMHO. I'm actually with Brad here. At least KDevelop's clang integration makes heavy use of -isystem to silence warnings etc. from stuff outside the project. We could hack that in ourselves by comparing an include path with the project root, but a better approach would be to get the info directly from CMake itself. Bye -- Milian Wolff mail at milianw.de http://milianw.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From Tobias.Hunger at qt.io Thu Jun 9 10:37:43 2016 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Thu, 9 Jun 2016 14:37:43 +0000 Subject: [cmake-developers] daemon-mode: Project structure In-Reply-To: <5759735F.7070503@kitware.com> References: <1465465663.811.98.camel@qt.io> <57596484.50702@kitware.com> <1465478844.811.137.camel@qt.io> <5759735F.7070503@kitware.com> Message-ID: <1465483061.811.145.camel@qt.io> On Do, 2016-06-09 at 09:47 -0400, Brad King wrote: > On 06/09/2016 09:27 AM, Tobias Hunger wrote: > > I am using the output of cmState::GetTargetTypeName. > > Okay.??We could consider excluding GLOBAL_TARGET targets from the > output.??They never have source files and are nebulously defined. OK, I'll remove GLOBAL_TARGETs completely from the output. You can already limited the target types that are going to be listed, and I intended to use that mechanism to suppress GLOBAL_TARGETs when using the daemon-mode from Qt Creator. > > How can I get the directory a library/executable will be put into during the > > build? > > See the cmGeneratorTarget::GetFullPath.??That is one place that has > been cleaned up to be consistent across generators. I just renamed the target's "buildDirectory" to "artifactDirectory". It is populated like this: ? ? const cmGeneratorTarget::OutputInfo* output = ??????target->GetOutputInfo(config); ????if (output) { ??????result[ARTIFACT_DIRECTORY_KEY] = output->OutDir; ????} I assume that is the directory where (main?) artifacts will end up in? Should I dump the other values of OutputInfo, too? > > For libraries the directory should be enough -- that suffices to set up > > LD_LIBRARY_PATH or whatever is needed for the system to look up libraries. > > For > > executables (which I need the full path of), the fullName combined with an > > artifact directory is probably enough. > > For shared libraries there can be two separate directories on Windows. > The .lib and .dll parts can be in different directories.??I think it > is simpler to enumerate the artifacts with some meta-data about the > type of each one.??The clients can compute from that the directories > or runtime path information that they need. > > > I would also like to put the location after "make install" > > The information is not associated with cmTarget or cmGeneratorTarget. > Each target may have more than one install rule, so the destinations > are associated with the install rules generated by the install() > command. > > See cmInstallTargetGenerator and cmExportInstallFileGenerator for > some of that infrastructure. I will look into that next. Best Regards, Tobias -- Tobias Hunger,?Senior?Software Engineer?| The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From brad.king at kitware.com Thu Jun 9 10:56:33 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 9 Jun 2016 10:56:33 -0400 Subject: [cmake-developers] daemon-mode: Project structure In-Reply-To: <1465483061.811.145.camel@qt.io> References: <1465465663.811.98.camel@qt.io> <57596484.50702@kitware.com> <1465478844.811.137.camel@qt.io> <5759735F.7070503@kitware.com> <1465483061.811.145.camel@qt.io> Message-ID: <575983A1.7020109@kitware.com> On 06/09/2016 10:37 AM, Tobias Hunger wrote: > I just renamed the target's "buildDirectory" to "artifactDirectory". Was the build directory meant to be the directory containing the built artifacts, or the working directory where compilers run? There can be more than one artifact directory. That's why I think we should just enumerate the artifacts by full path. > It is populated like this: > const cmGeneratorTarget::OutputInfo* output = > target->GetOutputInfo(config); > if (output) { > result[ARTIFACT_DIRECTORY_KEY] = output->OutDir; > } > > I assume that is the directory where (main?) artifacts will end up in? Yes. > Should I dump the other values of OutputInfo, too? ImpDir is the location of the import library on Windows. It shouldn't be necessary though if you enumerate the absolute paths to artifacts. Use cmGeneratorTarget::IsDLLPlatform to determine whether a shared library will have an import library or not. -Brad From Tobias.Hunger at qt.io Thu Jun 9 11:04:36 2016 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Thu, 9 Jun 2016 15:04:36 +0000 Subject: [cmake-developers] daemon-mode: Project structure In-Reply-To: <2776283.jsYiZ34Uqo@agathebauer> References: <1465465663.811.98.camel@qt.io> <57596484.50702@kitware.com> <1465478844.811.137.camel@qt.io> <2776283.jsYiZ34Uqo@agathebauer> Message-ID: <1465484674.811.149.camel@qt.io> On Do, 2016-06-09 at 16:07 +0200, Milian Wolff wrote: > On Donnerstag, 9. Juni 2016 13:27:26 CEST Tobias Hunger wrote: > > On Do, 2016-06-09 at 08:43 -0400, Brad King wrote: > > > > ??????????????????"includePath": > > > > ??????????????????[ > > > > ????????????????????"/tmp/cmake-build-test/Utilities", > > > > ????????????????????# > > > > ????????????????????"/home/code/src/cmake/Source/CursesDialog/form" > > > > ??????????????????], > > > > > > > > > Do we need some indication of whether each path is a "system" include > > > dir? > > > > Having that information would not hurt, but is not really critical IMHO. > > I'm actually with Brad here. At least KDevelop's clang integration makes > heavy? > use of -isystem to silence warnings etc. from stuff outside the project. We? > could hack that in ourselves by comparing an include path with the project? > root, but a better approach would be to get the info directly from CMake? > itself. Ok, changed. "includePath" is now reported like this: "includePath": [ ? { ? ? "isSystem":false, ? ? "path":"/tmp/cmake-build-test/Utilities" ? }, ? # ] Best Regards, Tobias -- Tobias Hunger,?Senior?Software Engineer?| The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From ben.boeckel at kitware.com Thu Jun 9 11:28:05 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 9 Jun 2016 11:28:05 -0400 Subject: [cmake-developers] cmLocalGenerator::GetTargetFlags In-Reply-To: <575827BD.8080402@kitware.com> References: <1465374222.811.67.camel@qt.io> <575827BD.8080402@kitware.com> Message-ID: <20160609152805.GA14294@megas.kitware.com> On Wed, Jun 08, 2016 at 10:12:13 -0400, Brad King wrote: > Side note: This is another thing that should be cleaned up in the Ninja > generator. It should hold target-wide flags in the per-target rules.ninja > entries instead of duplicating them for every object file in build.ninja. > That would make the build.ninja files smaller. Don't we already do this with target-specific build rules in rules.ninja? --Ben From brad.king at kitware.com Thu Jun 9 11:33:06 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 9 Jun 2016 11:33:06 -0400 Subject: [cmake-developers] cmLocalGenerator::GetTargetFlags In-Reply-To: <20160609152805.GA14294@megas.kitware.com> References: <1465374222.811.67.camel@qt.io> <575827BD.8080402@kitware.com> <20160609152805.GA14294@megas.kitware.com> Message-ID: <57598C32.7090905@kitware.com> On 06/09/2016 11:28 AM, Ben Boeckel wrote: > On Wed, Jun 08, 2016 at 10:12:13 -0400, Brad King wrote: >> Side note: This is another thing that should be cleaned up in the Ninja >> generator. It should hold target-wide flags in the per-target rules.ninja >> entries instead of duplicating them for every object file in build.ninja. >> That would make the build.ninja files smaller. > > Don't we already do this with target-specific build rules in > rules.ninja? We converted to target-specific rules but IIRC have not actually moved all the flags there. The build.ninja file still uses the rules but spells out all the flags on every object. -Brad From ben.boeckel at kitware.com Thu Jun 9 11:36:20 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 9 Jun 2016 11:36:20 -0400 Subject: [cmake-developers] RFC: LLVM community CMake documentation In-Reply-To: <961433AD-19F2-4829-928A-3A02821601A9@me.com> References: <961433AD-19F2-4829-928A-3A02821601A9@me.com> Message-ID: <20160609153620.GB14294@megas.kitware.com> On Thu, Apr 28, 2016 at 14:16:40 -0700, Chris Bieneman wrote: > The only comment I think I didn?t directly update the document for was > Dan?s comment about GLOBAL properties. I kinda have mixed feelings > about GLOBAL properties. I know why we use them, but I?m not sure I > want to encourage people to use them. I think some of the places we > use them is just wrong. Curious, but why? What alternative do you use? Using INTERNAL cache variables tends to have weird effects since they then persist between runs and if the variables aren't cleared at the start of configure diligently, you get old values left laying around (and has caused bugs in projects). Plus, updating them is easier since you don't have to keep doing `set(var full_val CACHE INTERNAL "")` and you have nice things like `set_property(GLOBAL APPEND)`. --Ben From Tobias.Hunger at qt.io Thu Jun 9 11:52:43 2016 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Thu, 9 Jun 2016 15:52:43 +0000 Subject: [cmake-developers] daemon-mode: Project structure In-Reply-To: <1465465663.811.98.camel@qt.io> References: <1465465663.811.98.camel@qt.io> Message-ID: <1465487561.811.165.camel@qt.io> Hello everybody, Ok, so far I changed this: ?* sourceGroups got renamed to fileGroups ?* System include paths get reported ?* GLOBAL_TARGETs are no longer listed. ? So this is what it looks right now: ? [== CMake MetaMagic ==[ { ? # Reply header: ? "cookie":"", ? "type":"reply", ? "inReplyTo":"project", ? # Project data: ? "projects": ? [ ? ? { ? ? ? "name":"CMAKE_FORM", ? ? ? "sourceDirectory":"/home/code/src/cmake/Source/CursesDialog/form" ? ? ? "buildDirectory":"/tmp/cmake-build-test/Source/CursesDialog/form", ? ? ? "configurations": ? ? ? [ ? ? ? ? { ? ? ? ? ? "name":"", ? ? ? ? ? "targets": ? ? ? ? ? [ ? ? ? ? ? ? { ? ? ? ? ? ? ? "artifactDirectory":"/tmp/cmake/Source/CursesDialog/form", ? ? ? ? ? ? ? "fileGroups": ? ? ? ? ? ? ? [ ? ? ? ? ? ? ? ? { ? ? ? ? ? ? ? ? ? "compileFlags":"??-std=gnu11", ? ? ? ? ? ? ? ? ? "defines": ? ? ? ? ? ? ? ? ? [? ? ? ? ? ? ? ? ? ? ? "SOMETHING=1", ? ? ? ? ? ? ? ? ? ? "LIBARCHIVE_STATIC" ? ? ? ? ? ? ? ? ? ], ? ? ? ? ? ? ? ? ? "includePath": ? ? ? ? ? ? ? ? ? [ ? ? ? ? ? ? ? ? ? ? { "path":"/tmp/cmake-build-test/Utilities" }, ? ? ? ? ? ? ? ? ? ? { "isSystem": true, "path":"/usr/include/something" }, ? ? ? ? ? ? ? ? ? ? # ; ? ? ? ? ? ? ? ? ? ] ? ? ? ? ? ? ? ? ? "lanugage":"C", ? ? ? ? ? ? ? ? ? "sources": ? ? ? ? ? ? ? ? ? [ ? ? ? ? ? ? ? ? ? ? "fld_arg.c", ? ? ? ? ? ? ? ? ? ? # ; ? ? ? ? ? ? ? ? ? ? "fty_regex.c" ? ? ? ? ? ? ? ? ? ] ? ? ? ? ? ? ? ? } ? ? ? ? ? ? ? ], ? ? ? ? ? ? ? "fullName":"libcmForm.a", ? ? ? ? ? ? ? "linkerLanguage":"C", ? ? ? ? ? ? ? "name":"cmForm", ? ? ? ? ? ? ? "type":"STATIC_LIBRARY" ? ? ? ? ? ? } ? ? ? ? ? ] ? ? ? ? } ? ? ? ], ? ? }, # end of project ? ? # ? ] # end of projects list } # end of message]== CMake MetaMagic ==] Output size is ~77KiB for the cmake project in raw JSON format. This is much smaller than before, due to the GLOBAL_TARGETs being gone. Still open: ?* What information to store about library build locations? Or maybe list build ? ?artifacts instead? ?* Where are targtes going to get installed to? Best Regards, Tobias --? Tobias Hunger,?Senior?Software Engineer?| The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From brad.king at kitware.com Thu Jun 9 13:57:54 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 9 Jun 2016 13:57:54 -0400 Subject: [cmake-developers] CMake daemon-mode In-Reply-To: <57596EAF.1020806@kitware.com> References: <1465227569.811.38.camel@qt.io> <5755B1AF.3000504@kitware.com> <1465310542.811.42.camel@qt.io> <5756DED0.5010404@kitware.com> <575702F2.6020502@kitware.com> <5758279C.1020706@kitware.com> <57596EAF.1020806@kitware.com> Message-ID: <5759AE22.6090405@kitware.com> On 06/09/2016 09:27 AM, Brad King wrote: >> https://github.com/hunger/CMake/commit/bc060a44b6b2c2281ffe99815163ba02ec835dd6 > Good. I need to review that one more deeply but should be able to integrate it. I split out some incremental commits toward that: cmCommonTargetGenerator: De-duplicate CMAKE_BUILD_TYPE lookup https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=de4ee088 cmLocalGenerator: Adopt GetFrameworkFlags method https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=70d3bf85 cmLocalGenerator: Move GetFrameworkFlags implementation to private helper https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d9613b96 Please rebase on that (at least once it is in master). For the main change, please also move over AddFortranFlags, perhaps becoming cmLocalGenerator::GetFortranFlags. The result should be that cmCommonTargetGenerator::GetFlags moves into the new cmLocalGenerator::GetTargetCompileFlags method except for the caching. That will preserve flag order for GetFlags. For the Xcode part of the changes, we cannot use the full GetTargetCompileFlags. The reason is that for Xcode some of the flags, like the architecture settings, become .pbxproj file properties instead of raw flags. It may be simplest to just drop that part of the change for now. Or, we need to factor out an intermediate helper that can be shared by GetTargetCompileFlags and Xcode. Thanks, -Brad From tobias.hunger at gmail.com Thu Jun 9 16:24:03 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Thu, 9 Jun 2016 22:24:03 +0200 Subject: [cmake-developers] CMake daemon-mode In-Reply-To: References: <1465227569.811.38.camel@qt.io> <5755B1AF.3000504@kitware.com> <1465310542.811.42.camel@qt.io> <5756DED0.5010404@kitware.com> <575702F2.6020502@kitware.com> <5758279C.1020706@kitware.com> <57596EAF.1020806@kitware.com> <5759AE22.6090405@kitware.com> Message-ID: Hi Brad, Am 09.06.2016 19:57 schrieb "Brad King" : > > On 06/09/2016 09:27 AM, Brad King wrote: > >> https://github.com/hunger/CMake/commit/bc060a44b6b2c2281ffe99815163ba02ec835dd6 > > Good. I need to review that one more deeply but should be able to integrate it. > > I split out some incremental commits toward that: > > cmCommonTargetGenerator: De-duplicate CMAKE_BUILD_TYPE lookup > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=de4ee088 > > cmLocalGenerator: Adopt GetFrameworkFlags method > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=70d3bf85 > > cmLocalGenerator: Move GetFrameworkFlags implementation to private helper > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d9613b96 > > Please rebase on that (at least once it is in master). How long does it usually take to get something into master? I do rebase rather often on top of master right anyway. I do want to stay current as I hate running into merge conflicts after weeksof solitary work in my little ivory tower of code:) > For the main change, please also move over AddFortranFlags, perhaps > becoming cmLocalGenerator::GetFortranFlags. The result should be > that cmCommonTargetGenerator::GetFlags moves into the new > cmLocalGenerator::GetTargetCompileFlags method except for the caching. > That will preserve flag order for GetFlags. I will give that a try. > For the Xcode part of the changes, we cannot use the full > GetTargetCompileFlags. The reason is that for Xcode some of the > flags, like the architecture settings, become .pbxproj file properties > instead of raw flags. It may be simplest to just drop that part of > the change for now. Or, we need to factor out an intermediate helper > that can be shared by GetTargetCompileFlags and Xcode. I think I will just drop that part then. I do not have a Mac handy to test anyway. > Thanks, > -Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Jun 9 16:31:00 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 9 Jun 2016 16:31:00 -0400 Subject: [cmake-developers] CMake daemon-mode In-Reply-To: References: <1465227569.811.38.camel@qt.io> <5755B1AF.3000504@kitware.com> <1465310542.811.42.camel@qt.io> <5756DED0.5010404@kitware.com> <575702F2.6020502@kitware.com> <5758279C.1020706@kitware.com> <57596EAF.1020806@kitware.com> <5759AE22.6090405@kitware.com> Message-ID: <5759D204.1090709@kitware.com> On 06/09/2016 04:24 PM, Tobias Hunger wrote: >> Please rebase on that (at least once it is in master). > > How long does it usually take to get something into master? Typically a (business) day or two, but sometimes longer depending on trouble with testing in 'next' on our dashboards. -Brad From neundorf at kde.org Thu Jun 9 16:21:00 2016 From: neundorf at kde.org (Alexander Neundorf) Date: Thu, 09 Jun 2016 22:21 +0200 Subject: [cmake-developers] daemon-mode: Project structure In-Reply-To: <1465477178.811.115.camel@qt.io> References: <1465465663.811.98.camel@qt.io> <25267446.k1QDeTQRl1@agathebauer> <1465477178.811.115.camel@qt.io> Message-ID: <3648658.mtVpPn1nUm@tuxedo.neundorf.net> On Thursday 09 June 2016 12:59:40 Tobias Hunger wrote: > Hi Milian, ... > > > "targets": > > > [ > > > { > > > "fullName":"test", > > > "name":"test", > > > "type":"GLOBAL_TARGET" > > > }, > > > > > > A nice-to-have would be a pointer to where the target got created, is > > that feasible? That would allow an IDE to add a context menu to the > > target list to jump to the CMakeLists.txt to edit the target. > > > Stephen's work has lots of debugging features. It should be straight forward > to figure out the location with those. So I am not sure it makes sense to > add this here. Users sometimes define their targets in ways that are way > too challenging to figure out with the little information available here > (think macros and whatnot). Getting the source directory of a target should be reliable and a useful information I guess ? Alex From daniel at pfeifer-mail.de Thu Jun 9 17:24:33 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Thu, 9 Jun 2016 23:24:33 +0200 Subject: [cmake-developers] Review request: extract-cmMessenger branch In-Reply-To: <57595E62.1010901@kitware.com> References: <56AA8B31.2010209@gmail.com> <57592643.3090104@gmail.com> <1465463211.811.89.camel@qt.io> <57595E62.1010901@kitware.com> Message-ID: On Thu, Jun 9, 2016 at 2:17 PM, Brad King wrote: > On 06/09/2016 05:06 AM, Tobias Hunger wrote: >> CMake Error at src/1/app/CMakeLists.txt:70 (add_custom_target): >> Cannot find source file: >> >> unknownFile.qml >> >> Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp >> >> >> CMake Error at src/1/CMakeLists.txt:8 (add_subdirectory): >> add_subdirectory given source "app1" which is not an existing directory. > > This is meant to be the canonical style, and the IssueMessage > infrastructure produces it. Not everything has been converted > to use it though. I have rebased again and pushed to my github clone: https://github.com/purpleKarrot/CMake/commits/extract-cmMessenger If I am not mistaken, the second commit improves consistency of this canonical style. The error messages became simpler. I for one never understood what "include could not find load file" really meant. However, the tests currently fail. I am unsure whether the implementation should be "fixed" or whether the tests should be adapted. Example: Expected stderr to match: expect-err> ^CMake Warning \(dev\) at message-internal-warning.cmake:3 \(include\): expect-err> A logical block opening on the line expect-err> expect-err> .*Tests/RunCMake/message/message-internal-warning.cmake:4 \(macro\) expect-err> expect-err> closes on the line expect-err> expect-err> .*Tests/RunCMake/message/message-internal-warning.cmake:5 \(endmacro\) expect-err> expect-err> with mis-matching arguments. expect-err> Call Stack \(most recent call first\): expect-err> CMakeLists.txt:3 \(include\) expect-err> This warning is for project developers. Use -Wno-dev to suppress it.$ Actual stderr: actual-err> CMake Warning (dev) in message-internal-warning.cmake: actual-err> A logical block opening on the line actual-err> actual-err> /home/daniel/Projects/CMake/Tests/RunCMake/message/message-internal-warning.cmake:4 (macro) actual-err> actual-err> closes on the line actual-err> actual-err> /home/daniel/Projects/CMake/Tests/RunCMake/message/message-internal-warning.cmake:5 (endmacro) actual-err> actual-err> with mis-matching arguments. actual-err> Call Stack (most recent call first): actual-err> CMakeLists.txt:3 (include) actual-err> This warning is for project developers. Use -Wno-dev to suppress it. I assume the actual stderr is preferred and the expectation should be changed. The mismatch is between line 4 and 5. It does not seem useful to report an error in line 3. From Stuart_Mentzer at objexx.com Thu Jun 9 17:35:35 2016 From: Stuart_Mentzer at objexx.com (Stuart Mentzer) Date: Thu, 9 Jun 2016 17:35:35 -0400 Subject: [cmake-developers] FindFreetype patch for Windows debug lib naming In-Reply-To: <31235822f8e86ec246c37046fecff48d@sf-mail.de> References: <3a99b00d-a99b-da5d-5eea-1923cc145fc4@objexx.com> <57596884.3000803@kitware.com> <31235822f8e86ec246c37046fecff48d@sf-mail.de> Message-ID: <82094528-1673-a04b-359c-4a741becd555@objexx.com> On 6/9/2016 9:33 AM, Rolf Eike Beer wrote: > Am 2016-06-09 15:00, schrieb Brad King: >> On 06/08/2016 12:33 AM, Stuart Mentzer wrote: >>> Here is a little patch that lets FindFreetype find the debug >>> library on Windows, where it is named with a d suffix. >> >> Thanks. I split the patch into two and applied: >> >> FindFreetype: Factor out common find command arguments >> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=746a4245 >> >> FindFreetype: Search for a separate debug library >> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6085b855 > > This will probably not work: SLC will look for FREETYPE_LIBRARY_RELEASE, which is never set. So you will have to > > set(FREETYPE_LIBRARY_RELEASE ${FREETYPE_LIBRARY}) > SLC() > unset(FREETYPE_LIBRARY_RELEASE) > > or something like that. > > Greetings, > > Eike I'm a little confused here. Eike, you suggested that I shouldn't name the release variable FREETYPE_LIBRARY_RELEASE, so I changed it to FREETYPE_LIBRARY, but looking at SLC code it seems that would both work and get FREETYPE_LIBRARY set. I guess doing it the way you suggest above would also achieve the same thing but it seemed and seems more symmetric to name the release variable with _RELEASE and let SLC do its job. Anyway, I'm happy to submit the second part of the patch once it is clear what is best. Thanks, Stuart From steveire at gmail.com Thu Jun 9 18:01:46 2016 From: steveire at gmail.com (Stephen Kelly) Date: Fri, 10 Jun 2016 00:01:46 +0200 Subject: [cmake-developers] Review request: extract-cmMessenger branch In-Reply-To: References: <56AA8B31.2010209@gmail.com> <57592643.3090104@gmail.com> <1465463211.811.89.camel@qt.io> <57595E62.1010901@kitware.com> Message-ID: <5759E74A.4060100@gmail.com> On 06/09/2016 11:24 PM, Daniel Pfeifer wrote: > On Thu, Jun 9, 2016 at 2:17 PM, Brad King wrote: >> On 06/09/2016 05:06 AM, Tobias Hunger wrote: >>> CMake Error at src/1/app/CMakeLists.txt:70 (add_custom_target): >>> Cannot find source file: >>> >>> unknownFile.qml >>> >>> Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp >>> >>> >>> CMake Error at src/1/CMakeLists.txt:8 (add_subdirectory): >>> add_subdirectory given source "app1" which is not an existing directory. >> This is meant to be the canonical style, and the IssueMessage >> infrastructure produces it. Not everything has been converted >> to use it though. > I have rebased again and pushed to my github clone: > https://github.com/purpleKarrot/CMake/commits/extract-cmMessenger You seem to still be rebasing an old version of the branch, not the updated one from my github. I'm sure the tests on my github branch all pass - at least they did a few hours ago. Thanks, Steve. From eike at sf-mail.de Fri Jun 10 02:45:12 2016 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 10 Jun 2016 08:45:12 +0200 Subject: [cmake-developers] FindFreetype patch for Windows debug lib naming In-Reply-To: <82094528-1673-a04b-359c-4a741becd555@objexx.com> References: <3a99b00d-a99b-da5d-5eea-1923cc145fc4@objexx.com> <57596884.3000803@kitware.com> <31235822f8e86ec246c37046fecff48d@sf-mail.de> <82094528-1673-a04b-359c-4a741becd555@objexx.com> Message-ID: <7ada2c7b5b27d874078d49550a409807@sf-mail.de> Am 2016-06-09 23:35, schrieb Stuart Mentzer: > On 6/9/2016 9:33 AM, Rolf Eike Beer wrote: >> Am 2016-06-09 15:00, schrieb Brad King: >>> On 06/08/2016 12:33 AM, Stuart Mentzer wrote: >>>> Here is a little patch that lets FindFreetype find the debug >>>> library on Windows, where it is named with a d suffix. >>> >>> Thanks. I split the patch into two and applied: >>> >>> FindFreetype: Factor out common find command arguments >>> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=746a4245 >>> >>> FindFreetype: Search for a separate debug library >>> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6085b855 >> >> This will probably not work: SLC will look for >> FREETYPE_LIBRARY_RELEASE, which is never set. So you will have to >> >> set(FREETYPE_LIBRARY_RELEASE ${FREETYPE_LIBRARY}) >> SLC() >> unset(FREETYPE_LIBRARY_RELEASE) >> >> or something like that. > I'm a little confused here. Eike, you suggested that I shouldn't name > the release variable FREETYPE_LIBRARY_RELEASE, so I changed it to > FREETYPE_LIBRARY, but looking at SLC code it seems that would both > work and get FREETYPE_LIBRARY set. I guess doing it the way you > suggest above would also achieve the same thing but it seemed and > seems more symmetric to name the release variable with _RELEASE and > let SLC do its job. Anyway, I'm happy to submit the second part of the > patch once it is clear what is best. Hi, I'm sure I also wrote "you probably need to set/unset FREETYPE_LIBRARY_RELEASE around SLC so it still works", although I can't find the mail where I said that (besides the above, of course). In the end you can test it easily: if both libraries are found, but only one ends up in FREETYPE_LIBRARIES then something went wrong. The point here is that you can't change the variable name that is used in find_library() as it would break compatibility. Greetings, Eike From Stuart_Mentzer at objexx.com Fri Jun 10 03:19:31 2016 From: Stuart_Mentzer at objexx.com (Stuart Mentzer) Date: Fri, 10 Jun 2016 03:19:31 -0400 Subject: [cmake-developers] FindFreetype patch for Windows debug lib naming In-Reply-To: <7ada2c7b5b27d874078d49550a409807@sf-mail.de> References: <3a99b00d-a99b-da5d-5eea-1923cc145fc4@objexx.com> <57596884.3000803@kitware.com> <31235822f8e86ec246c37046fecff48d@sf-mail.de> <82094528-1673-a04b-359c-4a741becd555@objexx.com> <7ada2c7b5b27d874078d49550a409807@sf-mail.de> Message-ID: <18cceeab-720f-bf88-e752-c195c11aef8e@objexx.com> On 6/10/2016 2:45 AM, Rolf Eike Beer wrote: > Am 2016-06-09 23:35, schrieb Stuart Mentzer: >> On 6/9/2016 9:33 AM, Rolf Eike Beer wrote: >>> Am 2016-06-09 15:00, schrieb Brad King: >>>> On 06/08/2016 12:33 AM, Stuart Mentzer wrote: >>>>> Here is a little patch that lets FindFreetype find the debug >>>>> library on Windows, where it is named with a d suffix. >>>> >>>> Thanks. I split the patch into two and applied: >>>> >>>> FindFreetype: Factor out common find command arguments >>>> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=746a4245 >>>> >>>> FindFreetype: Search for a separate debug library >>>> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6085b855 >>> >>> This will probably not work: SLC will look for FREETYPE_LIBRARY_RELEASE, which is never set. So you will have to >>> >>> set(FREETYPE_LIBRARY_RELEASE ${FREETYPE_LIBRARY}) >>> SLC() >>> unset(FREETYPE_LIBRARY_RELEASE) >>> >>> or something like that. > >> I'm a little confused here. Eike, you suggested that I shouldn't name >> the release variable FREETYPE_LIBRARY_RELEASE, so I changed it to >> FREETYPE_LIBRARY, but looking at SLC code it seems that would both >> work and get FREETYPE_LIBRARY set. I guess doing it the way you >> suggest above would also achieve the same thing but it seemed and >> seems more symmetric to name the release variable with _RELEASE and >> let SLC do its job. Anyway, I'm happy to submit the second part of the >> patch once it is clear what is best. > > Hi, > > I'm sure I also wrote "you probably need to set/unset FREETYPE_LIBRARY_RELEASE around SLC so it still works", although I can't find the mail where I said that (besides the above, of course). In the end you can test it easily: if both libraries are found, but only one ends up in FREETYPE_LIBRARIES then something went wrong. > > The point here is that you can't change the variable name that is used in find_library() as it would break compatibility. > > Greetings, > > Eike Eike, Thanks for trying to help but really I don't know (or want to know) enough of CMake's internals to quickly resolve this. My only build example that uses FindFreetype builds debug and release separately and it would take some work to try to do them together. At this point I need some help or I have to move on and give up here. Is there someone who can just do what is needed and let us be done with this? Thanks, Stuart From Tobias.Hunger at qt.io Fri Jun 10 04:34:56 2016 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Fri, 10 Jun 2016 08:34:56 +0000 Subject: [cmake-developers] cmCacheManager related changes Message-ID: <1465547694.811.172.camel@qt.io> Hi Brad, I got some more changes to enable daemon-mode to access the full contents of the CMakeCacheManager. With these patches and the daemon mode as of today Daniel should be able to implement something like ccmake with daemon-mode only. These patches are all concerned about accessing the properties that are set on the cache values. https://github.com/hunger/CMake/commit/b46f1feae7c2f1bd47b7d1848ce31d4edf505a1e makes the list of defined properties accessible from the cmPropertyMap. https://github.com/hunger/CMake/commit/a7bf58458172580e0aab865726b18341af142248 makes the list of defined properties accessible from the cmCacheEntry. https://github.com/hunger/CMake/commit/0ff8cd2e862b52a0baf271b127945bed00f8db38 It kills an uninitialized cmCacheManager* in the cmake object and its getter. https://github.com/hunger/CMake/commit/958c0bfd18f26a9d61d2a39ed826a7ce40fce35c Adds an interface to cmState to retrieve the property list. Best Regards, Tobias -- Tobias Hunger,?Senior?Software Engineer?| The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From brad.king at kitware.com Fri Jun 10 09:03:13 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 10 Jun 2016 09:03:13 -0400 Subject: [cmake-developers] FindFreetype patch for Windows debug lib naming In-Reply-To: <18cceeab-720f-bf88-e752-c195c11aef8e@objexx.com> References: <3a99b00d-a99b-da5d-5eea-1923cc145fc4@objexx.com> <57596884.3000803@kitware.com> <31235822f8e86ec246c37046fecff48d@sf-mail.de> <82094528-1673-a04b-359c-4a741becd555@objexx.com> <7ada2c7b5b27d874078d49550a409807@sf-mail.de> <18cceeab-720f-bf88-e752-c195c11aef8e@objexx.com> Message-ID: <575ABA91.60802@kitware.com> On 06/10/2016 03:19 AM, Stuart Mentzer wrote: > On 6/10/2016 2:45 AM, Rolf Eike Beer wrote: >> I'm sure I also wrote "you probably need to set/unset >> FREETYPE_LIBRARY_RELEASE around SLC so it still works", >> The point here is that you can't change the variable name >> that is used in find_library() as it would break compatibility. > > Is there someone who can just do what is needed and let us be done with this? Eike, IIRC what we've done for other modules is change the cache entries to use ${pkg}_LIBRARY_{RELEASE,DEBUG} and then provided compatibility with scripts that explicitly set ${pkg}_LIBRARY by using the value if set and skipping the search. See FindZLIB for an example of this. -Brad From daniel at pfeifer-mail.de Fri Jun 10 09:30:05 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Fri, 10 Jun 2016 15:30:05 +0200 Subject: [cmake-developers] Questions about coding conventions Message-ID: Hi, By looking at the CMake source code, there are some inconsistencies regarding coding conventions. This is not a big problem and fixing them probably does not have a high priority. I would like to know what conventions to follow for new code. Formatting: No longer an issue. A .clang-format is provided and most inconsistencies have disappeared. Braces around single conditional statements: This is currently not consistent. Should they be avoided? Should they be required? We could add the missing ones with clang-tidy. If we want them. Naming conventions: Classes are named cmLikeThis. Member functions and member variables are named LikeThis. Local variables are named likeThis. Members are always accessed with `this->`. So far it is pretty consistent. But how to name free functions and macros? I have seen all kinds of variations. `const T` or `T const` (also: `const T&` or `T const&`): Currently, CMake uses both. I have not analyzed which one dominates. Passing and returning strings: We have `const char*`, `std::string`, and `std::string const&`. Unifying this can affect performance. Storing `const char*` in a `std::string` creates a (potentially unneded) copy (assuming it is not null). `const char*` can distinguish invalid from empty. Do we actually need this distinction? Or should we assume empty==invalid and always prefer `std::string const&` arguments? Or should we introduce a C++17-like cmStringView? cheers, Daniel From eric.noulard at gmail.com Fri Jun 10 09:31:05 2016 From: eric.noulard at gmail.com (Eric Noulard) Date: Fri, 10 Jun 2016 15:31:05 +0200 Subject: [cmake-developers] Update bash completion scripts Message-ID: Hi, Here comes an update of the bash completion scripts. All of them now handle the same set of --help-xxx options the handling of --help-manual has been added. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Update-bash-completion-scripts-for-cmake-cpack-ctest.patch Type: text/x-diff Size: 4283 bytes Desc: not available URL: From brad.king at kitware.com Fri Jun 10 09:43:18 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 10 Jun 2016 09:43:18 -0400 Subject: [cmake-developers] Questions about coding conventions In-Reply-To: References: Message-ID: <575AC3F6.30108@kitware.com> On 06/10/2016 09:30 AM, Daniel Pfeifer wrote: > By looking at the CMake source code, there are some inconsistencies > regarding coding conventions. This is not a big problem and fixing > them probably does not have a high priority. > I would like to know what conventions to follow for new code. Please look at documenting this in CONTRIBUTING.rst once we resolve this discussion. > Formatting: No longer an issue. A .clang-format is provided and most > inconsistencies have disappeared. Yes, and thanks for all your work on that. > Braces around single conditional statements: This is currently not > consistent. Should they be avoided? Should they be required? We could > add the missing ones with clang-tidy. If we want them. The intention has been to use braces for all blocks even with single statements. Due to lack of documentation and enforcement this has not been maintained consistently. > Naming conventions: Classes are named cmLikeThis. Member functions > and member variables are named LikeThis. Local variables are named > likeThis. Members are always accessed with `this->`. Yes, though there are also many local variables named `like_this` too. I have no strong feelings on enforcing local variable name conventions. > So far it is pretty consistent. But how to name free functions and > macros? I have seen all kinds of variations. No convention was ever established for those. > `const T` or `T const` (also: `const T&` or `T const&`): Currently, > CMake uses both. I have not analyzed which one dominates. I prefer `T const` always, except for `const char*` specifically. > Passing and returning strings: We have `const char*`, `std::string`, > and `std::string const&`. Unifying this can affect performance. > Storing `const char*` in a `std::string` creates a (potentially > unneded) copy (assuming it is not null). `const char*` can distinguish > invalid from empty. Do we actually need this distinction? Last year we had a few cleanup passes done along those lines, but it is far from consistent everywhere. There are cases where we need to distinguish invalid from empty, like GetDefinition(). It would be nice to have an optional or something like that so we can keep the distinction but avoid using `const char*` all over. Any change like this should be introduced gradually, as many of the related areas are performance sensitive. -Brad From brad.king at kitware.com Fri Jun 10 09:56:46 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 10 Jun 2016 09:56:46 -0400 Subject: [cmake-developers] Update bash completion scripts In-Reply-To: References: Message-ID: <575AC71E.6050207@kitware.com> On 06/10/2016 09:31 AM, Eric Noulard wrote: > Here comes an update of the bash completion scripts. > All of them now handle the same set of --help-xxx options > the handling of --help-manual has been added. Thanks, applied: bash-completion: Add cmake --help-manual https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f67afbdc bash-completion: Add ctest --help-{manual,module,policy,property,variable} https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c8178a77 bash-completion: Add cpack --help-{manual,module,policy,property} https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eacb75de > + --help-policy) > + COMPREPLY=( $( compgen -W '$( ctest --help-policies 2>/dev/null | > + grep "^ CMP" 2>/dev/null )' -- "$cur" ) ) > + return > + ;; Does this actually work? IIRC older CMake versions did not have `--help-policy-list` so the `--help-policies` hack was used. However, I don't know if the output format of the latter will be matched by the `grep` anymore. If needed, please post a follow-up patch to fix policy completion for cmake, ctest, and cpack. Thanks, -Brad From brad.king at kitware.com Fri Jun 10 10:06:35 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 10 Jun 2016 10:06:35 -0400 Subject: [cmake-developers] daemon-mode: Project structure In-Reply-To: <1465487561.811.165.camel@qt.io> References: <1465465663.811.98.camel@qt.io> <1465487561.811.165.camel@qt.io> Message-ID: <575AC96B.5010503@kitware.com> On 06/09/2016 11:52 AM, Tobias Hunger wrote: > [== CMake MetaMagic ==[ What is the purpose of this non-json wrapper in the content? Just part of the message protocol so that readers do not have to parse the json to know when the end of the message is reached (balanced with the start)? I'd prefer a more descriptive name than "MetaMagic". > "artifactDirectory":"/tmp/cmake/Source/CursesDialog/form", See below. > "fileGroups": Good. > Output size is ~77KiB for the cmake project in raw JSON format. This is much > smaller than before, due to the GLOBAL_TARGETs being gone. Good. > * What information to store about library build locations? Or maybe list build > artifacts instead? I prefer the latter as I've mentioned elsewhere in the related threads. Thanks, -Brad From eric.noulard at gmail.com Fri Jun 10 10:12:09 2016 From: eric.noulard at gmail.com (Eric Noulard) Date: Fri, 10 Jun 2016 16:12:09 +0200 Subject: [cmake-developers] Update bash completion scripts In-Reply-To: <575AC71E.6050207@kitware.com> References: <575AC71E.6050207@kitware.com> Message-ID: 2016-06-10 15:56 GMT+02:00 Brad King : > On 06/10/2016 09:31 AM, Eric Noulard wrote: > > Here comes an update of the bash completion scripts. > > All of them now handle the same set of --help-xxx options > > the handling of --help-manual has been added. > > Thanks, applied: > > bash-completion: Add cmake --help-manual > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f67afbdc > > bash-completion: Add ctest --help-{manual,module,policy,property,variable} > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c8178a77 > > bash-completion: Add cpack --help-{manual,module,policy,property} > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eacb75de > > > + --help-policy) > > + COMPREPLY=( $( compgen -W '$( ctest --help-policies > 2>/dev/null | > > + grep "^ CMP" 2>/dev/null )' -- "$cur" ) ) > > + return > > + ;; > > Does this actually work? IIRC older CMake versions did not > have `--help-policy-list` so the `--help-policies` hack was > used. However, I don't know if the output format of the > latter will be matched by the `grep` anymore. > You are right this part was obsolete. To be honest I did not test the policy completion :-( > > If needed, please post a follow-up patch to fix policy completion > for cmake, ctest, and cpack. > Here you go. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Update-help-policy-completion-with-comtemporary-cmak.patch Type: text/x-diff Size: 2325 bytes Desc: not available URL: From Tobias.Hunger at qt.io Fri Jun 10 10:16:58 2016 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Fri, 10 Jun 2016 14:16:58 +0000 Subject: [cmake-developers] Questions about coding conventions In-Reply-To: References: Message-ID: <1465568217.811.192.camel@qt.io> On Fr, 2016-06-10 at 15:30 +0200, Daniel Pfeifer wrote: > Naming conventions: Classes are named??cmLikeThis. Member functions > and member variables are named LikeThis. Local variables are named > likeThis. Members are always accessed with `this->`. So far it is > pretty consistent. But how to name free functions and macros? I have > seen all kinds of variations. May I asked why "this->" is used so often? I find it totally annoying to skip this line noise all the time and I never encountered this convention before. Best Regards, Tobias -- Tobias Hunger,?Senior?Software Engineer?| The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From daniel at constexpr.org Fri Jun 10 10:11:18 2016 From: daniel at constexpr.org (Daniel Scharrer) Date: Fri, 10 Jun 2016 16:11:18 +0200 Subject: [cmake-developers] [PATCH] Search lib32 on more platforms Message-ID: <20160610141118.22264-1-daniel@constexpr.org> This adss a global property FIND_LIBRARY_USE_LIB32_PATHS analogous to the FIND_LIBRARY_USE_LIB64_PATHS property, fixing linking issues on multilib systems that use lib32 directories and either don't have lib symlinks or point lib to lib64. Bug: https://public.kitware.com/Bug/view.php?id=11260 --- Help/command/find_library.rst | 7 +++++++ Help/manual/cmake-properties.7.rst | 1 + Help/prop_gbl/FIND_LIBRARY_USE_LIB32_PATHS.rst | 9 +++++++++ Modules/FindPkgConfig.cmake | 8 ++++++-- Modules/Platform/Linux.cmake | 3 ++- Modules/Platform/OpenBSD.cmake | 1 + Modules/Platform/UnixPaths.cmake | 3 ++- Source/cmFindLibraryCommand.cxx | 9 ++++----- Source/cmFindPackageCommand.cxx | 11 +++++++++++ Source/cmFindPackageCommand.h | 1 + Source/cmMakefile.cxx | 8 ++++++++ Source/cmMakefile.h | 3 +++ Tests/CMakeOnly/find_library/CMakeLists.txt | 7 +++++++ Tests/CMakeOnly/find_library/lib/32/libtest5.a | 0 Tests/CMakeOnly/find_library/lib/A/lib32/libtest3.a | 0 Tests/CMakeOnly/find_library/lib32/A/lib/libtest2.a | 0 Tests/CMakeOnly/find_library/lib32/A/lib32/libtest4.a | 0 Tests/CMakeOnly/find_library/lib32/A/libtest4.a | 0 Tests/CMakeOnly/find_library/lib32/libtest4.a | 0 .../FindPkgConfig/FindPkgConfig_CMAKE_APPBUNDLE_PATH.cmake | 11 ++++++++--- .../FindPkgConfig/FindPkgConfig_CMAKE_FRAMEWORK_PATH.cmake | 11 ++++++++--- .../FindPkgConfig/FindPkgConfig_NO_PKGCONFIG_PATH.cmake | 3 --- .../RunCMake/FindPkgConfig/FindPkgConfig_PKGCONFIG_PATH.cmake | 11 ++++++++--- ...ndPkgConfig_PKGCONFIG_PATH_NO_CMAKE_ENVIRONMENT_PATH.cmake | 11 ++++++++--- .../FindPkgConfig_PKGCONFIG_PATH_NO_CMAKE_PATH.cmake | 11 ++++++++--- .../FindPkgConfig/pc-bar/lib32/pkgconfig/.placeholder | 0 .../FindPkgConfig/pc-foo/lib32/pkgconfig/.placeholder | 0 27 files changed, 102 insertions(+), 27 deletions(-) create mode 100644 Help/prop_gbl/FIND_LIBRARY_USE_LIB32_PATHS.rst create mode 100644 Tests/CMakeOnly/find_library/lib/32/libtest5.a create mode 100644 Tests/CMakeOnly/find_library/lib/A/lib32/libtest3.a create mode 100644 Tests/CMakeOnly/find_library/lib32/A/lib/libtest2.a create mode 100644 Tests/CMakeOnly/find_library/lib32/A/lib32/libtest4.a create mode 100644 Tests/CMakeOnly/find_library/lib32/A/libtest4.a create mode 100644 Tests/CMakeOnly/find_library/lib32/libtest4.a create mode 100644 Tests/RunCMake/FindPkgConfig/pc-bar/lib32/pkgconfig/.placeholder create mode 100644 Tests/RunCMake/FindPkgConfig/pc-foo/lib32/pkgconfig/.placeholder diff --git a/Help/command/find_library.rst b/Help/command/find_library.rst index 31e6ec0..1eb50f7 100644 --- a/Help/command/find_library.rst +++ b/Help/command/find_library.rst @@ -49,6 +49,13 @@ path to the framework ``/A.framework``. When a full path to a framework is used as a library, CMake will use a ``-framework A``, and a ``-F`` to link the framework to the target. +If the :prop_gbl:`FIND_LIBRARY_USE_LIB32_PATHS` global property is set +all search paths will be tested as normal, with ``32/`` appended, and +with all matches of ``lib/`` replaced with ``lib32/``. This property is +automatically set for the platforms that are known to need it if at +least one of the languages supported by the :command:`project` command +is enabled. + If the :prop_gbl:`FIND_LIBRARY_USE_LIB64_PATHS` global property is set all search paths will be tested as normal, with ``64/`` appended, and with all matches of ``lib/`` replaced with ``lib64/``. This property is diff --git a/Help/manual/cmake-properties.7.rst b/Help/manual/cmake-properties.7.rst index 3403dcd..3574b7f 100644 --- a/Help/manual/cmake-properties.7.rst +++ b/Help/manual/cmake-properties.7.rst @@ -24,6 +24,7 @@ Properties of Global Scope /prop_gbl/DISABLED_FEATURES /prop_gbl/ENABLED_FEATURES /prop_gbl/ENABLED_LANGUAGES + /prop_gbl/FIND_LIBRARY_USE_LIB32_PATHS /prop_gbl/FIND_LIBRARY_USE_LIB64_PATHS /prop_gbl/FIND_LIBRARY_USE_OPENBSD_VERSIONING /prop_gbl/GLOBAL_DEPENDS_DEBUG_MODE diff --git a/Help/prop_gbl/FIND_LIBRARY_USE_LIB32_PATHS.rst b/Help/prop_gbl/FIND_LIBRARY_USE_LIB32_PATHS.rst new file mode 100644 index 0000000..3911e49 --- /dev/null +++ b/Help/prop_gbl/FIND_LIBRARY_USE_LIB32_PATHS.rst @@ -0,0 +1,9 @@ +FIND_LIBRARY_USE_LIB32_PATHS +---------------------------- + +Whether FIND_LIBRARY should automatically search lib32 directories. + +FIND_LIBRARY_USE_LIB32_PATHS is a boolean specifying whether the +FIND_LIBRARY command should automatically search the lib32 variant of +directories called lib in the search path when building 32-bit +binaries. diff --git a/Modules/FindPkgConfig.cmake b/Modules/FindPkgConfig.cmake index 644687c..33290c4 100644 --- a/Modules/FindPkgConfig.cmake +++ b/Modules/FindPkgConfig.cmake @@ -316,9 +316,13 @@ macro(_pkg_check_modules_internal _is_required _is_silent _no_cmake_path _no_cma list(APPEND _lib_dirs "lib/${CMAKE_LIBRARY_ARCHITECTURE}/pkgconfig") endif() else() - # not debian, chech the FIND_LIBRARY_USE_LIB64_PATHS property + # not debian, check the FIND_LIBRARY_USE_LIB32_PATHS and FIND_LIBRARY_USE_LIB64_PATHS properties + get_property(uselib32 GLOBAL PROPERTY FIND_LIBRARY_USE_LIB32_PATHS) + if(uselib32 AND CMAKE_SIZEOF_VOID_P EQUAL 4) + list(APPEND _lib_dirs "lib32/pkgconfig") + endif() get_property(uselib64 GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS) - if(uselib64) + if(uselib64 AND CMAKE_SIZEOF_VOID_P EQUAL 8) list(APPEND _lib_dirs "lib64/pkgconfig") endif() endif() diff --git a/Modules/Platform/Linux.cmake b/Modules/Platform/Linux.cmake index e40a74f..1f8c1b4 100644 --- a/Modules/Platform/Linux.cmake +++ b/Modules/Platform/Linux.cmake @@ -50,8 +50,9 @@ set(CMAKE_LIBRARY_ARCHITECTURE_REGEX "[a-z0-9_]+(-[a-z0-9_]+)?-linux-gnu[a-z0-9_ include(Platform/UnixPaths) -# Debian has lib64 paths only for compatibility so they should not be +# Debian has lib32 and lib64 paths only for compatibility so they should not be # searched. if(NOT CMAKE_CROSSCOMPILING AND EXISTS "/etc/debian_version") + set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB32_PATHS FALSE) set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS FALSE) endif() diff --git a/Modules/Platform/OpenBSD.cmake b/Modules/Platform/OpenBSD.cmake index 7ac6c7e..6466a0a 100644 --- a/Modules/Platform/OpenBSD.cmake +++ b/Modules/Platform/OpenBSD.cmake @@ -18,6 +18,7 @@ endif() set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_OPENBSD_VERSIONING 1) # OpenBSD has no multilib +set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB32_PATHS FALSE) set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS FALSE) # OpenBSD policy requires that shared libraries be installed without diff --git a/Modules/Platform/UnixPaths.cmake b/Modules/Platform/UnixPaths.cmake index 20ee1d1..d6c3d41 100644 --- a/Modules/Platform/UnixPaths.cmake +++ b/Modules/Platform/UnixPaths.cmake @@ -93,5 +93,6 @@ list(APPEND CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES /usr/include ) -# Enable use of lib64 search path variants by default. +# Enable use of lib32 and lib64 search path variants by default. +set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB32_PATHS TRUE) set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS TRUE) diff --git a/Source/cmFindLibraryCommand.cxx b/Source/cmFindLibraryCommand.cxx index a4d4dbb..3094fcf 100644 --- a/Source/cmFindLibraryCommand.cxx +++ b/Source/cmFindLibraryCommand.cxx @@ -40,11 +40,10 @@ bool cmFindLibraryCommand::InitialPass(std::vector const& argsIn, return true; } - if (const char* abi_name = - this->Makefile->GetDefinition("CMAKE_INTERNAL_PLATFORM_ABI")) { - std::string abi = abi_name; - if (abi.find("ELF N32") != abi.npos) { - // Convert lib to lib32. + if (this->Makefile->GetState()->GetGlobalPropertyAsBool( + "FIND_LIBRARY_USE_LIB32_PATHS")) { + // add special 32 bit paths if this is a 32 bit compile. + if (this->Makefile->PlatformIs32Bit()) { this->AddArchitecturePaths("32"); } } diff --git a/Source/cmFindPackageCommand.cxx b/Source/cmFindPackageCommand.cxx index 7908afe..1a44d73 100644 --- a/Source/cmFindPackageCommand.cxx +++ b/Source/cmFindPackageCommand.cxx @@ -43,6 +43,7 @@ cmFindPackageCommand::cmFindPackageCommand() this->UseConfigFiles = true; this->UseFindModules = true; this->DebugMode = false; + this->UseLib32Paths = false; this->UseLib64Paths = false; this->PolicyScope = true; this->VersionMajor = 0; @@ -110,6 +111,13 @@ bool cmFindPackageCommand::InitialPass(std::vector const& args, this->LibraryArchitecture = arch; } + // Lookup whether lib32 paths should be used. + if (this->Makefile->PlatformIs32Bit() && + this->Makefile->GetState()->GetGlobalPropertyAsBool( + "FIND_LIBRARY_USE_LIB32_PATHS")) { + this->UseLib32Paths = true; + } + // Lookup whether lib64 paths should be used. if (this->Makefile->PlatformIs64Bit() && this->Makefile->GetState()->GetGlobalPropertyAsBool( @@ -1907,6 +1915,9 @@ bool cmFindPackageCommand::SearchPrefix(std::string const& prefix_in) if (!this->LibraryArchitecture.empty()) { common.push_back("lib/" + this->LibraryArchitecture); } + if (this->UseLib32Paths) { + common.push_back("lib32"); + } if (this->UseLib64Paths) { common.push_back("lib64"); } diff --git a/Source/cmFindPackageCommand.h b/Source/cmFindPackageCommand.h index eff6b80..9019f1b 100644 --- a/Source/cmFindPackageCommand.h +++ b/Source/cmFindPackageCommand.h @@ -148,6 +148,7 @@ private: bool NoUserRegistry; bool NoSystemRegistry; bool DebugMode; + bool UseLib32Paths; bool UseLib64Paths; bool PolicyScope; std::string LibraryArchitecture; diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx index ca30b3d..eaf6a7d 100644 --- a/Source/cmMakefile.cxx +++ b/Source/cmMakefile.cxx @@ -2076,6 +2076,14 @@ bool cmMakefile::IsSet(const std::string& name) const return true; } +bool cmMakefile::PlatformIs32Bit() const +{ + if (const char* sizeof_dptr = this->GetDefinition("CMAKE_SIZEOF_VOID_P")) { + return atoi(sizeof_dptr) == 4; + } + return false; +} + bool cmMakefile::PlatformIs64Bit() const { if (const char* sizeof_dptr = this->GetDefinition("CMAKE_SIZEOF_VOID_P")) { diff --git a/Source/cmMakefile.h b/Source/cmMakefile.h index c665b1f..1d9ccd0 100644 --- a/Source/cmMakefile.h +++ b/Source/cmMakefile.h @@ -437,6 +437,9 @@ public: bool IsOn(const std::string& name) const; bool IsSet(const std::string& name) const; + /** Return whether the target platform is 32-bit. */ + bool PlatformIs32Bit() const; + /** Return whether the target platform is 64-bit. */ bool PlatformIs64Bit() const; diff --git a/Tests/CMakeOnly/find_library/CMakeLists.txt b/Tests/CMakeOnly/find_library/CMakeLists.txt index 2d4ecaf..9958650 100644 --- a/Tests/CMakeOnly/find_library/CMakeLists.txt +++ b/Tests/CMakeOnly/find_library/CMakeLists.txt @@ -33,16 +33,23 @@ endmacro() set(CMAKE_FIND_LIBRARY_PREFIXES "lib") set(CMAKE_FIND_LIBRARY_SUFFIXES ".a") +set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB32_PATHS TRUE) set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS TRUE) set(CMAKE_SIZEOF_VOID_P 4) foreach(lib + lib/32/libtest5.a lib/A/lib/libtest1.a + lib/A/lib32/libtest3.a lib/A/libtest1.a lib/libtest1.a lib/libtest2.a lib/libtest3.a lib/libtest3.a + lib32/A/lib/libtest2.a + lib32/A/lib32/libtest4.a + lib32/A/libtest4.a + lib32/libtest4.a ) test_find_library_subst(${lib}) endforeach() diff --git a/Tests/CMakeOnly/find_library/lib/32/libtest5.a b/Tests/CMakeOnly/find_library/lib/32/libtest5.a new file mode 100644 index 0000000..e69de29 diff --git a/Tests/CMakeOnly/find_library/lib/A/lib32/libtest3.a b/Tests/CMakeOnly/find_library/lib/A/lib32/libtest3.a new file mode 100644 index 0000000..e69de29 diff --git a/Tests/CMakeOnly/find_library/lib32/A/lib/libtest2.a b/Tests/CMakeOnly/find_library/lib32/A/lib/libtest2.a new file mode 100644 index 0000000..e69de29 diff --git a/Tests/CMakeOnly/find_library/lib32/A/lib32/libtest4.a b/Tests/CMakeOnly/find_library/lib32/A/lib32/libtest4.a new file mode 100644 index 0000000..e69de29 diff --git a/Tests/CMakeOnly/find_library/lib32/A/libtest4.a b/Tests/CMakeOnly/find_library/lib32/A/libtest4.a new file mode 100644 index 0000000..e69de29 diff --git a/Tests/CMakeOnly/find_library/lib32/libtest4.a b/Tests/CMakeOnly/find_library/lib32/libtest4.a new file mode 100644 index 0000000..e69de29 diff --git a/Tests/RunCMake/FindPkgConfig/FindPkgConfig_CMAKE_APPBUNDLE_PATH.cmake b/Tests/RunCMake/FindPkgConfig/FindPkgConfig_CMAKE_APPBUNDLE_PATH.cmake index 9d4826f..4a41533 100644 --- a/Tests/RunCMake/FindPkgConfig/FindPkgConfig_CMAKE_APPBUNDLE_PATH.cmake +++ b/Tests/RunCMake/FindPkgConfig/FindPkgConfig_CMAKE_APPBUNDLE_PATH.cmake @@ -1,4 +1,4 @@ -# Needed for CMAKE_SYSTEM_NAME, CMAKE_LIBRARY_ARCHITECTURE and FIND_LIBRARY_USE_LIB64_PATHS +# Needed for CMAKE_SYSTEM_NAME, CMAKE_LIBRARY_ARCHITECTURE, FIND_LIBRARY_USE_LIB32_PATHS and FIND_LIBRARY_USE_LIB64_PATHS enable_language(C) # Prepare environment and variables @@ -29,10 +29,15 @@ if(NOT DEFINED CMAKE_SYSTEM_NAME set(expected_path "/baz:${CMAKE_CURRENT_SOURCE_DIR}/pc-foo/lib/pkgconfig:${CMAKE_CURRENT_SOURCE_DIR}/pc-bar/lib/pkgconfig") endif() else() - # not debian, chech the FIND_LIBRARY_USE_LIB64_PATHS property + # not debian, check the FIND_LIBRARY_USE_LIB32_PATHS and FIND_LIBRARY_USE_LIB64_PATHS properties + get_property(uselib32 GLOBAL PROPERTY FIND_LIBRARY_USE_LIB32_PATHS) get_property(uselib64 GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS) - if(uselib64) + if(uselib32 AND CMAKE_SIZEOF_VOID_P EQUAL 4) + set(expected_path "/baz:${CMAKE_CURRENT_SOURCE_DIR}/pc-foo/lib32/pkgconfig:${CMAKE_CURRENT_SOURCE_DIR}/pc-foo/lib/pkgconfig:${CMAKE_CURRENT_SOURCE_DIR}/pc-bar/lib32/pkgconfig:${CMAKE_CURRENT_SOURCE_DIR}/pc-bar/lib/pkgconfig") + elseif(uselib64 AND CMAKE_SIZEOF_VOID_P EQUAL 8) set(expected_path "/baz:${CMAKE_CURRENT_SOURCE_DIR}/pc-foo/lib64/pkgconfig:${CMAKE_CURRENT_SOURCE_DIR}/pc-foo/lib/pkgconfig:${CMAKE_CURRENT_SOURCE_DIR}/pc-bar/lib64/pkgconfig:${CMAKE_CURRENT_SOURCE_DIR}/pc-bar/lib/pkgconfig") + else() + set(expected_path "/baz:${CMAKE_CURRENT_SOURCE_DIR}/pc-foo/lib/pkgconfig:${CMAKE_CURRENT_SOURCE_DIR}/pc-bar/lib/pkgconfig") endif() endif() else() diff --git a/Tests/RunCMake/FindPkgConfig/FindPkgConfig_CMAKE_FRAMEWORK_PATH.cmake b/Tests/RunCMake/FindPkgConfig/FindPkgConfig_CMAKE_FRAMEWORK_PATH.cmake index d9943d4..b66d02f 100644 --- a/Tests/RunCMake/FindPkgConfig/FindPkgConfig_CMAKE_FRAMEWORK_PATH.cmake +++ b/Tests/RunCMake/FindPkgConfig/FindPkgConfig_CMAKE_FRAMEWORK_PATH.cmake @@ -1,4 +1,4 @@ -# Needed for CMAKE_SYSTEM_NAME, CMAKE_LIBRARY_ARCHITECTURE and FIND_LIBRARY_USE_LIB64_PATHS +# Needed for CMAKE_SYSTEM_NAME, CMAKE_LIBRARY_ARCHITECTURE, FIND_LIBRARY_USE_LIB32_PATHS and FIND_LIBRARY_USE_LIB64_PATHS enable_language(C) # Prepare environment and variables @@ -29,10 +29,15 @@ if(NOT DEFINED CMAKE_SYSTEM_NAME set(expected_path "/baz:${CMAKE_CURRENT_SOURCE_DIR}/pc-foo/lib/pkgconfig:${CMAKE_CURRENT_SOURCE_DIR}/pc-bar/lib/pkgconfig") endif() else() - # not debian, chech the FIND_LIBRARY_USE_LIB64_PATHS property + # not debian, check the FIND_LIBRARY_USE_LIB64_PATHS and FIND_LIBRARY_USE_LIB64_PATHS properties + get_property(uselib32 GLOBAL PROPERTY FIND_LIBRARY_USE_LIB32_PATHS) get_property(uselib64 GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS) - if(uselib64) + if(uselib32 AND CMAKE_SIZEOF_VOID_P EQUAL 4) + set(expected_path "/baz:${CMAKE_CURRENT_SOURCE_DIR}/pc-foo/lib32/pkgconfig:${CMAKE_CURRENT_SOURCE_DIR}/pc-foo/lib/pkgconfig:${CMAKE_CURRENT_SOURCE_DIR}/pc-bar/lib32/pkgconfig:${CMAKE_CURRENT_SOURCE_DIR}/pc-bar/lib/pkgconfig") + elseif(uselib64 AND CMAKE_SIZEOF_VOID_P EQUAL 8) set(expected_path "/baz:${CMAKE_CURRENT_SOURCE_DIR}/pc-foo/lib64/pkgconfig:${CMAKE_CURRENT_SOURCE_DIR}/pc-foo/lib/pkgconfig:${CMAKE_CURRENT_SOURCE_DIR}/pc-bar/lib64/pkgconfig:${CMAKE_CURRENT_SOURCE_DIR}/pc-bar/lib/pkgconfig") + else() + set(expected_path "/baz:${CMAKE_CURRENT_SOURCE_DIR}/pc-foo/lib/pkgconfig:${CMAKE_CURRENT_SOURCE_DIR}/pc-bar/lib/pkgconfig") endif() endif() else() diff --git a/Tests/RunCMake/FindPkgConfig/FindPkgConfig_NO_PKGCONFIG_PATH.cmake b/Tests/RunCMake/FindPkgConfig/FindPkgConfig_NO_PKGCONFIG_PATH.cmake index 89ce4c6..25a775d 100644 --- a/Tests/RunCMake/FindPkgConfig/FindPkgConfig_NO_PKGCONFIG_PATH.cmake +++ b/Tests/RunCMake/FindPkgConfig/FindPkgConfig_NO_PKGCONFIG_PATH.cmake @@ -1,6 +1,3 @@ -# Needed for CMAKE_SYSTEM_NAME, CMAKE_LIBRARY_ARCHITECTURE and FIND_LIBRARY_USE_LIB64_PATHS -enable_language(C) - # Prepare environment and variables set(PKG_CONFIG_USE_CMAKE_PREFIX_PATH FALSE) set(CMAKE_PREFIX_PATH "${CMAKE_CURRENT_SOURCE_DIR}/pc-foo") diff --git a/Tests/RunCMake/FindPkgConfig/FindPkgConfig_PKGCONFIG_PATH.cmake b/Tests/RunCMake/FindPkgConfig/FindPkgConfig_PKGCONFIG_PATH.cmake index c903279..bdecb8a 100644 --- a/Tests/RunCMake/FindPkgConfig/FindPkgConfig_PKGCONFIG_PATH.cmake +++ b/Tests/RunCMake/FindPkgConfig/FindPkgConfig_PKGCONFIG_PATH.cmake @@ -1,4 +1,4 @@ -# Needed for CMAKE_SYSTEM_NAME, CMAKE_LIBRARY_ARCHITECTURE and FIND_LIBRARY_USE_LIB64_PATHS +# Needed for CMAKE_SYSTEM_NAME, CMAKE_LIBRARY_ARCHITECTURE, FIND_LIBRARY_USE_LIB32_PATHS and FIND_LIBRARY_USE_LIB64_PATHS enable_language(C) # Prepare environment and variables @@ -29,10 +29,15 @@ if(NOT DEFINED CMAKE_SYSTEM_NAME set(expected_path "/baz:${CMAKE_CURRENT_SOURCE_DIR}/pc-foo/lib/pkgconfig:${CMAKE_CURRENT_SOURCE_DIR}/pc-bar/lib/pkgconfig") endif() else() - # not debian, chech the FIND_LIBRARY_USE_LIB64_PATHS property + # not debian, check the FIND_LIBRARY_USE_LIB32_PATHS and FIND_LIBRARY_USE_LIB64_PATHS propertie + get_property(uselib32 GLOBAL PROPERTY FIND_LIBRARY_USE_LIB32_PATHS) get_property(uselib64 GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS) - if(uselib64) + if(uselib32 AND CMAKE_SIZEOF_VOID_P EQUAL 4) + set(expected_path "/baz:${CMAKE_CURRENT_SOURCE_DIR}/pc-foo/lib32/pkgconfig:${CMAKE_CURRENT_SOURCE_DIR}/pc-foo/lib/pkgconfig:${CMAKE_CURRENT_SOURCE_DIR}/pc-bar/lib32/pkgconfig:${CMAKE_CURRENT_SOURCE_DIR}/pc-bar/lib/pkgconfig") + elseif(uselib64 AND CMAKE_SIZEOF_VOID_P EQUAL 8) set(expected_path "/baz:${CMAKE_CURRENT_SOURCE_DIR}/pc-foo/lib64/pkgconfig:${CMAKE_CURRENT_SOURCE_DIR}/pc-foo/lib/pkgconfig:${CMAKE_CURRENT_SOURCE_DIR}/pc-bar/lib64/pkgconfig:${CMAKE_CURRENT_SOURCE_DIR}/pc-bar/lib/pkgconfig") + else() + set(expected_path "/baz:${CMAKE_CURRENT_SOURCE_DIR}/pc-foo/lib/pkgconfig:${CMAKE_CURRENT_SOURCE_DIR}/pc-bar/lib/pkgconfig") endif() endif() else() diff --git a/Tests/RunCMake/FindPkgConfig/FindPkgConfig_PKGCONFIG_PATH_NO_CMAKE_ENVIRONMENT_PATH.cmake b/Tests/RunCMake/FindPkgConfig/FindPkgConfig_PKGCONFIG_PATH_NO_CMAKE_ENVIRONMENT_PATH.cmake index a52bcbf..df67235 100644 --- a/Tests/RunCMake/FindPkgConfig/FindPkgConfig_PKGCONFIG_PATH_NO_CMAKE_ENVIRONMENT_PATH.cmake +++ b/Tests/RunCMake/FindPkgConfig/FindPkgConfig_PKGCONFIG_PATH_NO_CMAKE_ENVIRONMENT_PATH.cmake @@ -1,4 +1,4 @@ -# Needed for CMAKE_SYSTEM_NAME, CMAKE_LIBRARY_ARCHITECTURE and FIND_LIBRARY_USE_LIB64_PATHS +# Needed for CMAKE_SYSTEM_NAME, CMAKE_LIBRARY_ARCHITECTURE, FIND_LIBRARY_USE_LIB32_PATHS and FIND_LIBRARY_USE_LIB64_PATHS enable_language(C) # Prepare environment and variables @@ -29,10 +29,15 @@ if(NOT DEFINED CMAKE_SYSTEM_NAME set(expected_path "/baz:${CMAKE_CURRENT_SOURCE_DIR}/pc-foo/lib/pkgconfig") endif() else() - # not debian, chech the FIND_LIBRARY_USE_LIB64_PATHS property + # not debian, check the FIND_LIBRARY_USE_LIB32_PATHS and FIND_LIBRARY_USE_LIB64_PATHS properties + get_property(uselib32 GLOBAL PROPERTY FIND_LIBRARY_USE_LIB32_PATHS) get_property(uselib64 GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS) - if(uselib64) + if(uselib32 AND CMAKE_SIZEOF_VOID_P EQUAL 4) + set(expected_path "/baz:${CMAKE_CURRENT_SOURCE_DIR}/pc-foo/lib32/pkgconfig:${CMAKE_CURRENT_SOURCE_DIR}/pc-foo/lib/pkgconfig") + elseif(uselib64 AND CMAKE_SIZEOF_VOID_P EQUAL 8) set(expected_path "/baz:${CMAKE_CURRENT_SOURCE_DIR}/pc-foo/lib64/pkgconfig:${CMAKE_CURRENT_SOURCE_DIR}/pc-foo/lib/pkgconfig") + else() + set(expected_path "/baz:${CMAKE_CURRENT_SOURCE_DIR}/pc-foo/lib/pkgconfig") endif() endif() else() diff --git a/Tests/RunCMake/FindPkgConfig/FindPkgConfig_PKGCONFIG_PATH_NO_CMAKE_PATH.cmake b/Tests/RunCMake/FindPkgConfig/FindPkgConfig_PKGCONFIG_PATH_NO_CMAKE_PATH.cmake index 2fabe5b..1351b6f 100644 --- a/Tests/RunCMake/FindPkgConfig/FindPkgConfig_PKGCONFIG_PATH_NO_CMAKE_PATH.cmake +++ b/Tests/RunCMake/FindPkgConfig/FindPkgConfig_PKGCONFIG_PATH_NO_CMAKE_PATH.cmake @@ -1,4 +1,4 @@ -# Needed for CMAKE_SYSTEM_NAME, CMAKE_LIBRARY_ARCHITECTURE and FIND_LIBRARY_USE_LIB64_PATHS +# Needed for CMAKE_SYSTEM_NAME, CMAKE_LIBRARY_ARCHITECTURE, FIND_LIBRARY_USE_LIB32_PATHS and FIND_LIBRARY_USE_LIB64_PATHS enable_language(C) # Prepare environment and variables @@ -29,10 +29,15 @@ if(NOT DEFINED CMAKE_SYSTEM_NAME set(expected_path "/baz:${CMAKE_CURRENT_SOURCE_DIR}/pc-bar/lib/pkgconfig") endif() else() - # not debian, chech the FIND_LIBRARY_USE_LIB64_PATHS property + # not debian, check the FIND_LIBRARY_USE_LIB64_PATHS and FIND_LIBRARY_USE_LIB32_PATHS properties + get_property(uselib32 GLOBAL PROPERTY FIND_LIBRARY_USE_LIB32_PATHS) get_property(uselib64 GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS) - if(uselib64) + if(uselib32 AND CMAKE_SIZEOF_VOID_P EQUAL 4) + set(expected_path "/baz:${CMAKE_CURRENT_SOURCE_DIR}/pc-bar/lib32/pkgconfig:${CMAKE_CURRENT_SOURCE_DIR}/pc-bar/lib/pkgconfig") + elseif(uselib64 AND CMAKE_SIZEOF_VOID_P EQUAL 8) set(expected_path "/baz:${CMAKE_CURRENT_SOURCE_DIR}/pc-bar/lib64/pkgconfig:${CMAKE_CURRENT_SOURCE_DIR}/pc-bar/lib/pkgconfig") + else() + set(expected_path "/baz:${CMAKE_CURRENT_SOURCE_DIR}/pc-bar/lib/pkgconfig") endif() endif() else() diff --git a/Tests/RunCMake/FindPkgConfig/pc-bar/lib32/pkgconfig/.placeholder b/Tests/RunCMake/FindPkgConfig/pc-bar/lib32/pkgconfig/.placeholder new file mode 100644 index 0000000..e69de29 diff --git a/Tests/RunCMake/FindPkgConfig/pc-foo/lib32/pkgconfig/.placeholder b/Tests/RunCMake/FindPkgConfig/pc-foo/lib32/pkgconfig/.placeholder new file mode 100644 index 0000000..e69de29 -- 2.8.4 From Tobias.Hunger at qt.io Fri Jun 10 10:28:09 2016 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Fri, 10 Jun 2016 14:28:09 +0000 Subject: [cmake-developers] daemon-mode: Project structure In-Reply-To: <575AC96B.5010503@kitware.com> References: <1465465663.811.98.camel@qt.io> <1465487561.811.165.camel@qt.io> <575AC96B.5010503@kitware.com> Message-ID: <1465568887.811.204.camel@qt.io> On Fr, 2016-06-10 at 10:06 -0400, Brad King wrote: > On 06/09/2016 11:52 AM, Tobias Hunger wrote: > > ? [== CMake MetaMagic ==[ > > What is the purpose of this non-json wrapper in the content? > Just part of the message protocol so that readers do not have > to parse the json to know when the end of the message is reached > (balanced with the start)? At this time the daemon-mode accepts commands via stdin and responds via stdout. The problem is that cmake will still happily send lots of output to stdout... and in theory could even accept input from stdin. So Stephen added these CMake MetaMagic around the JSON input/output. It is pretty convenient for debugging and testing and we can always ask libuv to communicate via a socket instead if that becomes necessary. > I'd prefer a more descriptive name than "MetaMagic". Please feel free to suggest whatever you prefer. I have no opinion on these strings, as long as they are fixed:-) > * What information to store about library build locations? Or maybe list > > build > > ???artifacts instead? > > I prefer the latter as I've mentioned elsewhere in the related threads. Any pointers on how to get to that information? Any example code that gets the artifact list? I do not think this information is particularly worthwhile to add, but am open to change this. Best Regards, Tobias -- Tobias Hunger,?Senior?Software Engineer?| The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From daniel at pfeifer-mail.de Fri Jun 10 10:34:03 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Fri, 10 Jun 2016 16:34:03 +0200 Subject: [cmake-developers] Questions about coding conventions In-Reply-To: <1465568217.811.192.camel@qt.io> References: <1465568217.811.192.camel@qt.io> Message-ID: On Fri, Jun 10, 2016 at 4:16 PM, Tobias Hunger wrote: > On Fr, 2016-06-10 at 15:30 +0200, Daniel Pfeifer wrote: >> Naming conventions: Classes are named cmLikeThis. Member functions >> and member variables are named LikeThis. Local variables are named >> likeThis. Members are always accessed with `this->`. So far it is >> pretty consistent. But how to name free functions and macros? I have >> seen all kinds of variations. > > May I asked why "this->" is used so often? I find it totally annoying to skip > this line noise all the time and I never encountered this convention before. If used consistently, it indicates that you are dealing with a member. I personally prefer `this->` over `m_`. With semantic syntax highlighting you probably don't need either of them. But then again, you often look at code that does not have semantic highlighting (eg. inside diffs). From brad.king at kitware.com Fri Jun 10 10:40:12 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 10 Jun 2016 10:40:12 -0400 Subject: [cmake-developers] Questions about coding conventions In-Reply-To: References: <1465568217.811.192.camel@qt.io> Message-ID: <575AD14C.5060500@kitware.com> On 06/10/2016 10:34 AM, Daniel Pfeifer wrote: >> May I asked why "this->" is used so often? > > If used consistently, it indicates that you are dealing with a member. > I personally prefer `this->` over `m_`. ... > you often look at code that does not have semantic highlighting (eg. > inside diffs). Yes, and this has been part of our coding convention from the beginning of CMake. -Brad From brad.king at kitware.com Fri Jun 10 10:41:32 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 10 Jun 2016 10:41:32 -0400 Subject: [cmake-developers] daemon-mode: Project structure In-Reply-To: <1465568887.811.204.camel@qt.io> References: <1465465663.811.98.camel@qt.io> <1465487561.811.165.camel@qt.io> <575AC96B.5010503@kitware.com> <1465568887.811.204.camel@qt.io> Message-ID: <575AD19C.1010705@kitware.com> On 06/10/2016 10:28 AM, Tobias Hunger wrote: > Any pointers on how to get to that information? Any example code that gets the > artifact list? > > I do not think this information is particularly worthwhile to add, but am open > to change this. An "artifactDirectory" field is not appropriate because there can be more than one artifact per target, and in different directories. What is it that an IDE might want to do with this information? If nothing, we could just drop it for now. The cmGeneratorTarget::GetFullName method will give you the name of the "main" file for a target. Passing `implib = true` will give the DLL import library path on platforms where IsDLLPlatform returns true. -Brad From brad.king at kitware.com Fri Jun 10 10:42:27 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 10 Jun 2016 10:42:27 -0400 Subject: [cmake-developers] cmCacheManager related changes In-Reply-To: <1465547694.811.172.camel@qt.io> References: <1465547694.811.172.camel@qt.io> Message-ID: <575AD1D3.3020709@kitware.com> On 06/10/2016 04:34 AM, Tobias Hunger wrote: > I got some more changes to enable daemon-mode to access the full contents of the > CMakeCacheManager. With these patches and the daemon mode as of today Daniel > should be able to implement something like ccmake with daemon-mode only. Nice. I've applied more of the changes from the beginning of that topic: cmLocalGenerator: Constify AppendDefines and AddCompileDefinitions https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=853b1bb4 cmLocalGenerator: Add GetTargetDefines to get all defines for a target https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f62ed322 cmake: Kill cmake::CacheManager and its getter https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7066218e cmPropertyList: Add a way to retrieve all properties https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=120899c6 cmCacheEntry: Retrieve all properties of cache entries https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6eee2463 cmState: Expose list of properties of values in the cache https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=63c0e92c Thanks, -Brad From brad.king at kitware.com Fri Jun 10 10:48:47 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 10 Jun 2016 10:48:47 -0400 Subject: [cmake-developers] Update bash completion scripts In-Reply-To: References: <575AC71E.6050207@kitware.com> Message-ID: <575AD34F.5040405@kitware.com> On 06/10/2016 10:12 AM, Eric Noulard wrote: > Here you go. Thanks. I've revised the original series: bash-completion: Add cmake --help-manual https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f67afbdc bash-completion: Fix cmake --help-policy lookup https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=48cb388e bash-completion: Add ctest --help-{manual,module,policy,property,variable} https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b08cae9b bash-completion: Add cpack --help-{manual,module,policy,property} https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=797c3c54 -Brad From brad.king at kitware.com Fri Jun 10 11:11:09 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 10 Jun 2016 11:11:09 -0400 Subject: [cmake-developers] [PATCH] Search lib32 on more platforms In-Reply-To: <20160610141118.22264-1-daniel@constexpr.org> References: <20160610141118.22264-1-daniel@constexpr.org> Message-ID: <575AD88D.40006@kitware.com> On 06/10/2016 10:11 AM, Daniel Scharrer wrote: > This adss a global property FIND_LIBRARY_USE_LIB32_PATHS analogous to > the FIND_LIBRARY_USE_LIB64_PATHS property, fixing linking issues on > multilib systems that use lib32 directories and either don't have lib > symlinks or point lib to lib64. > > Bug: https://public.kitware.com/Bug/view.php?id=11260 Very nice! Applied with minor tweaks: Teach find_library and find_package to search lib32 paths (#11260) https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=896ad251 Thanks, -Brad From Tobias.Hunger at qt.io Fri Jun 10 11:24:10 2016 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Fri, 10 Jun 2016 15:24:10 +0000 Subject: [cmake-developers] daemon-mode: Project structure In-Reply-To: <575AD19C.1010705@kitware.com> References: <1465465663.811.98.camel@qt.io> <1465487561.811.165.camel@qt.io> <575AC96B.5010503@kitware.com> <1465568887.811.204.camel@qt.io> <575AD19C.1010705@kitware.com> Message-ID: <1465572248.811.220.camel@qt.io> On Fr, 2016-06-10 at 10:41 -0400, Brad King wrote: > On 06/10/2016 10:28 AM, Tobias Hunger wrote: > > Any pointers on how to get to that information? Any example code that gets > > the > > artifact list? > > > > I do not think this information is particularly worthwhile to add, but am > > open > > to change this. > > An "artifactDirectory" field is not appropriate because there can be more > than one artifact per target, and in different directories.??What is it > that an IDE might want to do with this information???If nothing, we could > just drop it for now. I need the path to executables that get built as well as directories that libraries (dlls in windows) end up in, so that I can set up the environment for the executables in such a way that they find their libraries. > The cmGeneratorTarget::GetFullName method will give you the name of the > "main" file for a target.??Passing `implib = true` will give the DLL > import library path on platforms where IsDLLPlatform returns true. I would have never found that! I'll change the code to list both the main artefact and the implib (if applicable). Best Regards, Tobias -- Tobias Hunger,?Senior?Software Engineer?| The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From brad.king at kitware.com Fri Jun 10 11:48:12 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 10 Jun 2016 11:48:12 -0400 Subject: [cmake-developers] daemon-mode: Project structure In-Reply-To: <1465572248.811.220.camel@qt.io> References: <1465465663.811.98.camel@qt.io> <1465487561.811.165.camel@qt.io> <575AC96B.5010503@kitware.com> <1465568887.811.204.camel@qt.io> <575AD19C.1010705@kitware.com> <1465572248.811.220.camel@qt.io> Message-ID: <575AE13C.90401@kitware.com> On 06/10/2016 11:24 AM, Tobias Hunger wrote: >> The cmGeneratorTarget::GetFullName method will give you the name of the >> "main" file for a target. Passing `implib = true` will give the DLL >> import library path on platforms where IsDLLPlatform returns true. > > I would have never found that! > > I'll change the code to list both the main artefact and the implib (if > applicable). Oops, I meant to point you at cmGeneratorTarget::GetFullPath to get the absolute paths with file names. -Brad From Tobias.Hunger at qt.io Fri Jun 10 11:19:42 2016 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Fri, 10 Jun 2016 15:19:42 +0000 Subject: [cmake-developers] Questions about coding conventions In-Reply-To: References: <1465568217.811.192.camel@qt.io> Message-ID: <1465571980.811.215.camel@qt.io> On Fr, 2016-06-10 at 16:34 +0200, Daniel Pfeifer wrote: > If used consistently, it indicates that you are dealing with a member. > I personally prefer `this->` over `m_`. With semantic syntax > highlighting you probably don't need either of them. But then again, > you often look at code that does not have semantic highlighting (eg. > inside diffs). So you optimize for teletype terminals and punish everybody that has invested in new stuff like screens with *color* in the last couple of decades:-/ /me is trapped in 1995! Best Regards, Tobias -- Tobias Hunger,?Senior?Software Engineer?| The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From tobias.hunger at gmail.com Fri Jun 10 12:31:17 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Fri, 10 Jun 2016 18:31:17 +0200 Subject: [cmake-developers] CMake daemon-mode In-Reply-To: <5759AE22.6090405@kitware.com> References: <1465227569.811.38.camel@qt.io> <5755B1AF.3000504@kitware.com> <1465310542.811.42.camel@qt.io> <5756DED0.5010404@kitware.com> <575702F2.6020502@kitware.com> <5758279C.1020706@kitware.com> <57596EAF.1020806@kitware.com> <5759AE22.6090405@kitware.com> Message-ID: Hi Brad, On Thu, Jun 9, 2016 at 7:57 PM, Brad King wrote: > On 06/09/2016 09:27 AM, Brad King wrote: >>> https://github.com/hunger/CMake/commit/bc060a44b6b2c2281ffe99815163ba02ec835dd6 >> Good. I need to review that one more deeply but should be able to integrate it. > > I split out some incremental commits toward that: > > cmCommonTargetGenerator: De-duplicate CMAKE_BUILD_TYPE lookup > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=de4ee088 > > cmLocalGenerator: Adopt GetFrameworkFlags method > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=70d3bf85 > > cmLocalGenerator: Move GetFrameworkFlags implementation to private helper > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d9613b96 > > Please rebase on that (at least once it is in master). > > For the main change, please also move over AddFortranFlags, perhaps > becoming cmLocalGenerator::GetFortranFlags. The result should be > that cmCommonTargetGenerator::GetFlags moves into the new > cmLocalGenerator::GetTargetCompileFlags method except for the caching. > That will preserve flag order for GetFlags. > > For the Xcode part of the changes, we cannot use the full > GetTargetCompileFlags. The reason is that for Xcode some of the > flags, like the architecture settings, become .pbxproj file properties > instead of raw flags. It may be simplest to just drop that part of > the change for now. Or, we need to factor out an intermediate helper > that can be shared by GetTargetCompileFlags and Xcode. I did try to do the changes you requested. The branch is here: https://github.com/hunger/CMake/commits/compileflags Some comments on the individual commits (and a direct link): This moves the fortran module directory creation: https://github.com/hunger/CMake/commit/eb417fef8bd1c91041a211899a2a7984aa75774d Next patch moves the AddFortranFlags code. This will need some careful review, as it removes a path conversion that were present in the original code (in two places). I could just not figure out how to convert in the new place. https://github.com/hunger/CMake/commit/2d5f6c673cc8a39f8590acfc23d4a6d5af8900a7 Then I add the cmLocalGenerator::GetTargetCompileFlags method I want. https://github.com/hunger/CMake/commit/9be6beddfe2c2eac6b61d572ee3e5131b0f0b30e Finally I convert the Sublime generator over to the new code: https://github.com/hunger/CMake/commit/deb0793a243c266aee00d4f6e07685a5268f3dae As I said, the second one will need some special care during the review. I did run all unit tests with all patches applied, and all pass on my system. Best Regards, Tobias From steveire at gmail.com Fri Jun 10 14:17:34 2016 From: steveire at gmail.com (Stephen Kelly) Date: Fri, 10 Jun 2016 20:17:34 +0200 Subject: [cmake-developers] Review request: extract-cmMessenger branch References: <56AA8B31.2010209@gmail.com> <57592643.3090104@gmail.com> <1465463211.811.89.camel@qt.io> Message-ID: Tobias Hunger wrote: > Forcing messages into one consistent format will be a pain, agreed, but > continuing to add messages in whatever form the developer likes at the > time of writing the code is even worse. CMake has a lot of different error > message styles! This is something my branch addresses in part, which is why I drew attention to it in the context of the daemon. > If you were to unify on e.g. > > CMake Error at FILE:LINE (OPTIONAL_EXTRA_INFO): > MULTILINE_MESSAGE_WITH_INDENT_ENDING_IN_TWO_NEWLINES > > then you will probably hit existing code paths in IDEs. I don't think that's possible for all messages (not all messages have file or line information). However, that's not a problem when messages are delivered through the daemon, so I suggest that https://github.com/steveire/cmake/tree/extract-cmMessenger and the daemon itself are good places to direct your attention to improve this situation. Thanks, Steve. From steveire at gmail.com Fri Jun 10 14:13:50 2016 From: steveire at gmail.com (Stephen Kelly) Date: Fri, 10 Jun 2016 20:13:50 +0200 Subject: [cmake-developers] cmCacheManager related changes References: <1465547694.811.172.camel@qt.io> <575AD1D3.3020709@kitware.com> Message-ID: Brad King wrote: > cmState: Expose list of properties of values in the cache > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=63c0e92c The way these classes are designed, cmState is intended to be the way to access state which generally does not change during a CMake configure run in a way which would be observable to and relevant to the daemon. Things which do change in such a way should be accessed through cmState::Snapshot, or classes which depend on cmState::Snapshot such as cmState::Directory for directory properties, or some day cmState::Target for target properties. That way those properties can be versioned. It is true that some existing things in cmState should not be there (commands, cache properties etc). You can consider whether now is the time to move the cache property access to cmState::Snapshot (even without versioning internally) instead of adding more methods related to cache properties to cmState directly. Thanks, Steve. From steveire at gmail.com Fri Jun 10 14:52:46 2016 From: steveire at gmail.com (Stephen Kelly) Date: Fri, 10 Jun 2016 20:52:46 +0200 Subject: [cmake-developers] daemon-mode: Project structure References: <1465465663.811.98.camel@qt.io> Message-ID: Tobias Hunger wrote: > Hello everybody, > > I made some progress with extracting project structure from cmake via the > daemon-mode. I am rather happy with the information and would love to get > some feedback from other interested parties. > > Here is the format that is currently reported (with comments;-): > > [== CMake MetaMagic ==[ > { > # Reply header: > "cookie":"", > "type":"reply" > "inReplyTo":"project", Part of the design of the daemon is that messages that it sends can be 'spontaneous' - it watches for filesystem changes and can tell clients to re-read the buildsystem information. The inReplyTo does not fit that model. Additionally, it appears to be redundant if you have a 'cookie'? > > # Data: > "projects": What you call 'projects' appear to be 'targets' in CMake vocabulary. Is that correct? Note that a project is something different in CMake vocabulary (see the project command). Note also that in CMake, targets (libraries, executables etc) have a project name. Conceptualizing this as 'a project is a group of targets' doesn't work well because of how CMake deals with multiple project() commands and the VS and Xcode structures it generates. See cmGlobalGenerator::FillProjectMap() and how the result of that method is used. It is important that the daemon does not create a new claim of truth in this regard - the structure from the daemon should be the same as the structure generated for those ide projects. You may need to understand that before you can create something final here. Of course, my branch https://github.com/steveire/CMake/commits/cmake-daemon-lite is already 'correct' in this regard. I think you need to understand my branch more. You're doing some different things, but you haven't compared and explained the differences I think. There should be comparison and convergence in the end. > Is this the information you need for IDE integration? You might be packing too much into one protocol verb. Try this on LLVM and VTK for example to see how much data it is. Perhaps then compare with the gradual approach in my branch. In my branch I have * `buildsystem` - Get the targets (name, type, project) and backtraces * `target_info` - Get buildsystem properties for a target * `file_info` - Get buildsystem properties for a file in a target Getting the backtraces (instead of the location) for targets is important - the location relevant to the user might be a macro invocation, not the inside of a macro. See: https://www.youtube.com/watch?v=BPgXuvPAl-8&t=870 In general I think you are missing a lot by not understanding my branch. My branch is created with the mindset of 'expose what is correct in CMake'. You are creating what you think QtCreator needs - that's good, but what is needed is convergence between the two. If you rebase your work on top of mine, then you can explain why you do that, and we can find out if you are exposing 'correct' information (I'm thinking again of the project stuff). For your convenience, I have pushed your work to my clone (after rebasing): https://github.com/steveire/CMake/commits/daemon-hunger I suggest you continue your work from there. That way we can discuss your changes and converge on something correct. Notice that some of your changes make some diffs needlessly big and therefore harder to understand. For example you rename member variables from mLoop to m_Loop, and you rename the cmMetadataServer class to cmServer. Both only make it harder to understand your patches. I recommend fixing up your patches to remove those differences. That way we can converge on the dual goals of exposing correct information, and exposing what QtCreator needs. You are currently diverging from my work without explaining the differences, leading to incorrectness in some cases, and you are missing out on the work that I have already done. Thanks, Steve. From brad.king at kitware.com Fri Jun 10 15:19:39 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 10 Jun 2016 15:19:39 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake Issue Tracker Moved Message-ID: <575B12CB.4010009@kitware.com> Hi Folks, CMake issue tracking is now hosted on Kitware's GitLab instance: https://gitlab.kitware.com/cmake/cmake/issues The old mantis issue tracker will remain available as a read-only reference. All CMake issues from that tracker have been migrated to the new CMake Issues page with their original numbers intact and links back to the original mantis pages in their descriptions. Further discussion of any issue should take place on its new page. If you do not have an account on Kitware's GitLab instance, please visit this page to register and sign in: https://gitlab.kitware.com/users/sign_in If you have a GitHub Account (github.com) or a Google Account you may optionally use the corresponding icon on the "Sign in with" line instead of entering a user name and password. Alternatively, you may register with a user name and password first, and then visit your user settings Account page: https://gitlab.kitware.com/profile/account and associate your GitHub or Google accounts in the "Social sign-in" section. We also encourage you to enable two-factor authentication. For developers who could be assigned issues in mantis before, please email me privately with your Kitware GitLab user name so I can add you as a developer in the new CMake Issues page. The issues on the new page have not been assigned automatically. If an issue was assigned to you in mantis that you still wish to have assigned to you, please manually self-assign on the new page. Those issues that were open in mantis before the migration have been Resolved as "moved". One may use the old mantis query page here: https://cmake.org/Bug/view_all_bug_page.php Query for "Resolution: moved" and "Assigned To: " to find issues previously assigned to you that were not resolved prior to migration. -Brad From daniel at pfeifer-mail.de Fri Jun 10 16:07:41 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Fri, 10 Jun 2016 22:07:41 +0200 Subject: [cmake-developers] Review request: extract-cmMessenger branch In-Reply-To: References: <56AA8B31.2010209@gmail.com> <57592643.3090104@gmail.com> <1465463211.811.89.camel@qt.io> Message-ID: On Fri, Jun 10, 2016 at 8:17 PM, Stephen Kelly wrote: > Tobias Hunger wrote: >> Forcing messages into one consistent format will be a pain, agreed, but >> continuing to add messages in whatever form the developer likes at the >> time of writing the code is even worse. CMake has a lot of different error >> message styles! > > This is something my branch addresses in part, which is why I drew attention > to it in the context of the daemon. > >> If you were to unify on e.g. >> >> CMake Error at FILE:LINE (OPTIONAL_EXTRA_INFO): >> MULTILINE_MESSAGE_WITH_INDENT_ENDING_IN_TWO_NEWLINES >> >> then you will probably hit existing code paths in IDEs. > > I don't think that's possible for all messages (not all messages have file > or line information). > > However, that's not a problem when messages are delivered through the > daemon, so I suggest that > > https://github.com/steveire/cmake/tree/extract-cmMessenger > > and the daemon itself are good places to direct your attention to improve > this situation. I have reviewed the branch and wrote some inline comments on github. Overall, I confirm this is the right approach. So, "approval" from my side. From daniel at pfeifer-mail.de Fri Jun 10 16:25:44 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Fri, 10 Jun 2016 22:25:44 +0200 Subject: [cmake-developers] Questions about coding conventions In-Reply-To: <1465571980.811.215.camel@qt.io> References: <1465568217.811.192.camel@qt.io> <1465571980.811.215.camel@qt.io> Message-ID: On Fri, Jun 10, 2016 at 5:19 PM, Tobias Hunger wrote: > On Fr, 2016-06-10 at 16:34 +0200, Daniel Pfeifer wrote: >> If used consistently, it indicates that you are dealing with a member. >> I personally prefer `this->` over `m_`. With semantic syntax >> highlighting you probably don't need either of them. But then again, >> you often look at code that does not have semantic highlighting (eg. >> inside diffs). > > So you optimize for teletype terminals and punish everybody that has invested in > new stuff like screens with *color* in the last couple of decades:-/ > > /me is trapped in 1995! In 2016, semantic highlighting is the exception rather than the norm. I expect that to remain that way for some years to come. Git diff output, compiler diagnostics, github, the woboc code browser are all very colorful. Yet, members are not highlighted anywhere. From konstantin at podsvirov.pro Fri Jun 10 16:54:23 2016 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Fri, 10 Jun 2016 23:54:23 +0300 Subject: [cmake-developers] [ANNOUNCE] New Modules and Ports at DaD's House Message-ID: <4755441465592063@web10g.yandex.ru> Hi guys! Hello developers! My "DaD's Project" is based on CMake and QtIFW (specifically CPackIFW) continues its development: http://dad.podsvirov.pro - the official "DaD's House" website now. "DaD's House" is a resource where you can download the installers to install necessary dependencies and immediately begin developing their projects. Already declared support 40 the following modules: Curses, ZLib, LibPNG, Jpeg, Libxml2, LibTIFF, Perl, OpenSSL, LibSSH2, cURL, PCRE, PROJ, Expat, FreeType, SQLite, GEOS, GDAL, Boost, Qt, QtIFW, CMake KDSoap, OSG, osgEarth, osgQtQuick, PostgreSQL, Apache.Apr, The Apache.AprUtil, Apache.Httpd, Protobuf, gRPC, MapServer, Bullet, QCA, wxWidgets, LibXSLT, iconv, pgAdmin3, Wt, FreeGLUT. Also available in 4 port: - Windows Visual C++ Compiler 12.0 32bit - Windows Visual C++ Compiler 12.0 64bit and NEW - Windows 5.3.0 MinGW w64 32bit - Windows 5.3.0 MinGW w64 64bit The last 2 ports have appeared recently and there are still large but interesting work. All of this can be a good basis for your projects. All this is a good basis for my personal growth. I assess the status of the project as a Beta and write to lists for developers of basic technologies. Open the curtain. For each module I have a small CMakeLists.txt: http://git.podsvirov.pro/?a=project_list;pf=dad/mod These scripts help me to build the modules and create a repository of binary components. There is a need to spread content. All available here: http://download.podsvirov.pro My server is small and weak. I need help in distribution. I need a mirror "main" module: rsync://podsvirov.pro If there are interested parties and you give me the address of the mirror, then I can add them to MirrorBrain setup for more efficient distribution. If you are interested in developing this technology or already use my installers, I would like to hear your opinion and to get feedback. Have a great weekend and good luck in development of your projects! -- Regards, Konstantin Podsvirov From tobias.hunger at gmail.com Fri Jun 10 17:35:04 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Fri, 10 Jun 2016 23:35:04 +0200 Subject: [cmake-developers] daemon-mode: Project structure In-Reply-To: References: <1465465663.811.98.camel@qt.io> Message-ID: Hi Stephen, Am 10.06.2016 20:53 schrieb "Stephen Kelly" : > > [== CMake MetaMagic ==[ > > { > > # Reply header: > > "cookie":"", > > "type":"reply" > > "inReplyTo":"project", > > Part of the design of the daemon is that messages that it sends can be > 'spontaneous' - it watches for filesystem changes and can tell clients to > re-read the buildsystem information. That is currently not done or needed, but can be added. > The inReplyTo does not fit that model. It does. A filesystem change would be "type":"signal" or something instead and will not have a inReplyTo (as it was not generated in reply to something. > Additionally, it appears to be > redundant if you have a 'cookie'? No, cookies are to attach user data to requests and that is entirely orthogonal to what inReplyTo does. > > > > # Data: > > "projects": > > What you call 'projects' appear to be 'targets' in CMake vocabulary. Is that > correct? Note that a project is something different in CMake vocabulary (see > the project command). Actually that is exactly what is returned here. > Note also that in CMake, targets (libraries, executables etc) have a project > name. Conceptualizing this as 'a project is a group of targets' doesn't > work well because of how CMake deals with multiple project() commands and > the VS and Xcode structures it generates. See > > cmGlobalGenerator::FillProjectMap() > > and how the result of that method is used. It is important that the daemon > does not create a new claim of truth in this regard - the structure from the > daemon should be the same as the structure generated for those ide projects. Why? I want the structure that *CMake* sees. What some unrelated program generates out of that structure is irrelevant. > > Is this the information you need for IDE integration? > > You might be packing too much into one protocol verb. Try this on LLVM and > VTK for example to see how much data it is. Perhaps then compare with the > gradual approach in my branch. CMake itself is way below 100KiB. A typical developer machine should be able to handle several 10MiB of JSON data just fine. So I do not expect a problem there. > In my branch I have > > * `buildsystem` - Get the targets (name, type, project) and backtraces > * `target_info` - Get buildsystem properties for a target > * `file_info` - Get buildsystem properties for a file in a target I know. I did not like that, so I did it differently. Basically I do want the really important information in one go instead of requesting a little bit, iterate over the data, request some more, ... In the end that is a lots of needless round trips and you send more data over the wire, too, with all the protocol overhead. > Getting the backtraces (instead of the location) for targets is important - I am aware of the importance of backtraces, but I do not see any use case where this information needs to be available at the point the project structure is requested. An IDE can for example request backtraces for a target when/if needed and does not need it right away to set up a project tree and code model. A tool to run a static analyzer over all C++ files in a project will not need backtraces ever. This is why that information is not contained in the project structure at all. Yes, we need to provide a way to retrieve backtraces for targets (and other symbols), but not here. The biggest part of your mail is about the history of the patch set and how to collaborate further. My cmake-daemon branch on github documents how I got from your branch to mine. I basically copied the cmServer* files from that branch on top of a fresh CMake checkout when I started the new branch, removing all the Process* functions and wiring up the server again. There was no change outside the cmServer* files apart from the wiring to start the daemon. Then I proceeded to add the Process* methods and other functionality back in. I did that to make review simpler for *other* reviewers. I had not expected you to chime in at all. Don't get me wrong: I appreciate you experience, your patience and your reviews! I just had not expected it. The impression I got talking to you before is that you do not have the resources to push this functionality forward at this time. In fact that is the *only* reason I stepped up for this task. This is why I wonder how working through your branch is supposed to function within the resource limits on your side? I do not want for this work to vanish into some obscure github branch somewhere for weeks and month -- as it did so far. The CMake daemon is too cool a feature for that! Best Regards, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at pfeifer-mail.de Fri Jun 10 17:43:46 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Fri, 10 Jun 2016 23:43:46 +0200 Subject: [cmake-developers] Questions about coding conventions In-Reply-To: <575AC3F6.30108@kitware.com> References: <575AC3F6.30108@kitware.com> Message-ID: On Fri, Jun 10, 2016 at 3:43 PM, Brad King wrote: > On 06/10/2016 09:30 AM, Daniel Pfeifer wrote: >> By looking at the CMake source code, there are some inconsistencies >> regarding coding conventions. This is not a big problem and fixing >> them probably does not have a high priority. >> I would like to know what conventions to follow for new code. > > Please look at documenting this in CONTRIBUTING.rst once we resolve > this discussion. ok. >> Formatting: No longer an issue. A .clang-format is provided and most >> inconsistencies have disappeared. > > Yes, and thanks for all your work on that. > >> Braces around single conditional statements: This is currently not >> consistent. Should they be avoided? Should they be required? We could >> add the missing ones with clang-tidy. If we want them. > > The intention has been to use braces for all blocks even with single > statements. Due to lack of documentation and enforcement this has > not been maintained consistently. I have added some missing ones: https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=a16bf141bc5d393b27d13d8235d95a1b034052c2 >> Naming conventions: Classes are named cmLikeThis. Member functions >> and member variables are named LikeThis. Local variables are named >> likeThis. Members are always accessed with `this->`. > > Yes, though there are also many local variables named `like_this` too. > I have no strong feelings on enforcing local variable name conventions. > >> So far it is pretty consistent. But how to name free functions and >> macros? I have seen all kinds of variations. > > No convention was ever established for those. I see. Any strong opinion whether a convention should be established? I would assume UPPER_CASE for macros. Any prefix? Any opinions about free functions? >> `const T` or `T const` (also: `const T&` or `T const&`): Currently, >> CMake uses both. I have not analyzed which one dominates. > > I prefer `T const` always, except for `const char*` specifically. Good. >> Passing and returning strings: We have `const char*`, `std::string`, >> and `std::string const&`. Unifying this can affect performance. >> Storing `const char*` in a `std::string` creates a (potentially >> unneded) copy (assuming it is not null). `const char*` can distinguish >> invalid from empty. Do we actually need this distinction? > > Last year we had a few cleanup passes done along those lines, but > it is far from consistent everywhere. There are cases where we > need to distinguish invalid from empty, like GetDefinition(). It > would be nice to have an optional or something like that > so we can keep the distinction but avoid using `const char*` all > over. Any change like this should be introduced gradually, as > many of the related areas are performance sensitive. So the convention would be to use `std::string` or `cmOptional` as return values. Should `std::string const&` be allowed as return value? Arguments should be preferred as `const&` I assume. Some other questions: Can't `std::ifstream` and `std::ofstream` be used directly? It seams that kwsys does some workarounds for Visual Studio 2005 and newer. That surprises me. Workarounds are usually used for older, not newer compilers. I see that `#include ` is preferred over `#include `. Are there old compilers supported that prohibit the latter or was it just not changed yet? cmStandardIncludes.h includes many standard headers. That is against the idea of include-what-you-use. Is there a particular requirement or was it just not cleaned up yet? Should we begin using newer language features optionally by providing macros like CM_OVERRIDE? From steveire at gmail.com Sat Jun 11 08:14:47 2016 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 11 Jun 2016 14:14:47 +0200 Subject: [cmake-developers] Review request: extract-cmMessenger branch In-Reply-To: References: <56AA8B31.2010209@gmail.com> <57592643.3090104@gmail.com> <1465463211.811.89.camel@qt.io> Message-ID: <575C00B7.1030407@gmail.com> On 06/10/2016 10:07 PM, Daniel Pfeifer wrote: > On Fri, Jun 10, 2016 at 8:17 PM, Stephen Kelly wrote: >> However, that's not a problem when messages are delivered through the >> daemon, so I suggest that >> >> https://github.com/steveire/cmake/tree/extract-cmMessenger >> >> and the daemon itself are good places to direct your attention to improve >> this situation. > I have reviewed the branch and wrote some inline comments on github. > Overall, I confirm this is the right approach. So, "approval" from my side. Thanks for your thorough review! I think I've fixed the errors I introduced while rebasing now. I'm not completely certain that the gymnastics I do with the cmListFileBacktrace in the parser in the early commits in the branch are correct or appropriate. Thanks, Steve. From steveire at gmail.com Sat Jun 11 09:36:50 2016 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 11 Jun 2016 15:36:50 +0200 Subject: [cmake-developers] daemon-mode: Project structure In-Reply-To: References: <1465465663.811.98.camel@qt.io> Message-ID: <575C13F2.301@gmail.com> On 06/10/2016 11:35 PM, Tobias Hunger wrote: > > > Part of the design of the daemon is that messages that it sends can be > > 'spontaneous' - it watches for filesystem changes and can tell > clients to > > re-read the buildsystem information. > > That is currently not done or needed, but can be added. > I think this is essential to the first version of the protocol. The daemon is a long-running process, so it needs to be able to report about changes it is (designed to be) aware of. The central goal of the daemon is to make it easier to implement good support in existing tools and in new tools. In your branch you have a reset command in the protocol. I think that should be dropped because the daemon protocol should be designed such that it is never needed. > > Additionally, it appears to be > > redundant if you have a 'cookie'? > > No, cookies are to attach user data to requests and that is entirely > orthogonal to what inReplyTo does. > Ok. Then I don't understand why clients need inReplyTo. I don't understand why it is not redundant. Clients know what cookie they specified in a request and they get the same cookie back, so they can check their cookie jar and get the same information as inReplyTo, right? > > It is important that the daemon > > does not create a new claim of truth in this regard - the structure > from the > > daemon should be the same as the structure generated for those ide > projects. > > Why? > > I want the structure that *CMake* sees. What some unrelated program > generates out of that structure is irrelevant. > What CMake sees is what it generates for IDE buildsystems. Try taking a buildsystem of multiple directories and targets and putting project() commands at various positions - before/after add_subdirectory calls, in between targets, top of the file etc, and see what CMake does there. You might have an argument for *changing* what CMake does there, but you would need to state such a change explicitly. (and to do that you need to be aware of it in the first place) This is part of the design work for the daemon because the behavior of the daemon should not be accidental in any way. While protocol versioning will make it possible to introduce new versions of the protocol, old versions of the protocol will need to remain, and that can affect the C++ code of CMake in bad ways, particularly if what is exposed in the protocol is 'wrong' in some way. Just look at CMake policies - the first ones were introduced a decade ago and there is no plan for removing them. I emphasise the above just to make the points that: * Designing a protocol like this is hard (and not fast) * We should introduce something minimal, avoiding redundancy, because removing things is hard * The protocol should possibly expose a way to set policies so that they can be used to deprecate behaviors in a compatible way, as is done elsewhere in CMake * The version of the protocol should correspond to the version of CMake it appears in (Just like how QDataStream works). Currently you're versioning the protocol as '0.1' instead of the CMake version. Look at the mess of QML versions, and let's not reproduce that here :) http://thread.gmane.org/gmane.comp.lib.qt.devel/23246 > > > > > Is this the information you need for IDE integration? > > > > You might be packing too much into one protocol verb. Try this on > LLVM and > > VTK for example to see how much data it is. Perhaps then compare > with the > > gradual approach in my branch. > > CMake itself is way below 100KiB. > > A typical developer machine should be able to handle several 10MiB of > JSON data just fine. So I do not expect a problem there. > Then we can easily verify that and the impact (latency difference etc) with larger projects like the ones I mentioned. I don't know what's better but we should be able to quantify the impact of the choices made about what to return from particular protocol queries. > > In my branch I have > > > > * `buildsystem` - Get the targets (name, type, project) and backtraces > > * `target_info` - Get buildsystem properties for a target > > * `file_info` - Get buildsystem properties for a file in a target > > I know. I did not like that, so I did it differently. > > Basically I do want the really important information in one go instead > of requesting a little bit, iterate over the data, request some more, ... > Clients don't necessarily need all of it just to start up and show something on start. Maybe QtCreator does, I don't know. > In the end that is a lots of needless round trips and you send more > data over the wire, too, with all the protocol overhead. > That's something that should be quantifyable. If it makes no difference to compute and send it all, even on large projects then maybe that's fine. I think figuring this stuff out is part of the work of designing the protocol. > > Getting the backtraces (instead of the location) for targets is > important - > > I am aware of the importance of backtraces, but I do not see any use > case where this information needs to be available at the point the > project structure is requested. > It should also be possible to quantify the impact of that. How much extra data is it? How much latency is imposed if every time I click on a target in a treeview there is a round-trip to the server before the application even knows what should be shown in the editor next as a result of the click? How much simpler is the client code if they already have that information associated with the treeview node? > An IDE can for example request backtraces for a target when/if needed > and does not need it right away to set up a project tree and code model. > What about a clickable project tree? There are several different concerns here. You proposal might be the right answer, but my central point is that work needs to be done to analyze the needs and be explicit about the choices and trade-offs made. > A tool to run a static analyzer over all C++ files in a project will > not need backtraces ever. > A tool which *only* runs a windowless static analyzer on C++ files of a buildsystem without showing the buildsystem will probably not use the daemon. Depending on how the static analyzer works it would be likely that a different CMake feature would be more suitable. > The biggest part of your mail is about the history of the patch set > and how to collaborate further. > > I did that to make review simpler for *other* reviewers. > It makes sense to be able to compare your work with what came before it. There is a large design space here and it should be understood before merging a protocol to master. Renaming the class and renaming member variables (m_Foo is not conventional in CMake code) makes that harder. > I had not expected you to chime in at all. Don't get me wrong: I > appreciate you experience, your patience and your reviews! I just had > not expected it. The impression I got talking to you before is that > you do not have the resources to push this functionality forward at > this time. In fact that is the *only* reason I stepped up for this task. > Yes, I will provide guidance on this topic where I can. > This is why I wonder how working through your branch is supposed to > function within the resource limits on your side? > I still have knowledge to share, even if I'm not putting time into CMake development now :). > I do not want for this work to vanish into some obscure github branch > somewhere for weeks and month -- as it did so far. The CMake daemon is > too cool a feature for that! > It didn't really vanish. It's a fairly well-known repo, blog and video. No one worked on the topic for weeks or months. That is changing now, but the work to be done is still the same as it was in January. It's lots of design and analysis, and refactoring of CMake itself. The patches extracted from your branch in the last weeks are great progress for that, as is the wide-ranging refactoring from Daniel as he has more experience with the core of CMake. I don't think 'time to master' is an appropriate concern for a feature which has not received enough attention yet. This stuff is complex and I expect that doing it right would take more 'weeks and months'. My central point is that the design space for the protocol needs to be explored and understood so that: * What it exposes is correct from the CMake POV (what is 'correct' might have to be changed *first*, as you suggest might be necessary with the project parts). * It can be used by QtCreator * It can be used by other tools * It can be extended with some of the kinds of features I showcased I don't think the protocol should be merged before that kind of design work is done, but ultimately it's indeed not up to me. Maybe we should talk about these issues over a beer instead :). Thanks, Steve. From steveire at gmail.com Sat Jun 11 09:45:30 2016 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 11 Jun 2016 15:45:30 +0200 Subject: [cmake-developers] Questions about coding conventions References: <575AC3F6.30108@kitware.com> Message-ID: Daniel Pfeifer wrote: > On Fri, Jun 10, 2016 at 3:43 PM, Brad King > wrote: >> On 06/10/2016 09:30 AM, Daniel Pfeifer wrote: >>> By looking at the CMake source code, there are some inconsistencies >>> regarding coding conventions. This is not a big problem and fixing >>> them probably does not have a high priority. >>> I would like to know what conventions to follow for new code. >> >> Please look at documenting this in CONTRIBUTING.rst once we resolve >> this discussion. > > ok. Or link to Help/manual/cmake-developer.7.rst and put it there. > I see that `#include ` is preferred over `#include > `. Are there old compilers supported that prohibit the latter > or was it just not changed yet? Probably just not changed with. Porting CMake away from C++95 happened quite recently. The same is probably true of other includes like assert.h > cmStandardIncludes.h includes many standard headers. That is against > the idea of include-what-you-use. Is there a particular requirement or > was it just not cleaned up yet? I cleaned up some of these last year. IIRC there are things in cmConfigure.h which must be before some of the remaining includes, otherwise bad things happen in certain translation units on some dashboard machines. Thanks, Steve. From tobias.hunger at gmail.com Sat Jun 11 16:32:54 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Sat, 11 Jun 2016 22:32:54 +0200 Subject: [cmake-developers] daemon-mode: Project structure In-Reply-To: <575C13F2.301@gmail.com> References: <1465465663.811.98.camel@qt.io> <575C13F2.301@gmail.com> Message-ID: Hi Stephen, Am 11.06.2016 15:37 schrieb "Stephen Kelly" : > > On 06/10/2016 11:35 PM, Tobias Hunger wrote: > > > > > Part of the design of the daemon is that messages that it sends can be > > > 'spontaneous' - it watches for filesystem changes and can tell > > clients to > > > re-read the buildsystem information. > > > > That is currently not done or needed, but can be added. > > > > I think this is essential to the first version of the protocol. Let's Start small and build from there. At this time this is not needed and it is trivial to add when it becomes necessary. Can we get something that is useful and working before going overboard? > The central goal of the daemon is to make it easier to implement good > support in existing tools and in new tools. In your branch you have a > reset command in the protocol. I think that should be dropped because > the daemon protocol should be designed such that it is never needed. The Reset command is extremely handy as it allows to go back to a clean slate to e.g. switch to a different project. Without it you have to restart the daemon. I do not want to run one CMake daemon per CMake project that is open in Creator. That can be a lot, and once you store snapshots memory usage will increase quite a bit I assume:) > > > Additionally, it appears to be > > > redundant if you have a 'cookie'? > > > > No, cookies are to attach user data to requests and that is entirely > > orthogonal to what inReplyTo does. > > Ok. Then I don't understand why clients need inReplyTo. I don't > understand why it is not redundant. Clients know what cookie they > specified in a request and they get the same cookie back, so they can > check their cookie jar and get the same information as inReplyTo, right? A cookie is used to attach user data to a request. Discovering how messages relate to each other has to be possible without a cookie. > > > It is important that the daemon > > > does not create a new claim of truth in this regard - the structure > > from the > > > daemon should be the same as the structure generated for those ide > > projects. > > > > Why? > > > > I want the structure that *CMake* sees. What some unrelated program > > generates out of that structure is irrelevant. > > > > What CMake sees is what it generates for IDE buildsystems. > > Try taking a buildsystem of multiple directories and targets and putting > project() commands at various positions - before/after add_subdirectory > calls, in between targets, top of the file etc, and see what CMake does > there. > > You might have an argument for *changing* what CMake does there, but you > would need to state such a change explicitly. (and to do that you need > to be aware of it in the first place) I do not want to change anything here! This mechanism works well, it is what the Codeblocks generator uses and it also happens to be very close to how CMake operates. At least the concepts map down to CMake object very naturally. > This is part of the design work for the daemon because the behavior of > the daemon should not be accidental in any way. While protocol > versioning will make it possible to introduce new versions of the > protocol, old versions of the protocol will need to remain, and that can > affect the C++ code of CMake in bad ways, particularly if what is > exposed in the protocol is 'wrong' in some way. Just look at CMake > policies - the first ones were introduced a decade ago and there is no > plan for removing them. I see no problem there: You can always cut out old protocols if their implementation hurts too much. That sucks for users that need the old version, but it can be cleanly detected. This is an fact better than working with the command line client right now, which regularly introduces niggling small changes all over the place which are much harder to detect. > I emphasise the above just to make the points that: > > * Designing a protocol like this is hard (and not fast) We have been discussing this for about two years now. Due to the protocol versioning the implementation can be changed again later. If the old version is not too different we can do that even without breaking clients! > * We should introduce something minimal, avoiding redundancy, because > removing things is hard I agree. That is why the current daemon is very much limited to dumping the project structure. It is a strong foundation to go further than that. > * The protocol should possibly expose a way to set policies so that they > can be used to deprecate behaviors in a compatible way, as is done > elsewhere in CMake The policies applied elsewhere in CMake should already be expressed in the project structure managed by CMake. If that internal project structure changes in a significant way inside CMake, then we will need to adapt the daemon mode anyway. I see no need to to apply policies on the daemon output at this time. For now protocol versions should suffice I think. > * The version of the protocol should correspond to the version of CMake > it appears in (Just like how QDataStream works). Currently you're > versioning the protocol as '0.1' instead of the CMake version. Look at > the mess of QML versions, and let's not reproduce that here :) > > http://thread.gmane.org/gmane.comp.lib.qt.devel/23246 The protocol version is meant to get minor version bumps on feature additions and major version increases for incompatible changes anywhere in the protocol. This makes it really simple to work with for clients. If I develop something for protocol version 1.3, then I can probably work with protocol 1.5 and 1.6. Protocol version 2.3 will be more risky:) Using the CMake version as protocol version is really painful on the other hand: With each CMake release I have to test compatibility and hardcode a support matrix into Creator. This is assuming that CMake will not change its versioning scheme to follow the protocol version -- which would be silly IMHO. The protocol version is also entirely invisible to users. That is very different from QML version numbers:-) > > > > > > > > Is this the information you need for IDE integration? > > > > > > You might be packing too much into one protocol verb. Try this on > > LLVM and > > > VTK for example to see how much data it is. Perhaps then compare > > with the > > > gradual approach in my branch. > > > > CMake itself is way below 100KiB. > > > > A typical developer machine should be able to handle several 10MiB of > > JSON data just fine. So I do not expect a problem there. > > > > Then we can easily verify that and the impact (latency difference etc) > with larger projects like the ones I mentioned. I can provide numbers for my implementation. No problem there. In fact I should probably add debug features to the daemon to make it easy to collect processing times and data throughput:-) > I don't know what's better but we should be able to quantify the impact > of the choices made about what to return from particular protocol queries. > > > > In my branch I have > > > > > > * `buildsystem` - Get the targets (name, type, project) and backtraces > > > * `target_info` - Get buildsystem properties for a target > > > * `file_info` - Get buildsystem properties for a file in a target > > > > I know. I did not like that, so I did it differently. > > > > Basically I do want the really important information in one go instead > > of requesting a little bit, iterate over the data, request some more, ... > > > > Clients don't necessarily need all of it just to start up and show > something on start. Maybe QtCreator does, I don't know. ... which is why you can already limit what is returned in the project structure ... I even documented that already:-) > > In the end that is a lots of needless round trips and you send more > > data over the wire, too, with all the protocol overhead. > > > > That's something that should be quantifyable. > > If it makes no difference to compute and send it all, even on large > projects then maybe that's fine. > > I think figuring this stuff out is part of the work of designing the > protocol. > > > > Getting the backtraces (instead of the location) for targets is > > important - > > > > I am aware of the importance of backtraces, but I do not see any use > > case where this information needs to be available at the point the > > project structure is requested. > > > > It should also be possible to quantify the impact of that. How much > extra data is it? How much latency is imposed if every time I click on a > target in a treeview there is a round-trip to the server before the > application even knows what should be shown in the editor next as a > result of the click? How much simpler is the client code if they already > have that information associated with the treeview node? I would set up the tree as fast as possible and then fill in none critical information as it arrives *after the tree is displayed*. This is what Creator does anyway for nodes... add various stuff after the tree is initially displayed. > > An IDE can for example request backtraces for a target when/if needed > > and does not need it right away to set up a project tree and code model. > > > > What about a clickable project tree? See above. > There are several different concerns here. You proposal might be the > right answer, but my central point is that work needs to be done to > analyze the needs and be explicit about the choices and trade-offs made. > > > A tool to run a static analyzer over all C++ files in a project will > > not need backtraces ever. > > A tool which *only* runs a windowless static analyzer on C++ files of a > buildsystem without showing the buildsystem will probably not use the > daemon. Depending on how the static analyzer works it would be likely > that a different CMake feature would be more suitable. Daemon-mode makes it dead easy to extract the necessary information with a script. Admittedly harder than just using the JSON dump of compile commands, but it still is a use case I have in the back of my head:) Ideally you should be able to write a generator in Python using the information from daemon mode. I doubt the information returned right now suffices for that though:-) Or a UI like cmake-gui... that should actually be completely doable with the code in my branch, even though I did not discuss the necessary command on the mailing list yet. > > The biggest part of your mail is about the history of the patch set > > and how to collaborate further. > > > > I did that to make review simpler for *other* reviewers. > > > > It makes sense to be able to compare your work with what came before it. > There is a large design space here and it should be understood before > merging a protocol to master. > > Renaming the class and renaming member variables (m_Foo is not > conventional in CMake code) makes that harder. Yeap, it does. Check the cmake-daemon branch, I am pretty sure the renames are a separate commit there. I found it highly annoying that file name and class name did not match:-) I doubt that would have made it through review, too. > > I had not expected you to chime in at all. Don't get me wrong: I > > appreciate you experience, your patience and your reviews! I just had > > not expected it. The impression I got talking to you before is that > > you do not have the resources to push this functionality forward at > > this time. In fact that is the *only* reason I stepped up for this task. > > > > Yes, I will provide guidance on this topic where I can. Great:) > > This is why I wonder how working through your branch is supposed to > > function within the resource limits on your side? > > > > I still have knowledge to share, even if I'm not putting time into CMake > development now :). That is very much appreciated, but without you being able to commit to timely reviews of merge requests I will not use your branch as upstream. This daemon mode has a huge potential, and having that in a branch on github somewhere does not help anybody. > > I do not want for this work to vanish into some obscure github branch > > somewhere for weeks and month -- as it did so far. The CMake daemon is > > too cool a feature for that! > > > > It didn't really vanish. It's a fairly well-known repo, blog and video. Yes it is. And basically nobody will play with the code till it lands in CMake itself. In my experience nobody tests experimental branches ever! > No one worked on the topic for weeks or months. That is changing now, > but the work to be done is still the same as it was in January. It's > lots of design and analysis, and refactoring of CMake itself. The > patches extracted from your branch in the last weeks are great progress > for that, as is the wide-ranging refactoring from Daniel as he has more > experience with the core of CMake. I agree that refactoring of cmake is crucial to land all the functionality of your cmake-daemon branch. But let's merge the stuff that can go in as soon as possible. I am not saying that what I have now is perfect, I fully expect that to change. That is why I added the protocol version support: So that we have more freedom to change things again as feedback comes in. > I don't think 'time to master' is an appropriate concern for a feature > which has not received enough attention yet. This stuff is complex and I > expect that doing it right would take more 'weeks and months'. The project stuff is not overly complex. I know what Creator needs. I have a very good idea what other IDEs need, too. Milian already agreed that what I have now is a step forward for KDevelop. Creator already supports several build systems, so I do know what I can reasonably expect buildsystems to provide and which information is rather stable and which is not. The code you work on *is* complex, at least looking at it with the experience I have with CMake. But that is currently not discussed at all and totally outside my focus at this time. Please do not drag that complexity into this discussion. Right now the questions are: * Is the daemon infrastructure extensible and robust enough to handle more complexity as that becomes necessary. * Is there enough benefit in the project structure to warrant adding the daemon code? My hope is to get the changes I need in the CMake core merged first. Brad already merged some of these changes. Once these changes are in, the daemon-mode branch is very self-contained and only touches one file that currently exists in the CMake sources. That is the file where the command line arguments are parsed and the daemon gets started. So adding this is pretty low-risk, but of course it comes with a promise to keep the daemon working *once a CMake version that contains this code is officially released*. So we can still back out for a while longer... it will not be in the next version anyway. I did volunteer to maintain the daemon-mode code going forward. IMHO the risk the CMake project is taking with this patch set is rather limited. > My central point is that the design space for the protocol needs to be > explored and understood so that: > > * What it exposes is correct from the CMake POV (what is 'correct' might > have to be changed *first*, as you suggest might be necessary with the > project parts). > * It can be used by QtCreator > * It can be used by other tools > * It can be extended with some of the kinds of features I showcased Sorry, we have been discussing this for *years* now. Kdevelop, Clion and Creator agreed that we wanted a JSON file that is unconditionally written by CMake, with pretty much what is in the proposed project structure. IIRC that was in response to a patch by kdevelop developers in 2014. I think the requirements for a way to retrieve project structure data are pretty clear by now. How to get much of the desired information out of cmake was not. I covered almost everything now in my patch set. > I don't think the protocol should be merged before that kind of design > work is done, but ultimately it's indeed not up to me. Are you referring to the daemon infrastructure code here or the command to query the project structure? I do agree that the daemon mode infrastructure should not get merged before there is some real-world use case covered by it. > Maybe we should talk about these issues over a beer instead :). I am all for it! We both are located in Berlin, Germany after all. How about Tuesday night? Maybe somebody from KDevelop, kate or other IDEs can join in? By the way: I ask for a BoF session on CMake and IDEs at QtCon (Qtcon.org, Berlin, Germany, Sept. 1-4 IIRC). Let's hope the session will make it into the conference program. That would be a great place to discuss in a wider round. I expect you will be around for QtCon? I hope to see some parts merged by then, so that it is easy for other developers to play with the code before joining the session:-) Best Regards, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From ch.schmidbauer at gmail.com Sun Jun 12 05:59:25 2016 From: ch.schmidbauer at gmail.com (Christian Schmidbauer) Date: Sun, 12 Jun 2016 11:59:25 +0200 Subject: [cmake-developers] [PATCH] Allow LIB_SUFFIX be used as find path Message-ID: <1465725565-8925-1-git-send-email-ch.schmidbauer@gmail.com> Inspired by commit 896ad25 for bug #11260, this commit allows to use the variable LIB_SUFFIX to be used as find path as well. Allowing the find path to be more deterministic on custom setups. A similar idea has already been suggested in #10287 and is required for bug #15594. --- Help/command/find_library.rst | 5 ++++ Help/manual/cmake-properties.7.rst | 1 + Modules/FindPkgConfig.cmake | 5 +++- Source/cmFindLibraryCommand.cxx | 27 ++++++++++-------- Source/cmFindPackageCommand.cxx | 32 +++++++++++++++------- Source/cmFindPackageCommand.h | 1 + Tests/CMakeOnly/find_library/CMakeLists.txt | 14 ++++++++++ .../CMakeOnly/find_library/lib/A/libXYZ/libtest3.a | 0 Tests/CMakeOnly/find_library/lib/XYZ/libtest2.a | 0 .../CMakeOnly/find_library/libXYZ/A/lib/libtest2.a | 0 .../find_library/libXYZ/A/libXYZ/libtest1.a | 0 Tests/CMakeOnly/find_library/libXYZ/A/libtest1.a | 0 Tests/CMakeOnly/find_library/libXYZ/libtest1.a | 0 13 files changed, 62 insertions(+), 23 deletions(-) create mode 100644 Tests/CMakeOnly/find_library/lib/A/libXYZ/libtest3.a create mode 100644 Tests/CMakeOnly/find_library/lib/XYZ/libtest2.a create mode 100644 Tests/CMakeOnly/find_library/libXYZ/A/lib/libtest2.a create mode 100644 Tests/CMakeOnly/find_library/libXYZ/A/libXYZ/libtest1.a create mode 100644 Tests/CMakeOnly/find_library/libXYZ/A/libtest1.a create mode 100644 Tests/CMakeOnly/find_library/libXYZ/libtest1.a diff --git a/Help/command/find_library.rst b/Help/command/find_library.rst index 1eb50f7..66eb401 100644 --- a/Help/command/find_library.rst +++ b/Help/command/find_library.rst @@ -49,6 +49,11 @@ path to the framework ``/A.framework``. When a full path to a framework is used as a library, CMake will use a ``-framework A``, and a ``-F`` to link the framework to the target. +If the :prop_gbl:`FIND_LIBRARY_USE_CUSTOM_SUFFIX` global property is set +all search paths will be tested as normal, with `LIB_SUFFIX` appended, and +with all matches of ``lib/`` replaced with `lib${LIB_SUFFIX}/`. This property +overrides both `FIND_LIBRARY_USE_LIB32_PATHS` and `FIND_LIBRARY_USE_LIB64_PATHS`. + If the :prop_gbl:`FIND_LIBRARY_USE_LIB32_PATHS` global property is set all search paths will be tested as normal, with ``32/`` appended, and with all matches of ``lib/`` replaced with ``lib32/``. This property is diff --git a/Help/manual/cmake-properties.7.rst b/Help/manual/cmake-properties.7.rst index d16f231..128f180 100644 --- a/Help/manual/cmake-properties.7.rst +++ b/Help/manual/cmake-properties.7.rst @@ -24,6 +24,7 @@ Properties of Global Scope /prop_gbl/DISABLED_FEATURES /prop_gbl/ENABLED_FEATURES /prop_gbl/ENABLED_LANGUAGES + /prop_gbl/FIND_LIBRARY_USE_CUSTOM_SUFFIX /prop_gbl/FIND_LIBRARY_USE_LIB32_PATHS /prop_gbl/FIND_LIBRARY_USE_LIB64_PATHS /prop_gbl/FIND_LIBRARY_USE_OPENBSD_VERSIONING diff --git a/Modules/FindPkgConfig.cmake b/Modules/FindPkgConfig.cmake index 33290c4..75fbef8 100644 --- a/Modules/FindPkgConfig.cmake +++ b/Modules/FindPkgConfig.cmake @@ -311,7 +311,10 @@ macro(_pkg_check_modules_internal _is_required _is_silent _no_cmake_path _no_cma if(NOT DEFINED CMAKE_SYSTEM_NAME OR (CMAKE_SYSTEM_NAME MATCHES "^(Linux|kFreeBSD|GNU)$" AND NOT CMAKE_CROSSCOMPILING)) - if(EXISTS "/etc/debian_version") # is this a debian system ? + get_property(uselibcustom GLOBAL PROPERTY FIND_LIBRARY_USE_CUSTOM_SUFFIX) + if(uselibcustom) + list(APPEND _lib_dirs "lib${LIB_SUFFIX}/pkgconfig") + elseif(EXISTS "/etc/debian_version") # is this a debian system ? if(CMAKE_LIBRARY_ARCHITECTURE) list(APPEND _lib_dirs "lib/${CMAKE_LIBRARY_ARCHITECTURE}/pkgconfig") endif() diff --git a/Source/cmFindLibraryCommand.cxx b/Source/cmFindLibraryCommand.cxx index 3094fcf..d86137a 100644 --- a/Source/cmFindLibraryCommand.cxx +++ b/Source/cmFindLibraryCommand.cxx @@ -40,20 +40,23 @@ bool cmFindLibraryCommand::InitialPass(std::vector const& argsIn, return true; } + // add custom lib${LIB_SUFFIX} paths instead of defaults if (this->Makefile->GetState()->GetGlobalPropertyAsBool( - "FIND_LIBRARY_USE_LIB32_PATHS")) { - // add special 32 bit paths if this is a 32 bit compile. - if (this->Makefile->PlatformIs32Bit()) { - this->AddArchitecturePaths("32"); - } + "FIND_LIBRARY_USE_CUSTOM_SUFFIX") && + this->Makefile->GetDefinition("LIB_SUFFIX")) { + this->AddArchitecturePaths(this->Makefile->GetDefinition("LIB_SUFFIX")); } - - if (this->Makefile->GetState()->GetGlobalPropertyAsBool( - "FIND_LIBRARY_USE_LIB64_PATHS")) { - // add special 64 bit paths if this is a 64 bit compile. - if (this->Makefile->PlatformIs64Bit()) { - this->AddArchitecturePaths("64"); - } + // add special 32 bit paths if this is a 32 bit compile. + else if (this->Makefile->PlatformIs32Bit() && + this->Makefile->GetState()->GetGlobalPropertyAsBool( + "FIND_LIBRARY_USE_LIB32_PATHS")) { + this->AddArchitecturePaths("32"); + } + // add special 64 bit paths if this is a 64 bit compile. + else if (this->Makefile->PlatformIs64Bit() && + this->Makefile->GetState()->GetGlobalPropertyAsBool( + "FIND_LIBRARY_USE_LIB64_PATHS")) { + this->AddArchitecturePaths("64"); } std::string library = this->FindLibrary(); diff --git a/Source/cmFindPackageCommand.cxx b/Source/cmFindPackageCommand.cxx index 1a44d73..5dfedb4 100644 --- a/Source/cmFindPackageCommand.cxx +++ b/Source/cmFindPackageCommand.cxx @@ -43,6 +43,7 @@ cmFindPackageCommand::cmFindPackageCommand() this->UseConfigFiles = true; this->UseFindModules = true; this->DebugMode = false; + this->UseLibCustomSuffix = false; this->UseLib32Paths = false; this->UseLib64Paths = false; this->PolicyScope = true; @@ -111,17 +112,22 @@ bool cmFindPackageCommand::InitialPass(std::vector const& args, this->LibraryArchitecture = arch; } + // Lookup whether lib${LIB_SUFFIX} paths should be used + if (this->Makefile->GetState()->GetGlobalPropertyAsBool( + "FIND_LIBRARY_USE_CUSTOM_SUFFIX")) { + this->UseLibCustomSuffix = true; + std::cout << "FIND_LIBRARY_USE_CUSTOM_SUFFIX" << std::endl; + } // Lookup whether lib32 paths should be used. - if (this->Makefile->PlatformIs32Bit() && - this->Makefile->GetState()->GetGlobalPropertyAsBool( - "FIND_LIBRARY_USE_LIB32_PATHS")) { + else if (this->Makefile->PlatformIs32Bit() && + this->Makefile->GetState()->GetGlobalPropertyAsBool( + "FIND_LIBRARY_USE_LIB32_PATHS")) { this->UseLib32Paths = true; } - // Lookup whether lib64 paths should be used. - if (this->Makefile->PlatformIs64Bit() && - this->Makefile->GetState()->GetGlobalPropertyAsBool( - "FIND_LIBRARY_USE_LIB64_PATHS")) { + else if (this->Makefile->PlatformIs64Bit() && + this->Makefile->GetState()->GetGlobalPropertyAsBool( + "FIND_LIBRARY_USE_LIB64_PATHS")) { this->UseLib64Paths = true; } @@ -1915,10 +1921,16 @@ bool cmFindPackageCommand::SearchPrefix(std::string const& prefix_in) if (!this->LibraryArchitecture.empty()) { common.push_back("lib/" + this->LibraryArchitecture); } - if (this->UseLib32Paths) { + + if (this->UseLibCustomSuffix && + this->Makefile->GetDefinition("LIB_SUFFIX")) { + std::string custom_lib = "lib"; + custom_lib += this->Makefile->GetDefinition("LIB_SUFFIX"); + common.push_back(custom_lib.c_str()); + std::cout << "UseLibCustomSuffix() - " << custom_lib << std::endl; + } else if (this->UseLib32Paths) { common.push_back("lib32"); - } - if (this->UseLib64Paths) { + } else if (this->UseLib64Paths) { common.push_back("lib64"); } common.push_back("lib"); diff --git a/Source/cmFindPackageCommand.h b/Source/cmFindPackageCommand.h index 9019f1b..2cbeedc 100644 --- a/Source/cmFindPackageCommand.h +++ b/Source/cmFindPackageCommand.h @@ -148,6 +148,7 @@ private: bool NoUserRegistry; bool NoSystemRegistry; bool DebugMode; + bool UseLibCustomSuffix; bool UseLib32Paths; bool UseLib64Paths; bool PolicyScope; diff --git a/Tests/CMakeOnly/find_library/CMakeLists.txt b/Tests/CMakeOnly/find_library/CMakeLists.txt index 9958650..3500887 100644 --- a/Tests/CMakeOnly/find_library/CMakeLists.txt +++ b/Tests/CMakeOnly/find_library/CMakeLists.txt @@ -79,3 +79,17 @@ test_find_library("" A/libtestA.a NAMES testB testA NAMES_PER_DIR PATHS ${CMAKE_CURRENT_SOURCE_DIR}/A ${CMAKE_CURRENT_SOURCE_DIR}/B ) + +set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_CUSTOM_SUFFIX TRUE) +set(LIB_SUFFIX "XYZ") +foreach(libXYZ + lib/XYZ/libtest2.a + lib/A/libXYZ/libtest3.a + lib/libtest3.a + libXYZ/A/lib/libtest2.a + libXYZ/A/libXYZ/libtest1.a + libXYZ/A/libtest1.a + libXYZ/libtest1.a + ) + test_find_library_subst(${libXYZ}) +endforeach() diff --git a/Tests/CMakeOnly/find_library/lib/A/libXYZ/libtest3.a b/Tests/CMakeOnly/find_library/lib/A/libXYZ/libtest3.a new file mode 100644 index 0000000..e69de29 diff --git a/Tests/CMakeOnly/find_library/lib/XYZ/libtest2.a b/Tests/CMakeOnly/find_library/lib/XYZ/libtest2.a new file mode 100644 index 0000000..e69de29 diff --git a/Tests/CMakeOnly/find_library/libXYZ/A/lib/libtest2.a b/Tests/CMakeOnly/find_library/libXYZ/A/lib/libtest2.a new file mode 100644 index 0000000..e69de29 diff --git a/Tests/CMakeOnly/find_library/libXYZ/A/libXYZ/libtest1.a b/Tests/CMakeOnly/find_library/libXYZ/A/libXYZ/libtest1.a new file mode 100644 index 0000000..e69de29 diff --git a/Tests/CMakeOnly/find_library/libXYZ/A/libtest1.a b/Tests/CMakeOnly/find_library/libXYZ/A/libtest1.a new file mode 100644 index 0000000..e69de29 diff --git a/Tests/CMakeOnly/find_library/libXYZ/libtest1.a b/Tests/CMakeOnly/find_library/libXYZ/libtest1.a new file mode 100644 index 0000000..e69de29 -- 2.7.3 From ben.boeckel at kitware.com Sun Jun 12 10:26:37 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Sun, 12 Jun 2016 10:26:37 -0400 Subject: [cmake-developers] Questions about coding conventions In-Reply-To: References: Message-ID: <20160612142637.GB27068@megas.kitware.com> On Fri, Jun 10, 2016 at 15:30:05 +0200, Daniel Pfeifer wrote: > Passing and returning strings: We have `const char*`, `std::string`, > and `std::string const&`. Unifying this can affect performance. > Storing `const char*` in a `std::string` creates a (potentially > unneded) copy (assuming it is not null). I went through and changed all `const char*` paramters to `std::string const&` where the pointer was given to a string within the function (unless it was an error path or such). This allows eliding another allocation. > `const char*` can distinguish > invalid from empty. Do we actually need this distinction? It's used all over the place. --Ben From eike at sf-mail.de Sun Jun 12 12:33:24 2016 From: eike at sf-mail.de (Rolf Eike Beer) Date: Sun, 12 Jun 2016 18:33:24 +0200 Subject: [cmake-developers] FindFreetype patch for Windows debug lib naming In-Reply-To: <575ABA91.60802@kitware.com> References: <3a99b00d-a99b-da5d-5eea-1923cc145fc4@objexx.com> <18cceeab-720f-bf88-e752-c195c11aef8e@objexx.com> <575ABA91.60802@kitware.com> Message-ID: <209395162.bo6LCRPSAH@caliban.sf-tec.de> Am Freitag, 10. Juni 2016, 09:03:13 schrieb Brad King: > On 06/10/2016 03:19 AM, Stuart Mentzer wrote: > > On 6/10/2016 2:45 AM, Rolf Eike Beer wrote: > >> I'm sure I also wrote "you probably need to set/unset > >> FREETYPE_LIBRARY_RELEASE around SLC so it still works", > >> The point here is that you can't change the variable name > >> that is used in find_library() as it would break compatibility. > > > > Is there someone who can just do what is needed and let us be done with > > this? > Eike, IIRC what we've done for other modules is change the cache > entries to use ${pkg}_LIBRARY_{RELEASE,DEBUG} and then provided > compatibility with scripts that explicitly set ${pkg}_LIBRARY > by using the value if set and skipping the search. See FindZLIB > for an example of this. I'll hack something together, but that might take a day or two. 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 Stuart_Mentzer at objexx.com Sun Jun 12 13:52:36 2016 From: Stuart_Mentzer at objexx.com (Stuart Mentzer) Date: Sun, 12 Jun 2016 13:52:36 -0400 Subject: [cmake-developers] FindFreetype patch for Windows debug lib naming In-Reply-To: <209395162.bo6LCRPSAH@caliban.sf-tec.de> References: <3a99b00d-a99b-da5d-5eea-1923cc145fc4@objexx.com> <18cceeab-720f-bf88-e752-c195c11aef8e@objexx.com> <575ABA91.60802@kitware.com> <209395162.bo6LCRPSAH@caliban.sf-tec.de> Message-ID: <702f77d1-90f4-7407-6ad5-c49446874482@objexx.com> On 6/12/2016 12:33 PM, Rolf Eike Beer wrote: > Am Freitag, 10. Juni 2016, 09:03:13 schrieb Brad King: >> On 06/10/2016 03:19 AM, Stuart Mentzer wrote: >>> On 6/10/2016 2:45 AM, Rolf Eike Beer wrote: >>>> I'm sure I also wrote "you probably need to set/unset >>>> FREETYPE_LIBRARY_RELEASE around SLC so it still works", >>>> The point here is that you can't change the variable name >>>> that is used in find_library() as it would break compatibility. >>> Is there someone who can just do what is needed and let us be done with >>> this? >> Eike, IIRC what we've done for other modules is change the cache >> entries to use ${pkg}_LIBRARY_{RELEASE,DEBUG} and then provided >> compatibility with scripts that explicitly set ${pkg}_LIBRARY >> by using the value if set and skipping the search. See FindZLIB >> for an example of this. > I'll hack something together, but that might take a day or two. > > Greetings, > > Eike Looking at FindZlib.cmake I think the attached should be OK and it is working for my use case. It goes back to setting up FREETYPE_LIBRARY_RELEASE variable and letting SLC set up FREETYPE_LIBRARY, as my first try and FindZlib do. It also lets SLC do the mark_as_advanced for the _RELEASE and _DEBUG vars. If that seems good to you both I'm willing to do another patch submission. Thanks, Stuart -------------- next part -------------- #.rst: # FindFreetype # ------------ # # Locate FreeType library # # This module defines # # :: # # FREETYPE_LIBRARIES, the library to link against # FREETYPE_FOUND, if false, do not try to link to FREETYPE # FREETYPE_INCLUDE_DIRS, where to find headers. # FREETYPE_VERSION_STRING, the version of freetype found (since CMake 2.8.8) # This is the concatenation of the paths: # FREETYPE_INCLUDE_DIR_ft2build # FREETYPE_INCLUDE_DIR_freetype2 # # # # $FREETYPE_DIR is an environment variable that would correspond to the # ./configure --prefix=$FREETYPE_DIR used in building FREETYPE. #============================================================================= # Copyright 2007-2009 Kitware, Inc. # # Distributed under the OSI-approved BSD License (the "License"); # see accompanying file Copyright.txt for details. # # This software is distributed WITHOUT ANY WARRANTY; without even the # implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # See the License for more information. #============================================================================= # (To distribute this file outside of CMake, substitute the full # License text for the above reference.) # Created by Eric Wing. # Modifications by Alexander Neundorf. # This file has been renamed to "FindFreetype.cmake" instead of the correct # "FindFreeType.cmake" in order to be compatible with the one from KDE4, Alex. # Ugh, FreeType seems to use some #include trickery which # makes this harder than it should be. It looks like they # put ft2build.h in a common/easier-to-find location which # then contains a #include to a more specific header in a # more specific location (#include ). # Then from there, they need to set a bunch of #define's # so you can do something like: # #include FT_FREETYPE_H # Unfortunately, using CMake's mechanisms like include_directories() # wants explicit full paths and this trickery doesn't work too well. # I'm going to attempt to cut out the middleman and hope # everything still works. set(FREETYPE_FIND_ARGS HINTS ENV FREETYPE_DIR PATHS /usr/X11R6 /usr/local/X11R6 /usr/local/X11 /usr/freeware ENV GTKMM_BASEPATH [HKEY_CURRENT_USER\\SOFTWARE\\gtkmm\\2.4;Path] [HKEY_LOCAL_MACHINE\\SOFTWARE\\gtkmm\\2.4;Path] ) find_path( FREETYPE_INCLUDE_DIR_ft2build ft2build.h ${FREETYPE_FIND_ARGS} PATH_SUFFIXES include/freetype2 include freetype2 ) find_path( FREETYPE_INCLUDE_DIR_freetype2 NAMES freetype/config/ftheader.h config/ftheader.h ${FREETYPE_FIND_ARGS} PATH_SUFFIXES include/freetype2 include freetype2 ) if(NOT FREETYPE_LIBRARY) find_library(FREETYPE_LIBRARY_RELEASE NAMES freetype libfreetype freetype219 ${FREETYPE_FIND_ARGS} PATH_SUFFIXES lib ) find_library(FREETYPE_LIBRARY_DEBUG NAMES freetyped libfreetyped freetype219d ${FREETYPE_FIND_ARGS} PATH_SUFFIXES lib ) include(${CMAKE_CURRENT_LIST_DIR}/SelectLibraryConfigurations.cmake) select_library_configurations(FREETYPE) endif() unset(FREETYPE_FIND_ARGS) # set the user variables if(FREETYPE_INCLUDE_DIR_ft2build AND FREETYPE_INCLUDE_DIR_freetype2) set(FREETYPE_INCLUDE_DIRS "${FREETYPE_INCLUDE_DIR_ft2build};${FREETYPE_INCLUDE_DIR_freetype2}") list(REMOVE_DUPLICATES FREETYPE_INCLUDE_DIRS) endif() set(FREETYPE_LIBRARIES "${FREETYPE_LIBRARY}") if(EXISTS "${FREETYPE_INCLUDE_DIR_freetype2}/freetype/freetype.h") set(FREETYPE_H "${FREETYPE_INCLUDE_DIR_freetype2}/freetype/freetype.h") elseif(EXISTS "${FREETYPE_INCLUDE_DIR_freetype2}/freetype.h") set(FREETYPE_H "${FREETYPE_INCLUDE_DIR_freetype2}/freetype.h") endif() if(FREETYPE_INCLUDE_DIR_freetype2 AND FREETYPE_H) file(STRINGS "${FREETYPE_H}" freetype_version_str REGEX "^#[\t ]*define[\t ]+FREETYPE_(MAJOR|MINOR|PATCH)[\t ]+[0-9]+$") unset(FREETYPE_VERSION_STRING) foreach(VPART MAJOR MINOR PATCH) foreach(VLINE ${freetype_version_str}) if(VLINE MATCHES "^#[\t ]*define[\t ]+FREETYPE_${VPART}[\t ]+([0-9]+)$") set(FREETYPE_VERSION_PART "${CMAKE_MATCH_1}") if(FREETYPE_VERSION_STRING) set(FREETYPE_VERSION_STRING "${FREETYPE_VERSION_STRING}.${FREETYPE_VERSION_PART}") else() set(FREETYPE_VERSION_STRING "${FREETYPE_VERSION_PART}") endif() unset(FREETYPE_VERSION_PART) endif() endforeach() endforeach() endif() # handle the QUIETLY and REQUIRED arguments and set FREETYPE_FOUND to TRUE if # all listed variables are TRUE include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake) find_package_handle_standard_args( Freetype REQUIRED_VARS FREETYPE_LIBRARY FREETYPE_INCLUDE_DIRS VERSION_VAR FREETYPE_VERSION_STRING ) mark_as_advanced( FREETYPE_LIBRARY FREETYPE_INCLUDE_DIR_freetype2 FREETYPE_INCLUDE_DIR_ft2build ) From daniel at pfeifer-mail.de Sun Jun 12 17:47:26 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Sun, 12 Jun 2016 23:47:26 +0200 Subject: [cmake-developers] Dogfooding: clang-tidy, include-what-you-use, link-what-you-use Message-ID: Hi, now that we have integrated include-what-you-use, clang-tidy, and just recently also a mechanism for link-what-you-use, it is time we start eating our own dog food. https://en.wikipedia.org/wiki/Eating_your_own_dog_food I have set up a dashboard build where all three mechanisms are enabled: https://open.cdash.org/viewBuildError.php?type=1&buildid=4408215 The buildscript can be seen here: https://github.com/purpleKarrot/dotfiles/blob/master/config/cmake/ci_cmake.cmake I have already drastically reduced the number of clang-tidy warnings in the last weeks. I am currently experimenting with include-what-you-use and will push some changes in the coming days. Who wants to resolve the link-what-you-use violations? cheers, Daniel From daniel at pfeifer-mail.de Sun Jun 12 18:03:29 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Mon, 13 Jun 2016 00:03:29 +0200 Subject: [cmake-developers] Questions about coding conventions In-Reply-To: <20160612142637.GB27068@megas.kitware.com> References: <20160612142637.GB27068@megas.kitware.com> Message-ID: On Sun, Jun 12, 2016 at 4:26 PM, Ben Boeckel wrote: > On Fri, Jun 10, 2016 at 15:30:05 +0200, Daniel Pfeifer wrote: >> Passing and returning strings: We have `const char*`, `std::string`, >> and `std::string const&`. Unifying this can affect performance. >> Storing `const char*` in a `std::string` creates a (potentially >> unneded) copy (assuming it is not null). > > I went through and changed all `const char*` paramters to `std::string > const&` where the pointer was given to a string within the function > (unless it was an error path or such). This allows eliding another > allocation. I am aware of that. In case of passing `foo.c_str()`, this moved the creation of the unnecessary copy from inside the function to the call site, resulting in more allocations rather than less, assuming the function is called more than once. It is important to run clang-tidy after each such refactoring to remove the now unnecessary c_str() calls. >> `const char*` can distinguish >> invalid from empty. Do we actually need this distinction? > > It's used all over the place. Can you show an example? To be clear: We are looking for a function, that has a code path for `str == NULL` and a *different* codepath for `str[0] = '\0'`. From ben.boeckel at kitware.com Mon Jun 13 08:09:48 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 13 Jun 2016 08:09:48 -0400 Subject: [cmake-developers] Questions about coding conventions In-Reply-To: References: <20160612142637.GB27068@megas.kitware.com> Message-ID: <20160613120948.GB14295@megas.kitware.com> On Mon, Jun 13, 2016 at 00:03:29 +0200, Daniel Pfeifer wrote: > Can you show an example? To be clear: We are looking for a function, > that has a code path for `str == NULL` and a *different* codepath for > `str[0] = '\0'`. As input to functions? Usually NULL means "unset". See properties, variable values, etc. As an output, any place which doesn't care should already be using GetSafeDefinition(). As a concrete example, `set(CACHE)` cares about NULL versus *s == NULL: const char* existingValue = state->GetCacheEntryValue(variable); if (existingValue && (state->GetCacheEntryType(variable) != cmState::UNINITIALIZED)) { // if the set is trying to CACHE the value but the value // is already in the cache and the type is not internal // then leave now without setting any definitions in the cache // or the makefile if (cache && type != cmState::INTERNAL && !force) { return true; } } // if it is meant to be in the cache then define it in the cache if (cache) { this->Makefile->AddCacheDefinition(variable, value.c_str(), docstring, type, force); } else { // add the definition this->Makefile->AddDefinition(variable, value.c_str()); } --Ben From daniel at pfeifer-mail.de Mon Jun 13 10:14:51 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Mon, 13 Jun 2016 16:14:51 +0200 Subject: [cmake-developers] Questions about coding conventions In-Reply-To: <20160613120948.GB14295@megas.kitware.com> References: <20160612142637.GB27068@megas.kitware.com> <20160613120948.GB14295@megas.kitware.com> Message-ID: On Mon, Jun 13, 2016 at 2:09 PM, Ben Boeckel wrote: > On Mon, Jun 13, 2016 at 00:03:29 +0200, Daniel Pfeifer wrote: >> Can you show an example? To be clear: We are looking for a function, >> that has a code path for `str == NULL` and a *different* codepath for >> `str[0] = '\0'`. > > As input to functions? Either input or output. I am interested about both cases. > Usually NULL means "unset". See properties, > variable values, etc. As an output, any place which doesn't care should > already be using GetSafeDefinition(). I know that, at the moment, NULL is used for "unset" in many places. I am trying to figure out whether we could theoretically use "empy" to mean "unset". If there is a case where we distinguish between null and empty, this will not be possible. > As a concrete example, `set(CACHE)` cares about NULL versus *s == NULL: Thanks for the example. I found the check for `s != NULL` in the second line. Can you help me finding the check for `*s == NULL`? > const char* existingValue = state->GetCacheEntryValue(variable); > if (existingValue && > (state->GetCacheEntryType(variable) != cmState::UNINITIALIZED)) { > // if the set is trying to CACHE the value but the value > // is already in the cache and the type is not internal > // then leave now without setting any definitions in the cache > // or the makefile > if (cache && type != cmState::INTERNAL && !force) { > return true; > } > } > > // if it is meant to be in the cache then define it in the cache > if (cache) { > this->Makefile->AddCacheDefinition(variable, value.c_str(), docstring, > type, force); > } else { > // add the definition > this->Makefile->AddDefinition(variable, value.c_str()); > } From brad.king at kitware.com Mon Jun 13 10:16:21 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 13 Jun 2016 10:16:21 -0400 Subject: [cmake-developers] Dogfooding: clang-tidy, include-what-you-use, link-what-you-use In-Reply-To: References: Message-ID: <575EC035.1070701@kitware.com> On 06/12/2016 05:47 PM, Daniel Pfeifer wrote: > I have set up a dashboard build where all three mechanisms are enabled: [snip] > I have already drastically reduced the number of clang-tidy warnings > in the last weeks. I am currently experimenting with > include-what-you-use and will push some changes in the coming days. Thanks for your work on this! > Who wants to resolve the link-what-you-use violations? Currently that infrastructure hasn't even reached 'master' yet. Once it has then we can look at these. Thanks, -Brad From brad.king at kitware.com Mon Jun 13 10:16:29 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 13 Jun 2016 10:16:29 -0400 Subject: [cmake-developers] Questions about coding conventions In-Reply-To: References: <575AC3F6.30108@kitware.com> Message-ID: <575EC03D.9030800@kitware.com> On 06/10/2016 05:43 PM, Daniel Pfeifer wrote: >> Please look at documenting this in CONTRIBUTING.rst once we resolve >> this discussion. > > ok. +1 to Steve's suggestion of putting it in cmake-developer(7). >>> So far it is pretty consistent. But how to name free functions and >>> macros? I have seen all kinds of variations. >> >> No convention was ever established for those. > > I see. Any strong opinion whether a convention should be established? > I would assume UPPER_CASE for macros. Any prefix? > Any opinions about free functions? IIRC several existing macros use the CMAKE_ prefix and are named all upper-case. I think that or CM_ would be fine. For free functions I think naming them as cmCamelCase just like classes has been done in a few places. > So the convention would be to use `std::string` or > `cmOptional` as return values. Yes, though I think we should wait for this change until other pending cleanups are done. > Should `std::string const&` be allowed as return value? I like value semantics but IIRC we tried to replace some "getters" that currently return std::string by reference with values and it showed up in profiling for heavily-called getters. > Arguments should be preferred as `const&` I assume. Yes. > Some other questions: > > Can't `std::ifstream` and `std::ofstream` be used directly? It seams > that kwsys does some workarounds Yes, std::{o,f}stream can be used directly. KWSys may have some old workarounds that haven't been fully removed yet. > I see that `#include ` is preferred over `#include > `. Are there old compilers supported that prohibit the latter > or was it just not changed yet? The dashboard will tell us. As Steve said I think these are legacy. > cmStandardIncludes.h includes many standard headers. That is against > the idea of include-what-you-use. Is there a particular requirement or > was it just not cleaned up yet? We need cmsys/Configure.h to be the first file in every C++ translation unit. Also cmStandardIncludes.h used to have workarounds for system headers on old platforms. These days we can probably clean this up, especially with tools like include-what-you-use. > Should we begin using newer language features optionally by providing > macros like CM_OVERRIDE? Let's start with just CM_OVERRIDE. We have a lot of virtual methods and overrides so that will be a nice cleanup. It will also be a test case for initial introduction of the infrastructure needed to optionally use C++11 features. Thanks, -Brad From brad.king at kitware.com Mon Jun 13 10:16:37 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 13 Jun 2016 10:16:37 -0400 Subject: [cmake-developers] CMake daemon-mode In-Reply-To: References: <1465227569.811.38.camel@qt.io> <5755B1AF.3000504@kitware.com> <1465310542.811.42.camel@qt.io> <5756DED0.5010404@kitware.com> <575702F2.6020502@kitware.com> <5758279C.1020706@kitware.com> <57596EAF.1020806@kitware.com> <5759AE22.6090405@kitware.com> Message-ID: <575EC045.9070603@kitware.com> On 06/10/2016 12:31 PM, Tobias Hunger wrote: > I did try to do the changes you requested. The branch is here: > > https://github.com/hunger/CMake/commits/compileflags Thanks. I'm about to go on travel but should hopefully be able to look at that again when I return. -Brad From brad.king at kitware.com Mon Jun 13 10:16:46 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 13 Jun 2016 10:16:46 -0400 Subject: [cmake-developers] cmCacheManager related changes In-Reply-To: References: <1465547694.811.172.camel@qt.io> <575AD1D3.3020709@kitware.com> Message-ID: <575EC04E.1040700@kitware.com> On 06/10/2016 02:13 PM, Stephen Kelly wrote: > Things which do change in such a way should be accessed through > cmState::Snapshot, or classes which depend on cmState::Snapshot such as > cmState::Directory for directory properties, or some day cmState::Target for > target properties. That way those properties can be versioned. Thanks for explaining, Steve. > It is true that some existing things in cmState should not be there > (commands, cache properties etc). You can consider whether now is the time > to move the cache property access to cmState::Snapshot (even without > versioning internally) instead of adding more methods related to cache > properties to cmState directly. Tobias's change is just an update to the cache properties that are already exposed directly, so I think it is fine to merge it now. The added method can be subsumed into the refactoring to move it into Snapshot. Steve, would you please add comments to cmState.h to explain the above and also mark the method groups that currently violate the design with FIXME comments? Thanks, -Brad From brad.king at kitware.com Mon Jun 13 10:22:32 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 13 Jun 2016 10:22:32 -0400 Subject: [cmake-developers] Review request: extract-cmMessenger branch In-Reply-To: <575C00B7.1030407@gmail.com> References: <56AA8B31.2010209@gmail.com> <57592643.3090104@gmail.com> <1465463211.811.89.camel@qt.io> <575C00B7.1030407@gmail.com> Message-ID: <575EC1A8.3010905@kitware.com> On 06/11/2016 08:14 AM, Stephen Kelly wrote: > Thanks for your thorough review! I think I've fixed the errors I > introduced while rebasing now. > > I'm not completely certain that the gymnastics I do with the > cmListFileBacktrace in the parser in the early commits in the branch are > correct or appropriate. The role of `.Pop()` on `lfbt = this->Backtrace.Pop()` is not clear. I was not able to produce a RunCMake.Syntax test failure by removing it. The clean-up-Parser topic currently strips the backtrace lines and some other context from some expected test output even though the lines still appear, such as in Tests/RunCMake/Syntax/UnterminatedBracket0-stderr.txt and I think a few others. Please restore the context lines where possible. Overall I like the cleanup though. Thanks, -Brad From brad.king at kitware.com Mon Jun 13 11:22:42 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 13 Jun 2016 11:22:42 -0400 Subject: [cmake-developers] [PATCH] Allow LIB_SUFFIX be used as find path In-Reply-To: <1465725565-8925-1-git-send-email-ch.schmidbauer@gmail.com> References: <1465725565-8925-1-git-send-email-ch.schmidbauer@gmail.com> Message-ID: <575ECFC2.7090804@kitware.com> Hi Christian, Thanks for working on this. On 06/12/2016 05:59 AM, Christian Schmidbauer wrote: > A similar idea has already been suggested in #10287 Yes. > and is required for bug #15594. That issue appears unrelated. Did you typo the number? > Help/command/find_library.rst | 5 ++++ > Help/manual/cmake-properties.7.rst Please also add the FIND_LIBRARY_USE_CUSTOM_SUFFIX item documentation, or whatever it becomes after the discussion below. > +If the :prop_gbl:`FIND_LIBRARY_USE_CUSTOM_SUFFIX` global property is set > +all search paths will be tested as normal, with `LIB_SUFFIX` appended, and > +with all matches of ``lib/`` replaced with `lib${LIB_SUFFIX}/`. This property > +overrides both `FIND_LIBRARY_USE_LIB32_PATHS` and `FIND_LIBRARY_USE_LIB64_PATHS`. [snip] > +set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_CUSTOM_SUFFIX TRUE) > +set(LIB_SUFFIX "XYZ") Typically the FIND_LIBRARY_USE_LIB{32,64}_PATHS global properties can be set by the platform information modules in CMake itself on platforms that need the behavior. In what context might the FIND_LIBRARY_USE_CUSTOM_SUFFIX/LIB_SUFFIX values be set in practice? Thanks, -Brad From ben.boeckel at kitware.com Mon Jun 13 13:34:48 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 13 Jun 2016 13:34:48 -0400 Subject: [cmake-developers] Questions about coding conventions In-Reply-To: References: <20160612142637.GB27068@megas.kitware.com> <20160613120948.GB14295@megas.kitware.com> Message-ID: <20160613173448.GA22713@megas.kitware.com> On Mon, Jun 13, 2016 at 16:14:51 +0200, Daniel Pfeifer wrote: > On Mon, Jun 13, 2016 at 2:09 PM, Ben Boeckel wrote: > > Usually NULL means "unset". See properties, > > variable values, etc. As an output, any place which doesn't care should > > already be using GetSafeDefinition(). > > I know that, at the moment, NULL is used for "unset" in many places. I > am trying to figure out whether we could theoretically use "empy" to > mean "unset". > If there is a case where we distinguish between null and empty, this > will not be possible. And I'm saying that looking to port to GetSafeDefinition() will highlight those that *can't* be converted easily which will get you use cases for the current split. > > As a concrete example, `set(CACHE)` cares about NULL versus *s == NULL: > > Thanks for the example. I found the check for `s != NULL` in the > second line. Can you help me finding the check for `*s == NULL`? There isn't, hence the difference in behavior between NULL and empty. --Ben From steveire at gmail.com Mon Jun 13 14:53:30 2016 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 13 Jun 2016 20:53:30 +0200 Subject: [cmake-developers] Review request: extract-cmMessenger branch In-Reply-To: <575EC1A8.3010905@kitware.com> References: <56AA8B31.2010209@gmail.com> <57592643.3090104@gmail.com> <1465463211.811.89.camel@qt.io> <575C00B7.1030407@gmail.com> <575EC1A8.3010905@kitware.com> Message-ID: <575F012A.5040707@gmail.com> On 06/13/2016 04:22 PM, Brad King wrote: > On 06/11/2016 08:14 AM, Stephen Kelly wrote: >> Thanks for your thorough review! I think I've fixed the errors I >> introduced while rebasing now. >> >> I'm not completely certain that the gymnastics I do with the >> cmListFileBacktrace in the parser in the early commits in the branch are >> correct or appropriate. > The role of `.Pop()` on `lfbt = this->Backtrace.Pop()` is not clear. > I was not able to produce a RunCMake.Syntax test failure by removing it. > > The clean-up-Parser topic currently strips the backtrace lines and some > other context from some expected test output even though the lines still > appear, such as in > > Tests/RunCMake/Syntax/UnterminatedBracket0-stderr.txt > > and I think a few others. Please restore the context lines where possible. > > Overall I like the cleanup though. You're right, but I think digging into that again would take more time than I want to put into it now. I really just wanted to not have to rebase that branch again in the future :). I've merged other clean ups and pushed the rest of the extract-cmMessenger branch to my repo again. Thanks, Steve. From roman.wueger at gmx.at Mon Jun 13 14:58:14 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Mon, 13 Jun 2016 20:58:14 +0200 Subject: [cmake-developers] Problems when generating xcarchive from within Xcode Message-ID: <38A15792-E147-439A-AFDB-7580DEF05154@gmx.at> Hello, I have successfully configured a project with CMake 3.5.2 so it creates a valid Release and Debug *.app bundle which runs on iOS. However if I build an archive in Xcode with "Product->Archive" then the app bundle seems not complete under ~/Library/Developer/Xcode/Archives/YYY-MM-DD/*.xcarchive For example the Info.plist is not the same as in the Release folder, subfolders and some files are not copied/created. Did I need something special for this (the archive)? Thanks Roman From robert.maynard at kitware.com Mon Jun 13 15:08:11 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 13 Jun 2016 15:08:11 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.6.0-rc2 now ready for testing! Message-ID: I am proud to announce the second CMake 3.6 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.6 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.6/release/3.6.html Some of the more significant features of CMake 3.6 are: * The "Visual Studio 14 2015" generator learned to support the Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This feature is experimental. * The "list()" command gained a "FILTER" sub-command to filter list elements by regular expression. * A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally tell the "try_compile()" command to build a static library instead of an executable. This is useful for cross-compiling toolchains that cannot link binaries without custom flags or scripts. * A "_CLANG_TIDY" target property and supporting "CMAKE__CLANG_TIDY" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "clang-tidy" along with the compiler for "C" and "CXX" languages. * The "ExternalProject" module leared the "GIT_SHALLOW 1" option to perform a shallow clone of a Git repository. * The "ExternalProject" module learned to initialize Git submodules recursively and also to initialize new submodules on updates. Use the "GIT_SUBMODULES" option to restrict which submodules are initalized and updated. * The "InstallRequiredSystemLibraries" module learned a new "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment of the Windows Universal CRT libraries with Visual Studio 2015. * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX platforms. Deprecated and Removed Features =============================== * The "CMakeForceCompiler" module and its macros are now deprecated. See module documentation for an explanation. * The "Visual Studio 7 .NET 2003" generator is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 7" generator (for VS .NET 2002) has been removed. It had been deprecated since CMake 3.3. * The "Visual Studio 6" generator has been removed. It had been deprecated since CMake 3.3. CMake 3.6 Release Notes *********************** Changes made since CMake 3.5 include the following. New Features ============ Generators ---------- * The "Ninja" generator learned to produce phony targets of the form "sub/dir/all" to drive the build of a subdirectory. This is equivalent to "cd sub/dir; make all" with Makefile Generators. * The "Ninja" generator now includes system header files in build dependencies to ensure correct re-builds when system packages are updated. * The "Visual Studio 14 2015" generator learned to support the Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This feature is experimental. Commands -------- * The "add_custom_command()" and "add_custom_target()" commands learned how to use the "CROSSCOMPILING_EMULATOR" executable target property. * The "install()" command learned a new "EXCLUDE_FROM_ALL" option to leave installation rules out of the default installation. * The "list()" command gained a "FILTER" sub-command to filter list elements by regular expression. * The "string(TIMESTAMP)" and "file(TIMESTAMP)" commands gained support for the "%s" placeholder. This is the number of seconds since the UNIX Epoch. * The "try_compile()" command source file signature now honors configuration-specific flags (e.g. "CMAKE__FLAGS_DEBUG") in the generated test project. Previously only the default such flags for the current toolchain were used. Variables --------- * A "CMAKE_DEPENDS_IN_PROJECT_ONLY" variable was introduced to tell Makefile Generators to limit dependency scanning only to files in the project source and build trees. * A new "CMAKE_HOST_SOLARIS" variable was introduced to indicate when CMake is running on an Oracle Solaris host. * A "CMAKE__STANDARD_INCLUDE_DIRECTORIES" variable was added for use by toolchain files to specify system include directories to be appended to all compiler command lines. * The "CMAKE__STANDARD_LIBRARIES" variable is now documented. It is intended for use by toolchain files to specify system libraries to be added to all linker command lines. * A "CMAKE_NINJA_OUTPUT_PATH_PREFIX" variable was introduced to tell the "Ninja" generator to configure the generated "build.ninja" file for use as a "subninja". * A "CMAKE_TRY_COMPILE_PLATFORM_VARIABLES" variable was added for use by toolchain files to specify platform-specific variables that must be propagated by the "try_compile()" command into test projects. * A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally tell the "try_compile()" command to build a static library instead of an executable. This is useful for cross-compiling toolchains that cannot link binaries without custom flags or scripts. Properties ---------- * A "DEPLOYMENT_REMOTE_DIRECTORY" target property was introduced to tell the "Visual Studio 9 2008" and "Visual Studio 8 2005" generators to generate the "remote directory" for WinCE project deployment and debugger settings. * A "_CLANG_TIDY" target property and supporting "CMAKE__CLANG_TIDY" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "clang-tidy" along with the compiler for "C" and "CXX" languages. * A "TIMEOUT_AFTER_MATCH" test property was introduced to optionally tell CTest to enforce a secondary timeout after matching certain output from a test. * A "VS_CONFIGURATION_TYPE" target property was introduced to specify a custom project file type for Visual Studio Generators supporting VS 2010 and above. * A "VS_STARTUP_PROJECT" directory property was introduced to specify for Visual Studio Generators the default startup project for generated solutions (".sln" files). Modules ------- * The "CMakePushCheckState" module now pushes/pops/resets the variable "CMAKE_EXTRA_INCLUDE_FILE" used in "CheckTypeSize". * The "ExternalProject" module leared the "GIT_SHALLOW 1" option to perform a shallow clone of a Git repository. * The "ExternalProject" module learned to initialize Git submodules recursively and also to initialize new submodules on updates. Use the "GIT_SUBMODULES" option to restrict which submodules are initalized and updated. * The "ExternalProject" module leared the "DOWNLOAD_NO_EXTRACT 1" argument to skip extracting the file that is downloaded (e.g., for self-extracting shell installers or ".msi" files). * The "ExternalProject" module now uses "TLS_VERIFY" when fetching from git repositories. * The "FindBLAS" and "FindLAPACK" modules learned to support OpenBLAS. * The "FindCUDA" module learned to find the "cublas_device" library. * The "FindGTest" module "gtest_add_tests" function now causes CMake to automatically re-run when test sources change so that they can be re-scanned. * The "FindLTTngUST" module was introduced to find the LTTng-UST library. * The "FindPkgConfig" module learned to optionally create imported targets for the libraries it has found. * The "FindProtobuf" module learned to provide a "Protobuf_VERSION" variable and check the version number requested in a "find_package()" call. * The "InstallRequiredSystemLibraries" module learned a new "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment of the Windows Universal CRT libraries with Visual Studio 2015. Platforms --------- * The Clang compiler is now supported on CYGWIN. * Support was added for the Bruce C Compiler with compiler id "Bruce". CTest ----- * The "ctest_update()" command now looks at the "CTEST_GIT_INIT_SUBMODULES" variable to determine whether submodules should be updated or not before updating. * The "ctest_update()" command will now synchronize submodules on an update. Updates which add submodules or change a submodule's URL will now be pulled properly. CPack ----- * The "CPackDeb" module learned how to handle "$ORIGIN" in "CMAKE_INSTALL_RPATH" when "CPACK_DEBIAN_PACKAGE_SHLIBDEPS" is used for dependency auto detection. * The "CPackDeb" module learned how to generate "DEBIAN/shlibs" contorl file when package contains shared libraries. * The "CPackDeb" module learned how to generate "DEBIAN/postinst" and "DEBIAN/postrm" files if the package installs libraries in ldconfig- controlled locations (e.g. "/lib/", "/usr/lib/"). * The "CPackDeb" module learned how to generate dependencies between Debian packages if multi-component setup is used and "CPACK_COMPONENT__DEPENDS" variables are set. For backward compatibility this feature is disabled by default. See "CPACK_DEBIAN_ENABLE_COMPONENT_DEPENDS". * The "CPackDeb" module learned how to set custom package file names including how to generate properly-named Debian packages: _-_.deb For backward compatibility this feature is disabled by default. See "CPACK_DEBIAN_FILE_NAME" and "CPACK_DEBIAN__FILE_NAME". * The "CPackDeb" module learned how to set the package release number ("DebianRevisionNumber" in package file name when used in combination with "DEB-DEFAULT" value set by "CPACK_DEBIAN_FILE_NAME"). See "CPACK_DEBIAN_PACKAGE_RELEASE". * The "CPackDeb" module learned how to set the package architecture per-component. See "CPACK_DEBIAN__PACKAGE_ARCHITECTURE". * The "CPackDMG" module learned a new option to tell the CPack "DragNDrop" generaor to skip the "/Applications" symlink. See the "CPACK_DMG_DISABLE_APPLICATIONS_SYMLINK" variable. * The "CPackIFW" module gained a new "cpack_ifw_update_repository()" command to update a QtIFW-specific repository from a remote repository. * The "CPackRPM" module learned how to set RPM "dist" tag as part of RPM "Release:" tag when enabled (mandatory on some Linux distributions for e.g. on Fedora). See "CPACK_RPM_PACKAGE_RELEASE_DIST". * The "CPackRPM" module learned how to set default values for owning user/group and file/directory permissions of package content. See "CPACK_RPM_DEFAULT_USER", "CPACK_RPM_DEFAULT_GROUP", "CPACK_RPM_DEFAULT_FILE_PERMISSIONS", "CPACK_RPM_DEFAULT_DIR_PERMISSIONS" and their per component counterparts. * The "CPackRPM" module learned how to set user defined package file names, how to specify that rpmbuild should decide on file name format as well as handling of multiple rpm packages generated by a single user defined spec file. See "CPACK_RPM_PACKAGE_NAME" and "CPACK_RPM__PACKAGE_NAME". * The "CPackRPM" module learned how to correctly handle symlinks that are pointing outside generated packages. Other ----- * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX platforms. Deprecated and Removed Features =============================== * The "CMakeForceCompiler" module and its macros are now deprecated. See module documentation for an explanation. * The "find_library()", "find_path()", and "find_file()" commands no longer search in installation prefixes derived from the "PATH" environment variable on non-Windows platforms. This behavior was added in CMake 3.3 to support Windows hosts but has proven problematic on UNIX hosts. Users that keep some "/bin" directories in the "PATH" just for their tools do not necessarily want any supporting "/lib" directories searched. One may set the "CMAKE_PREFIX_PATH" environment variable with a ;-list of prefixes that are to be searched. * The "Visual Studio 7 .NET 2003" generator is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 7" generator (for VS .NET 2002) has been removed. It had been deprecated since CMake 3.3. * The "Visual Studio 6" generator has been removed. It had been deprecated since CMake 3.3. Other Changes ============= * The precompiled OS X binary provided on "cmake.org" now requires OS X 10.7 or newer. * On Linux and FreeBSD platforms, when building CMake itself from source and not using a system-provided libcurl, OpenSSL is now used by default if it is found on the system. This enables SSL/TLS support for commands supporting network communication via "https", such as "file(DOWNLOAD)", "file(UPLOAD)", and "ctest_submit()". * The "cmake(1)" "--build" command-line tool now rejects multiple "-- target" options with an error instead of silently ignoring all but the last one. * "AUTOMOC" now diagnoses name collisions when multiple source files in different directories use "#include " with the same name (because the generated "moc_foo.cpp" files would collide). * The "FindBISON" module "BISON_TARGET" macro now supports special characters by passing the "VERBATIM" option to internal "add_custom_command()" calls. This may break clients that added escaping manually to work around the bug. * The "FindFLEX" module "FLEX_TARGET" macro now supports special characters by passing the "VERBATIM" option to internal "add_custom_command()" calls. This may break clients that added escaping manually to work around the bug. * The "FindProtobuf" module input and output variables were all renamed from "PROTOBUF_" to "Protobuf_" for consistency with other find modules. Input variables of the old case will be honored if provided, and output variables of the old case are always provided. * The "CPackRPM" module now supports upper cased component names in per component CPackRPM specific variables. E.g. component named "foo" now expects component specific variable to be "CPACK_RPM_FOO_PACKAGE_NAME" while before it expected "CPACK_RPM_foo_PACKAGE_NAME". Upper cased component name part in variables is compatible with convention used for other CPack variables. For back compatibility old format of variables is still valid and preferred if both versions of variable are set, but the preferred future use is upper cased component names in variables. New variables that will be added to CPackRPM in later versions will only support upper cased component variable format. ---------------------------------------------------------------------------- Changes made since CMake 3.6.0-rc1: Brad King (4): libarchive: Restore OpenSSL include directory from upstream Help: Document ctest_update branch following behavior Help: Document CTest Git fetch-and-reset behavior CMake 3.6.0-rc2 Eric NOULARD (4): bash-completion: Add cmake --help-manual bash-completion: Fix cmake --help-policy lookup bash-completion: Add ctest --help-{manual,module,policy,property,variable} bash-completion: Add cpack --help-{manual,module,policy,property} Expat Upstream (1): expat 2016-06-05 (2b9cb7f5) Micha? G?rny (1): Platform: add flag definitions for PathScale compiler on SunOS (#16135) Orion Poplawski (1): FindLibArchive: Support libarchive 3.2 version string format Robert Maynard (1): cmake-gui: Teach Qt5 where plugins are when launched through a symlink From steveire at gmail.com Mon Jun 13 15:12:27 2016 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 13 Jun 2016 21:12:27 +0200 Subject: [cmake-developers] daemon-mode: Project structure References: <1465465663.811.98.camel@qt.io> <575C13F2.301@gmail.com> Message-ID: Tobias Hunger wrote: >> * Designing a protocol like this is hard (and not fast) > > We have been discussing this for about two years now. That's a misleading thing to say. Time since an effort or discussion started has never been a guideline for when something is ready for CMake master. > I see no problem there: You can always cut out old protocols if their > implementation hurts too much. That sucks for users that need the old > version, but it can be cleanly detected. I think you underestimate the cost of supporting old versions and the benefit of exploring the design space to get it as right as possible the first time (exploring the design space isn't the same as giving IDE developers votes). I suggest switching gears and designing the initial protocol handshake and version negotiation, and come back to this buildsystem description part of the protocol later. Designing the how versioning the protocol works can include design and discussion of end of support for particular protocol versions (how many years/releases it will be deprecated for before being removed etc). That is the first part that would get merged to master anyway. Thanks, Steve. From brad.king at kitware.com Mon Jun 13 15:12:56 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 13 Jun 2016 15:12:56 -0400 Subject: [cmake-developers] Problems when generating xcarchive from within Xcode In-Reply-To: <38A15792-E147-439A-AFDB-7580DEF05154@gmx.at> References: <38A15792-E147-439A-AFDB-7580DEF05154@gmx.at> Message-ID: <575F05B8.1070301@kitware.com> On 06/13/2016 02:58 PM, Roman W?ger wrote: > I have successfully configured a project with CMake 3.5.2 so it > creates a valid Release and Debug *.app bundle which runs on iOS. > However if I build an archive in Xcode with "Product->Archive" > then the app bundle seems not complete under > ~/Library/Developer/Xcode/Archives/YYY-MM-DD/*.xcarchive > > For example the Info.plist is not the same as in the Release > folder, subfolders and some files are not copied/created. > > Did I need something special for this (the archive)? Possibly related issues: https://gitlab.kitware.com/cmake/cmake/issues/12640 https://gitlab.kitware.com/cmake/cmake/issues/15183 -Brad From brad.king at kitware.com Mon Jun 13 15:34:42 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 13 Jun 2016 15:34:42 -0400 Subject: [cmake-developers] daemon-mode: Project structure In-Reply-To: References: <1465465663.811.98.camel@qt.io> <575C13F2.301@gmail.com> Message-ID: <575F0AD2.3040702@kitware.com> On 06/13/2016 03:12 PM, Stephen Kelly wrote: > I suggest switching gears and designing the initial protocol handshake and > version negotiation, and come back to this buildsystem description part of > the protocol later. > > Designing the how versioning the protocol works can include design and > discussion of end of support for particular protocol versions (how many > years/releases it will be deprecated for before being removed etc). That is > the first part that would get merged to master anyway. Yes. We don't want to end up like we did with policies where there is no plan or schedule for removal. We are carrying along quite a bit of code (and complexity) only to support policy OLD behavior. On 06/11/2016 04:32 PM, Tobias Hunger wrote: > Using the CMake version as protocol version is really painful on the other hand: Yes. The protocol should have its own versioning. IIRC the earlier discussion that proposed using the CMake version was back when we were going to put all this in a .json file on disk during generation. For an interactive protocol session it makes much more sense to have a dedicated protocol versioning scheme. -Brad From xademax at gmail.com Mon Jun 13 18:12:10 2016 From: xademax at gmail.com (Elie Roudninski) Date: Tue, 14 Jun 2016 00:12:10 +0200 Subject: [cmake-developers] Installation of imported targets Message-ID: I'm a CMake user for while now, and i found some limitation with the current state of imported targets. >From what i understand, they were introduced to manipulate _already installed_ binary/library inside CMake in order to handle linking, etc, and is used for example in exported project configuration file. Another regular use case that i encounter frequently, is when you need to build an ExternalProject (because there is no build system, or because the buildsystem is autotools and there is no package available) for a library, and you use imported targets to declare the library target and make it depend on the ExternalProject target. You can then properly link with it and build order dependency is respected. Everything works fine except when you need to install the imported target. You can't use the regular: install(TARGETS myimportedlib LIBRARY DESTINATION lib) It is not permitted for imported targets. At the moment, i usually use: install(FILES ${CMAKE_CURRENT_BINARY_DIR}/path/to/myimportedlib.so DESTINATION lib) to install it. The problem now, is when you need to export the library ... At the moment, you just can't do it properly. There is an ugly-tricky way that i thought of (without testing it ...) using a second fake target, but an interface one this time, linking with the futur full path of installed library ... Installing it with install(TARGETS myinterfacelib EXPORT myproj DESTINATION lib) will do nothing but you should be able to do an install(EXPORT myproj) You can track the issue here: https://gitlab.kitware.com/cmake/cmake/issues/14311 To solve the problem, there are many solutions, with one of them might be being able to install imported targets and use them pretty much like regular targets. Maybe that would make interface targets a bit useless ? In fact mixing INTERFACE and IMPORTED targets "should" do it. This solution could work with ExternalProject as decribed before, and even for other use cases, like providing closed-source library already built with your project as it is done by PF_RING for example ( https://github.com/ntop/PF_RING in userland/lib/libs) I did my best to explain myself, but if it is still confusing or if my english is bad, do not hesitate to respond, i'll try to do better :) Regards, marmeladema -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hunger at gmail.com Mon Jun 13 20:00:14 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Tue, 14 Jun 2016 02:00:14 +0200 Subject: [cmake-developers] daemon-mode: Infrastructure Message-ID: Hello, one important piece of feedback from the daemon-mode: Project structure discussion is that we need a policy to remove old code again. So I thought I should write up a bit about the infrastructure and versioning support of the daemon-mode branch I am working on. Basic Assumptions: ================= These are kind of hardcoded into the implementation and hard to change: * There will always be 1 client talking to a server. * Client/Server communicate using JSON messages Implementation Overview: ====================== Basically "daemon-mode" is implemented in the cmServer class. That class uses libuv to receive requests from a client application and to react on those requests. There is nothing that stops the cmServer from also signalling the client about state changes (e.g. CMakeLists.txt files being changed on disc), but that is not implemented at this time. In the constructor of cmServer you can define an arbitrary number of cmProtocolVersion objects, each with a different version number (major/minor numbers). On first connect the cmServer will present the list of supported protocol versions to the client and the client has to pick one of the supported versions. The server will call Activate() (do your initialization here;-) on the cmProtocolVersion object with the selected version number. >From that point on the cmProtocolVersion object is responsible for all further interactions with the client. The cmServer will turn all incoming messages into cmServerRequest objects and pass those to the selected cmProtocolVersion's Process(...) method. This method will return a cmServerResponse object (which can be created from the cmServerRequest), which the cmServer will send on to the client. Proposed Versioning: =================== The protocol version should start at version 1.0. Any time new functionality is made available to daemon-mode, the minor version number will be incremented. This includes new commands becoming available as well as existing commands returning new keys in addition to sending all the old keys. Any time a incompatible change (e.g. removal of functionality, restructuring of responses to requests, etc.) is made, the major version is incremented and the minor is reset to 0. This includes removing existing commands or changing the semantics/return types of keys returned in response to any existing command. If there was already a matching version bump, then there is no need to do another till after the next release of cmake made. So two new functionalities in one development cycle: Still only increase the minor number by one. Requesting Protocol Versions: ========================= Let's assume we are writing a client for cmake-daemon as shipped in cmake 4.2.4. At that time in the future the protocol version for the cmake-daemon is at version 1.4 and that is what we test our application with. Our client should then request daemon mode to use protocol version 1.4 if available. If that is not available, then it should just request the highest minor number for version 1 and use that. That *should* be compatible with version 1.4. If there is no more protocol version 1.x supported the client should abort or at least warn and continue with a higher major version number. Implementing new Protocol Versions: ============================== * minor version bumps: Add a new cmServerProtocol class. Have its Process(...) method implement the new functionality and then forward to an instance of the previous version. The sloppy approach would be to implement the the new functionality in the previous versions class and just bump its number:-) * major version bumps: At that point I would copy the existing code of the previous version into a new cmServerProtocol class and then clean it up. Then implement the changes in the new class. Deprecating old Protocol Versions: ============================ I would remove all the code for one major protocol version in one go. That should be fairly straight forward to do (and the reason why I suggested to just copy the code into a new major version of the protocol) and should have little potential for damage. In general I would suggest keeping old major versions around for at least three cmake releases, but I would not put hard rules here: If some old major version does not cost maintenance, then I'd suggest keeping it longer. On the other hand, if some changes require a major cmake version bump (e.g. changing the cmake language in incompatible ways, etc.) so that major user interaction is required during an update, then I would also dump all old protocol versions immediately. Such fundamental changes will probably also reflect deeply in the cmake internal structure, which will also reflect in the daemon-mode protocol. I do not think it makes sense to invest heavily into compatibility to old daemon-mode clients in such an event. What do you think? Does this make sense? Best Regards, Tobias From tobias.hunger at gmail.com Mon Jun 13 20:06:42 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Tue, 14 Jun 2016 02:06:42 +0200 Subject: [cmake-developers] CMake daemon-mode In-Reply-To: <575EC045.9070603@kitware.com> References: <1465227569.811.38.camel@qt.io> <5755B1AF.3000504@kitware.com> <1465310542.811.42.camel@qt.io> <5756DED0.5010404@kitware.com> <575702F2.6020502@kitware.com> <5758279C.1020706@kitware.com> <57596EAF.1020806@kitware.com> <5759AE22.6090405@kitware.com> <575EC045.9070603@kitware.com> Message-ID: Hi Brad, I just rebased this branch on top of current master and pushed it. There were some conflicts. Best Regards, Tobias On Mon, Jun 13, 2016 at 4:16 PM, Brad King wrote: > On 06/10/2016 12:31 PM, Tobias Hunger wrote: >> I did try to do the changes you requested. The branch is here: >> >> https://github.com/hunger/CMake/commits/compileflags > > Thanks. I'm about to go on travel but should hopefully be able to > look at that again when I return. > > -Brad > From daniel at pfeifer-mail.de Tue Jun 14 03:50:36 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Tue, 14 Jun 2016 09:50:36 +0200 Subject: [cmake-developers] fixup! Remove redundant arguments from fstream constructors Message-ID: This is a fixup for the std-fstream topic. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-fixup-Remove-redundant-arguments-from-fstream-constr.patch Type: text/x-patch Size: 1264 bytes Desc: not available URL: From Tobias.Hunger at qt.io Tue Jun 14 04:30:36 2016 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Tue, 14 Jun 2016 08:30:36 +0000 Subject: [cmake-developers] daemon-mode: Infrastructure In-Reply-To: References: Message-ID: <1465893033.811.238.camel@qt.io> PS: I think it would make perfect sense to ship the first cmake version with included daemon-mode with a big, fat warning that the interfaces are not finalized yet and will change in incompatible ways during the first release cycle (or maybe two:-). In my experience you only get the full feedback once the first release is out and users can test it without building the code themselves. So this would provide an opportunity to battle-harden all the daemon-mode APIs without commiting us too early. Best Regards, Tobias -- Tobias Hunger,?Senior?Software Engineer?| The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From brad.king at kitware.com Tue Jun 14 09:14:49 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 14 Jun 2016 09:14:49 -0400 Subject: [cmake-developers] Questions about coding conventions In-Reply-To: <575EC03D.9030800@kitware.com> References: <575AC3F6.30108@kitware.com> <575EC03D.9030800@kitware.com> Message-ID: <57600349.2060303@kitware.com> On 06/13/2016 10:16 AM, Brad King wrote: >> Can't `std::ifstream` and `std::ofstream` be used directly? It seams >> that kwsys does some workarounds > > Yes, std::{o,f}stream can be used directly. On second thought, std::{i,o}fstream should not be used to open files. The cmsys::{i,o}fstream interfaces are not about compatibility, they are about opening files on Windows using the wide character APIs by converting from UTF-8 to UCS-2. Sorry for the confusion. I've reverted the std-fstream topic for now. -Brad From brad.king at kitware.com Tue Jun 14 09:56:54 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 14 Jun 2016 09:56:54 -0400 Subject: [cmake-developers] Installation of imported targets In-Reply-To: References: Message-ID: <57600D26.6040906@kitware.com> On 06/13/2016 06:12 PM, Elie Roudninski wrote: > Everything works fine except when you need to install the imported target. > You can't use the regular: > install(TARGETS myimportedlib LIBRARY DESTINATION lib) > It is not permitted for imported targets. At the moment, i usually use: > install(FILES ${CMAKE_CURRENT_BINARY_DIR}/path/to/myimportedlib.so DESTINATION lib) > to install it. The main problem is that as the importer of the target we don't necessarily have enough information to properly install it. Shared libraries and executables often need RPATH updates or other (platform-specific) modifications during installation. Multiple files need to be installed to bring along import libraries or soname symlinks. Only the original build system that produces a file knows how it should be properly installed. Therefore installing imported targets is not a well-defined concept. > The problem now, is when you need to export the library ... At the moment, > you just can't do it properly. This is because imported targets are not meant to be exported. You got them from some other project, so your clients can get them directly from that other project too. Your package configuration file is responsible for providing the imported targets on which your exported targets depend so that a client sees all of them after using find_package(YourProject). It finds the dependency and loads its imported targets, and then loads your imported targets. There is no need for "re-export" of imported targets. All this was designed with the idea that external dependencies are installed separately. Using ExternalProject to extend your build system and then import a target is more of a trick than a first-class feature of CMake. Instead we typically have a "superbuild" project that has nothing but ExternalProject_Add calls to build all the source trees in order and share a common installation prefix. Then deployment is a matter of packaging what is left behind in that prefix after all the builds are done. -Brad From daniel at pfeifer-mail.de Tue Jun 14 10:09:06 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Tue, 14 Jun 2016 16:09:06 +0200 Subject: [cmake-developers] Questions about coding conventions In-Reply-To: <57600349.2060303@kitware.com> References: <575AC3F6.30108@kitware.com> <575EC03D.9030800@kitware.com> <57600349.2060303@kitware.com> Message-ID: On Tue, Jun 14, 2016 at 3:14 PM, Brad King wrote: > On 06/13/2016 10:16 AM, Brad King wrote: >>> Can't `std::ifstream` and `std::ofstream` be used directly? It seams >>> that kwsys does some workarounds >> >> Yes, std::{o,f}stream can be used directly. > > On second thought, std::{i,o}fstream should not be used to open files. > The cmsys::{i,o}fstream interfaces are not about compatibility, they > are about opening files on Windows using the wide character APIs by > converting from UTF-8 to UCS-2. I see. There are a few uses of std::{i,o}fstream. I guess we should migrate them all to kwsys. From nicolas.despres at gmail.com Tue Jun 14 11:18:43 2016 From: nicolas.despres at gmail.com (=?UTF-8?Q?Nicolas_Despr=C3=A8s?=) Date: Tue, 14 Jun 2016 17:18:43 +0200 Subject: [cmake-developers] Toward a more deterministic ninja generator Message-ID: Hi, While working on something else I wrote this patch: https://github.com/nicolasdespres/CMake/commit/59e4e62ba014c6fcd4519b57b621d9434f99ff19 It makes the ninja generator more deterministic by sorting the build edge's inputs/outputs. It does not introduce any regression on my macbookpro. This could help to fix issue #15968. Regards, -- Nicolas Despr?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tobias.Hunger at qt.io Tue Jun 14 11:21:00 2016 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Tue, 14 Jun 2016 15:21:00 +0000 Subject: [cmake-developers] codeblocks generator: Fix include directories being in unexpected order Message-ID: <1465917658.811.241.camel@qt.io> Hello, https://github.com/hunger/CMake/commit/a87e306fd03e7fae7409b16e4e586083822c6fe8 has a fix to not put include directories into random order while trying to make them unique. Would that be applicable for the next release? All Tests pass, with or without the patch. Best Regards, Tobias -- Tobias Hunger,?Senior?Software Engineer?| The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From clinton at elemtech.com Tue Jun 14 11:28:25 2016 From: clinton at elemtech.com (clinton at elemtech.com) Date: Tue, 14 Jun 2016 09:28:25 -0600 (MDT) Subject: [cmake-developers] Questions about coding conventions In-Reply-To: References: <575AC3F6.30108@kitware.com> <575EC03D.9030800@kitware.com> <57600349.2060303@kitware.com> Message-ID: <1838077940.58385819.1465918105406.JavaMail.zimbra@elemtech.com> ----- On Jun 14, 2016, at 8:09 AM, Daniel Pfeifer daniel at pfeifer-mail.de wrote: > On Tue, Jun 14, 2016 at 3:14 PM, Brad King wrote: >> On 06/13/2016 10:16 AM, Brad King wrote: >>>> Can't `std::ifstream` and `std::ofstream` be used directly? It seams >>>> that kwsys does some workarounds >>> >>> Yes, std::{o,f}stream can be used directly. >> >> On second thought, std::{i,o}fstream should not be used to open files. >> The cmsys::{i,o}fstream interfaces are not about compatibility, they >> are about opening files on Windows using the wide character APIs by >> converting from UTF-8 to UCS-2. > > I see. > > There are a few uses of std::{i,o}fstream. I guess we should migrate > them all to kwsys. Yes. Thanks. cmsys::{i,o}fstream is to support additional filenames on Windows by not using obsolete ANSI apis. Clint From Tobias.Hunger at qt.io Tue Jun 14 11:52:01 2016 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Tue, 14 Jun 2016 15:52:01 +0000 Subject: [cmake-developers] codeblocks generator: Fix include directories being in unexpected order In-Reply-To: <1465917658.811.241.camel@qt.io> References: <1465917658.811.241.camel@qt.io> Message-ID: <1465919519.811.243.camel@qt.io> On Di, 2016-06-14 at 15:21 +0000, Tobias Hunger wrote: > Hello, > > https://github.com/hunger/CMake/commit/a87e306fd03e7fae7409b16e4e586083822c6fe > 8 https://github.com/hunger/CMake/commit/f190b069db2e430fd94b25e6287cd7fbc28661e3 Is the same thing updated based on suggestions from Stephen. Best Regards, Tobias -- Tobias Hunger,?Senior?Software Engineer?| The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From florent.castelli at gmail.com Wed Jun 15 04:39:55 2016 From: florent.castelli at gmail.com (Florent Castelli) Date: Wed, 15 Jun 2016 10:39:55 +0200 Subject: [cmake-developers] Toward a more deterministic ninja generator In-Reply-To: References: Message-ID: To this, I would add that you could also remove duplicates. They?re rare but can happen in some conditions and trigger warnings in Ninja. /Florent > On 14 Jun 2016, at 17:18, Nicolas Despr?s wrote: > > Hi, > > While working on something else I wrote this patch: > https://github.com/nicolasdespres/CMake/commit/59e4e62ba014c6fcd4519b57b621d9434f99ff19 > > It makes the ninja generator more deterministic by sorting the build edge's inputs/outputs. It does not introduce any regression on my macbookpro. > > This could help to fix issue #15968. > > Regards, > > -- > Nicolas Despr?s > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/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 tobias.hunger at gmail.com Wed Jun 15 09:17:50 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Wed, 15 Jun 2016 15:17:50 +0200 Subject: [cmake-developers] daemon-mode: Project structure In-Reply-To: <575AE13C.90401@kitware.com> References: <1465465663.811.98.camel@qt.io> <1465487561.811.165.camel@qt.io> <575AC96B.5010503@kitware.com> <1465568887.811.204.camel@qt.io> <575AD19C.1010705@kitware.com> <1465572248.811.220.camel@qt.io> <575AE13C.90401@kitware.com> Message-ID: Hi Brad, The project structure now lists an array of artifacts per target. Best Regards, Tobias On Fri, Jun 10, 2016 at 5:48 PM, Brad King wrote: > On 06/10/2016 11:24 AM, Tobias Hunger wrote: >>> The cmGeneratorTarget::GetFullName method will give you the name of the >>> "main" file for a target. Passing `implib = true` will give the DLL >>> import library path on platforms where IsDLLPlatform returns true. >> >> I would have never found that! >> >> I'll change the code to list both the main artefact and the implib (if >> applicable). > > Oops, I meant to point you at cmGeneratorTarget::GetFullPath to get the > absolute paths with file names. > > -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 ruslan_baratov at yahoo.com Wed Jun 15 10:41:54 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Wed, 15 Jun 2016 17:41:54 +0300 Subject: [cmake-developers] [patch] iOS combined, some fixes Message-ID: <66aed97f-51c7-5e9b-a823-136c4f7bc765@yahoo.com> Hi, Sending some fixes found by testing with Xcode 7.3 Ruslo -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-CMakeIOSInstallCombined-add-some-sanity-checks.patch Type: text/x-patch Size: 996 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-CMakeIOSInstallCombined-do-not-merge-content-of-OUTP.patch Type: text/x-patch Size: 1381 bytes Desc: not available URL: From binkiepinkie1917 at gmail.com Wed Jun 15 14:34:27 2016 From: binkiepinkie1917 at gmail.com (Binkie Pinkie) Date: Wed, 15 Jun 2016 21:34:27 +0300 Subject: [cmake-developers] Possibly an obscure bug Message-ID: Hi, TL;DR: The project compiles fine first time, but after touching a source file to trigger a recompile, the recompilation fails with a large list of errors. To reproduce this must be done: 1) Have set(CMAKE_INCLUDE_CURRENT_DIR ON) 2) call your executable "list" 3) #include anywhere in your project or include a system/library header that #includes My own example, folder names have nothing to do with the bug: [-] Blink CMakeLists.txt [-]blink main.cpp CMakeLists.txt Top CMakeLists.txt content: cmake_minimum_required(VERSION 2.8.12) Project(Blink) add_subdirectory(blink) The other CMakeLists.txt file: set(CMAKE_INCLUDE_CURRENT_DIR ON) add_executable(list main.cpp) main.cpp: #include #include int main(int argc, char *argv[]) { printf("Hello, world\n"); return 0; } The project will compile, but if main.cpp gets touched the recompilation will fail. Using Ubuntu 16.04, cmake version 3.5.1, any compiler (gcc/clang) And here's the sample output of a failed compilation (the first umpteen lines): build$ make Scanning dependencies of target list make[2]: Circular blink/CMakeFiles/list.dir/main.cpp.o <- blink/list dependency dropped. [ 50%] Building CXX object blink/CMakeFiles/list.dir/main.cpp.o In file included from /media/data/docs/dev/Blink/blink/main.cpp:2:0: /media/data/docs/dev/Blink/build/blink/list:1:1: error: stray ?\177? in program ELF > ? @ @ ? @ 8 @ @ ^ /media/data/docs/dev/Blink/build/blink/list:1:1: error: stray ?\2? in program /media/data/docs/dev/Blink/build/blink/list:1:1: error: stray ?\1? in program /media/data/docs/dev/Blink/build/blink/list:1:1: error: stray ?\1? in program /media/data/docs/dev/Blink/build/blink/list:1:8: warning: null character(s) ignored ELF > ? @ @ ? @ 8 @ @ ^ Plus lots and lots of lines, and ends with: /media/data/docs/dev/Blink/build/blink/list:1:2: error: ?ELF? does not name a type ELF > ? @ @ ? @ 8 @ @ ^ /media/data/docs/dev/Blink/build/blink/list:1:651: error: ?N? does not name a type x-x86-64.so.2 GNU GNU ??.;N?)??S? cQ ^ blink/CMakeFiles/list.dir/build.make:62: recipe for target 'blink/CMakeFiles/list.dir/main.cpp.o' failed make[2]: *** [blink/CMakeFiles/list.dir/main.cpp.o] Error 1 CMakeFiles/Makefile2:85: recipe for target 'blink/CMakeFiles/list.dir/all' failed make[1]: *** [blink/CMakeFiles/list.dir/all] Error 2 Makefile:83: recipe for target 'all' failed make: *** [all] Error 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Wed Jun 15 14:54:18 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 15 Jun 2016 14:54:18 -0400 Subject: [cmake-developers] Possibly an obscure bug In-Reply-To: References: Message-ID: <20160615185418.GA11637@megas.kitware.com> On Wed, Jun 15, 2016 at 21:34:27 +0300, Binkie Pinkie wrote: > build$ make > Scanning dependencies of target list > make[2]: Circular blink/CMakeFiles/list.dir/main.cpp.o <- blink/list > dependency dropped. > [ 50%] Building CXX object blink/CMakeFiles/list.dir/main.cpp.o > In file included from /media/data/docs/dev/Blink/blink/main.cpp:2:0: > /media/data/docs/dev/Blink/build/blink/list:1:1: error: stray ?\177? in program > ELF > ? @ @ ? @ 8 @ @ > ^ Looks like the built binary gets found by the compiler and it tries to #include it. Try setting: set(EXECUTABLE_OUTPUT_PATH "${CMAKE_BINARY_DIR}/bin") to put the executable outside of the -I paths. --Ben From chuck.atkins at kitware.com Wed Jun 15 14:56:49 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Wed, 15 Jun 2016 14:56:49 -0400 Subject: [cmake-developers] Possibly an obscure bug In-Reply-To: References: Message-ID: This isn't a bug but more of a weird side effect of having your executable named the same as an include file and adding the destination directory for the executable in the include path. The same thing would happen if your executable was named foo and you had "#include ". By setting CMAKE_INCLUDE_CURRENT_DIR to on then CMake is adding -I/path/to/source/blink and -I/path/to/build/blink to the compile line. The default destination for the list executable also happens to be /path/to/build/blink. The second time around, the list executable from the first run is in the include path, thus #include picks up the executable instead of the C++ header. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gjasny at googlemail.com Wed Jun 15 15:59:30 2016 From: gjasny at googlemail.com (Gregor Jasny) Date: Wed, 15 Jun 2016 21:59:30 +0200 Subject: [cmake-developers] [patch] iOS combined, some fixes In-Reply-To: <66aed97f-51c7-5e9b-a823-136c4f7bc765@yahoo.com> References: <66aed97f-51c7-5e9b-a823-136c4f7bc765@yahoo.com> Message-ID: Hello, Thanks for the patch! On 15/06/16 16:41, Ruslan Baratov wrote: > Sending some fixes found by testing with Xcode 7.3 We were chasing some errors regarding the unified build some time ago. But it appeared some for of heisenbug: the more I looked the less likely it happened. Is the error 100% reproducible for you? And do you know what goes wrong? Does the list(LENGTH _lipo_path len) if(NOT len EQUAL 1) take paths with spaces into account? Thanks, Gregor From ruslan_baratov at yahoo.com Wed Jun 15 16:38:14 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Wed, 15 Jun 2016 23:38:14 +0300 Subject: [cmake-developers] [patch] iOS combined, some fixes In-Reply-To: References: <66aed97f-51c7-5e9b-a823-136c4f7bc765@yahoo.com> Message-ID: <1ff617d9-99da-aa10-9218-f0de72ac809f@yahoo.com> On 15-Jun-16 22:59, Gregor Jasny wrote: > Hello, > > Thanks for the patch! > > On 15/06/16 16:41, Ruslan Baratov wrote: >> Sending some fixes found by testing with Xcode 7.3 > We were chasing some errors regarding the unified build some time ago. > But it appeared some for of heisenbug: the more I looked the less likely > it happened. > > Is the error 100% reproducible for you? Yes - for the Travis VM with xcode7.3 image. Not - for my local machine. > And do you know what goes wrong? Yes, I've leaved a note in the comments section. There are some messages in error stream, they are not related to lipo location. Here is example of the log with error: CMake Error at /Users/travis/build/ingenue/hunter/_ci/cmake/share/cmake-3.5/Modules/CMakeIOSInstallCombined.cmake:102 (message): Command failed (File name too long): 2016-05-31 18:37:15.058 xcodebuild[6590:18239] Build settings from command line: 2016-05-31 18:37:15.059 xcodebuild[6590:18239] TOOLCHAINS = com.apple.dt.toolchain.XcodeDefault 2016-05-31 18:37:15.059 xcodebuild[6590:18239] XCODE_DEFAULT_TOOLCHAIN_OVERRIDE = /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo;-info;/Users/travis/build/ingenue/hunter/_testing/Hunter/_Base/7f9eaa4/f53c868/1c14a4b/Build/GTest/Build/GTest-Release-prefix/src/GTest-Release-build/googlemock/Release-iphonesimulator/libgmock.a > > Does the > > list(LENGTH _lipo_path len) > if(NOT len EQUAL 1) > > take paths with spaces into account? Nope as far as I know. In fact it doesn't catch the error I've seen, I decide to add some sanity checks just to be sure. Ruslo -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail6543210 at yahoo.com.tw Thu Jun 16 07:37:20 2016 From: mail6543210 at yahoo.com.tw (mail6543210 at yahoo.com.tw) Date: Thu, 16 Jun 2016 19:37:20 +0800 Subject: [cmake-developers] [Patch] Two trivial patches fixing type in CPack/DEB testcase Message-ID: Hi there, Here're two trivial patches for testing of CPack/DEB. One is for building cmake on SELinux-enabled system, and other is for a typo in the same file form the former one. These patches is based on commit 83ae7944 First patch: When building cmake on an SELinux-enabled system, there will be an extra dot at the end of permission field of `ls -l` like this: -rwxrwxrwx. ^ this dot This makes the testing RunCMake.CPack_DEB fail. This patch add an optional dot in the regex to fix it. Second patch: Fix typos in testing data. This bug causes two variable undefined. Since "result" MATCHES "${expected_but_undefined_variable}" returns true, this bug has no effect. BR, Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Enable-building-on-SELinux-enabled-system.patch Type: text/x-patch Size: 1682 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fix-typos-of-testing-data-in-CPack-DEB.patch Type: text/x-patch Size: 1339 bytes Desc: not available URL: From eike at sf-mail.de Thu Jun 16 08:45:41 2016 From: eike at sf-mail.de (Rolf Eike Beer) Date: Thu, 16 Jun 2016 14:45:41 +0200 Subject: [cmake-developers] [Patch] Two trivial patches fixing type in CPack/DEB testcase In-Reply-To: References: Message-ID: Am 2016-06-16 13:37, schrieb mail6543210--- via cmake-developers: > Hi there, > > Here're two trivial patches for testing of CPack/DEB. > > One is for building cmake on SELinux-enabled system, and other is for a > typo in the same file form the former one. > > These patches is based on commit 83ae7944 > > First patch: > > When building cmake on an SELinux-enabled system, there will be an > extra > dot at the end of permission field of `ls -l` like this: > -rwxrwxrwx. > ^ this dot > This makes the testing RunCMake.CPack_DEB fail. > > This patch add an optional dot in the regex to fix it. If it is exactly a dot and not "some random character", than you need to escape that in the regular expression as dot is the wildcard character there. Greetings, Eike From rleigh at codelibre.net Thu Jun 16 09:27:12 2016 From: rleigh at codelibre.net (Roger Leigh) Date: Thu, 16 Jun 2016 13:27:12 +0000 Subject: [cmake-developers] [patch] FindIce updates Message-ID: I have opened a couple of merge requests here, and also merged these into next for testing: https://gitlab.kitware.com/cmake/cmake/merge_requests/17 https://gitlab.kitware.com/cmake/cmake/merge_requests/19 The first adds support for the latest 3.6.x releases. The second adds support for finding debug variants of the library, uses SelectLibraryConfigurations and adds support for release and debug variants to the imported targets. Regards, Roger From brad.king at kitware.com Thu Jun 16 13:14:44 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 16 Jun 2016 13:14:44 -0400 Subject: [cmake-developers] codeblocks generator: Fix include directories being in unexpected order In-Reply-To: <1465919519.811.243.camel@qt.io> References: <1465917658.811.241.camel@qt.io> <1465919519.811.243.camel@qt.io> Message-ID: <5762DE84.4010803@kitware.com> On 06/14/2016 11:52 AM, Tobias Hunger wrote: > https://github.com/hunger/CMake/commit/f190b069db2e430fd94b25e6287cd7fbc28661e3 > > Is the same thing updated based on suggestions from Stephen. Thanks, applied: cmExtraCodeBlocksGenerator: Do not shuffle include directories https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f190b069 -Brad From brad.king at kitware.com Thu Jun 16 13:14:50 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 16 Jun 2016 13:14:50 -0400 Subject: [cmake-developers] Toward a more deterministic ninja generator In-Reply-To: References: Message-ID: <5762DE8A.30700@kitware.com> On 06/14/2016 11:18 AM, Nicolas Despr?s wrote: > It makes the ninja generator more deterministic by sorting the > build edge's inputs/outputs. It does not introduce any > regression on my macbookpro. > > This could help to fix issue #15968. What examples of non-determinism have you observed after the changes already made for that issue? > + // We assume that commands using $in and $out varialbes do not care > + // about the order of their inputs/outputs files, but commands that do > + // not use them do care (like custom commands for instance). I'd prefer not to make this assumption. CMake should order the inputs and outputs in a deterministic way before getting to the code in question. If that is not happening then there may be a deeper problem. Sorting this late is fixing the symptom. -Brad From Tobias.Hunger at qt.io Fri Jun 17 03:31:20 2016 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Fri, 17 Jun 2016 07:31:20 +0000 Subject: [cmake-developers] codeblocks generator: Fix include directories being in unexpected order In-Reply-To: <5762DE84.4010803@kitware.com> References: <1465917658.811.241.camel@qt.io> <1465919519.811.243.camel@qt.io> <5762DE84.4010803@kitware.com> Message-ID: <1466148677.811.246.camel@qt.io> On Do, 2016-06-16 at 13:14 -0400, Brad King wrote: > On 06/14/2016 11:52 AM, Tobias Hunger wrote: > > https://github.com/hunger/CMake/commit/f190b069db2e430fd94b25e6287cd7fbc2866 > > 1e3 > > > > Is the same thing updated based on suggestions from Stephen. > > Thanks, applied: > > ?cmExtraCodeBlocksGenerator: Do not shuffle include directories > ?https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f190b069 Could this please go into 3.6? This is the root cause of quite a few bug reports hitting Qt Creator bug tracker right now, so I would love to see a fix out in the wild ASAP. Best Regards, Tobias -- Tobias Hunger,?Senior?Software Engineer?| The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From nicolas.despres at gmail.com Fri Jun 17 05:40:29 2016 From: nicolas.despres at gmail.com (=?UTF-8?Q?Nicolas_Despr=C3=A8s?=) Date: Fri, 17 Jun 2016 11:40:29 +0200 Subject: [cmake-developers] Toward a more deterministic ninja generator In-Reply-To: <5762DE8A.30700@kitware.com> References: <5762DE8A.30700@kitware.com> Message-ID: On Thu, Jun 16, 2016 at 7:14 PM, Brad King wrote: > On 06/14/2016 11:18 AM, Nicolas Despr?s wrote: > > It makes the ninja generator more deterministic by sorting the > > build edge's inputs/outputs. It does not introduce any > > regression on my macbookpro. > > > > This could help to fix issue #15968. > > What examples of non-determinism have you observed after the changes > already made for that issue? > The LINK_LIBRARIES list has not the same order for an executable target. I have that after the 79th generation using cmake 3.5.2. With cmake master (d4283ca18b7) I did not reproduce it after 100 tries. > > + // We assume that commands using $in and $out varialbes do not care > > + // about the order of their inputs/outputs files, but commands that do > > + // not use them do care (like custom commands for instance). > > I'd prefer not to make this assumption. CMake should order the > inputs and outputs in a deterministic way before getting to the > code in question. If that is not happening then there may be > a deeper problem. Sorting this late is fixing the symptom. > > Yes you are right. I did not took enough time to read the issue history and I did not test with master. Sorry for the noise. -- Nicolas Despr?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Fri Jun 17 09:36:33 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 17 Jun 2016 09:36:33 -0400 Subject: [cmake-developers] FindPkgConfig and IMPORTED_TARGET in 3.6.0 Message-ID: <20160617133633.GA29166@megas.kitware.com> Hi, Nils, the IMPORTED_TARGET feature in pkg_check_modules is nice! Thanks for that. However, it is hidden behind the check that pkg_check_modules uses to see if it already ran: if (NOT DEFINED __pkg_config_checked_${_prefix} OR __pkg_config_checked_${_prefix} LESS ${PKG_CONFIG_VERSION} OR NOT ${_prefix}_FOUND) which means that on the second configure, the target is not created causing build faiures. Could you please look at reordering the logic so that the imported target is always created (if requested)? Thanks. Brad, this is in the rc releases; what should be done? Block the release, undocument the feature, or wait for a patch? --Ben From nilsgladitz at gmail.com Fri Jun 17 09:40:45 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 17 Jun 2016 15:40:45 +0200 Subject: [cmake-developers] FindPkgConfig and IMPORTED_TARGET in 3.6.0 In-Reply-To: <20160617133633.GA29166@megas.kitware.com> References: <20160617133633.GA29166@megas.kitware.com> Message-ID: <5763FDDD.4050403@gmail.com> On 06/17/2016 03:36 PM, Ben Boeckel wrote: > Nils, the IMPORTED_TARGET feature in pkg_check_modules is nice! Thanks > for that. However, it is hidden behind the check that pkg_check_modules > uses to see if it already ran: I have not been involved in that development. From what I can tell this is Eike's work. Nils From eike at sf-mail.de Fri Jun 17 09:47:04 2016 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 17 Jun 2016 15:47:04 +0200 Subject: [cmake-developers] FindPkgConfig and IMPORTED_TARGET in 3.6.0 In-Reply-To: <20160617133633.GA29166@megas.kitware.com> References: <20160617133633.GA29166@megas.kitware.com> Message-ID: <3b18caf1c7a36542800b372db346c2ee@sf-mail.de> Am 2016-06-17 15:36, schrieb Ben Boeckel: > Hi, > > Nils, the IMPORTED_TARGET feature in pkg_check_modules is nice! Thanks > for that. However, it is hidden behind the check that pkg_check_modules > uses to see if it already ran: > > if (NOT DEFINED __pkg_config_checked_${_prefix} OR > __pkg_config_checked_${_prefix} LESS ${PKG_CONFIG_VERSION} OR > NOT ${_prefix}_FOUND) > > which means that on the second configure, the target is not created > causing build faiures. Could you please look at reordering the logic so > that the imported target is always created (if requested)? Thanks. > > Brad, this is in the rc releases; what should be done? Block the > release, undocument the feature, or wait for a patch? I also have another todo for FindFreetype open which I must handle. I'll do both over the weekend. Greetings, Eike From brad.king at kitware.com Fri Jun 17 09:48:42 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 17 Jun 2016 09:48:42 -0400 Subject: [cmake-developers] FindPkgConfig and IMPORTED_TARGET in 3.6.0 In-Reply-To: <5763FDDD.4050403@gmail.com> References: <20160617133633.GA29166@megas.kitware.com> <5763FDDD.4050403@gmail.com> Message-ID: <5763FFBA.6080708@kitware.com> On 06/17/2016 09:40 AM, Nils Gladitz wrote: > On 06/17/2016 03:36 PM, Ben Boeckel wrote: >> Nils, the IMPORTED_TARGET feature in pkg_check_modules is nice! Thanks >> for that. However, it is hidden behind the check that pkg_check_modules >> uses to see if it already ran: > > From what I can tell this is Eike's work. Yes. On 06/17/2016 09:36 AM, Ben Boeckel wrote: > Brad, this is in the rc releases; what should be done? Block the > release, undocument the feature, or wait for a patch? Since it is a bug in a new feature a fix qualifies for inclusion in the release. If Eike can solve it soon (which is likely) then I'll include the fix. Otherwise I'd revert the feature. -Brad From ben.boeckel at kitware.com Fri Jun 17 09:49:56 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 17 Jun 2016 09:49:56 -0400 Subject: [cmake-developers] FindPkgConfig and IMPORTED_TARGET in 3.6.0 In-Reply-To: <5763FDDD.4050403@gmail.com> References: <20160617133633.GA29166@megas.kitware.com> <5763FDDD.4050403@gmail.com> Message-ID: <20160617134956.GC29166@megas.kitware.com> On Fri, Jun 17, 2016 at 15:40:45 +0200, Nils Gladitz wrote: > I have not been involved in that development. > From what I can tell this is Eike's work. Ack, sorry. Should have double checked. --Ben From brad.king at kitware.com Fri Jun 17 11:13:04 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 17 Jun 2016 11:13:04 -0400 Subject: [cmake-developers] codeblocks generator: Fix include directories being in unexpected order In-Reply-To: <1466148677.811.246.camel@qt.io> References: <1465917658.811.241.camel@qt.io> <1465919519.811.243.camel@qt.io> <5762DE84.4010803@kitware.com> <1466148677.811.246.camel@qt.io> Message-ID: <57641380.20902@kitware.com> On 06/17/2016 03:31 AM, Tobias Hunger wrote: > Could this please go into 3.6? > > This is the root cause of quite a few bug reports hitting Qt Creator bug tracker > right now, so I would love to see a fix out in the wild ASAP. Normally I don't make non-regression/doc fixes after the first RC but this change seems pretty isolated. I've rebased the commit back before the release branch: cmExtraCodeBlocksGenerator: Do not shuffle include directories https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=76b462ea I've queued this for merge to `release` for 3.6. Thanks, -Brad From brad.king at kitware.com Fri Jun 17 11:54:49 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 17 Jun 2016 11:54:49 -0400 Subject: [cmake-developers] FindFreetype patch for Windows debug lib naming In-Reply-To: <702f77d1-90f4-7407-6ad5-c49446874482@objexx.com> References: <3a99b00d-a99b-da5d-5eea-1923cc145fc4@objexx.com> <18cceeab-720f-bf88-e752-c195c11aef8e@objexx.com> <575ABA91.60802@kitware.com> <209395162.bo6LCRPSAH@caliban.sf-tec.de> <702f77d1-90f4-7407-6ad5-c49446874482@objexx.com> Message-ID: <57641D49.7010900@kitware.com> On 06/12/2016 01:52 PM, Stuart Mentzer wrote: > Looking at FindZlib.cmake I think the attached should be OK Thanks. I've applied that as a patch here: FindFreetype: Find release and debug libraries separately https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b213a7f6 -Brad From ch.schmidbauer at gmail.com Fri Jun 17 12:53:31 2016 From: ch.schmidbauer at gmail.com (Christian Schmidbauer) Date: Fri, 17 Jun 2016 18:53:31 +0200 Subject: [cmake-developers] [PATCH] Allow LIB_SUFFIX be used as find path In-Reply-To: <575ECFC2.7090804@kitware.com> References: <1465725565-8925-1-git-send-email-ch.schmidbauer@gmail.com> <575ECFC2.7090804@kitware.com> Message-ID: On Mon, Jun 13, 2016 at 5:22 PM, Brad King wrote: > Hi Christian, > > Thanks for working on this. > > On 06/12/2016 05:59 AM, Christian Schmidbauer wrote: >> A similar idea has already been suggested in #10287 > > Yes. > >> and is required for bug #15594. > > That issue appears unrelated. Did you typo the number? > Indeed, I meant bug #15994. >> Help/command/find_library.rst | 5 ++++ >> Help/manual/cmake-properties.7.rst > > Please also add the FIND_LIBRARY_USE_CUSTOM_SUFFIX item documentation, > or whatever it becomes after the discussion below. > Where do you want me to document it? >> +If the :prop_gbl:`FIND_LIBRARY_USE_CUSTOM_SUFFIX` global property is set >> +all search paths will be tested as normal, with `LIB_SUFFIX` appended, and >> +with all matches of ``lib/`` replaced with `lib${LIB_SUFFIX}/`. This property >> +overrides both `FIND_LIBRARY_USE_LIB32_PATHS` and `FIND_LIBRARY_USE_LIB64_PATHS`. > [snip] >> +set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_CUSTOM_SUFFIX TRUE) >> +set(LIB_SUFFIX "XYZ") > > Typically the FIND_LIBRARY_USE_LIB{32,64}_PATHS global properties > can be set by the platform information modules in CMake itself > on platforms that need the behavior. In what context might the > FIND_LIBRARY_USE_CUSTOM_SUFFIX/LIB_SUFFIX values be set in practice? > > Thanks, > -Brad > In custom environments, where neither lib, lib32 or lib64 would serve the purpose but some custom library folder. I have a multilib system with an additional "libx32" next to lib/lib32 and lib64. Currently, you have to trick cmake in order to for libraries to be found. You could go ahead and add a similar patch like the lib32 one, but I think it's a better approach to let the user decide in such scenarios where he wants cmake to look. Best regards, Chris From Stuart_Mentzer at objexx.com Fri Jun 17 13:02:30 2016 From: Stuart_Mentzer at objexx.com (Stuart Mentzer) Date: Fri, 17 Jun 2016 13:02:30 -0400 Subject: [cmake-developers] FindFreetype patch for Windows debug lib naming In-Reply-To: <57641D49.7010900@kitware.com> References: <3a99b00d-a99b-da5d-5eea-1923cc145fc4@objexx.com> <18cceeab-720f-bf88-e752-c195c11aef8e@objexx.com> <575ABA91.60802@kitware.com> <209395162.bo6LCRPSAH@caliban.sf-tec.de> <702f77d1-90f4-7407-6ad5-c49446874482@objexx.com> <57641D49.7010900@kitware.com> Message-ID: <24abf2a7-0c57-0269-c77c-98c222e9c916@objexx.com> An HTML attachment was scrubbed... URL: From eike at sf-mail.de Fri Jun 17 13:11:19 2016 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 17 Jun 2016 19:11:19 +0200 Subject: [cmake-developers] FindFreetype patch for Windows debug lib naming In-Reply-To: <24abf2a7-0c57-0269-c77c-98c222e9c916@objexx.com> References: <3a99b00d-a99b-da5d-5eea-1923cc145fc4@objexx.com> <57641D49.7010900@kitware.com> <24abf2a7-0c57-0269-c77c-98c222e9c916@objexx.com> Message-ID: <3069568.DpKXKfD31r@caliban.sf-tec.de> Am Freitag, 17. Juni 2016, 13:02:30 schrieb Stuart Mentzer: > On 6/17/2016 11:54 AM, Brad King wrote: > On 06/12/2016 01:52 PM, Stuart Mentzer wrote: > Looking at FindZlib.cmake I think the attached should be OK > Thanks. I've applied that as a patch here: > > FindFreetype: Find release and debug libraries separately > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b213a7f6 > > -Brad > Thanks but a line was lost in translation at the bottom: > > mark_as_advanced( > FREETYPE_LIBRARY > FREETYPE_INCLUDE_DIR_freetype2 > FREETYPE_INCLUDE_DIR_ft2build > ) > > SLC handles mark_as_advanced for the _DEBUG and _RELEASE variables but I > assume we still need the base variable handled in FindFreetype. > > With that fix, if Eike is OK with this then it is done. No, this is actually correct. The things marked as advanced are cache variables. FREETYPE_LIBRARY is computed dynamically. The "advanced" thing is to hide these in the default view of cmake-gui. If Brad says the change of what is cached is ok I'm entirely fine with it. 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 brad.king at kitware.com Fri Jun 17 13:12:43 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 17 Jun 2016 13:12:43 -0400 Subject: [cmake-developers] FindFreetype patch for Windows debug lib naming In-Reply-To: <24abf2a7-0c57-0269-c77c-98c222e9c916@objexx.com> References: <3a99b00d-a99b-da5d-5eea-1923cc145fc4@objexx.com> <18cceeab-720f-bf88-e752-c195c11aef8e@objexx.com> <575ABA91.60802@kitware.com> <209395162.bo6LCRPSAH@caliban.sf-tec.de> <702f77d1-90f4-7407-6ad5-c49446874482@objexx.com> <57641D49.7010900@kitware.com> <24abf2a7-0c57-0269-c77c-98c222e9c916@objexx.com> Message-ID: <57642F8B.9050401@kitware.com> On 06/17/2016 01:02 PM, Stuart Mentzer wrote: > Thanks but a line was lost in translation at the bottom: > > mark_as_advanced( > *FREETYPE_LIBRARY* > FREETYPE_INCLUDE_DIR_freetype2 > FREETYPE_INCLUDE_DIR_ft2build > ) > > SLC handles mark_as_advanced for the _DEBUG and _RELEASE variables > but I assume we still need the base variable handled in FindFreetype. I dropped it intentionally. We no longer add FREETYPE_LIBRARY to the cache, so we are not responsible for marking it as advanced. We only use the value if it was set by someone else. -Brad From brad.king at kitware.com Fri Jun 17 13:13:14 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 17 Jun 2016 13:13:14 -0400 Subject: [cmake-developers] [PATCH] Allow LIB_SUFFIX be used as find path In-Reply-To: References: <1465725565-8925-1-git-send-email-ch.schmidbauer@gmail.com> <575ECFC2.7090804@kitware.com> Message-ID: <57642FAA.5050507@kitware.com> On 06/17/2016 12:53 PM, Christian Schmidbauer wrote: >> Please also add the FIND_LIBRARY_USE_CUSTOM_SUFFIX item documentation, >> or whatever it becomes after the discussion below. >> > Where do you want me to document it? In the same places that FIND_LIBRARY_USE_LIB32_PATHS documentation was added. Add a `Help/prop_gbl/FIND_LIBRARY_USE_CUSTOM_SUFFIX.rst` and associated links to it. >> Typically the FIND_LIBRARY_USE_LIB{32,64}_PATHS global properties >> can be set by the platform information modules in CMake itself >> on platforms that need the behavior. In what context might the >> FIND_LIBRARY_USE_CUSTOM_SUFFIX/LIB_SUFFIX values be set in practice? >> > In custom environments, where neither lib, lib32 or lib64 would serve > the purpose but some custom library folder. Actually I was asking in what source code context the actual set(LIB_SUFFIX ...) set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_CUSTOM_SUFFIX ...) lines would appear. CMake sets the lib32/lib64 ones in its own platform modules for the relevant platforms so user code never needs to do it. Where in user code would it be done? Thanks, -Brad From Stuart_Mentzer at objexx.com Fri Jun 17 13:23:59 2016 From: Stuart_Mentzer at objexx.com (Stuart Mentzer) Date: Fri, 17 Jun 2016 13:23:59 -0400 Subject: [cmake-developers] FindFreetype patch for Windows debug lib naming In-Reply-To: <57642F8B.9050401@kitware.com> References: <3a99b00d-a99b-da5d-5eea-1923cc145fc4@objexx.com> <18cceeab-720f-bf88-e752-c195c11aef8e@objexx.com> <575ABA91.60802@kitware.com> <209395162.bo6LCRPSAH@caliban.sf-tec.de> <702f77d1-90f4-7407-6ad5-c49446874482@objexx.com> <57641D49.7010900@kitware.com> <24abf2a7-0c57-0269-c77c-98c222e9c916@objexx.com> <57642F8B.9050401@kitware.com> Message-ID: On 6/17/2016 1:12 PM, Brad King wrote: > On 06/17/2016 01:02 PM, Stuart Mentzer wrote: >> Thanks but a line was lost in translation at the bottom: >> >> mark_as_advanced( >> *FREETYPE_LIBRARY* >> FREETYPE_INCLUDE_DIR_freetype2 >> FREETYPE_INCLUDE_DIR_ft2build >> ) >> >> SLC handles mark_as_advanced for the _DEBUG and _RELEASE variables >> but I assume we still need the base variable handled in FindFreetype. > I dropped it intentionally. We no longer add FREETYPE_LIBRARY to > the cache, so we are not responsible for marking it as advanced. > We only use the value if it was set by someone else. > > -Brad Ah, OK. This doesn't match the usage in FindZlib that I was using as a guide: mark_as_advanced(ZLIB_LIBRARY ZLIB_INCLUDE_DIR) Stuart From ch.schmidbauer at gmail.com Fri Jun 17 13:33:04 2016 From: ch.schmidbauer at gmail.com (Christian Schmidbauer) Date: Fri, 17 Jun 2016 19:33:04 +0200 Subject: [cmake-developers] [PATCH] Allow LIB_SUFFIX be used as find path In-Reply-To: <57642FAA.5050507@kitware.com> References: <1465725565-8925-1-git-send-email-ch.schmidbauer@gmail.com> <575ECFC2.7090804@kitware.com> <57642FAA.5050507@kitware.com> Message-ID: On Fri, Jun 17, 2016 at 7:13 PM, Brad King wrote: > On 06/17/2016 12:53 PM, Christian Schmidbauer wrote: >>> Please also add the FIND_LIBRARY_USE_CUSTOM_SUFFIX item documentation, >>> or whatever it becomes after the discussion below. >>> >> Where do you want me to document it? > > In the same places that FIND_LIBRARY_USE_LIB32_PATHS documentation was > added. Add a `Help/prop_gbl/FIND_LIBRARY_USE_CUSTOM_SUFFIX.rst` and > associated links to it. > Ok, I will add those and re-send the patch. >>> Typically the FIND_LIBRARY_USE_LIB{32,64}_PATHS global properties >>> can be set by the platform information modules in CMake itself >>> on platforms that need the behavior. In what context might the >>> FIND_LIBRARY_USE_CUSTOM_SUFFIX/LIB_SUFFIX values be set in practice? >>> >> In custom environments, where neither lib, lib32 or lib64 would serve >> the purpose but some custom library folder. > > Actually I was asking in what source code context the actual > > set(LIB_SUFFIX ...) > set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_CUSTOM_SUFFIX ...) > > lines would appear. CMake sets the lib32/lib64 ones in its own > platform modules for the relevant platforms so user code never > needs to do it. Where in user code would it be done? > > Thanks, > -Brad > In my setup, I would create a custom my-config.cmake file like which I can include in each cmake build with the following content: SET (LIB_SUFFIX x32 CACHE STRING "library path suffix" FORCE) SET (FIND_LIBRARY_USE_CUSTOM_PATHS TRUE CACHE BOOL "force libx32 search path" FORCE) SET (CMAKE_INSTALL_LIBDIR libx32 CACHE PATH "Output directory for libraries") This way I can overwrite cmake's default lib32/lib64 search folders. Why do you ask? Do you have a specific opinion about this? Best regards, Chris From brad.king at kitware.com Fri Jun 17 14:10:48 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 17 Jun 2016 14:10:48 -0400 Subject: [cmake-developers] [PATCH] Allow LIB_SUFFIX be used as find path In-Reply-To: References: <1465725565-8925-1-git-send-email-ch.schmidbauer@gmail.com> <575ECFC2.7090804@kitware.com> <57642FAA.5050507@kitware.com> Message-ID: <57643D28.6070501@kitware.com> On 06/17/2016 01:33 PM, Christian Schmidbauer wrote: >> CMake sets the lib32/lib64 ones in its own >> platform modules for the relevant platforms so user code never >> needs to do it. Where in user code would it be done? > > In my setup, I would create a custom my-config.cmake file And that is included from CMakeLists.txt files? > SET (FIND_LIBRARY_USE_CUSTOM_PATHS TRUE CACHE BOOL "force libx32 search path" FORCE) I think you meant to use set_property here. It is not a cache entry. However, see below. > This way I can overwrite cmake's default lib32/lib64 search folders. > Why do you ask? Do you have a specific opinion about this? If the goal is to be able to override it for a local build then we shouldn't have to modify the project CMake code. Setting the global property requires editing code. The existing properties FIND_LIBRARY_USE_LIB{32,64}_PATHS make sense because they are configured by CMake as properties of the current system. Instead we could activate this behavior through a variable that could then be added to the cache on the command line via -D. That would allow local builds to configure any project to search this way. For example: cmake ../src -DCMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX=x32 -Brad From brad.king at kitware.com Fri Jun 17 16:09:28 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 17 Jun 2016 16:09:28 -0400 Subject: [cmake-developers] CMake daemon-mode In-Reply-To: References: <1465227569.811.38.camel@qt.io> <5755B1AF.3000504@kitware.com> <1465310542.811.42.camel@qt.io> <5756DED0.5010404@kitware.com> <575702F2.6020502@kitware.com> <5758279C.1020706@kitware.com> <57596EAF.1020806@kitware.com> <5759AE22.6090405@kitware.com> Message-ID: <576458F8.60800@kitware.com> On 06/10/2016 12:31 PM, Tobias Hunger wrote: > I did try to do the changes you requested. The branch is here: > https://github.com/hunger/CMake/commits/compileflags Thanks. I did some refactoring to help address the path conversion problem: Refactor Makefile/Ninja tool working directory storage https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0392f72b Then I applied the patches with some revisions: cmGeneratorTarget: Adopt Fortran module directory generation https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=49f10f0d cmLocalGenerator: Add method to get Fortran-specific compiler flags https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5467e794 cmLocalGenerator: Adopt target compile flag generation https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3c488ce8 cmExtraSublimeTextGenerator: Use GetTargetCompileFlags https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=802b36fb These have been merged to `next` for testing. > Next patch moves the AddFortranFlags code. This will need some careful > review, as it removes a path conversion that were present in the > original code (in two places). I could just not figure out how > to convert in the new place. I replaced that commit with a different one that preserves the path conversion. The implementation needs to be in cmLocalCommonGenerator in order to have access to the needed information to do the conversion. I used virtual dispatch to achieve this. On other generators we do not need these flags anyway. Thanks, -Brad From brad.king at kitware.com Fri Jun 17 16:24:09 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 17 Jun 2016 16:24:09 -0400 Subject: [cmake-developers] daemon-mode: Infrastructure In-Reply-To: References: Message-ID: <57645C69.4090403@kitware.com> On 06/13/2016 08:00 PM, Tobias Hunger wrote: > * There will always be 1 client talking to a server. > * Client/Server communicate using JSON messages Yes. IIRC it is using stdin/stdout (I haven't checked the code), so limiting to one client is implicit. In this case, is it actually a daemon? It is not expected to outlive the client that started it. Perhaps we should consider a different name. One possible problem with using stdin/stdout is that when CMake runs the configuration the project code can do things like execute_process that may share the stdout with the child process. That may allow the child process to print content formatted to look like the protocol and trick the client. Ideally all output handling would avoid printing things to stdout in server/daemon mode, but that may take some effort to achieve. > What do you think? Does this make sense? It sounds fine to me. I'll state the caveat that I've had little experience in maintaining versioned protocols like this though. Hopefully others can review this too. On 06/14/2016 04:30 AM, Tobias Hunger wrote: > I think it would make perfect sense to ship the first cmake version with > included daemon-mode with a big, fat warning that the interfaces are not > finalized yet and will change in incompatible ways during the first release > cycle (or maybe two:-). Yes. Should we make the option to activate it different, and include "experimental" in its name? I think the idea is that no clients should be released that depend on the experimental behavior in CMake. Thanks, -Brad From gilles.khouzam at microsoft.com Fri Jun 17 17:42:13 2016 From: gilles.khouzam at microsoft.com (Gilles Khouzam) Date: Fri, 17 Jun 2016 21:42:13 +0000 Subject: [cmake-developers] Patch: Add ability to override the default Visual Studio tool Message-ID: This patch is to add the ability to override the default tool assigned by the Visual Studio generator based on the extension, by using a new source property VS_TOOL_OVERRIDE. This also allows for new tools to be defined without having to teach CMake how to handle them. For example, this allows to have resource support (.resw) files and specifying that they are processed with the PRIResource tool. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-VS_TOOL_OVERRIDE.PATCH Type: application/octet-stream Size: 9881 bytes Desc: 0001-VS_TOOL_OVERRIDE.PATCH URL: From gilles.khouzam at microsoft.com Fri Jun 17 17:34:25 2016 From: gilles.khouzam at microsoft.com (Gilles Khouzam) Date: Fri, 17 Jun 2016 21:34:25 +0000 Subject: [cmake-developers] Patch: Add the ability to specify SDK_REFERENCES for Visual Studio Message-ID: This patch is to add the ability with Visual Studio generators to add references to SDKs. This is similar to the DESKTOP, IOT and MOBILE extensions for Windows 10, but makes the process more generic, using the Property VS_SDK_REFERENCES as a semi-colon separated list. For example, adding a reference to the AdMediatorSDK would look something like this: set_property(TARGET ${EXE_NAME} PROPERTY VS_SDK_REFERENCES "Microsoft.AdMediatorWindows81, Version=1.0") -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-VS_SDK_REFERENCES.patch Type: application/octet-stream Size: 4338 bytes Desc: 0001-VS_SDK_REFERENCES.patch URL: From mail6543210 at yahoo.com.tw Sat Jun 18 05:34:04 2016 From: mail6543210 at yahoo.com.tw (mail6543210 at yahoo.com.tw) Date: Sat, 18 Jun 2016 17:34:04 +0800 Subject: [cmake-developers] [Patch] Two trivial patches fixing type in CPack/DEB testcase In-Reply-To: References: Message-ID: My bad. It's exactly a dot when that file is within an SELinux context. I forgot the backslash. Here're the refreshed patches. BR, Patrick 2016-06-16 20:45 GMT+08:00 Rolf Eike Beer : > Am 2016-06-16 13:37, schrieb mail6543210--- via cmake-developers: > >> Hi there, >> >> Here're two trivial patches for testing of CPack/DEB. >> >> One is for building cmake on SELinux-enabled system, and other is for a >> typo in the same file form the former one. >> >> These patches is based on commit 83ae7944 >> >> First patch: >> >> When building cmake on an SELinux-enabled system, there will be an extra >> dot at the end of permission field of `ls -l` like this: >> -rwxrwxrwx. >> ^ this dot >> This makes the testing RunCMake.CPack_DEB fail. >> >> This patch add an optional dot in the regex to fix it. >> > > If it is exactly a dot and not "some random character", than you need to > escape that in the regular expression as dot is the wildcard character > there. > > Greetings, > > Eike > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Enable-building-on-SELinux-enabled-system.patch Type: text/x-patch Size: 1688 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fix-typos-of-testing-data-in-CPack-DEB.patch Type: text/x-patch Size: 1346 bytes Desc: not available URL: From steveire at gmail.com Sat Jun 18 08:12:52 2016 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 18 Jun 2016 14:12:52 +0200 Subject: [cmake-developers] CMake 32 and 64 bit packages on Windows Message-ID: Hi, I tried the CMake 3.6 RC on Windows yesterday. I initially downloaded the 64 bit version, and the installer uninstalled my CMake 3.5 (32 bit). Then, in my 'Visual Studio 14 2015 64 bit command prompt', the cmake executable was no longer found. I think the difference is that the 64 bit cmake is installed to 'Program Files (x64)', whereas the 32 bit version is installed to 'Program Files'. I installed the 3.6 RC 32 bit and that worked fine with my command prompt. It is possible that I somehow made a mistake or messed up my visual studio command prompt environment (I don't recall doing that), but it didn't seem to be looking in the 64 bit location for cmake. It might be something for someone more familiar with Windows to look into. Thanks, Steve. From steveire at gmail.com Sat Jun 18 08:15:51 2016 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 18 Jun 2016 14:15:51 +0200 Subject: [cmake-developers] How to set startup project in Visual Studio Message-ID: Hi, the outcome of https://cmake.org/Bug/view.php?id=15578 seems to be https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=78ec0461 a DIRECTORY property VS_STARTUP_PROJECT which sets the start up project in Visual Studio. I tried it in the 3.6 RC and it works fine if I set the property in the top-level directory, so thanks for that. However, the documentation does not say which directory to set it in, or why it is a DIRECTORY property. Why is this not a GLOBAL property? Thanks, Steve. From eike at sf-mail.de Sat Jun 18 08:41:34 2016 From: eike at sf-mail.de (Rolf Eike Beer) Date: Sat, 18 Jun 2016 14:41:34 +0200 Subject: [cmake-developers] FindPkgConfig and IMPORTED_TARGET in 3.6.0 In-Reply-To: <20160617133633.GA29166@megas.kitware.com> References: <20160617133633.GA29166@megas.kitware.com> Message-ID: <19050833.sZjQFlm67H@eto> Ben Boeckel wrote: > Hi, > > Nils, the IMPORTED_TARGET feature in pkg_check_modules is nice! Thanks > for that. However, it is hidden behind the check that pkg_check_modules > uses to see if it already ran: > > if (NOT DEFINED __pkg_config_checked_${_prefix} OR > __pkg_config_checked_${_prefix} LESS ${PKG_CONFIG_VERSION} OR > NOT ${_prefix}_FOUND) > > which means that on the second configure, the target is not created > causing build faiures. Could you please look at reordering the logic so > that the imported target is always created (if requested)? Thanks. > > Brad, this is in the rc releases; what should be done? Block the > release, undocument the feature, or wait for a patch? Please check if https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3213b747a84a4e584e9edc6bd8c114b809b18bec fixes it for you. 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 laurent at mbdsys.com Sat Jun 18 12:10:12 2016 From: laurent at mbdsys.com (laurent) Date: Sat, 18 Jun 2016 18:10:12 +0200 Subject: [cmake-developers] speed up package with mingw on Windows host Message-ID: <3A90179F-F09C-4B8C-B17D-148E116B048C@mbdsys.com> Hello, I would like to share my experience about speed up package with BundleUtilities on Windows host using mingw32 env. My test setup : - Windows 7 - cmake 3.4.1 - msys2 i686-20160205 Currently my project take about 40 min to package. This is not acceptable. The main reason is about deep dependencies analyse with objdump. 1/ There is already a patch trying to resolve this issue : https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f01a8823 But this patch use grep. grep is a unix utility not provided by Windows. grep could be replaced by findstr on Windows. This way we can achieve the same level of filtering with the same criteria. 2/ Regarding fixup_bundle flow, we can observe multi recursive analyse call to the same library. This is an huge time consumer. This simple patch disable analyse of already processed libraries. (The time to package my project drop down to 4 min with this patch) --- GetPrerequisites.cmake 2016-04-15 15:41:21.000000000 +0200 +++ GetPrerequisites.cmake.new 2016-06-18 17:36:19.000000000 +0200 @@ -727,7 +727,11 @@ 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(WIN32) + find_program(gp_grep_cmd findstr) + else() + find_program(gp_grep_cmd grep) + endif() if(gp_grep_cmd) set(gp_cmd_maybe_filter COMMAND ${gp_grep_cmd} "^[[:blank:]]*DLL Name: ") endif() @@ -920,9 +924,18 @@ list(SORT ${prerequisites_var}) endif() if(${recurse}) + GET_PROPERTY(MyLocalVariable GLOBAL PROPERTY MY_PREREQUISE) + list(APPEND analysed ${MyLocalVariable} ${target}) + list(REMOVE_DUPLICATES analysed) + SET_PROPERTY(GLOBAL PROPERTY MY_PREREQUISE ${analysed}) + set(more_inputs ${unseen_prereqs}) foreach(input ${more_inputs}) - get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} ${recurse} "${exepath}" "${dirs}" "${rpaths}") + GET_PROPERTY(MyTmp GLOBAL PROPERTY MY_PREREQUISE) + list (FIND MyTmp ${input} is_found) + if(${is_found} EQUAL -1) + get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} ${recurse} "${exepath}" "${dirs}" "${rpaths}") + endif() endforeach() endif() Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Sun Jun 19 03:36:26 2016 From: eike at sf-mail.de (Rolf Eike Beer) Date: Sun, 19 Jun 2016 09:36:26 +0200 Subject: [cmake-developers] FindPkgConfig and IMPORTED_TARGET in 3.6.0 In-Reply-To: <19050833.sZjQFlm67H@eto> References: <20160617133633.GA29166@megas.kitware.com> <19050833.sZjQFlm67H@eto> Message-ID: <24040301.G2Ov5PPHuF@caliban.sf-tec.de> Am Samstag, 18. Juni 2016, 14:41:34 schrieb Rolf Eike Beer: > Ben Boeckel wrote: > > Hi, > > > > Nils, the IMPORTED_TARGET feature in pkg_check_modules is nice! Thanks > > for that. However, it is hidden behind the check that pkg_check_modules > > > > uses to see if it already ran: > > if (NOT DEFINED __pkg_config_checked_${_prefix} OR > > > > __pkg_config_checked_${_prefix} LESS ${PKG_CONFIG_VERSION} OR > > NOT ${_prefix}_FOUND) > > > > which means that on the second configure, the target is not created > > causing build faiures. Could you please look at reordering the logic so > > that the imported target is always created (if requested)? Thanks. > > > > Brad, this is in the rc releases; what should be done? Block the > > release, undocument the feature, or wait for a patch? > > Please check if > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3213b747a84a4e584e9edc6b > d8c114b809b18bec fixes it for you. Version without stupid typo: https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8345c6463d813fb39ee6a6dee5259ee18525c62c -------------- 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 der_ghulbus at ghulbus-inc.de Sun Jun 19 07:00:07 2016 From: der_ghulbus at ghulbus-inc.de (Andreas Weis) Date: Sun, 19 Jun 2016 13:00:07 +0200 Subject: [cmake-developers] Imported Locations in FindBoost.cmake Message-ID: <569fcee6-d4ef-2989-b571-d7fe96f251f1@ghulbus-inc.de> Hi there, I ran into a small issue with the new imported target interface of FindBoost.cmake. Just like the old variable-based interface, the script only detects Debug and Release configurations of installed Boost binaries. In the old interface, the debug binaries where used only for debug builds (care of the debug keyword in the classic target_link_libraries function), while the release binaries were used for all other configurations (optimized keyword). It seems that with the new interface, this was inverted. On MSVC for instance, the RelWithDebInfo and MinSizeRel configurations use the debug binaries of Boost. This is not desirable and can even break those configurations on MSVC due to inconsistent use of the debug runtime and STL debug iterators. After fiddling around with the issue, I found that reversing the order in which the IMPORTED_LOCATION_* fields on the imported target are being set resolves the issue. It seems that the first configuration that's added here will be used as a default for the not explicitly added configurations? I attached a small patch to demonstrate what I mean, but I am unsure if this is a proper fix for the issue. Thanks and regards, Andreas -------------- next part -------------- From c201749b494c5aa44d7cc6c9139d8c71db849cf2 Mon Sep 17 00:00:00 2001 From: Andreas Weis Date: Sun, 19 Jun 2016 12:44:29 +0200 Subject: [PATCH] Switched order of adding locations to imported target FindBoost only detects Debug and Release configurations; All other configurations will fall back to whichever IMPORTED_LOCATION_ was added *first*. This change makes sure that that is the Release configuration. Adding Debug first is likely to cause conflicts on MSVC, where the Debug runtime is not to be used for RelWithDebInfo and MinSizeRel builds. --- Modules/FindBoost.cmake | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake index 6bf6401..2560459 100644 --- a/Modules/FindBoost.cmake +++ b/Modules/FindBoost.cmake @@ -1734,13 +1734,6 @@ if(Boost_FOUND) IMPORTED_LINK_INTERFACE_LANGUAGES "CXX" IMPORTED_LOCATION "${Boost_${UPPERCOMPONENT}_LIBRARY}") endif() - if(EXISTS "${Boost_${UPPERCOMPONENT}_LIBRARY_DEBUG}") - set_property(TARGET Boost::${COMPONENT} APPEND PROPERTY - IMPORTED_CONFIGURATIONS DEBUG) - set_target_properties(Boost::${COMPONENT} PROPERTIES - IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG "CXX" - IMPORTED_LOCATION_DEBUG "${Boost_${UPPERCOMPONENT}_LIBRARY_DEBUG}") - endif() if(EXISTS "${Boost_${UPPERCOMPONENT}_LIBRARY_RELEASE}") set_property(TARGET Boost::${COMPONENT} APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE) @@ -1748,6 +1741,13 @@ if(Boost_FOUND) IMPORTED_LINK_INTERFACE_LANGUAGES_RELEASE "CXX" IMPORTED_LOCATION_RELEASE "${Boost_${UPPERCOMPONENT}_LIBRARY_RELEASE}") endif() + if(EXISTS "${Boost_${UPPERCOMPONENT}_LIBRARY_DEBUG}") + set_property(TARGET Boost::${COMPONENT} APPEND PROPERTY + IMPORTED_CONFIGURATIONS DEBUG) + set_target_properties(Boost::${COMPONENT} PROPERTIES + IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG "CXX" + IMPORTED_LOCATION_DEBUG "${Boost_${UPPERCOMPONENT}_LIBRARY_DEBUG}") + endif() if(_Boost_${UPPERCOMPONENT}_DEPENDENCIES) unset(_Boost_${UPPERCOMPONENT}_TARGET_DEPENDENCIES) foreach(dep ${_Boost_${UPPERCOMPONENT}_DEPENDENCIES}) -- 2.5.0.windows.1 From tobias.hunger at gmail.com Sun Jun 19 13:33:13 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Sun, 19 Jun 2016 19:33:13 +0200 Subject: [cmake-developers] daemon-mode: Infrastructure In-Reply-To: <57645C69.4090403@kitware.com> References: <57645C69.4090403@kitware.com> Message-ID: Hi Brad, Am 17.06.2016 22:24 schrieb "Brad King" : > > On 06/13/2016 08:00 PM, Tobias Hunger wrote: > > * There will always be 1 client talking to a server. > > * Client/Server communicate using JSON messages > > Yes. IIRC it is using stdin/stdout (I haven't checked the code), > so limiting to one client is implicit. True. Still it does not hurt to state explicitly, especially considering that I think of the stdin/out as an implementation detail. There is no reason for the code not to switch to pipes or sockets for communication. > In this case, is it actually a daemon? It is not expected to outlive > the client that started it. Perhaps we should consider a different name. I am bad at names:-) Plus Stephen made quite a bit of PR for the CMake daemon idea. > One possible problem with using stdin/stdout is that when CMake runs the > configuration the project code can do things like execute_process that > may share the stdout with the child process. That may allow the child > process to print content formatted to look like the protocol and trick > the client. Ideally all output handling would avoid printing things to > stdout in server/daemon mode, but that may take some effort to achieve. Yes, unexpected output on stdout could cause havok to the parser. So far this worked well though, and the magic string before/after messages prevented any unexpected interactions. > > What do you think? Does this make sense? > > It sounds fine to me. I'll state the caveat that I've had little experience > in maintaining versioned protocols like this though. Hopefully others can > review this too. Yes, I hope other IDE developers will chime in at some point... > On 06/14/2016 04:30 AM, Tobias Hunger wrote: > > I think it would make perfect sense to ship the first cmake version with > > included daemon-mode with a big, fat warning that the interfaces are not > > finalized yet and will change in incompatible ways during the first release > > cycle (or maybe two:-). > > Yes. Should we make the option to activate it different, and include > "experimental" in its name? I think the idea is that no clients should > be released that depend on the experimental behavior in CMake. I now added a patch that allows protocol versions to be marked as experimental. These are only visible to clients that started "cmake -E daemon --experimental". The only existing protocol version is now marked experimental. I think that makes it pretty clear what is experimental and what is not and clients do not need to change (except for maybe dropping the --experimental flag) to go to a stable interface once we are satisfied with the first version. Best Regards, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hunger at gmail.com Sun Jun 19 13:40:58 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Sun, 19 Jun 2016 19:40:58 +0200 Subject: [cmake-developers] CMake daemon-mode In-Reply-To: <576458F8.60800@kitware.com> References: <1465227569.811.38.camel@qt.io> <5755B1AF.3000504@kitware.com> <1465310542.811.42.camel@qt.io> <5756DED0.5010404@kitware.com> <575702F2.6020502@kitware.com> <5758279C.1020706@kitware.com> <57596EAF.1020806@kitware.com> <5759AE22.6090405@kitware.com> <576458F8.60800@kitware.com> Message-ID: Hi Brad, Am 17.06.2016 22:09 schrieb "Brad King" : > Then I applied the patches with some revisions: > > cmGeneratorTarget: Adopt Fortran module directory generation > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=49f10f0d > > cmLocalGenerator: Add method to get Fortran-specific compiler flags > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5467e794 > > cmLocalGenerator: Adopt target compile flag generation > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3c488ce8 > > cmExtraSublimeTextGenerator: Use GetTargetCompileFlags > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=802b36fb > > These have been merged to `next` for testing. Wonderful! Thanks for improving the patches I'll rebase my branch on top of these as soon as they hit master. Best Regards, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikedld at mikedld.com Sun Jun 19 15:17:08 2016 From: mikedld at mikedld.com (Mike Gelfand) Date: Sun, 19 Jun 2016 22:17:08 +0300 Subject: [cmake-developers] Imported Locations in FindBoost.cmake In-Reply-To: <569fcee6-d4ef-2989-b571-d7fe96f251f1@ghulbus-inc.de> References: <569fcee6-d4ef-2989-b571-d7fe96f251f1@ghulbus-inc.de> Message-ID: <16740d1b-ea67-a4c0-d358-efaa6b158170@mikedld.com> Hello, On 06/19/2016 02:00 PM, Andreas Weis wrote: > After fiddling around with the issue, I found that reversing the order > in which the IMPORTED_LOCATION_* fields on the imported target are being > set resolves the issue. It seems that the first configuration that's > added here will be used as a default for the not explicitly added > configurations? Seems to be true for me as well. I don't think just reverting the order is a proper fix though. Consider exported target configuration files generated by the CMake itself. They consist of .cmake and a set of -.cmake files which are included from the former in unknown order. At east file(GLOB) documentation doesn't specify the order, but even if it's sorted alphabetically then -debug.cmake always comes before -release.cmake or -relwithdebinfo.cmake. The suggested way to deal with this seems to be to use MAP_IMPORTED_CONFIG_ target properties, but I suppose it should only (?) be used when imported target (or target it's being linked to) has non-standard configurations, which isn't so in this case. Mapping Release to "Release;RelWithDebInfo" and RelWithDebInfo to "RelWithDebInfo;Release" looks odd enough (and I didn't add MinRelSize here). Maybe there should exist some default mapping built-in with the similar effect?.. Regards, Mike From domen.vrankar at gmail.com Sun Jun 19 16:42:26 2016 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Sun, 19 Jun 2016 22:42:26 +0200 Subject: [cmake-developers] [Patch] Two trivial patches fixing type in CPack/DEB testcase In-Reply-To: References: Message-ID: >>> Here're two trivial patches for testing of CPack/DEB. >>> >>> One is for building cmake on SELinux-enabled system, and other is for a >>> typo in the same file form the former one. Applied to next with extension of first patch to newer tests: https://cmake.org/gitweb?p=cmake.git;a=commit;h=b661d4a Brad could this topic be merged to 3.6 since it is a test fix? Thanks, Domen From mikedld at mikedld.com Sun Jun 19 17:42:16 2016 From: mikedld at mikedld.com (Mike Gelfand) Date: Mon, 20 Jun 2016 00:42:16 +0300 Subject: [cmake-developers] How to set startup project in Visual Studio In-Reply-To: References: Message-ID: <1a4a94a3-eb3e-f612-4ae7-fc1b758c8a0d@mikedld.com> Hello, On 06/18/2016 03:15 PM, Stephen Kelly wrote: > a DIRECTORY property VS_STARTUP_PROJECT which sets the start up project in > Visual Studio. I tried it in the 3.6 RC and it works fine if I set the > property in the top-level directory, so thanks for that. > > However, the documentation does not say which directory to set it in, or why > it is a DIRECTORY property. > > Why is this not a GLOBAL property? My guess would be because CMake generates .sln file for each project() call (e.g. if you have additional project() calls in subdirectories apart from the top-level one), and then for each .sln file it would be possible to specify different startup [VS] project. So it's not exactly a directory, but a project property I would say, but there're no "project properties" in CMake. Regards, Mike From d3ck0r at gmail.com Mon Jun 20 00:02:37 2016 From: d3ck0r at gmail.com (J Decker) Date: Sun, 19 Jun 2016 21:02:37 -0700 Subject: [cmake-developers] How to set startup project in Visual Studio In-Reply-To: <1a4a94a3-eb3e-f612-4ae7-fc1b758c8a0d@mikedld.com> References: <1a4a94a3-eb3e-f612-4ae7-fc1b758c8a0d@mikedld.com> Message-ID: The setting is in a different file that's .vcproj.user (or .user.vcproj) and cmake doesn't write that... would be nice if it could at least write those entiries required... nice thing about xml should be that what's there can be read and used and filled in with the rest of the settings? Well I guess that's really implementation dependant. On Sun, Jun 19, 2016 at 2:42 PM, Mike Gelfand wrote: > Hello, > > On 06/18/2016 03:15 PM, Stephen Kelly wrote: > > a DIRECTORY property VS_STARTUP_PROJECT which sets the start up project > in > > Visual Studio. I tried it in the 3.6 RC and it works fine if I set the > > property in the top-level directory, so thanks for that. > > > > However, the documentation does not say which directory to set it in, or > why > > it is a DIRECTORY property. > > > > Why is this not a GLOBAL property? > My guess would be because CMake generates .sln file for each project() > call (e.g. if you have additional project() calls in subdirectories > apart from the top-level one), and then for each .sln file it would be > possible to specify different startup [VS] project. So it's not exactly > a directory, but a project property I would say, but there're no > "project properties" in CMake. > > Regards, > Mike > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/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 der_ghulbus at ghulbus-inc.de Mon Jun 20 01:32:17 2016 From: der_ghulbus at ghulbus-inc.de (Andreas Weis) Date: Mon, 20 Jun 2016 07:32:17 +0200 Subject: [cmake-developers] Imported Locations in FindBoost.cmake In-Reply-To: <16740d1b-ea67-a4c0-d358-efaa6b158170@mikedld.com> References: <569fcee6-d4ef-2989-b571-d7fe96f251f1@ghulbus-inc.de> <16740d1b-ea67-a4c0-d358-efaa6b158170@mikedld.com> Message-ID: On 6/19/2016 9:17 PM, Mike Gelfand wrote: > > The suggested way to deal with this seems to be to use > MAP_IMPORTED_CONFIG_ target properties, but I suppose it should > only (?) be used when imported target (or target it's being linked to) > has non-standard configurations, which isn't so in this case. > Alternatively, maybe it makes sense for FindBoost to simply set all configurations explicitly? By iterating over CMAKE_CONFIGURATION_TYPES (or inspecting CMAKE_BUILD_TYPE for single-config generators) and using the global property DEBUG_CONFIGURATIONS to determine whether a given configuration needs the debug or the release binaries. I'm still unsure what to make of the current fallback-to-first-configuration behavior. I did not find this mentioned anywhere in the docs, so I guess it's not a behavior one should rely upon? I was wondering whether it would make sense to properly define what CMake does in such a case. In particular since, as you mentioned, package configuration files might already rely on some assumptions there. Best regards, Andreas From sergey.nikulov at gmail.com Mon Jun 20 07:23:41 2016 From: sergey.nikulov at gmail.com (Sergei Nikulov) Date: Mon, 20 Jun 2016 14:23:41 +0300 Subject: [cmake-developers] Fwd: Question about CHECK_C_COMPILER_FLAG In-Reply-To: References: Message-ID: Hi All, I have a question about CHECK_C_COMPILER_FLAG behaviour. Documentation will tell that "the compiler does not give an error message when it encounters the flag". Unfortunately, it not only compiles but try to link executable. If linker fails, due missed libraries it also does not produce positive result even if compilation was successful. Is it expected behaviour or issue? My example environment cmake v3.4.3/Linux/gcc v4.8.5 check_c_compiler_flag("-fsanitize=address" HAVE_C_FLAG_asan) Log in CMakeError.log ... erforming C SOURCE FILE Test HAVE_C_FLAG_asan failed with the following output: Change Dir: /home/snikulov/work/github/curl/build/CMakeFiles/CMakeTmp Run Build Command:"/usr/bin/gmake" "cmTC_846be/fast" /usr/bin/gmake -f CMakeFiles/cmTC_846be.dir/build.make CMakeFiles/cmTC_846be.dir/build gmake[1]: Entering directory `/home/snikulov/work/github/curl/build/CMakeFiles/CMakeTmp' Building C object CMakeFiles/cmTC_846be.dir/src.c.o /usr/bin/cc -DHAVE_C_FLAG_asan -fsanitize=address -o CMakeFiles/cmTC_846be.dir/src.c.o -c /home/snikulov/work/github/curl/build/CMakeFiles/CMakeTmp/src.c Linking C executable cmTC_846be /usr/local/bin/cmake -E cmake_link_script CMakeFiles/cmTC_846be.dir/link.txt --verbose=1 /usr/bin/cc -DHAVE_C_FLAG_asan CMakeFiles/cmTC_846be.dir/src.c.o -o cmTC_846be -rdynamic /usr/lib64/libssl.so /usr/lib64/libcrypto.so -lldap -llber CMakeFiles/cmTC_846be.dir/src.c.o: In function `_GLOBAL__sub_I_00099_0_main': src.c:(.text+0x10): undefined reference to `__asan_init_v1' collect2: error: ld returned 1 exit status gmake[1]: *** [cmTC_846be] Error 1 gmake[1]: Leaving directory `/home/snikulov/work/github/curl/build/CMakeFiles/CMakeTmp' gmake: *** [cmTC_846be/fast] Error 2 Source file was: int main(void) { return 0; } ... -- Best Regards, Sergei Nikulov From farbos.arnaud at gmail.com Mon Jun 20 07:55:16 2016 From: farbos.arnaud at gmail.com (Farbos a) Date: Mon, 20 Jun 2016 13:55:16 +0200 Subject: [cmake-developers] [PATCH] add debug glew to FindGLEW Message-ID: Hi, I added the Glew debug library to the FindGLEW.cmake, here is the patch. Tell me if everything looks good and if I can do a pull request. Thanks, -- Arnaud FARBOS -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-add-debug-glew-to-FindGLEW.patch Type: application/octet-stream Size: 1603 bytes Desc: not available URL: From brad.king at kitware.com Mon Jun 20 10:17:41 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 20 Jun 2016 10:17:41 -0400 Subject: [cmake-developers] Fwd: Question about CHECK_C_COMPILER_FLAG In-Reply-To: References: Message-ID: <5767FB05.8080802@kitware.com> On 06/20/2016 07:23 AM, Sergei Nikulov wrote: > Documentation will tell that "the compiler does not give an error > message when it encounters the flag". > Unfortunately, it not only compiles but try to link executable. > > If linker fails, due missed libraries it also does not produce > positive result even if compilation was successful. > > Is it expected behaviour or issue? It is expected. If a compiler cannot do "cc -flag hello.c" then the flag must have some special behavior that needs a smarter check. CMake 3.6 introduces CMAKE_TRY_COMPILE_TARGET_TYPE: https://cmake.org/cmake/help/v3.6/variable/CMAKE_TRY_COMPILE_TARGET_TYPE.html which might be of help here. -Brad From brad.king at kitware.com Mon Jun 20 10:17:31 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 20 Jun 2016 10:17:31 -0400 Subject: [cmake-developers] Imported Locations in FindBoost.cmake In-Reply-To: References: <569fcee6-d4ef-2989-b571-d7fe96f251f1@ghulbus-inc.de> <16740d1b-ea67-a4c0-d358-efaa6b158170@mikedld.com> Message-ID: <5767FAFB.4040304@kitware.com> Hi Folks, For reference, there is an issue tracker entry for this problem: https://gitlab.kitware.com/cmake/cmake/issues/16091 Similar alternatives have been discussed there. On 06/20/2016 01:32 AM, Andreas Weis wrote: > On 6/19/2016 9:17 PM, Mike Gelfand wrote: >> The suggested way to deal with this seems to be to use >> MAP_IMPORTED_CONFIG_ target properties That property is meant for client code to set when it has a different set of configurations than those imported. Technically that is true here, but CMake should have better default behavior for the builtin configurations like RelWithDebInfo. > I'm still unsure what to make of the current > fallback-to-first-configuration behavior. I did not find this mentioned > anywhere in the docs, so I guess it's not a behavior one should rely upon? > I was wondering whether it would make sense to properly define what > CMake does in such a case. In particular since, as you mentioned, > package configuration files might already rely on some assumptions there. There is discussion about this in the above-linked issue. I think switching the order of configurations is a good solution to use until the alternatives can be considered: FindBoost: Make imported targets fall back to `Release` https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c9fca42f Thanks, -Brad From brad.king at kitware.com Mon Jun 20 10:17:45 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 20 Jun 2016 10:17:45 -0400 Subject: [cmake-developers] [PATCH] add debug glew to FindGLEW In-Reply-To: References: Message-ID: <5767FB09.2080303@kitware.com> On 06/20/2016 07:55 AM, Farbos a wrote: > I added the Glew debug library to the FindGLEW.cmake, here is the patch. Good start. Here are some comments: * For compatibility with scripts that set GLEW_LIBRARY we need to honor the old name if it is set. See FindZLIB for an example. (Near the "Allow ZLIB_LIBRARY to be set manually" comment.) * The imported target needs to have each configuration added only if it exists. See FindZLIB for an example. IMPORTED_CONFIGURATIONS needs to list the available configurations. Thanks, -Brad From brad.king at kitware.com Mon Jun 20 10:17:55 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 20 Jun 2016 10:17:55 -0400 Subject: [cmake-developers] [Patch] Two trivial patches fixing type in CPack/DEB testcase In-Reply-To: References: Message-ID: <5767FB13.9040903@kitware.com> On 06/19/2016 04:42 PM, Domen Vrankar wrote: > Applied to next with extension of first patch to newer tests: > https://cmake.org/gitweb?p=cmake.git;a=commit;h=b661d4a > > Brad could this topic be merged to 3.6 since it is a test fix? I rebased the topic: CPack/Deb: Fix tests for SELinux-enabled systems https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=302391ba CPack/Deb: Fix test to actually test the preinst script https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6107fab4 and queued it for merge to 'release' for 3.6. Thanks, -Brad From brad.king at kitware.com Mon Jun 20 10:18:01 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 20 Jun 2016 10:18:01 -0400 Subject: [cmake-developers] FindPkgConfig and IMPORTED_TARGET in 3.6.0 In-Reply-To: <24040301.G2Ov5PPHuF@caliban.sf-tec.de> References: <20160617133633.GA29166@megas.kitware.com> <19050833.sZjQFlm67H@eto> <24040301.G2Ov5PPHuF@caliban.sf-tec.de> Message-ID: <5767FB19.1010707@kitware.com> On 06/19/2016 03:36 AM, Rolf Eike Beer wrote: > Version without stupid typo: > > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8345c6463d813fb39ee6a6dee5259ee18525c62c Thanks. I've queued this for merge to 'release' for 3.6. -Brad From brad.king at kitware.com Mon Jun 20 10:18:07 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 20 Jun 2016 10:18:07 -0400 Subject: [cmake-developers] CMake 32 and 64 bit packages on Windows In-Reply-To: References: Message-ID: <5767FB1F.6080101@kitware.com> On 06/18/2016 08:12 AM, Stephen Kelly wrote: > I tried the CMake 3.6 RC on Windows yesterday. I initially downloaded the 64 > bit version, and the installer uninstalled my CMake 3.5 (32 bit). This is because the MSI package records only a single package name for all CMake versions. Each installation is assumed to replace any existing installation of the same package. Linux distro package tools do the same thing. One can use the .zip files to have independent versions not managed by a package system. > Then, in my 'Visual Studio 14 2015 64 bit command prompt', the cmake > executable was no longer found. The type of prompt should make no difference. The installer provides an option for adding the CMake installation to your system PATH. MSI takes care of reversing effects of the removed installation, so that may have removed it from your PATH. -Brad From brad.king at kitware.com Mon Jun 20 10:48:37 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 20 Jun 2016 10:48:37 -0400 Subject: [cmake-developers] Patch: Add ability to override the default Visual Studio tool In-Reply-To: References: Message-ID: <57680245.309@kitware.com> On 06/17/2016 05:42 PM, Gilles Khouzam wrote: > This patch is to add the ability to override the default tool > assigned by the Visual Studio generator based on the extension Thanks, applied: VS: Add a VS_TOOL_OVERRIDE source file property https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed05f11d -Brad From brad.king at kitware.com Mon Jun 20 10:48:42 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 20 Jun 2016 10:48:42 -0400 Subject: [cmake-developers] Patch: Add the ability to specify SDK_REFERENCES for Visual Studio In-Reply-To: References: Message-ID: <5768024A.3080204@kitware.com> On 06/17/2016 05:34 PM, Gilles Khouzam wrote: > This patch is to add the ability with Visual Studio generators > to add references to SDKs. Thanks, applied: VS: Add VS_SDK_REFERENCES target property to reference external SDKs https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ccc6270d -Brad From brad.king at kitware.com Mon Jun 20 10:48:48 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 20 Jun 2016 10:48:48 -0400 Subject: [cmake-developers] speed up package with mingw on Windows host In-Reply-To: <3A90179F-F09C-4B8C-B17D-148E116B048C@mbdsys.com> References: <3A90179F-F09C-4B8C-B17D-148E116B048C@mbdsys.com> Message-ID: <57680250.9010800@kitware.com> On 06/18/2016 12:10 PM, laurent wrote: > I would like to share my experience about speed up package with BundleUtilities > on Windows host using mingw32 env. Thanks. Please provide a Full Name format name for the commit authorship record. > - find_program(gp_grep_cmd grep) > + if(WIN32) > + find_program(gp_grep_cmd findstr) > + else() > + find_program(gp_grep_cmd grep) > + endif() Good. Is `findstr` command-line compatible with `grep` for the use case in question? > + GET_PROPERTY(MyLocalVariable GLOBAL PROPERTY MY_PREREQUISE) > + list(APPEND analysed ${MyLocalVariable} ${target}) > + list(REMOVE_DUPLICATES analysed) > + SET_PROPERTY(GLOBAL PROPERTY MY_PREREQUISE ${analysed}) Rather than maintaining and searching a list in CMake code, please try recording each target in a dedicated variable or property name, e.g. `GET_PREREQUISITES_ANALYZED_${target}`. Thanks, -Brad From farbos.arnaud at gmail.com Mon Jun 20 10:52:43 2016 From: farbos.arnaud at gmail.com (Farbos a) Date: Mon, 20 Jun 2016 16:52:43 +0200 Subject: [cmake-developers] [PATCH] add debug glew to FindGLEW In-Reply-To: <5767FB09.2080303@kitware.com> References: <5767FB09.2080303@kitware.com> Message-ID: Brad, Here is the patch fixed. Thanks, 2016-06-20 16:17 GMT+02:00 Brad King : > On 06/20/2016 07:55 AM, Farbos a wrote: >> I added the Glew debug library to the FindGLEW.cmake, here is the patch. > > Good start. Here are some comments: > > * For compatibility with scripts that set GLEW_LIBRARY we need to > honor the old name if it is set. See FindZLIB for an example. > (Near the "Allow ZLIB_LIBRARY to be set manually" comment.) > > * The imported target needs to have each configuration added only > if it exists. See FindZLIB for an example. IMPORTED_CONFIGURATIONS > needs to list the available configurations. > > Thanks, > -Brad > -- Arnaud FARBOS -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-add-debug-glew-to-FindGLEW.patch Type: application/octet-stream Size: 2544 bytes Desc: not available URL: From anonim288 at gmail.com Mon Jun 20 14:02:54 2016 From: anonim288 at gmail.com (ivan Ivanov) Date: Mon, 20 Jun 2016 21:02:54 +0300 Subject: [cmake-developers] proposal of fix for FindLua In-Reply-To: <57309165.9020907@kitware.com> References: <57309165.9020907@kitware.com> Message-ID: Fixed, please review it again (patches are attached to #15756 ) . Erase variable from cache is necessary, I think (see comment at gitlab). Ignoring of LUA_INCLUDE_DIR was my fault, fixed. For now I use this variable as a recommendation, i.e. if there is no lua.h with compatible version in this dir, search will be continue in another dirs and in case of success this variable will be changed. Sorry for delay. 2016-05-09 16:32 GMT+03:00 Brad King : > On 05/06/2016 09:02 AM, ivan Ivanov wrote: > > Fix for https://cmake.org/Bug/view.php?id=15756 > > Thanks for working on this. > > Please split the patch to first perform refactoring like moving > the version extraction into a helper function. Then the actual > logic change will be easier to see in the second commit. Also > please name helper functions as "_lua_...". We might as well > rename the set_lua_version_vars helper while we're at it. > > > + unset(LUA_INCLUDE_PREFIX CACHE) > > + find_path(LUA_INCLUDE_PREFIX ${subdir}/lua.h > > This renames the cache entry from LUA_INCLUDE_DIR to > LUA_INCLUDE_PREFIX and also stops re-using an already-found > or user-provided value. Neither of these follows CMake conventions. > I don't follow why this change is needed. Using version-specific > paths in a normal find_path(LUA_INCLUDE_DIR ...) should be enough. > > Thanks, > -Brad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laurent at mbdsys.com Mon Jun 20 14:49:09 2016 From: laurent at mbdsys.com (laurent) Date: Mon, 20 Jun 2016 20:49:09 +0200 Subject: [cmake-developers] speed up package with mingw on Windows host In-Reply-To: <57680250.9010800@kitware.com> References: <3A90179F-F09C-4B8C-B17D-148E116B048C@mbdsys.com> <57680250.9010800@kitware.com> Message-ID: Let?s make a demonstration by example : // With grep $ objdump -p /c/msys32/mingw32.exe | grep "^[[:blank:]]*DLL Name: " DLL Name: KERNEL32.dll DLL Name: msvcrt.dll DLL Name: USER32.dll // With findstr $ objdump -p /c/msys32/mingw32.exe | findstr "^[[:blank:]]*DLL Name: " DLL Name: KERNEL32.dll DLL Name: msvcrt.dll DLL Name: USER32.dll Outputs are identical. Attached a git patch against current cmake master branch. (I will make later another patch about *GET_PREREQUISITES_ANALYZED_${target}*) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Use-findstr-instead-of-grep-on-Windows-host-in-conjo.patch Type: application/octet-stream Size: 1067 bytes Desc: not available URL: -------------- next part -------------- Laurent > Le 20 juin 2016 ? 16:48, Brad King a ?crit : > > On 06/18/2016 12:10 PM, laurent wrote: >> I would like to share my experience about speed up package with BundleUtilities >> on Windows host using mingw32 env. > > Thanks. Please provide a > > Full Name > > format name for the commit authorship record. > >> - find_program(gp_grep_cmd grep) >> + if(WIN32) >> + find_program(gp_grep_cmd findstr) >> + else() >> + find_program(gp_grep_cmd grep) >> + endif() > > Good. Is `findstr` command-line compatible with `grep` for the use case > in question? > >> + GET_PROPERTY(MyLocalVariable GLOBAL PROPERTY MY_PREREQUISE) >> + list(APPEND analysed ${MyLocalVariable} ${target}) >> + list(REMOVE_DUPLICATES analysed) >> + SET_PROPERTY(GLOBAL PROPERTY MY_PREREQUISE ${analysed}) > > Rather than maintaining and searching a list in CMake code, please try > recording each target in a dedicated variable or property name, e.g. > `GET_PREREQUISITES_ANALYZED_${target}`. > > Thanks, > -Brad > From brad.king at kitware.com Mon Jun 20 14:54:21 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 20 Jun 2016 14:54:21 -0400 Subject: [cmake-developers] speed up package with mingw on Windows host In-Reply-To: References: <3A90179F-F09C-4B8C-B17D-148E116B048C@mbdsys.com> <57680250.9010800@kitware.com> Message-ID: <57683BDD.70901@kitware.com> On 06/20/2016 02:49 PM, laurent wrote: > Let?s make a demonstration by example : Thanks. > Attached a git patch against current cmake master branch. Thanks. Actually I was saying that we would like to record a Full Name as your authorship. Are you: Tarrisse Laurent TARRISSE Laurent Tarrisse LAURENT Laurent Tarrisse Laurent TARRISSE LAURENT Tarrisse ? Thanks, -Brad From brad.king at kitware.com Mon Jun 20 15:09:30 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 20 Jun 2016 15:09:30 -0400 Subject: [cmake-developers] [PATCH] add debug glew to FindGLEW In-Reply-To: References: <5767FB09.2080303@kitware.com> Message-ID: <57683F6A.3040005@kitware.com> On 06/20/2016 10:52 AM, Farbos a wrote: > Here is the patch fixed. Thanks, applied: FindGLEW: Search for debug and release configurations separately https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6087b9e4 -Brad From brad.king at kitware.com Mon Jun 20 15:09:32 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 20 Jun 2016 15:09:32 -0400 Subject: [cmake-developers] proposal of fix for FindLua In-Reply-To: References: <57309165.9020907@kitware.com> Message-ID: <57683F6C.5020807@kitware.com> On 06/20/2016 02:02 PM, ivan Ivanov wrote: > Fixed, please review it again Thanks, applied: FindLua: Prefix private APIs with `_lua_` https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=92c67b9f FindLua: Factor out a helper function for version extraction https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=281c707b FindLua: Check header file against suitable versions https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3532cbce FindLua: Iterate through all include subdirs to find a suitable header https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eecd307e -Brad From brad.king at kitware.com Mon Jun 20 16:11:07 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 20 Jun 2016 16:11:07 -0400 Subject: [cmake-developers] Dogfooding: clang-tidy, include-what-you-use, link-what-you-use In-Reply-To: <575EC035.1070701@kitware.com> References: <575EC035.1070701@kitware.com> Message-ID: <57684DDB.50105@kitware.com> On 06/13/2016 10:16 AM, Brad King wrote: > On 06/12/2016 05:47 PM, Daniel Pfeifer wrote: >> I have set up a dashboard build where all three mechanisms are enabled: Thanks. It looks like you have a Continuous build for this. That will be nice in the future but for now it is not useful until the build is green for `master`. Please switch back to having an Experimental build instead while we get the rest of the current warnings fixed. FYI, I had to revert your attempt at fixing the stdint.h inclusion order from `next`: cmStandardLexer: #include https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=64157fa5 Revert "cmStandardLexer: #include " https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=93627769 Unfortunately the flex-generated output includes several headers before any content that comes from the input file. That means we will have to edit the generated source files to add the include of cm_kwiml.h (and perhaps cmConfigure.h). There is a comment block in the .in files that explains the modifications we already do to the generated output, so there is precedent for it. If you can get the headers added in the right place I can look at updating the instructions in the comment blocks. >> Who wants to resolve the link-what-you-use violations? > > Currently that infrastructure hasn't even reached 'master' yet. The link-what-you-use feature is now in `master`. -Brad From laurent at mbdsys.com Mon Jun 20 17:05:11 2016 From: laurent at mbdsys.com (laurent) Date: Mon, 20 Jun 2016 23:05:11 +0200 Subject: [cmake-developers] speed up package with mingw on Windows host In-Reply-To: <57683BDD.70901@kitware.com> References: <3A90179F-F09C-4B8C-B17D-148E116B048C@mbdsys.com> <57680250.9010800@kitware.com> <57683BDD.70901@kitware.com> Message-ID: I prefer : Laurent Tarrisse Could you make the correction by yourself or do I need to re-send my patch with correct full name ? I wonder if my next patch will not break packing with multi package ? I mean dependencies will be marked as *analysed* at global scope. Is cpack able to pack 2 binaries at the same time ? Maybe i could suffix GET_PREREQUISITES_ANALYZED with something unique to the current main target (get_prerequisites has an argument called exepath ) Do you have some advices ? Current patch state : diff --git a/Modules/GetPrerequisites.cmake b/Modules/GetPrerequisites.cmake index 1981040..9c5dfbc 100644 --- a/Modules/GetPrerequisites.cmake +++ b/Modules/GetPrerequisites.cmake @@ -944,10 +944,15 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa list(SORT ${prerequisites_var}) endif() if(${recurse}) - set(more_inputs ${unseen_prereqs}) - foreach(input ${more_inputs}) - get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} ${recurse} "${exepath}" "${dirs}" "${rpaths}") - endforeach() + if(NOT GET_PREREQUISITES_ANALYZED_${target}) + set(GET_PREREQUISITES_ANALYZED_${target} True CACHE BOOL "GET_PREREQUISITES_ANALYSED_${target}") + set(more_inputs ${unseen_prereqs}) + foreach(input ${more_inputs}) + if(NOT GET_PREREQUISITES_ANALYZED_${input}) + get_prerequisites("${input}" ${prerequisites_var} ${exclude_system} ${recurse} "${exepath}" "${dirs}" "${rpaths}") + endif() + endforeach() + endif() endif() set(${prerequisites_var} ${${prerequisites_var}} PARENT_SCOPE) > Le 20 juin 2016 ? 20:54, Brad King a ?crit : > > On 06/20/2016 02:49 PM, laurent wrote: >> Let?s make a demonstration by example : > > Thanks. > >> Attached a git patch against current cmake master branch. > > Thanks. Actually I was saying that we would like to record a > Full Name as your authorship. Are you: > > Tarrisse Laurent > TARRISSE Laurent > Tarrisse LAURENT > > Laurent Tarrisse > Laurent TARRISSE > LAURENT Tarrisse > > ? > > 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 From steveire at gmail.com Mon Jun 20 17:10:02 2016 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 20 Jun 2016 23:10:02 +0200 Subject: [cmake-developers] CMake 32 and 64 bit packages on Windows References: <5767FB1F.6080101@kitware.com> Message-ID: Brad King wrote: > MSI > takes care of reversing effects of the removed installation, so that > may have removed it from your PATH. Hmm, the steps I took were: * Uninstall my pre-existing CMake 3.1 installation * Install the CMake 3.5 32 bit package ** At this point everything worked on the command line. Maybe MSI added the correct directory to the PATH. * Install the CMake 3.6 RC 64 bit package ** This may have caused MSI to remove the CMake 3.5 installation and to reverse the PATH manipulation for CMake 3.5. ** The install location for CMake 3.6 RC 64 bit was not added to my PATH? * Install the CMake 3.6 RC 32 bit package ** This added the correct directory to my PATH, so I could use it in the command line environment. Even if I look at it this way, there still seems to be a bug somewhere. If no one can reproduce this, then I may have somehow made a mistake in the installation. Thanks, Steve. From steveire at gmail.com Mon Jun 20 17:11:36 2016 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 20 Jun 2016 23:11:36 +0200 Subject: [cmake-developers] How to set startup project in Visual Studio References: <1a4a94a3-eb3e-f612-4ae7-fc1b758c8a0d@mikedld.com> Message-ID: J Decker wrote: > The setting is in a different file that's .vcproj.user (or .user.vcproj) And there is not one of these for each project() command? It seems to me that this should either be a GLOBAL property, or the documentation which directory to set the DIRECTORY property on. I have no idea what the answer is. Thanks, Steve. From ben.boeckel at kitware.com Mon Jun 20 17:40:38 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 20 Jun 2016 17:40:38 -0400 Subject: [cmake-developers] speed up package with mingw on Windows host In-Reply-To: References: <3A90179F-F09C-4B8C-B17D-148E116B048C@mbdsys.com> <57680250.9010800@kitware.com> <57683BDD.70901@kitware.com> Message-ID: <20160620214038.GB1266@megas.kitware.com> On Mon, Jun 20, 2016 at 23:05:11 +0200, laurent wrote: > I mean dependencies will be marked as *analysed* at global scope. > > Is cpack able to pack 2 binaries at the same time ? Concurrently, no. In a single invokation, yes (though it is still just one package). > Maybe i could suffix GET_PREREQUISITES_ANALYZED with something unique > to the current main target (get_prerequisites has an argument called > exepath ) > > Do you have some advices ? Multiple executables might go into the same package and amortizing looking at common libraries that way would be useful. I think a new keyword to get_prerequisites along the lines of "PACKAGE_GROUP" or something would be useful for those that need such things (with it defaulting to "default" or something). --Ben From laurent at mbdsys.com Mon Jun 20 19:55:45 2016 From: laurent at mbdsys.com (laurent) Date: Tue, 21 Jun 2016 01:55:45 +0200 Subject: [cmake-developers] speed up package with mingw on Windows host In-Reply-To: <20160620214038.GB1266@megas.kitware.com> References: <3A90179F-F09C-4B8C-B17D-148E116B048C@mbdsys.com> <57680250.9010800@kitware.com> <57683BDD.70901@kitware.com> <20160620214038.GB1266@megas.kitware.com> Message-ID: I?m looking at platforms which need rpath rewrite. Maybe I?m wrong but I imagine that the patch will be more complicated (and my knowledge of cpack architecture is limited). Why not activate this optimisation only for mingw32, cause the main problem is cpack with mingw32 is unusable for the moment ? Majority of Windows installers place multiple executables and libraries inside the same folder, so maybe we can forget about *granular* get_prerequisites ? Optimisation should be deactivated by default (this way cpack will have the same behavior as earlier version and will not break previous projects) My 2 cents ... Laurent > Le 20 juin 2016 ? 23:40, Ben Boeckel a ?crit : > > On Mon, Jun 20, 2016 at 23:05:11 +0200, laurent wrote: >> I mean dependencies will be marked as *analysed* at global scope. >> >> Is cpack able to pack 2 binaries at the same time ? > > Concurrently, no. In a single invokation, yes (though it is still just > one package). > >> Maybe i could suffix GET_PREREQUISITES_ANALYZED with something unique >> to the current main target (get_prerequisites has an argument called >> exepath ) >> >> Do you have some advices ? > > Multiple executables might go into the same package and amortizing > looking at common libraries that way would be useful. I think a new > keyword to get_prerequisites along the lines of "PACKAGE_GROUP" or > something would be useful for those that need such things (with it > defaulting to "default" or something). > > --Ben From d3ck0r at gmail.com Mon Jun 20 20:42:02 2016 From: d3ck0r at gmail.com (J Decker) Date: Mon, 20 Jun 2016 17:42:02 -0700 Subject: [cmake-developers] How to set startup project in Visual Studio In-Reply-To: References: <1a4a94a3-eb3e-f612-4ae7-fc1b758c8a0d@mikedld.com> Message-ID: One might be able to use FILE() to generate a .vcxproj.user if( NOT EXISTS ) This is a version from 2012 project. ALL_BUILD.vcxproj.user (it's the default project. so it's the one i usually set, unless something clever along these lines happened.... ) ??? C:\General\Build\karaway\chatment\output\bin\chatment.exe C:\General\Build\karaway\chatment\output\bin WindowsLocalDebugger ------------- That's not even a very large file to write the whole thing.... Another for VS14 ??? C:\General\Build\sack-x64\Debug_out\core\bin\test.json.parser.exe C:\General\Build\sack-x64\Debug_out\core\bin WindowsLocalDebugger ----------- I guess there's some platform settings that will make it bigger, but done in a foreach( target ) writeProjectUser( target ) shouldn't be too painful... On Mon, Jun 20, 2016 at 2:11 PM, Stephen Kelly wrote: > J Decker wrote: > > > The setting is in a different file that's .vcproj.user (or .user.vcproj) > > And there is not one of these for each project() command? > > It seems to me that this should either be a GLOBAL property, or the > documentation which directory to set the DIRECTORY property on. I have no > idea what the answer is. > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From farbos.arnaud at gmail.com Tue Jun 21 04:57:39 2016 From: farbos.arnaud at gmail.com (Farbos a) Date: Tue, 21 Jun 2016 10:57:39 +0200 Subject: [cmake-developers] How can we add Find**** Message-ID: Hi, I was wondering how can we add new Find****.cmake. For examples I don't see any FindTBB, FindJsonCpp ... and I think some of them are used a lot. So my question is, Who decide if we can add new Find*** ? Thanks, -- Arnaud FARBOS From nilsgladitz at gmail.com Tue Jun 21 05:06:09 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 21 Jun 2016 11:06:09 +0200 Subject: [cmake-developers] How can we add Find**** In-Reply-To: References: Message-ID: <57690381.5050701@gmail.com> On 06/21/2016 10:57 AM, Farbos a wrote: > I was wondering how can we add new Find****.cmake. For examples I > don't see any FindTBB, FindJsonCpp ... and I think some of them are > used a lot. > > So my question is, Who decide if we can add new Find*** ? See https://cmake.org/Wiki/CMake:Module_Maintainers Nils From farbos.arnaud at gmail.com Tue Jun 21 05:33:43 2016 From: farbos.arnaud at gmail.com (Farbos a) Date: Tue, 21 Jun 2016 11:33:43 +0200 Subject: [cmake-developers] [PATCH] add debug glew to FindGLEW In-Reply-To: <57683F6A.3040005@kitware.com> References: <5767FB09.2080303@kitware.com> <57683F6A.3040005@kitware.com> Message-ID: I am not sure to understand why you removed GLEW_LIBRARY: -mark_as_advanced(GLEW_INCLUDE_DIR GLEW_LIBRARY) +mark_as_advanced(GLEW_INCLUDE_DIR) 2016-06-20 21:09 GMT+02:00 Brad King : > On 06/20/2016 10:52 AM, Farbos a wrote: >> Here is the patch fixed. > > Thanks, applied: > > FindGLEW: Search for debug and release configurations separately > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6087b9e4 > > -Brad > -- Arnaud FARBOS From brad.king at kitware.com Tue Jun 21 09:36:11 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 21 Jun 2016 09:36:11 -0400 Subject: [cmake-developers] speed up package with mingw on Windows host In-Reply-To: References: <3A90179F-F09C-4B8C-B17D-148E116B048C@mbdsys.com> <57680250.9010800@kitware.com> <57683BDD.70901@kitware.com> Message-ID: <576942CB.9070900@kitware.com> On 06/20/2016 05:05 PM, laurent wrote: > Could you make the correction by yourself or do I need to re-send my > patch with correct full name ? Applied, thanks: GetPrerequisites: Optimize on Windows by filtering `objdump` output https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=867b73e2 -Brad From brad.king at kitware.com Tue Jun 21 09:36:31 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 21 Jun 2016 09:36:31 -0400 Subject: [cmake-developers] [PATCH] add debug glew to FindGLEW In-Reply-To: References: <5767FB09.2080303@kitware.com> <57683F6A.3040005@kitware.com> Message-ID: <576942DF.9070101@kitware.com> On 06/21/2016 05:33 AM, Farbos a wrote: > I am not sure to understand why you removed GLEW_LIBRARY: > > -mark_as_advanced(GLEW_INCLUDE_DIR GLEW_LIBRARY) > +mark_as_advanced(GLEW_INCLUDE_DIR) We no longer define the GLEW_LIBRARY cache entry ourselves, only read it for legacy reasons, so we are not responsible for marking it advanced. See discussion about the same thing in FindFreetype here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/16573/focus=16709 I've updated FindZLIB accordingly: FindZLIB: Do not mark unused variable as advanced https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4bb83514 -Brad From brad.king at kitware.com Tue Jun 21 09:37:36 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 21 Jun 2016 09:37:36 -0400 Subject: [cmake-developers] CMake 32 and 64 bit packages on Windows In-Reply-To: References: <5767FB1F.6080101@kitware.com> Message-ID: <57694320.9050808@kitware.com> On 06/20/2016 05:10 PM, Stephen Kelly wrote: > * Install the CMake 3.6 RC 64 bit package > ** The install location for CMake 3.6 RC 64 bit was not added to my PATH? I just un-installed my 64-bit RC and re-installed it with the option to manipulate the system PATH. At this point the PATH as reported in the Windows system settings dialog contains the proper modification. However, when I start a command prompt through a shortcut (e.g. in the start menu) the prompt does not have the path. If I instead do Start -> Run -> `c:\Windows\system32\cmd.exe` then that prompt gets the PATH with the modification. I logged out and logged back in and then everything gets the proper PATH. Then I un-installed again and had to logout/login again to get the PATH updated for programs launched through shortcuts. > * Install the CMake 3.6 RC 32 bit package > ** This added the correct directory to my PATH I suspect the above may be a problem in Windows with interaction between 64-bit configuration updates and a 32-bit explorer.exe environment running the login session, but I'm not familiar enough with this area of Windows to know. Nils, the installers in question were produced from your WiX installer work (thanks again for that!). Is this something wrong with the 64-bit installer or simply a Windows/MSI subtlety/bug? Thanks, -Brad From brad.king at kitware.com Tue Jun 21 09:37:46 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 21 Jun 2016 09:37:46 -0400 Subject: [cmake-developers] How to set startup project in Visual Studio In-Reply-To: References: <1a4a94a3-eb3e-f612-4ae7-fc1b758c8a0d@mikedld.com> Message-ID: <5769432A.4080809@kitware.com> On 06/20/2016 05:11 PM, Stephen Kelly wrote: > documentation which directory to set the DIRECTORY property on. I've updated the documentation: Help: Clarify VS_STARTUP_PROJECT documentation https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d3e538ea -Brad From nilsgladitz at gmail.com Tue Jun 21 10:01:44 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 21 Jun 2016 16:01:44 +0200 Subject: [cmake-developers] CMake 32 and 64 bit packages on Windows In-Reply-To: <57694320.9050808@kitware.com> References: <5767FB1F.6080101@kitware.com> <57694320.9050808@kitware.com> Message-ID: <576948C8.4050906@gmail.com> On 06/21/2016 03:37 PM, Brad King wrote: > > Nils, the installers in question were produced from your WiX > installer work (thanks again for that!). Is this something wrong > with the 64-bit installer or simply a Windows/MSI subtlety/bug? > > I can't try this out here right now but looking at the windows installer documentation[1] applications should be automatically notified about environment variable changes performed by the .msi by the WM_SETTINGCHANGE message. I am not sure which processes listen and act on the message. Nils [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa372883(v=vs.85).aspx From brad.king at kitware.com Tue Jun 21 10:31:45 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 21 Jun 2016 10:31:45 -0400 Subject: [cmake-developers] Patch: Add the ability to specify SDK_REFERENCES for Visual Studio In-Reply-To: <5768024A.3080204@kitware.com> References: <5768024A.3080204@kitware.com> Message-ID: <57694FD1.9000309@kitware.com> On 06/20/2016 10:48 AM, Brad King wrote: > VS: Add VS_SDK_REFERENCES target property to reference external SDKs > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ccc6270d This caused the VSWinStorePhone tests to fail, e.g.: https://open.cdash.org/testDetails.php?test=457508384&build=4422066 (ResolveSDKReferences target) -> C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(2049,5): error MSB3774: Could not find SDK "Microsoft.NET.Native.Runtime.1.1, Version=1.1". The problem is that the hard-coded VS_SDK_REFERENCES value in the test names a SDK that does not exist on the test machine. Some other approach will be needed to know what SDK can be referenced by the test. Thanks, -Brad From gilles.khouzam at microsoft.com Tue Jun 21 10:33:55 2016 From: gilles.khouzam at microsoft.com (Gilles Khouzam) Date: Tue, 21 Jun 2016 14:33:55 +0000 Subject: [cmake-developers] Patch: Add the ability to specify SDK_REFERENCES for Visual Studio In-Reply-To: <57694FD1.9000309@kitware.com> References: <5768024A.3080204@kitware.com>,<57694FD1.9000309@kitware.com> Message-ID: I'll take a look to find an sdk that is included. Sent from my Windows 10 phone From: Brad King Sent: Tuesday, June 21, 2016 7:31 To: Gilles Khouzam Cc: cmake-developers at cmake.org Subject: Re: Patch: Add the ability to specify SDK_REFERENCES for Visual Studio On 06/20/2016 10:48 AM, Brad King wrote: > VS: Add VS_SDK_REFERENCES target property to reference external SDKs > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ccc6270d This caused the VSWinStorePhone tests to fail, e.g.: https://open.cdash.org/testDetails.php?test=457508384&build=4422066 (ResolveSDKReferences target) -> C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(2049,5): error MSB3774: Could not find SDK "Microsoft.NET.Native.Runtime.1.1, Version=1.1". The problem is that the hard-coded VS_SDK_REFERENCES value in the test names a SDK that does not exist on the test machine. Some other approach will be needed to know what SDK can be referenced by the test. Thanks, -Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruslan_baratov at yahoo.com Tue Jun 21 12:48:20 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Tue, 21 Jun 2016 19:48:20 +0300 Subject: [cmake-developers] [patch] iOS combined, some fixes In-Reply-To: <1ff617d9-99da-aa10-9218-f0de72ac809f@yahoo.com> References: <66aed97f-51c7-5e9b-a823-136c4f7bc765@yahoo.com> <1ff617d9-99da-aa10-9218-f0de72ac809f@yahoo.com> Message-ID: Is the patch applied? Let me know if there are any questions left about it. On 15-Jun-16 23:38, Ruslan Baratov via cmake-developers wrote: > On 15-Jun-16 22:59, Gregor Jasny wrote: >> Hello, >> >> Thanks for the patch! >> >> On 15/06/16 16:41, Ruslan Baratov wrote: >>> Sending some fixes found by testing with Xcode 7.3 >> We were chasing some errors regarding the unified build some time ago. >> But it appeared some for of heisenbug: the more I looked the less likely >> it happened. >> >> Is the error 100% reproducible for you? > Yes - for the Travis VM with xcode7.3 image. Not - for my local machine. > >> And do you know what goes wrong? > Yes, I've leaved a note in the comments section. There are some > messages in error stream, they are not related to lipo location. Here > is example of the log with error: > > CMake Error at > /Users/travis/build/ingenue/hunter/_ci/cmake/share/cmake-3.5/Modules/CMakeIOSInstallCombined.cmake:102 > (message): > Command failed (File name too long): 2016-05-31 18:37:15.058 > xcodebuild[6590:18239] Build settings from command line: > 2016-05-31 18:37:15.059 xcodebuild[6590:18239] TOOLCHAINS = > com.apple.dt.toolchain.XcodeDefault > 2016-05-31 18:37:15.059 xcodebuild[6590:18239] > XCODE_DEFAULT_TOOLCHAIN_OVERRIDE = > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo;-info;/Users/travis/build/ingenue/hunter/_testing/Hunter/_Base/7f9eaa4/f53c868/1c14a4b/Build/GTest/Build/GTest-Release-prefix/src/GTest-Release-build/googlemock/Release-iphonesimulator/libgmock.a > > >> Does the >> >> list(LENGTH _lipo_path len) >> if(NOT len EQUAL 1) >> >> take paths with spaces into account? > Nope as far as I know. In fact it doesn't catch the error I've seen, I > decide to add some sanity checks just to be sure. > > Ruslo > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmtg at hotmail.com Tue Jun 21 14:25:33 2016 From: tmtg at hotmail.com (Thomas Beaudry) Date: Tue, 21 Jun 2016 18:25:33 +0000 Subject: [cmake-developers] can't upgrade cmake 2.8 on CentOS Message-ID: Hi, I am trying to upgrade my cmake 2.8 on CentOS. I have tried unsuccessfully installing both versions 3.4.3 and 3.5.2 (i tried using both the .sh and .tar.gz). After downloading and unzipping, in the root directory I see the following directories: bin doc man share I tried doing a "make && make install" or a "cmake ." but i get the following error: CMake Error: The source directory "/data/opt/cmake/cmake-3.4.3-Linux-x86_64" does not appear to contain CMakeLists.txt. How should i go about upgrading my version of cmake? Thanks In advance! Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Jun 21 14:59:20 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 21 Jun 2016 14:59:20 -0400 Subject: [cmake-developers] can't upgrade cmake 2.8 on CentOS In-Reply-To: References: Message-ID: <57698E88.3070504@kitware.com> On 06/21/2016 02:25 PM, Thomas Beaudry wrote: > in the root directory I see the following directories: > bin doc man share > I tried doing a "make && make install" or a "cmake ." Those are prebuilt binaries. You don't need to build anything. You can run `bin/cmake` right out of the extracted tree. > How should i go about upgrading my version of cmake? If you prefer to build from source you can download `cmake-3.5.2.tar.gz` from the download page where you got the binaries. There is a README.rst file that explains how to build: `./bootstrap && make && make install`. -Brad From chris.bieneman at me.com Tue Jun 21 14:18:51 2016 From: chris.bieneman at me.com (Chris Bieneman) Date: Tue, 21 Jun 2016 11:18:51 -0700 Subject: [cmake-developers] Using a custom DSL compiler in CMake Message-ID: Hello cmake-developers, I?m trying to find a solution to a long running problem in our build. In LLVM we have a domain specific language named TableGen that we use to generate header files used throughout the project. Our current solution to work with this tool in CMake is pretty terrible for a number of reasons. The biggest problem is that we don?t have good dependency handling around the inputs and outputs from the DSL. Some of this is caused by our CMake targets not being granular (which I know how to fix). The harder part is that our DSL supports C-like includes. Our DSL compiler can generate .d files, but hooking that up to CMake is a harder problem. My thought was to try and treat TableGen as a language. There are some complications with that because we don?t actually have a compiler for it at configuration time. Any thoughts and guidance would be greatly appreciated. I feel as if I?m about to fall into a deep and scary rabbit hole. Thanks, -Chris From rleigh at codelibre.net Tue Jun 21 15:43:55 2016 From: rleigh at codelibre.net (Roger Leigh) Date: Tue, 21 Jun 2016 19:43:55 +0000 Subject: [cmake-developers] Using a custom DSL compiler in CMake In-Reply-To: References: Message-ID: On 21/06/2016 18:18, Chris Bieneman wrote: > Hello cmake-developers, > > I?m trying to find a solution to a long running problem in our build. In LLVM we have a domain specific language named TableGen that we use to generate header files used throughout the project. Our current solution to work with this tool in CMake is pretty terrible for a number of reasons. > > The biggest problem is that we don?t have good dependency handling around the inputs and outputs from the DSL. Some of this is caused by our CMake targets not being granular (which I know how to fix). The harder part is that our DSL supports C-like includes. > > Our DSL compiler can generate .d files, but hooking that up to CMake is a harder problem. My thought was to try and treat TableGen as a language. There are some complications with that because we don?t actually have a compiler for it at configuration time. > > Any thoughts and guidance would be greatly appreciated. I feel as if I?m about to fall into a deep and scary rabbit hole. In one of the projects I maintain at work, we generate a lot of different C++ sources and headers using a custom generator tool. It consumes an XML schema, and then processes it to turn that formal data model into a set of C++ classes, enums and serialisation functions, using a series of templates. I needed to make this work seamlessly with CMake, and so I wrote a set of functions to introspect the dependencies and then generate all the necessary targets with appropriate dependencies. While I can't claim this is going to be the best use of CMake in the world, it's quite functional and does its job well. https://github.com/openmicroscopy/bioformats/blob/develop/cpp/cmake/XsdFu.cmake This contains helper macros to do the introspection. We basically run the generator twice for each "target" using --print-generated and --print-depends options. These cause the corresponding files to be dumped to stdout. We then use these file lists as the OUTPUT and DEPENDS lists for add_custom_command. NB. This tool outputs multiple source files at once which all go into the OUTPUT. You can then see those macros in use here: https://github.com/openmicroscopy/bioformats/blob/develop/cpp/lib/ome/xml/CMakeLists.txt#L42 where we then add those outputs to a regular library target. While I think this is too custom to be of direct use, it might be useful for inspiration. The essential point is to introspect the dependencies and outputs as you run cmake (which can emit the includes you mentioned as dependencies), and then use that information to generate the appropriate custom commands. Everything will then be built at build time, in parallel. How you do the introspection is entirely up to you. I added support to the generator itself since it already had the relevant information (it's a python tool) and was quick and easy to add. You could also parse the files directly with cmake, or with a custom script in any language you like. Hope that's at least provided some ideas! Regards, Roger From brad.king at kitware.com Tue Jun 21 16:05:47 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 21 Jun 2016 16:05:47 -0400 Subject: [cmake-developers] Using a custom DSL compiler in CMake In-Reply-To: References: Message-ID: <57699E1B.6090208@kitware.com> On 06/21/2016 02:18 PM, Chris Bieneman wrote: > Our current solution to work with this tool in CMake For reference, a quick look at LLVM's `cmake/modules/TableGen.cmake` indicates that the current solution is based on add_custom_command. > The harder part is that our DSL supports C-like includes. The add_custom_command signature has an IMPLICIT_DEPENDS option for this, but it only works for Makefile generators. > Our DSL compiler can generate .d files, but hooking that up to > CMake is a harder problem. With some work it may be possible to teach our Ninja generator how to consume .d files in custom commands. Perhaps such support could even be extended to the Makefile generators instead of using our approximate scanning implementation. In general implicit dependencies cannot be cleanly supported by the Visual Studio or Xcode generators. Those environments provide no hooks for custom build-time dependency scanning. At best one can have the custom command produce a file as a side effect that can be consumed by CMake on the next run. This would work for all generators but causes lots of CMake re-runs. > My thought was to try and treat TableGen as a language. > There are some complications with that because we don?t > actually have a compiler for it at configuration time. I don't think that is a good approach both because we won't be able to enable the language without the compiler already existing and because custom languages do not work well in the IDE generators (and will have the same dependency scanning problems as above). See above approaches instead. -Brad From chris.bieneman at me.com Tue Jun 21 19:31:55 2016 From: chris.bieneman at me.com (Chris Bieneman) Date: Tue, 21 Jun 2016 16:31:55 -0700 Subject: [cmake-developers] Using a custom DSL compiler in CMake In-Reply-To: <57699E1B.6090208@kitware.com> References: <57699E1B.6090208@kitware.com> Message-ID: <04096F48-F9BE-4C8C-9B3B-A820E7006B2A@me.com> Brad, Thanks for the detailed response. This all makes a lot of sense. I?ll have to stew on this a bit and see where it leads me. In general it sounds to me like there is no easy solution here. Thanks, -Chris > On Jun 21, 2016, at 1:05 PM, Brad King wrote: > > On 06/21/2016 02:18 PM, Chris Bieneman wrote: >> Our current solution to work with this tool in CMake > > For reference, a quick look at LLVM's `cmake/modules/TableGen.cmake` > indicates that the current solution is based on add_custom_command. > >> The harder part is that our DSL supports C-like includes. > > The add_custom_command signature has an IMPLICIT_DEPENDS option > for this, but it only works for Makefile generators. > >> Our DSL compiler can generate .d files, but hooking that up to >> CMake is a harder problem. > > With some work it may be possible to teach our Ninja generator how > to consume .d files in custom commands. Perhaps such support could > even be extended to the Makefile generators instead of using our > approximate scanning implementation. > > In general implicit dependencies cannot be cleanly supported by > the Visual Studio or Xcode generators. Those environments provide > no hooks for custom build-time dependency scanning. At best one > can have the custom command produce a file as a side effect that > can be consumed by CMake on the next run. This would work for > all generators but causes lots of CMake re-runs. > >> My thought was to try and treat TableGen as a language. >> There are some complications with that because we don?t >> actually have a compiler for it at configuration time. > > I don't think that is a good approach both because we won't > be able to enable the language without the compiler already > existing and because custom languages do not work well in > the IDE generators (and will have the same dependency scanning > problems as above). See above approaches instead. > > -Brad > From gilles.khouzam at microsoft.com Tue Jun 21 21:25:08 2016 From: gilles.khouzam at microsoft.com (Gilles Khouzam) Date: Wed, 22 Jun 2016 01:25:08 +0000 Subject: [cmake-developers] Patch: Add the ability to specify SDK_REFERENCES for Visual Studio In-Reply-To: <57694FD1.9000309@kitware.com> References: <5768024A.3080204@kitware.com> <57694FD1.9000309@kitware.com> Message-ID: I've changed it to the Debug Universal C-Runtime which should be included with the SDK. This also leverages the version of the SDK to match the other extensions reducing the risk of failures. -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Tuesday, June 21, 2016 07:32 To: Gilles Khouzam Cc: cmake-developers at cmake.org Subject: Re: Patch: Add the ability to specify SDK_REFERENCES for Visual Studio On 06/20/2016 10:48 AM, Brad King wrote: > VS: Add VS_SDK_REFERENCES target property to reference external SDKs > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ccc6270d This caused the VSWinStorePhone tests to fail, e.g.: https://open.cdash.org/testDetails.php?test=457508384&build=4422066 (ResolveSDKReferences target) -> C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(2049,5): error MSB3774: Could not find SDK "Microsoft.NET.Native.Runtime.1.1, Version=1.1". The problem is that the hard-coded VS_SDK_REFERENCES value in the test names a SDK that does not exist on the test machine. Some other approach will be needed to know what SDK can be referenced by the test. Thanks, -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-FixVS_SDK_REFERENCES.PATCH Type: application/octet-stream Size: 1116 bytes Desc: 0001-FixVS_SDK_REFERENCES.PATCH URL: From farbos.arnaud at gmail.com Wed Jun 22 08:11:49 2016 From: farbos.arnaud at gmail.com (Farbos a) Date: Wed, 22 Jun 2016 14:11:49 +0200 Subject: [cmake-developers] handling components in Find**** Message-ID: Hi, I am trying to write a Find module with components and I am not sure of how it should be written. I attached the find module, Could someone tell me if I did it well? Thanks, -- Arnaud FARBOS -------------- next part -------------- A non-text attachment was scrubbed... Name: FindILMBase.cmake Type: application/octet-stream Size: 2911 bytes Desc: not available URL: From brad.king at kitware.com Wed Jun 22 08:36:31 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 22 Jun 2016 08:36:31 -0400 Subject: [cmake-developers] Patch: Add the ability to specify SDK_REFERENCES for Visual Studio In-Reply-To: References: <5768024A.3080204@kitware.com> <57694FD1.9000309@kitware.com> Message-ID: <576A864F.5050702@kitware.com> On 06/21/2016 09:25 PM, Gilles Khouzam wrote: > I've changed it to the Debug Universal C-Runtime > > This also leverages the version of the SDK to match the other > extensions reducing the risk of failures. Thanks, I've squashed that fixup in: VS: Add VS_SDK_REFERENCES target property to reference external SDKs https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=35a6cac2 -Brad From roman.wueger at gmx.at Wed Jun 22 11:22:02 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Wed, 22 Jun 2016 17:22:02 +0200 Subject: [cmake-developers] [iOS] What is the correct way to add resources to an XCode project Message-ID: <21D325C1-601B-4393-8BBB-7D82B36456E7@gmx.at> Hello, I read the mailing list but did find a way which works. At the moment I use Xcode 7.3.1 and CMake 3.5.2 which creates a project for iOS 9.3. All I want is to add the directory "Images.xcassets" and a second directory structure to be copied to the Resource folder listed in XCode. When I manually drag'n drop the directories into the Resource folder as reference or as group everything is working. How can I archive this with CMake? Thanks and regards Roman From robert.maynard at kitware.com Wed Jun 22 15:13:10 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 22 Jun 2016 15:13:10 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.6.0-rc3 now ready for testing! Message-ID: I am proud to announce the third CMake 3.6 release candidate. Sources and binaries are available at: https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.6 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.6/release/3.6.html Some of the more significant features of CMake 3.6 are: * The "Visual Studio 14 2015" generator learned to support the Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This feature is experimental. * The "list()" command gained a "FILTER" sub-command to filter list elements by regular expression. * A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally tell the "try_compile()" command to build a static library instead of an executable. This is useful for cross-compiling toolchains that cannot link binaries without custom flags or scripts. * A "_CLANG_TIDY" target property and supporting "CMAKE__CLANG_TIDY" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "clang-tidy" along with the compiler for "C" and "CXX" languages. * The "ExternalProject" module leared the "GIT_SHALLOW 1" option to perform a shallow clone of a Git repository. * The "ExternalProject" module learned to initialize Git submodules recursively and also to initialize new submodules on updates. Use the "GIT_SUBMODULES" option to restrict which submodules are initalized and updated. * The "InstallRequiredSystemLibraries" module learned a new "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment of the Windows Universal CRT libraries with Visual Studio 2015. * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX platforms. Deprecated and Removed Features =============================== * The "CMakeForceCompiler" module and its macros are now deprecated. See module documentation for an explanation. * The "Visual Studio 7 .NET 2003" generator is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 7" generator (for VS .NET 2002) has been removed. It had been deprecated since CMake 3.3. * The "Visual Studio 6" generator has been removed. It had been deprecated since CMake 3.3. CMake 3.6 Release Notes *********************** Changes made since CMake 3.5 include the following. New Features ============ Generators ---------- * The "Ninja" generator learned to produce phony targets of the form "sub/dir/all" to drive the build of a subdirectory. This is equivalent to "cd sub/dir; make all" with Makefile Generators. * The "Ninja" generator now includes system header files in build dependencies to ensure correct re-builds when system packages are updated. * The "Visual Studio 14 2015" generator learned to support the Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This feature is experimental. Commands -------- * The "add_custom_command()" and "add_custom_target()" commands learned how to use the "CROSSCOMPILING_EMULATOR" executable target property. * The "install()" command learned a new "EXCLUDE_FROM_ALL" option to leave installation rules out of the default installation. * The "list()" command gained a "FILTER" sub-command to filter list elements by regular expression. * The "string(TIMESTAMP)" and "file(TIMESTAMP)" commands gained support for the "%s" placeholder. This is the number of seconds since the UNIX Epoch. * The "try_compile()" command source file signature now honors configuration-specific flags (e.g. "CMAKE__FLAGS_DEBUG") in the generated test project. Previously only the default such flags for the current toolchain were used. Variables --------- * A "CMAKE_DEPENDS_IN_PROJECT_ONLY" variable was introduced to tell Makefile Generators to limit dependency scanning only to files in the project source and build trees. * A new "CMAKE_HOST_SOLARIS" variable was introduced to indicate when CMake is running on an Oracle Solaris host. * A "CMAKE__STANDARD_INCLUDE_DIRECTORIES" variable was added for use by toolchain files to specify system include directories to be appended to all compiler command lines. * The "CMAKE__STANDARD_LIBRARIES" variable is now documented. It is intended for use by toolchain files to specify system libraries to be added to all linker command lines. * A "CMAKE_NINJA_OUTPUT_PATH_PREFIX" variable was introduced to tell the "Ninja" generator to configure the generated "build.ninja" file for use as a "subninja". * A "CMAKE_TRY_COMPILE_PLATFORM_VARIABLES" variable was added for use by toolchain files to specify platform-specific variables that must be propagated by the "try_compile()" command into test projects. * A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally tell the "try_compile()" command to build a static library instead of an executable. This is useful for cross-compiling toolchains that cannot link binaries without custom flags or scripts. Properties ---------- * A "DEPLOYMENT_REMOTE_DIRECTORY" target property was introduced to tell the "Visual Studio 9 2008" and "Visual Studio 8 2005" generators to generate the "remote directory" for WinCE project deployment and debugger settings. * A "_CLANG_TIDY" target property and supporting "CMAKE__CLANG_TIDY" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "clang-tidy" along with the compiler for "C" and "CXX" languages. * A "TIMEOUT_AFTER_MATCH" test property was introduced to optionally tell CTest to enforce a secondary timeout after matching certain output from a test. * A "VS_CONFIGURATION_TYPE" target property was introduced to specify a custom project file type for Visual Studio Generators supporting VS 2010 and above. * A "VS_STARTUP_PROJECT" directory property was introduced to specify for Visual Studio Generators the default startup project for generated solutions (".sln" files). Modules ------- * The "CMakePushCheckState" module now pushes/pops/resets the variable "CMAKE_EXTRA_INCLUDE_FILE" used in "CheckTypeSize". * The "ExternalProject" module leared the "GIT_SHALLOW 1" option to perform a shallow clone of a Git repository. * The "ExternalProject" module learned to initialize Git submodules recursively and also to initialize new submodules on updates. Use the "GIT_SUBMODULES" option to restrict which submodules are initalized and updated. * The "ExternalProject" module leared the "DOWNLOAD_NO_EXTRACT 1" argument to skip extracting the file that is downloaded (e.g., for self-extracting shell installers or ".msi" files). * The "ExternalProject" module now uses "TLS_VERIFY" when fetching from git repositories. * The "FindBLAS" and "FindLAPACK" modules learned to support OpenBLAS. * The "FindCUDA" module learned to find the "cublas_device" library. * The "FindGTest" module "gtest_add_tests" function now causes CMake to automatically re-run when test sources change so that they can be re-scanned. * The "FindLTTngUST" module was introduced to find the LTTng-UST library. * The "FindPkgConfig" module learned to optionally create imported targets for the libraries it has found. * The "FindProtobuf" module learned to provide a "Protobuf_VERSION" variable and check the version number requested in a "find_package()" call. * The "InstallRequiredSystemLibraries" module learned a new "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment of the Windows Universal CRT libraries with Visual Studio 2015. Platforms --------- * The Clang compiler is now supported on CYGWIN. * Support was added for the Bruce C Compiler with compiler id "Bruce". CTest ----- * The "ctest_update()" command now looks at the "CTEST_GIT_INIT_SUBMODULES" variable to determine whether submodules should be updated or not before updating. * The "ctest_update()" command will now synchronize submodules on an update. Updates which add submodules or change a submodule's URL will now be pulled properly. CPack ----- * The "CPackDeb" module learned how to handle "$ORIGIN" in "CMAKE_INSTALL_RPATH" when "CPACK_DEBIAN_PACKAGE_SHLIBDEPS" is used for dependency auto detection. * The "CPackDeb" module learned how to generate "DEBIAN/shlibs" contorl file when package contains shared libraries. * The "CPackDeb" module learned how to generate "DEBIAN/postinst" and "DEBIAN/postrm" files if the package installs libraries in ldconfig- controlled locations (e.g. "/lib/", "/usr/lib/"). * The "CPackDeb" module learned how to generate dependencies between Debian packages if multi-component setup is used and "CPACK_COMPONENT__DEPENDS" variables are set. For backward compatibility this feature is disabled by default. See "CPACK_DEBIAN_ENABLE_COMPONENT_DEPENDS". * The "CPackDeb" module learned how to set custom package file names including how to generate properly-named Debian packages: _-_.deb For backward compatibility this feature is disabled by default. See "CPACK_DEBIAN_FILE_NAME" and "CPACK_DEBIAN__FILE_NAME". * The "CPackDeb" module learned how to set the package release number ("DebianRevisionNumber" in package file name when used in combination with "DEB-DEFAULT" value set by "CPACK_DEBIAN_FILE_NAME"). See "CPACK_DEBIAN_PACKAGE_RELEASE". * The "CPackDeb" module learned how to set the package architecture per-component. See "CPACK_DEBIAN__PACKAGE_ARCHITECTURE". * The "CPackDMG" module learned a new option to tell the CPack "DragNDrop" generaor to skip the "/Applications" symlink. See the "CPACK_DMG_DISABLE_APPLICATIONS_SYMLINK" variable. * The "CPackIFW" module gained a new "cpack_ifw_update_repository()" command to update a QtIFW-specific repository from a remote repository. * The "CPackRPM" module learned how to set RPM "dist" tag as part of RPM "Release:" tag when enabled (mandatory on some Linux distributions for e.g. on Fedora). See "CPACK_RPM_PACKAGE_RELEASE_DIST". * The "CPackRPM" module learned how to set default values for owning user/group and file/directory permissions of package content. See "CPACK_RPM_DEFAULT_USER", "CPACK_RPM_DEFAULT_GROUP", "CPACK_RPM_DEFAULT_FILE_PERMISSIONS", "CPACK_RPM_DEFAULT_DIR_PERMISSIONS" and their per component counterparts. * The "CPackRPM" module learned how to set user defined package file names, how to specify that rpmbuild should decide on file name format as well as handling of multiple rpm packages generated by a single user defined spec file. See "CPACK_RPM_PACKAGE_NAME" and "CPACK_RPM__PACKAGE_NAME". * The "CPackRPM" module learned how to correctly handle symlinks that are pointing outside generated packages. Other ----- * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX platforms. Deprecated and Removed Features =============================== * The "CMakeForceCompiler" module and its macros are now deprecated. See module documentation for an explanation. * The "find_library()", "find_path()", and "find_file()" commands no longer search in installation prefixes derived from the "PATH" environment variable on non-Windows platforms. This behavior was added in CMake 3.3 to support Windows hosts but has proven problematic on UNIX hosts. Users that keep some "/bin" directories in the "PATH" just for their tools do not necessarily want any supporting "/lib" directories searched. One may set the "CMAKE_PREFIX_PATH" environment variable with a ;-list of prefixes that are to be searched. * The "Visual Studio 7 .NET 2003" generator is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 7" generator (for VS .NET 2002) has been removed. It had been deprecated since CMake 3.3. * The "Visual Studio 6" generator has been removed. It had been deprecated since CMake 3.3. Other Changes ============= * The precompiled OS X binary provided on "cmake.org" now requires OS X 10.7 or newer. * On Linux and FreeBSD platforms, when building CMake itself from source and not using a system-provided libcurl, OpenSSL is now used by default if it is found on the system. This enables SSL/TLS support for commands supporting network communication via "https", such as "file(DOWNLOAD)", "file(UPLOAD)", and "ctest_submit()". * The "cmake(1)" "--build" command-line tool now rejects multiple "-- target" options with an error instead of silently ignoring all but the last one. * "AUTOMOC" now diagnoses name collisions when multiple source files in different directories use "#include " with the same name (because the generated "moc_foo.cpp" files would collide). * The "FindBISON" module "BISON_TARGET" macro now supports special characters by passing the "VERBATIM" option to internal "add_custom_command()" calls. This may break clients that added escaping manually to work around the bug. * The "FindFLEX" module "FLEX_TARGET" macro now supports special characters by passing the "VERBATIM" option to internal "add_custom_command()" calls. This may break clients that added escaping manually to work around the bug. * The "FindProtobuf" module input and output variables were all renamed from "PROTOBUF_" to "Protobuf_" for consistency with other find modules. Input variables of the old case will be honored if provided, and output variables of the old case are always provided. * The "CPackRPM" module now supports upper cased component names in per component CPackRPM specific variables. E.g. component named "foo" now expects component specific variable to be "CPACK_RPM_FOO_PACKAGE_NAME" while before it expected "CPACK_RPM_foo_PACKAGE_NAME". Upper cased component name part in variables is compatible with convention used for other CPack variables. For back compatibility old format of variables is still valid and preferred if both versions of variable are set, but the preferred future use is upper cased component names in variables. New variables that will be added to CPackRPM in later versions will only support upper cased component variable format. ---------------------------------------------------------------------------- Changes made since CMake 3.6.0-rc2: Brad King (5): VS: Fix regressed mapping for the cl `/Os` compiler flag README: Update Issue Tracker link to new location FindQt4: Document Qt4::QtDeclarative imported target (#16157) Help: Clarify VS_STARTUP_PROJECT documentation CMake 3.6.0-rc3 Domen Vrankar (2): CPack/Deb: Fix tests for SELinux-enabled systems CPack/Deb: Fix test to actually test the preinst script LibArchive Upstream (1): LibArchive 2016-06-19 (139d0576) Rolf Eike Beer (1): FindPkgConfig: define the imported targets also when the data comes from cache Tobias Hunger (1): cmExtraCodeBlocksGenerator: Do not shuffle include directories From steveire at gmail.com Wed Jun 22 16:45:26 2016 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 22 Jun 2016 22:45:26 +0200 Subject: [cmake-developers] How to set startup project in Visual Studio References: <1a4a94a3-eb3e-f612-4ae7-fc1b758c8a0d@mikedld.com> <5769432A.4080809@kitware.com> Message-ID: Brad King wrote: > On 06/20/2016 05:11 PM, Stephen Kelly wrote: >> documentation which directory to set the DIRECTORY property on. > > I've updated the documentation: > > Help: Clarify VS_STARTUP_PROJECT documentation > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d3e538ea Thanks! From steveire at gmail.com Wed Jun 22 16:46:12 2016 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 22 Jun 2016 22:46:12 +0200 Subject: [cmake-developers] CMake 32 and 64 bit packages on Windows References: <5767FB1F.6080101@kitware.com> <57694320.9050808@kitware.com> Message-ID: Brad King wrote: > I logged out and logged back in and > then everything gets the proper PATH. > > Then I un-installed again and had to logout/login again to get the > PATH updated for programs launched through shortcuts. Hmm, I didn't do any logging out or in. Maybe that was the cause. Thanks, Steve. From ben.boeckel at kitware.com Wed Jun 22 17:22:20 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 22 Jun 2016 17:22:20 -0400 Subject: [cmake-developers] Using a custom DSL compiler in CMake In-Reply-To: <57699E1B.6090208@kitware.com> References: <57699E1B.6090208@kitware.com> Message-ID: <20160622212220.GA5271@megas.kitware.com> On Tue, Jun 21, 2016 at 16:05:47 -0400, Brad King wrote: > On 06/21/2016 02:18 PM, Chris Bieneman wrote: > > Our DSL compiler can generate .d files, but hooking that up to > > CMake is a harder problem. > > With some work it may be possible to teach our Ninja generator how > to consume .d files in custom commands. Perhaps such support could > even be extended to the Makefile generators instead of using our > approximate scanning implementation. Here's the relevant issue for Ninja: https://gitlab.kitware.com/cmake/cmake/issues/15479 --Ben From mdrahos at aurisrobotics.com Wed Jun 22 20:08:04 2016 From: mdrahos at aurisrobotics.com (Miroslav Drahos) Date: Thu, 23 Jun 2016 00:08:04 +0000 Subject: [cmake-developers] patch for FindProtobuf.cmake Message-ID: Folks, I believe I found a bug in FindProtobuf.cmake. Using set with two parameters will insert an unwanted semicolon, the list separator. The changes I made are like this (several occurrences): - set(_protobuf_include_path -I ${CMAKE_CURRENT_SOURCE_DIR}) + set(_protobuf_include_path "-I${CMAKE_CURRENT_SOURCE_DIR}") I also added a test for FindProtobuf.cmake, which is a new addition. The complete patch is attached. What I cannot figure out is how to run the test? When I configure cmake build, I don't see an option to set the path to protobuf. The test doesn't show up in `ctest -N` result. Cheers, Miro -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Removing-semicolon-in-FindProtobuf.cmake-and-adding-.patch Type: application/octet-stream Size: 5021 bytes Desc: 0001-Removing-semicolon-in-FindProtobuf.cmake-and-adding-.patch URL: From Tobias.Hunger at qt.io Thu Jun 23 08:27:22 2016 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Thu, 23 Jun 2016 12:27:22 +0000 Subject: [cmake-developers] daemon-mode meeting last Tuesday Message-ID: <1466684840.811.269.camel@qt.io> Hello CMake Developers, Stephen Kelly and me met last Tuesday to talk about the daemon-mode patch we both have been working on. It was a very productive meeting: We managed to resolve almost all the differences of opinion we had. Here is a short summary of what we talked about: 0) General ? * We both want a daemon mode:-) ?? ? * Some names could be improved. Suggestions welcome. ?? ? * Having cmMessanger would be nice and will make things easier. ?? ? * We agreed that we should get the basic infrastructure part reviewed first, ????followed by the functionality up to the project structure (codemodel). ???? ? * We both think it only makes sense to merge the infrastructure part into ????cmake (if it passes review first of course) once we have some functionality ????that is genuinely useful. So we want to aim at having the infrastructure ????and the codemodel merged in one go. 1) Infrastructure: ? 1.1 Communication: ?? ? * Clients should talk to daemon mode via a socket (libuv supports that),? ????but we also want to support stdin/stdout at least for a "debug mode" ?????* There should be a separate command line switch to start stdin/out mode ???????and for socket mode ?????* This is needed before it makes sense to merge the patch set. ? 1.2 Protocol versions ? * We need the daemon-mode to support different protocol versions. These ????need to be versioned independently of the cmake binary itself and we will ????try to keep the protocol versions working as long as that is reasonable, ????but would try to support them for at least a year or two (if there ????are no overriding concerns). ???? ? * We want to have the option to mark protocol versions as experimental. ????Experimental protocol versions come with *NO* guarantees and can change ????*AT ANY TIME*. If a experimental protocol ends up in a cmake release there ????still are no guarantees. I would like to see experimental protocol versions ? ? in cmake releases, since that makes it really easy for other parties to ? ? evaluate changes. In my experience hardly anybody builds custom branches:-/ ???? ? ? All this would need to be communicated by cmake e.g. in the release notes. ? 1.3 Basic Protocol ?? ? * Client/daemon talk via JSON messages. ?? ? * All messages have a "type" with a string specifying the type of message. ?? ? * We (mostly) have a request/reply model. The client sends a request message ????and will receive a reply or an error. ?? ? * Requests contain a type, and an optional cookie (which will be returned ????together with any message sent by the daemon in response to the request). ????A cookie can be any JSON object. ???? ? * A reply is a JSON message of type "reply". It contains the cookie of its ????request and any data that the daemon wants to send its client. ???? ? * An error is a JSON message of type "error". It contains the cookie of its ????request and an "errorMessage". ???? ? * There are more JSON messages for progress information and messages, etc. and ????we can add more as needed. ?? ? TO DECIDE: ?? ? * Currently a reply (and error and all other messages in response to a ????request) contain a "inReplyTo" with the type string from the request ????triggering the reply. ???? ????Stephen thinks that is not necessary and argues anything that is not ????strictly necessary should not be in the first version of the protocol. ???? ????I like having this as it makes it helps to identify what a reply/error is ????related to. I often paste a whole string of requests into the daemon and ????if there is an error it is really easy to see how for things got. ???? ? * Should we have a split between header (cookie/type/inReplyTo) and data? ?? ????Stephen suggested passing all data that is from/for the client in a ????"body" attribute to make messages more uniform. ???? ????I think that is just adding one more level into the JSON file for no ????real benefit. ???? 2) Basic Command Set ? 2.1) Reset (Reset to a state right after daemon start) ?? ? * Remove this. This is error prone as data structures may not be cleaned out ????properly. ???? ? 2.2) globalSettings (Query generators, debug flags, etc.) ?? ? * Move generators and other static information into a separate cmake ????commandline invocation (http://public.kitware.com/Bug/view.php?id=15462): ???? ????* Generators with information on them ????* CMake version information ????* Module path ????* Daemon mode support ???? ????all should be available in a machine readable way from that command. ???? ????TODO: Figure out how to get all the generator information, e.g. which values ????the flags some generator taken can have (architecture, etc.). Stephen ????volunteered to check into this. ???? ? * We can report the selected generator/extragenerator here. ?? ? * Undecided about whether it makes sense to report source/builddirectory here ???? ? 2.3) setGlobalSettings (set the information from globalSettings) ?? ? * This is currently used to set sourcedirectory, builddirectory and ????generator. ???? ????These three should be passed in via the command line instead, again ????to avoid trouble with users switching to different build directories/etc. ????while the daemon is running, which might trigger problems with state ????cleanup, etc. ???? ? * The rest (trigger developer warnings, etc.) seems fine. ?? ? * Generator/build- and sourcedirectory may not be set (even if reported ????via globalSettings). Extragenerator can be set. ?? ? 2.4) configure (Trigger cmake to configure a builddirectory) ?? ? * Fine, handles "-DSOMETHING=other", etc. via normal cmake commandline ????parsing. ???? ? TODO: Validate that it handles broken input with decent error reporting. ?? ? 2.5) generate ?? ? * Rename this to "compute", which is what this actually triggers in cmake. ?? ? 2.6) project (Return project structure) ?? ? * add backtrace information to targets ?? ? * Rename to "codemodel" to make the use-case for the data more clear. ?? ? * Focus on providing data for the use-case of feeding a code model. ?? ? * Make the configuration the top-level, then report projects, targets and ????files (in groups) beneath that. Currently projects are the top level, then ????there is configurations, targets and files. ???? ????Switching this around should offer more flexibility to change cmake ????internals going forward. ???? ? * We do not want cmake internals to leak into the output. So do not report ????cmake features, etc. ???? ? * We try to minimize the assumptions of cmake internals in the implemention ????to allow cmake room to innovate without breaking changes to this. ???? ? * Policies should not be visible at this level and do not need to be exposed ????to clients. ???? ? FUTURE WORK: ?? ? Stephen and I did not agree on how to handle other but similar use-cases that ? need similar information as to what is in this view and we will need to ? revisit this topic as new use-cases will get added in the future: ?? ? Stephen prefers having special commands for each use-case, returning output ? tailored to that use-case. ?? ? I would prefer having one command to gather the complete state of the ? project structure and then allow the user to limit what is returned from this ? command (e.g. only show one configuration/target/types of targets/etc. and ? options to filter out e.g. backtraces from the data that is returned). ?? ? Stephens approach has the advantage that it is easier to use and more ? predictable what is returned. My approach allows client authors more ? flexibility as to which information they need without having to ask ? cmake developers to add a new command/change an existing one. ?? ? But this is for the future: For the first iteration we want to concentrate on ? data relevant to feeding a code model. ? TODO: ?? ? * Figure out whether a PDB file is actually going to be build. Currently ????the PDB file is added to the list of artifacts whenever there is a .lib ????file, which is probably wrong. Brad: Do you have an idea how to ????get this information? ? 2.7 cache (report contents of CMakeCache.txt file) ?? ? * Review by other potential users would be appreciated, but no obvious ????problems seen. ?? ? 2.8 buildsystem (return cmake files) ?? ? * Return a list of cmake files (CMakeLists.txt, etc.) in different categories ????(in source directory/in build directory/in the system). ???? ? * Stephen suggested to rename this to "cmake_rerun_depends". I am not sure ????that name is much better than what is currently used. ???? 3.0 Features from Stephen's branch that need porting ???We only skimmed this, as many of his highlights need refactoring in cmake ???to land first. ???3.1 parse ??? ???* This duplicates the parser and will need some refactoring. ??? ??? Status Information: I started to add some tasks to github to track what needs to be done before proposing the daemon-mode branch for release. This can be viewed here: https://github.com/hunger/CMake/issues Best Regards, Tobias -- Tobias Hunger,?Senior?Software Engineer?| The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From brad.king at kitware.com Thu Jun 23 10:31:12 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 23 Jun 2016 10:31:12 -0400 Subject: [cmake-developers] handling components in Find**** In-Reply-To: References: Message-ID: <576BF2B0.5040603@kitware.com> On 06/22/2016 08:11 AM, Farbos a wrote: > I am trying to write a Find module with components and I am not sure > of how it should be written. > I attached the find module, Could someone tell me if I did it well? It looks okay to me from a quick glance. Side note: For variables private to the module I suggest using a prefix like `_IlmBase_` to make it clear to readers that they are not for public use. Are there any dependencies between components? If so then things need to be more complicated, especially to provide the imported targets. See FindBoost for an example. -Brad From brad.king at kitware.com Thu Jun 23 10:31:15 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 23 Jun 2016 10:31:15 -0400 Subject: [cmake-developers] patch for FindProtobuf.cmake In-Reply-To: References: Message-ID: <576BF2B3.5010005@kitware.com> On 06/22/2016 08:08 PM, Miroslav Drahos wrote: > I believe I found a bug in FindProtobuf.cmake. Using set with two > parameters will insert an unwanted semicolon, the list separator. > The changes I made are like this (several occurrences): > > - set(_protobuf_include_path -I ${CMAKE_CURRENT_SOURCE_DIR}) > + set(_protobuf_include_path "-I${CMAKE_CURRENT_SOURCE_DIR}") The ";" in the value of the _protobuf_include_path are just normal list separators which will be used to divide the list when the variable is later referenced as ${_protobuf_include_path} in add_custom_command calls. The difference that this patch makes is `-I foo` v. `-Ifoo` on the resulting command lines. > I also added a test for FindProtobuf.cmake, which is a new addition. > The complete patch is attached. What I cannot figure out is how to > run the test? When I configure cmake build, I don?t see an option > to set the path to protobuf. Thanks for writing a test! The `CMake_TEST_Find...` options are all undocumented options that have to be added explicitly to the cache when configuring (e.g. -DCMake_TEST_FindProtobuf=1). The problem is that we don't know what packages are installed on a system such that running a find module test for them will work. Therefore we just keep them off by default and enable the tests on nightly testing machines where they are expected to work. I'd like to find a better solution but this is at least better than when we had no tests for individual find modules at all. Currently the patch makes the test get added as part of the build of CMake itself. Please see the other Tests/Find* directories for how the tests should be laid out. Thanks, -Brad From gang65 at poczta.onet.pl Thu Jun 23 11:50:46 2016 From: gang65 at poczta.onet.pl (Bartosz Kosiorek) Date: Thu, 23 Jun 2016 17:50:46 +0200 Subject: [cmake-developers] [PATCH] Update documentation for VERSION and SOVERSION for Mach-O file formats (OSX, iOS, BSD etc.) Message-ID: Hello. Last time I faced problem, how to set "current version" and "compatibility version" on binaries produced by OS X. I have updated documentation to describe how to archieve that, to make life easier for new CMake users. Please let me know what do you think about it. Do you think it could be pushed into CMake 3.6 ? Best Regards Bartosz -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-description-of-versions-target-property-for-Mach.patch Type: application/octet-stream Size: 6290 bytes Desc: not available URL: From konstantin at podsvirov.pro Thu Jun 23 12:37:58 2016 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Thu, 23 Jun 2016 19:37:58 +0300 Subject: [cmake-developers] [MODERN] CMake 3.6+ vs Qt 5.7 vs MSVC2015 In-Reply-To: <4434461464882342@web5o.yandex.ru> References: <1821991437643934@web22o.yandex.ru> <55B0E831.7070603@yahoo.com> <35881437659256@web4h.yandex.ru> <1975171437723971@web22h.yandex.ru> <55B653D0.4020001@kitware.com> <198581438094978@web29o.yandex.ru> <825181443680946@web21o.yandex.ru> <56451463763913@web25o.yandex.ru> <476621464710287@web16g.yandex.ru> <4434461464882342@web5o.yandex.ru> Message-ID: <629571466699878@web27g.yandex.ru> Hi all! Modern master updated! :-) It's time to upgrade: CMake 3.6.20160623 and CMake 3.6.0-rc3 now available! Let me remind you of the link. Windows 32bit: http://ifw.podsvirov.pro/cmake/cmake-master-win32-online.exe http://ifw.podsvirov.pro/cmake/files/v3.6/cmake-3.6.0-rc3-win32-x86.exe Windows 64bit: http://ifw.podsvirov.pro/cmake/cmake-master-win64-online.exe http://ifw.podsvirov.pro/cmake/files/v3.6/cmake-3.6.0-rc3-win64-x64.exe If you have used it before, you can update via "CMake Maintenance Tool" I used Windows 7, but it should work for Windows Vista and Windows 8 and Windows 10. I ask those wishing to test the functionality. Please test it :-) >>> ??01.10.2015, 09:29, Konstantin Podsvirov" : >>>> ???Hi all! Modern master alive! :-) >>>> >>>> ???It's been almost a month and it's time to upgrade: >>>> >>>> ???3.3.20150901 CMake => CMake 3.3.20151001 >>>> >>>> ???Dear friends, I have a question and call for help. >>>> >>>> ???With my assistance the project has an option for component installation project: >>>> >>>> ???CMake_INSTALL_COMPONENTS >>>> >>>> ???Unfortunately not all files found your component. >>>> ???The files to be installed without specifying a component fall into 'Unspecified' component. >>>> ???Need to parse them out and assign them to the component context. >>>> >>>> ???Now have the components: >>>> >>>> ???- cmake; >>>> ???- ctest; >>>> ???- cpack; >>>> ???- cmake-gui; >>>> ???- sphinx-man; >>>> ???- sphinx-html; >>>> ???- sphinx singlehtml; >>>> ???- sphinx-qthelp >>>> >>>> ???and General for everything else >>>> >>>> ???Is Unspecified; >>>> >>>> ???A list of unaccounted for 'Unspecified' of files to install on the Window is attached. >>>> >>>> ???Links to the installers were specified earlier (see below). >>>> >>>> ???On 28.07.2015, 17:49, "Konstantin Podsvirov" : >>>>> ???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 >>>>>>> ???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 option CMake_INSTALL_DEPENDENCIES >>>>>> ???http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=068e7962 >>>>> >>>>> ???Code now in 'master' branch. >>>>> >>>>> ???Thanks, Brad! >>>>> >>>>> ???Meet/install/CMake built modern update 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 >>>>> >>>>> ???The 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 >>>> ???,-- >>>> >>>> ???Powered by www.kitware.com >>>> >>>> ???Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>>> >>>> ???Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>>> >>>> ???CMake Support: http://cmake.org/cmake/help/support.html >>>> ???CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>> ???CMake Training Courses: http://cmake.org/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 >>> >>> ??Regards, >>> ??Konstantin Podsvirov > > Regards, > Konstantin Podsvirov > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/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 Regards, Konstantin Podsvirov From brad.king at kitware.com Thu Jun 23 13:47:46 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 23 Jun 2016 13:47:46 -0400 Subject: [cmake-developers] [PATCH] Update documentation for VERSION and SOVERSION for Mach-O file formats (OSX, iOS, BSD etc.) In-Reply-To: References: Message-ID: <576C20C2.70308@kitware.com> On 06/23/2016 11:50 AM, Bartosz Kosiorek wrote: > how to set "current version" and "compatibility version" on > binaries produced by OS X. > I have updated documentation to describe how to archieve that Thanks. I revised the changes a bit and applied the patch: Help: Describe VERSION and SOVERSION meanings for Mach-O binaries https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=00caa1dd > Do you think it could be pushed into CMake 3.6 ? Yes, since it is a documentation-only update. I've queued it for merge to 'release'. -Brad From brad.king at kitware.com Thu Jun 23 16:46:48 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 23 Jun 2016 16:46:48 -0400 Subject: [cmake-developers] daemon-mode meeting last Tuesday In-Reply-To: <1466684840.811.269.camel@qt.io> References: <1466684840.811.269.camel@qt.io> Message-ID: <576C4AB8.9040408@kitware.com> On 06/23/2016 08:27 AM, Tobias Hunger wrote: > Stephen Kelly and me met last Tuesday to talk about the daemon-mode patch we > both have been working on. It was a very productive meeting: We managed to > resolve almost all the differences of opinion we had. Great! Thanks for the detailed summary of the meeting and status of the design. > * Some names could be improved. Suggestions welcome. We'll cover these in more detail during review. The most important name is the name of the feature, and IMO "daemon" is not an accurate description of it (it is never re-parented to 'init' and has a lifetime tied to the client). I think "server" would be better but am open to other suggestions. Even if it later really becomes a daemon the name "server" will still be appropriate. As you said before there has been a lot of PR with the name "daemon", but I don't think it is too late to change it. Those interested in the features will see the new name when it appears in release notes and should easily be able to recognize it. > * Clients should talk to daemon mode via a socket (libuv supports that), > but we also want to support stdin/stdout at least for a "debug mode" > * There should be a separate command line switch to start stdin/out mode > and for socket mode > * This is needed before it makes sense to merge the patch set. Given the noise we have on stdout it makes sense to offer a dedicated communication path for clients. > * Currently a reply (and error and all other messages in response to a > request) contain a "inReplyTo" with the type string from the request > triggering the reply. > > Stephen thinks that is not necessary and argues anything that is not > strictly necessary should not be in the first version of the protocol. > > I like having this as it makes it helps to identify what a reply/error is > related to. I often paste a whole string of requests into the daemon and > if there is an error it is really easy to see how for things got. Would each type of query have a known type of response? Shouldn't the response objects have a type too? Also, doesn't the cookie allow the query/response pairs to be matched? > * Should we have a split between header (cookie/type/inReplyTo) and data? > > Stephen suggested passing all data that is from/for the client in a > "body" attribute to make messages more uniform. > > I think that is just adding one more level into the JSON file for no > real benefit. I agree with Tobias that there is no reason to put the body fields in a sub-object. However, I think the header fields should go in a sub-object named by a "header" field. That will isolate the header field names from the body fields (good for sorted views, future addition of headers, etc.). > * This is currently used to set sourcedirectory, builddirectory and > generator. > > These three should be passed in via the command line instead, again > to avoid trouble with users switching to different build directories/etc. > while the daemon is running, which might trigger problems with state > cleanup, etc. Currently cmake-gui supports switching generators, build trees, etc., so there is some precedent for such switching within a single process. If we have (re-)initialization bugs they should simply be fixed. > * Figure out whether a PDB file is actually going to be build. Currently > the PDB file is added to the list of artifacts whenever there is a .lib > file, which is probably wrong. Brad: Do you have an idea how to > get this information? I'm not sure we have that information. IIRC CMake only adds settings to the generated build system to tell the tools where to put the .pdb and what to call it if it happens to be created. We don't have install rules for them so there has never been a need to know whether they will actually be created. Perhaps our format for the list of artifacts needs a way to indicate whether an artifact is optionally present. > 2.8 buildsystem (return cmake files) > > * Return a list of cmake files (CMakeLists.txt, etc.) in different categories > (in source directory/in build directory/in the system). > > * Stephen suggested to rename this to "cmake_rerun_depends". I am not sure > that name is much better than what is currently used. "cmake_rerun_depends" describes the current use case for these. I don't think the name "buildsystem" is clear though. Other ideas: * cmake_files * cmake_inputs * input_files -Brad From ben.boeckel at kitware.com Thu Jun 23 16:48:14 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 23 Jun 2016 16:48:14 -0400 Subject: [cmake-developers] daemon-mode meeting last Tuesday In-Reply-To: <576C4AB8.9040408@kitware.com> References: <1466684840.811.269.camel@qt.io> <576C4AB8.9040408@kitware.com> Message-ID: <20160623204814.GA13633@megas.kitware.com> On Thu, Jun 23, 2016 at 16:46:48 -0400, Brad King wrote: > On 06/23/2016 08:27 AM, Tobias Hunger wrote: > > * Some names could be improved. Suggestions welcome. > > We'll cover these in more detail during review. The most important name is > the name of the feature, and IMO "daemon" is not an accurate description of > it (it is never re-parented to 'init' and has a lifetime tied to the client). > I think "server" would be better but am open to other suggestions. Even if > it later really becomes a daemon the name "server" will still be appropriate. > > As you said before there has been a lot of PR with the name "daemon", but I > don't think it is too late to change it. Those interested in the features > will see the new name when it appears in release notes and should easily be > able to recognize it. cmake-oracle sounds reasonable for what it's doing to me. --Ben From ben.boeckel at kitware.com Thu Jun 23 16:57:24 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 23 Jun 2016 16:57:24 -0400 Subject: [cmake-developers] daemon-mode meeting last Tuesday In-Reply-To: <576C4AB8.9040408@kitware.com> References: <1466684840.811.269.camel@qt.io> <576C4AB8.9040408@kitware.com> Message-ID: <20160623205724.GB13633@megas.kitware.com> On Thu, Jun 23, 2016 at 16:46:48 -0400, Brad King wrote: > On 06/23/2016 08:27 AM, Tobias Hunger wrote: > > * Figure out whether a PDB file is actually going to be build. Currently > > the PDB file is added to the list of artifacts whenever there is a .lib > > file, which is probably wrong. Brad: Do you have an idea how to > > get this information? > > I'm not sure we have that information. IIRC CMake only adds settings to the > generated build system to tell the tools where to put the .pdb and what to > call it if it happens to be created. We don't have install rules for them > so there has never been a need to know whether they will actually be created. > Perhaps our format for the list of artifacts needs a way to indicate whether > an artifact is optionally present. Well, there is this issue: https://gitlab.kitware.com/cmake/cmake/issues/10636 which requests that they always be generated :) . > > 2.8 buildsystem (return cmake files) > > > > * Return a list of cmake files (CMakeLists.txt, etc.) in different categories > > (in source directory/in build directory/in the system). > > > > * Stephen suggested to rename this to "cmake_rerun_depends". I am not sure > > that name is much better than what is currently used. > > "cmake_rerun_depends" describes the current use case for these. I don't think > the name "buildsystem" is clear though. Other ideas: > > * cmake_files > * cmake_inputs > * input_files Also possible: regen_trigger_files --Ben From eike at sf-mail.de Thu Jun 23 17:00:29 2016 From: eike at sf-mail.de (Rolf Eike Beer) Date: Thu, 23 Jun 2016 23:00:29 +0200 Subject: [cmake-developers] daemon-mode meeting last Tuesday In-Reply-To: <1466684840.811.269.camel@qt.io> References: <1466684840.811.269.camel@qt.io> Message-ID: <6774054.CF68T2xT38@caliban.sf-tec.de> > 1.1 Communication: > > * Clients should talk to daemon mode via a socket (libuv supports that), > but we also want to support stdin/stdout at least for a "debug mode" * > There should be a separate command line switch to start stdin/out mode and > for socket mode > * This is needed before it makes sense to merge the patch set. What about just passing --server-fd= into it? That way the client can set up whatever if wants to pass there and CMake has nothing to do with any setup. And if one really wants to get messy one could pass a tty there. 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 Thu Jun 23 17:06:13 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 23 Jun 2016 17:06:13 -0400 Subject: [cmake-developers] daemon-mode: Infrastructure In-Reply-To: References: Message-ID: <20160623210613.GC13633@megas.kitware.com> On Tue, Jun 14, 2016 at 02:00:14 +0200, Tobias Hunger wrote: > Implementing new Protocol Versions: > ============================== > Deprecating old Protocol Versions: > ============================ One idea that came up on a previous project was the following: namespace protocol { namespace aspect1 { namespace v1 { } namespace v2 { } } namespace aspect2 { namespace v1 { } } namespace v1 { namespace aspect1 = aspect1::v1; namespace aspect2 = aspect1::v1; Version version(1, 0); bool deprecated = true; } namespace v2 { namespace aspect1 = aspect1::v2; namespace aspect2 = aspect1::v1; Version version(2, 0); bool deprecated = false; } namespace latest = v2; } Then the code can use `protocol::v1::aspect1::` for explicit v1 communication and `protocol::latest::` in any normal code. It does require C++11 though. There's probably some template metaprogramming magic that could be done to instantiate communication ends for each protocol namespace once communication is done. I have no idea how maintainable in the long-term this is though. --Ben From tobias.hunger at gmail.com Thu Jun 23 17:19:30 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Thu, 23 Jun 2016 23:19:30 +0200 Subject: [cmake-developers] daemon-mode meeting last Tuesday In-Reply-To: <576C4AB8.9040408@kitware.com> References: <1466684840.811.269.camel@qt.io> <576C4AB8.9040408@kitware.com> Message-ID: Am 23.06.2016 22:46 schrieb "Brad King" : > > On 06/23/2016 08:27 AM, Tobias Hunger wrote: > Great! Thanks for the detailed summary of the meeting and status of the design. You are welcome. > > * Some names could be improved. Suggestions welcome. > > We'll cover these in more detail during review. The most important name is > the name of the feature, and IMO "daemon" is not an accurate description of > it (it is never re-parented to 'init' and has a lifetime tied to the client). > I think "server" would be better but am open to other suggestions. Even if > it later really becomes a daemon the name "server" will still be appropriate. I'll create a task to rename it to "server" then. > > * Currently a reply (and error and all other messages in response to a > > request) contain a "inReplyTo" with the type string from the request > > triggering the reply. > > > > Stephen thinks that is not necessary and argues anything that is not > > strictly necessary should not be in the first version of the protocol. > > > > I like having this as it makes it helps to identify what a reply/error is > > related to. I often paste a whole string of requests into the daemon and > > if there is an error it is really easy to see how for things got. > > Would each type of query have a known type of response? Shouldn't the response > objects have a type too? It has a type: "reply" (or "error"). I so far use the inReplyTo field to specify what the request a reply refers to. Stephen thinks that is not necessary as there is always one request in flight and the client can just figure things out without additional information. > Also, doesn't the cookie allow the query/response > pairs to be matched? In theory yes. But a protocol should work without having to reply on cookies. A cookie is user data attached to an request. The idea is that e.g. an IDE can run a request for some more details on some node in the project tree view and pass some form of ID of the node the information is for along with the query. That can simplify client code a lot. > > * Should we have a split between header (cookie/type/inReplyTo) and data? > > > > Stephen suggested passing all data that is from/for the client in a > > "body" attribute to make messages more uniform. > > > > I think that is just adding one more level into the JSON file for no > > real benefit. > > I agree with Tobias that there is no reason to put the body fields in > a sub-object. However, I think the header fields should go in a sub-object > named by a "header" field. That will isolate the header field names from > the body fields (good for sorted views, future addition of headers, etc.). The header currently is the type, inReplyTo and the cookie. I did not see the need to separate those. > > * This is currently used to set sourcedirectory, builddirectory and > > generator. > > > > These three should be passed in via the command line instead, again > > to avoid trouble with users switching to different build directories/etc. > > while the daemon is running, which might trigger problems with state > > cleanup, etc. > > Currently cmake-gui supports switching generators, build trees, etc., so > there is some precedent for such switching within a single process. If > we have (re-)initialization bugs they should simply be fixed. So you think we should keep that? I do not have an opinion here and need to follow the advise of people more knowledgeable about CMake code than I am. > > * Figure out whether a PDB file is actually going to be build. Currently > > the PDB file is added to the list of artifacts whenever there is a .lib > > file, which is probably wrong. Brad: Do you have an idea how to > > get this information? > > I'm not sure we have that information. IIRC CMake only adds settings to the > generated build system to tell the tools where to put the .pdb and what to > call it if it happens to be created. We don't have install rules for them > so there has never been a need to know whether they will actually be created. > Perhaps our format for the list of artifacts needs a way to indicate whether > an artifact is optionally present. I think CMake should know what is generated and should not leave decisions like that up to generators. > > 2.8 buildsystem (return cmake files) > > > > * Return a list of cmake files (CMakeLists.txt, etc.) in different categories > > (in source directory/in build directory/in the system). > > > > * Stephen suggested to rename this to "cmake_rerun_depends". I am not sure > > that name is much better than what is currently used. > > "cmake_rerun_depends" describes the current use case for these. I don't think > the name "buildsystem" is clear though. Other ideas: > > * cmake_files > * cmake_inputs > * input_files I like "cmakeInputs":-) I'll make a task to change it if nobody opposes this suggestion. Best Regards, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hunger at gmail.com Thu Jun 23 17:21:21 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Thu, 23 Jun 2016 23:21:21 +0200 Subject: [cmake-developers] daemon-mode meeting last Tuesday In-Reply-To: <20160623204814.GA13633@megas.kitware.com> References: <1466684840.811.269.camel@qt.io> <576C4AB8.9040408@kitware.com> <20160623204814.GA13633@megas.kitware.com> Message-ID: Hi Ben, Am 23.06.2016 22:48 schrieb "Ben Boeckel" : > cmake-oracle sounds reasonable for what it's doing to me. I hope this thing will provide information more reliable than e.g. the Oracle of Delphi in ancient Greece:-) Best Regards, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hunger at gmail.com Thu Jun 23 17:23:30 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Thu, 23 Jun 2016 23:23:30 +0200 Subject: [cmake-developers] daemon-mode meeting last Tuesday In-Reply-To: <6774054.CF68T2xT38@caliban.sf-tec.de> References: <1466684840.811.269.camel@qt.io> <6774054.CF68T2xT38@caliban.sf-tec.de> Message-ID: Hi Rolf, Am 23.06.2016 23:00 schrieb "Rolf Eike Beer" : > What about just passing --server-fd= into it? That way the client can set > up whatever if wants to pass there and CMake has nothing to do with any setup. > And if one really wants to get messy one could pass a tty there. Not sure whether that is even possible on all platforms we need. Libuv (which the server is using) apparently has a cross-platform solution for setting up a communication channel like the one we need, so I want to give that a try. Best Regards, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at pfeifer-mail.de Fri Jun 24 03:59:01 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Fri, 24 Jun 2016 09:59:01 +0200 Subject: [cmake-developers] daemon-mode meeting last Tuesday In-Reply-To: <1466684840.811.269.camel@qt.io> References: <1466684840.811.269.camel@qt.io> Message-ID: On Thu, Jun 23, 2016 at 2:27 PM, Tobias Hunger wrote: > * We both think it only makes sense to merge the infrastructure part into > cmake (if it passes review first of course) once we have some functionality > that is genuinely useful. So we want to aim at having the infrastructure > and the codemodel merged in one go. Please think about adding libuv earlier. As Brad wrote before, libuv could replace some #ifdef code that we currently have (process handling, file operations). I am currently refactoring the code around the cmOutputConverter and I would like to introduce a cmPath class (I will write more about that later, but I can already say that libuv might come handy for some functionality). > 2.7 cache (report contents of CMakeCache.txt file) > > * Review by other potential users would be appreciated, but no obvious > problems seen. Is this needed? If the CMakeCache.txt file continues to be written, clients could just parse that file. If clients want to make changes (ie. cache editors), they can rewrite the file. Is that a problem? I assume it is, because CMake needs to reconfigure when it rereads it. In that case, the server should provide a way to report the contents, but also ways to modify it. Cheers, Daniel PS: Next meeting in a Biergarten in Munich? From tobias.hunger at gmail.com Fri Jun 24 04:12:08 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Fri, 24 Jun 2016 10:12:08 +0200 Subject: [cmake-developers] daemon-mode meeting last Tuesday In-Reply-To: References: <1466684840.811.269.camel@qt.io> Message-ID: Hallo Daniel, On Fri, Jun 24, 2016 at 9:59 AM, Daniel Pfeifer wrote: > On Thu, Jun 23, 2016 at 2:27 PM, Tobias Hunger wrote: >> * We both think it only makes sense to merge the infrastructure part into >> cmake (if it passes review first of course) once we have some functionality >> that is genuinely useful. So we want to aim at having the infrastructure >> and the codemodel merged in one go. > > Please think about adding libuv earlier. As Brad wrote before, libuv > could replace some #ifdef code that we currently have (process > handling, file operations). I am currently refactoring the code around > the cmOutputConverter and I would like to introduce a cmPath class (I > will write more about that later, but I can already say that libuv > might come handy for some functionality). Feel free to merge it at your own pace. I'll just use your copy then:-) Currently I just link to an external version of said library and have not yet tried to figure out what the policy is wrt. 3rd party code in cmake. Stephen suggested that we would need to include a copy into the cmake repository and hinted at a script that keeps these copies updated. >> 2.7 cache (report contents of CMakeCache.txt file) >> >> * Review by other potential users would be appreciated, but no obvious >> problems seen. > > Is this needed? If the CMakeCache.txt file continues to be written, > clients could just parse that file. If clients want to make changes > (ie. cache editors), they can rewrite the file. Is that a problem? I > assume it is, because CMake needs to reconfigure when it rereads it. > In that case, the server should provide a way to report the contents, > but also ways to modify it. Yes, this is needed. I do not want 3rd party code to interact with what is basically a file internal to cmake. And the syntax of that file is not as trivial as the comment at its top claims it is. Just check how properties on values are encoded. Best Regards, Tobias From tobias.hunger at gmail.com Fri Jun 24 10:56:51 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Fri, 24 Jun 2016 16:56:51 +0200 Subject: [cmake-developers] daemon-mode meeting last Tuesday In-Reply-To: <576C4AB8.9040408@kitware.com> References: <1466684840.811.269.camel@qt.io> <576C4AB8.9040408@kitware.com> Message-ID: Hi Brad, On Thu, Jun 23, 2016 at 10:46 PM, Brad King wrote: >> * This is currently used to set sourcedirectory, builddirectory and >> generator. >> >> These three should be passed in via the command line instead, again >> to avoid trouble with users switching to different build directories/etc. >> while the daemon is running, which might trigger problems with state >> cleanup, etc. > > Currently cmake-gui supports switching generators, build trees, etc., so > there is some precedent for such switching within a single process. If > we have (re-)initialization bugs they should simply be fixed. So you opt for enabling the cmake-server to switch between different build directories? That would have the following side-effects: * We would need the reset command to get the server back into a defined state * We need to keep it possible to set source directory, build directory and generator from inside server mode * We can keep the existing generators query-able from inside server mode. If they are set inside server mode, then there is no need to know them before starting server mode after all. * The commandline way of querying generators is not necessary. We might still want that, but it does not belong into this patch set anymore. Is this the way to do? I will need to back out some changes I did since speaking with Stephen then. No problem, git has everything;-) Best Regards, Tobias From daniel at pfeifer-mail.de Fri Jun 24 11:08:00 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Fri, 24 Jun 2016 17:08:00 +0200 Subject: [cmake-developers] daemon-mode meeting last Tuesday In-Reply-To: References: <1466684840.811.269.camel@qt.io> <576C4AB8.9040408@kitware.com> Message-ID: On Fri, Jun 24, 2016 at 4:56 PM, Tobias Hunger wrote: > Hi Brad, > > On Thu, Jun 23, 2016 at 10:46 PM, Brad King wrote: >>> * This is currently used to set sourcedirectory, builddirectory and >>> generator. >>> >>> These three should be passed in via the command line instead, again >>> to avoid trouble with users switching to different build directories/etc. >>> while the daemon is running, which might trigger problems with state >>> cleanup, etc. >> >> Currently cmake-gui supports switching generators, build trees, etc., so >> there is some precedent for such switching within a single process. If >> we have (re-)initialization bugs they should simply be fixed. > > So you opt for enabling the cmake-server to switch between different > build directories? Clients who need this feature could simply restart the server in the new directory. From tobias.hunger at gmail.com Fri Jun 24 11:24:02 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Fri, 24 Jun 2016 17:24:02 +0200 Subject: [cmake-developers] daemon-mode meeting last Tuesday In-Reply-To: References: <1466684840.811.269.camel@qt.io> <576C4AB8.9040408@kitware.com> Message-ID: Hi Daniel, On Fri, Jun 24, 2016 at 5:08 PM, Daniel Pfeifer wrote: >>> Currently cmake-gui supports switching generators, build trees, etc., so >>> there is some precedent for such switching within a single process. If >>> we have (re-)initialization bugs they should simply be fixed. >> >> So you opt for enabling the cmake-server to switch between different >> build directories? > > Clients who need this feature could simply restart the server in the > new directory. yes, that was what Stephen and me thought, too. I understood Brad to imply that we should just do everything inside server-mode and fix any fallout we run into instead. That is why I wanted to have this clarified, as this does cause quite a few changes in the implementation. Best Regards, Tobias From daniel at pfeifer-mail.de Fri Jun 24 11:43:06 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Fri, 24 Jun 2016 17:43:06 +0200 Subject: [cmake-developers] daemon-mode meeting last Tuesday In-Reply-To: References: <1466684840.811.269.camel@qt.io> <576C4AB8.9040408@kitware.com> Message-ID: On Fri, Jun 24, 2016 at 5:24 PM, Tobias Hunger wrote: > Hi Daniel, > > On Fri, Jun 24, 2016 at 5:08 PM, Daniel Pfeifer wrote: >>>> Currently cmake-gui supports switching generators, build trees, etc., so >>>> there is some precedent for such switching within a single process. If >>>> we have (re-)initialization bugs they should simply be fixed. >>> >>> So you opt for enabling the cmake-server to switch between different >>> build directories? >> >> Clients who need this feature could simply restart the server in the >> new directory. > > yes, that was what Stephen and me thought, too. I understood Brad to > imply that we should just do everything inside server-mode and fix any > fallout we run into instead. I just opened cmake-gui and checked what exactly can be changed. There is no graphical option to change the generator (you can change the option sting in the cache, of course). When you change the binary directory, it reads the cache from that directory, with the effect that the source directory is changed too. To me, that feels like a hard reset/restart. To me it feels like the only reason why there is precedent for such switching within a single process, is that cmake-gui links against libcmake instead of using the cmake-server. I don't see any technical reason apart from that it hasn't been split into two processes yet. From konstantin at podsvirov.pro Fri Jun 24 12:23:50 2016 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Fri, 24 Jun 2016 19:23:50 +0300 Subject: [cmake-developers] [ANNOUNCE] DaD's House Standalone Installers In-Reply-To: <4755441465592063@web10g.yandex.ru> References: <4755441465592063@web10g.yandex.ru> Message-ID: <4898291466785430@web5j.yandex.ru> Hello dear developers! Standalone installers for some DaD's House releases now available at SF mirror: https://sourceforge.net/projects/dad-mirror/files/standalone/2015/dad-0.3.1-windows-vc12x64-2015-standalone.exe/download https://sourceforge.net/projects/dad-mirror/files/standalone/2015/dad-0.3.1-windows-vc12x86-2015-standalone.exe/download https://sourceforge.net/projects/dad-mirror/files/standalone/2014/dad-0.3.1-windows-vc12x64-2014-standalone.exe/download https://sourceforge.net/projects/dad-mirror/files/standalone/2014/dad-0.3.1-windows-vc12x86-2014-standalone.exe/download This info also available at installers page: http://dad.podsvirov.pro/house/installers 10.06.2016, 23:54, "Konstantin Podsvirov" : > Hi guys! Hello developers! > > My "DaD's Project" is based on CMake and QtIFW (specifically CPackIFW) continues its development: > > http://dad.podsvirov.pro - the official "DaD's House" website now. > > "DaD's House" is a resource where you can download the installers to install necessary dependencies > and immediately begin developing their projects. > > Already declared support 40 the following modules: > > Curses, ZLib, LibPNG, Jpeg, Libxml2, LibTIFF, Perl, OpenSSL, LibSSH2, cURL, > PCRE, PROJ, Expat, FreeType, SQLite, GEOS, GDAL, Boost, Qt, QtIFW, > CMake KDSoap, OSG, osgEarth, osgQtQuick, PostgreSQL, Apache.Apr, The Apache.AprUtil, Apache.Httpd, Protobuf, > gRPC, MapServer, Bullet, QCA, wxWidgets, LibXSLT, iconv, pgAdmin3, Wt, FreeGLUT. > > Also available in 4 port: > > ?- Windows Visual C++ Compiler 12.0 32bit > ?- Windows Visual C++ Compiler 12.0 64bit > > and NEW > > ?- Windows 5.3.0 MinGW w64 32bit > ?- Windows 5.3.0 MinGW w64 64bit > > The last 2 ports have appeared recently and there are still large but interesting work. > > All of this can be a good basis for your projects. > All this is a good basis for my personal growth. > > I assess the status of the project as a Beta and write to lists for developers of basic technologies. > > Open the curtain. > > For each module I have a small CMakeLists.txt: > > http://git.podsvirov.pro/?a=project_list;pf=dad/mod > > These scripts help me to build the modules and create a repository of binary components. > > There is a need to spread content. All available here: > > http://download.podsvirov.pro > > My server is small and weak. I need help in distribution. I need a mirror "main" module: > > rsync://podsvirov.pro > > If there are interested parties and you give me the address of the mirror, then I can add them to MirrorBrain setup > for more efficient distribution. > > If you are interested in developing this technology or already use my installers, I would like to hear your opinion > and to get feedback. > > Have a great weekend and good luck in development of your projects! > > -- > Regards, > Konstantin Podsvirov > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/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 Regards, Konstantin Podsvirov From oleg at kaa.org.ua Fri Jun 24 12:19:49 2016 From: oleg at kaa.org.ua (Oleh Kravchenko) Date: Fri, 24 Jun 2016 19:19:49 +0300 Subject: [cmake-developers] Status of pre-compiled headers Message-ID: <576D5DA5.3040803@kaa.org.ua> Hello! As far as I can see from issue tracker and the mail list archives of "precompiled headers" feature we are still struggling for solution. I'm ready to contribute to development, but have not idea where shall I start :) https://cmake.org/Bug/view.php?id=1260 https://gitlab.kitware.com/cmake/cmake/issues/1260 I have in-depth knowledge of C/C++ development for different platforms (Windows, Linux), (arm, x86, amd64) and GCC/MSVC compilers. Please point me to where can I learn the correct process of adding new features to CMake and current state of "precompiled headers" feature development. Best Regards, Oleh Kravchenko From afuller at teradici.com Fri Jun 24 14:22:07 2016 From: afuller at teradici.com (Andrew Fuller) Date: Fri, 24 Jun 2016 18:22:07 +0000 Subject: [cmake-developers] Improved handling of %directives in CPACK_RPM_USER_FILELIST Message-ID: <1466792527006.65919@teradici.com> Attached is a patch to improve the handling of %directives in CPACK_RPM_USER_FILELIST. Specifically it accepts any characters (even spaces) inside the parenthesis so it doesn't need to keep changing every time there's a new valid symbol. The current open ticket is https://gitlab.kitware.com/cmake/cmake/issues/13468 which is asking to use an underscore. %caps requires the use of '+' and also spaces. I've created a merge request here: https://gitlab.kitware.com/cmake/cmake/merge_requests/23? with the same contents as this format-patch, but the contribution guidelines say a format-patch to this list is desired. Cheers, -Andrew?? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Adjust-the-regex-to-handle-foo-and-foo-anything-dire.patch Type: text/x-patch Size: 1283 bytes Desc: 0001-Adjust-the-regex-to-handle-foo-and-foo-anything-dire.patch URL: From gjasny at googlemail.com Sat Jun 25 07:56:31 2016 From: gjasny at googlemail.com (Gregor Jasny) Date: Sat, 25 Jun 2016 13:56:31 +0200 Subject: [cmake-developers] [patch] iOS combined, some fixes In-Reply-To: References: <66aed97f-51c7-5e9b-a823-136c4f7bc765@yahoo.com> <1ff617d9-99da-aa10-9218-f0de72ac809f@yahoo.com> Message-ID: On 21/06/16 18:48, Ruslan Baratov wrote: > Is the patch applied? Let me know if there are any questions left about it. Pushed into next. Sorry for the delay. From ruslan_baratov at yahoo.com Sat Jun 25 11:46:26 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Sat, 25 Jun 2016 18:46:26 +0300 Subject: [cmake-developers] [patch] iOS combined, some fixes In-Reply-To: References: <66aed97f-51c7-5e9b-a823-136c4f7bc765@yahoo.com> <1ff617d9-99da-aa10-9218-f0de72ac809f@yahoo.com> Message-ID: Great, thank you! On 25-Jun-16 14:56, Gregor Jasny wrote: > On 21/06/16 18:48, Ruslan Baratov wrote: >> Is the patch applied? Let me know if there are any questions left about it. > Pushed into next. Sorry for the delay. > > > From brad.king at kitware.com Mon Jun 27 11:02:42 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 27 Jun 2016 11:02:42 -0400 Subject: [cmake-developers] daemon-mode meeting last Tuesday In-Reply-To: <20160623204814.GA13633@megas.kitware.com> References: <1466684840.811.269.camel@qt.io> <576C4AB8.9040408@kitware.com> <20160623204814.GA13633@megas.kitware.com> Message-ID: <57714012.9030303@kitware.com> On 06/23/2016 04:48 PM, Ben Boeckel wrote: > cmake-oracle sounds reasonable for what it's doing to me. That name conflicts with a well-known vendor behind a platform on which CMake runs so IMO would be confusing. -Brad From brad.king at kitware.com Mon Jun 27 11:02:56 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 27 Jun 2016 11:02:56 -0400 Subject: [cmake-developers] libuv in cmake (was: daemon-mode meeting last Tuesday) In-Reply-To: References: <1466684840.811.269.camel@qt.io> Message-ID: <57714020.1040804@kitware.com> On 06/24/2016 04:12 AM, Tobias Hunger wrote: >> Please think about adding libuv earlier. As Brad wrote before, libuv >> could replace some #ifdef code that we currently have > > Feel free to merge it at your own pace. I'll just use your copy then:-) > > Currently I just link to an external version of said library and have > not yet tried to figure out what the policy is wrt. 3rd party code in > cmake. Stephen suggested that we would need to include a copy into the > cmake repository and hinted at a script that keeps these copies > updated. I can take care of the details of getting libuv enabled as a third-party package within CMake. I've just been waiting for time to do it and an initial use case. Daniel, if you are interested in this I once started a prototype to convert cmSystemTools::RunSingleCommand over to libuv that you could take over finishing. Once you have it working I can look at making libuv available in `master`. -Brad From brad.king at kitware.com Mon Jun 27 11:03:06 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 27 Jun 2016 11:03:06 -0400 Subject: [cmake-developers] daemon-mode meeting last Tuesday In-Reply-To: References: <1466684840.811.269.camel@qt.io> <576C4AB8.9040408@kitware.com> Message-ID: <5771402A.30301@kitware.com> On 06/24/2016 11:43 AM, Daniel Pfeifer wrote: > On Fri, Jun 24, 2016, Tobias Hunger wrote: >>>> So you opt for enabling the cmake-server to switch between different >>>> build directories? >>> >>> Clients who need this feature could simply restart the server in the >>> new directory. >> >> yes, that was what Stephen and me thought, too. I understood Brad to >> imply that we should just do everything inside server-mode and fix any >> fallout we run into instead. > > To me it feels like the only reason why there is precedent for such > switching within a single process, is that cmake-gui links against > libcmake instead of using the cmake-server. I don't see any technical > reason apart from that it hasn't been split into two processes yet. Yes. I was just pointing out that it is possible to use a single process if we want. If it is simpler to make the src/bld/gen settings part of the startup command line then I think we should do that. -Brad From brad.king at kitware.com Mon Jun 27 11:03:16 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 27 Jun 2016 11:03:16 -0400 Subject: [cmake-developers] daemon-mode meeting last Tuesday In-Reply-To: References: <1466684840.811.269.camel@qt.io> <576C4AB8.9040408@kitware.com> Message-ID: <57714034.4020102@kitware.com> On 06/23/2016 05:19 PM, Tobias Hunger wrote: > I'll create a task to rename it to "server" then. Sounds good. >> Would each type of query have a known type of response? > > It has a type: "reply" (or "error"). I so far use the inReplyTo field to > specify what the request a reply refers to. Stephen thinks that is not > necessary as there is always one request in flight and the client can just > figure things out without additional information. Okay. If the field makes debugging or other use cases easier I see no reason not to include it. >> Also, doesn't the cookie allow the query/response pairs to be matched? > > In theory yes. But a protocol should work without having to reply on cookies. Yes, I see. > The header currently is the type, inReplyTo and the cookie. I did not see > the need to separate those. Okay. This may be easier to review in context when the time comes. >> Currently cmake-gui supports switching generators, build trees, etc., so >> there is some precedent for such switching within a single process. If >> we have (re-)initialization bugs they should simply be fixed. > > So you think we should keep that? No. See response in another branch of this thread. >> I'm not sure we have that information. IIRC CMake only adds settings to the >> generated build system to tell the tools where to put the .pdb and what to >> call it if it happens to be created. > > I think CMake should know what is generated and should not leave decisions > like that up to generators. Yes, but that will take some additional investigation and work to achieve. CMake will have to be taught more about which tools/platforms actually produce the .pdb files. They are not first-class artifacts in CMake's model right now. > I like "cmakeInputs" Sounds good. Thanks, -Brad From brad.king at kitware.com Mon Jun 27 11:03:26 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 27 Jun 2016 11:03:26 -0400 Subject: [cmake-developers] Improved handling of %directives in CPACK_RPM_USER_FILELIST In-Reply-To: <1466792527006.65919@teradici.com> References: <1466792527006.65919@teradici.com> Message-ID: <5771403E.10104@kitware.com> On 06/24/2016 02:22 PM, Andrew Fuller wrote: > I've created a merge request here: > https://gitlab.kitware.com/cmake/cmake/merge_requests/23? with the > same contents as this format-patch, but the contribution guidelines > say a format-patch to this list is desired. Thanks. We can pick up review directly on the MR. We're still experimenting with that workflow so CONTRIBUTING.rst has not been updated yet. Posting here helps to reach more people anyway. -Brad From brad.king at kitware.com Mon Jun 27 11:09:43 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 27 Jun 2016 11:09:43 -0400 Subject: [cmake-developers] Status of pre-compiled headers In-Reply-To: <576D5DA5.3040803@kaa.org.ua> References: <576D5DA5.3040803@kaa.org.ua> Message-ID: <577141B7.2020009@kitware.com> On 06/24/2016 12:19 PM, Oleh Kravchenko wrote: > As far as I can see from issue tracker and the mail list archives of > "precompiled headers" feature we are still struggling for solution. > https://cmake.org/Bug/view.php?id=1260 > https://gitlab.kitware.com/cmake/cmake/issues/1260 Yes. Currently we support some primitives that make it possible to use PCH in some circumstances but it is not a first-class feature. One reason is that we (upstream) have never needed it for our own projects. > I'm ready to contribute to development, but have not idea where shall I start :) > I have in-depth knowledge of C/C++ development for different platforms > (Windows, Linux), (arm, x86, amd64) and GCC/MSVC compilers. Great, thanks for stepping forward. The first step is to propose porcelain (e.g. a target property) to enable and configure PCH settings, along with examples of how that would map to the underlying generator behavior. We need to find an abstraction that works well for the way each native toolchain does PCH. Thanks, -Brad From daniel at pfeifer-mail.de Mon Jun 27 11:16:09 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Mon, 27 Jun 2016 17:16:09 +0200 Subject: [cmake-developers] libuv in cmake (was: daemon-mode meeting last Tuesday) In-Reply-To: <57714020.1040804@kitware.com> References: <1466684840.811.269.camel@qt.io> <57714020.1040804@kitware.com> Message-ID: On Mon, Jun 27, 2016 at 5:02 PM, Brad King wrote: > On 06/24/2016 04:12 AM, Tobias Hunger wrote: >>> Please think about adding libuv earlier. As Brad wrote before, libuv >>> could replace some #ifdef code that we currently have >> >> Feel free to merge it at your own pace. I'll just use your copy then:-) >> >> Currently I just link to an external version of said library and have >> not yet tried to figure out what the policy is wrt. 3rd party code in >> cmake. Stephen suggested that we would need to include a copy into the >> cmake repository and hinted at a script that keeps these copies >> updated. > > I can take care of the details of getting libuv enabled as a third-party > package within CMake. I've just been waiting for time to do it and an > initial use case. Daniel, if you are interested in this I once started > a prototype to convert cmSystemTools::RunSingleCommand over to libuv > that you could take over finishing. Once you have it working I can look > at making libuv available in `master`. I currently have some open topics that I want to finish first. From daniel at pfeifer-mail.de Mon Jun 27 11:24:17 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Mon, 27 Jun 2016 17:24:17 +0200 Subject: [cmake-developers] Status of pre-compiled headers In-Reply-To: <577141B7.2020009@kitware.com> References: <576D5DA5.3040803@kaa.org.ua> <577141B7.2020009@kitware.com> Message-ID: On Mon, Jun 27, 2016 at 5:09 PM, Brad King wrote: > On 06/24/2016 12:19 PM, Oleh Kravchenko wrote: >> As far as I can see from issue tracker and the mail list archives of >> "precompiled headers" feature we are still struggling for solution. >> https://cmake.org/Bug/view.php?id=1260 >> https://gitlab.kitware.com/cmake/cmake/issues/1260 > > Yes. Currently we support some primitives that make it possible to use > PCH in some circumstances but it is not a first-class feature. One > reason is that we (upstream) have never needed it for our own projects. > >> I'm ready to contribute to development, but have not idea where shall I start :) >> I have in-depth knowledge of C/C++ development for different platforms >> (Windows, Linux), (arm, x86, amd64) and GCC/MSVC compilers. > > Great, thanks for stepping forward. > > The first step is to propose porcelain (e.g. a target property) to > enable and configure PCH settings, along with examples of how that > would map to the underlying generator behavior. We need to find an > abstraction that works well for the way each native toolchain does > PCH. You may find this branch useful as a staring point: https://github.com/purpleKarrot/CMake/commits/pch The reason I never finished that is the same as Brad mentioned above: I currently don't need this feature for any project. cheers, Daniel From daniel at pfeifer-mail.de Mon Jun 27 11:34:15 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Mon, 27 Jun 2016 17:34:15 +0200 Subject: [cmake-developers] Status of pre-compiled headers In-Reply-To: References: <576D5DA5.3040803@kaa.org.ua> <577141B7.2020009@kitware.com> Message-ID: On Mon, Jun 27, 2016 at 5:24 PM, Daniel Pfeifer wrote: > On Mon, Jun 27, 2016 at 5:09 PM, Brad King wrote: >> On 06/24/2016 12:19 PM, Oleh Kravchenko wrote: >>> As far as I can see from issue tracker and the mail list archives of >>> "precompiled headers" feature we are still struggling for solution. >>> https://cmake.org/Bug/view.php?id=1260 >>> https://gitlab.kitware.com/cmake/cmake/issues/1260 >> >> Yes. Currently we support some primitives that make it possible to use >> PCH in some circumstances but it is not a first-class feature. One >> reason is that we (upstream) have never needed it for our own projects. >> >>> I'm ready to contribute to development, but have not idea where shall I start :) >>> I have in-depth knowledge of C/C++ development for different platforms >>> (Windows, Linux), (arm, x86, amd64) and GCC/MSVC compilers. >> >> Great, thanks for stepping forward. >> >> The first step is to propose porcelain (e.g. a target property) to >> enable and configure PCH settings, along with examples of how that >> would map to the underlying generator behavior. We need to find an >> abstraction that works well for the way each native toolchain does >> PCH. > > You may find this branch useful as a staring point: > https://github.com/purpleKarrot/CMake/commits/pch > > The reason I never finished that is the same as Brad mentioned above: > I currently don't need this feature for any project. Please also see the discussion here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12589 From tobias.hunger at gmail.com Mon Jun 27 11:49:32 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Mon, 27 Jun 2016 17:49:32 +0200 Subject: [cmake-developers] daemon-mode meeting last Tuesday In-Reply-To: <57714034.4020102@kitware.com> References: <1466684840.811.269.camel@qt.io> <576C4AB8.9040408@kitware.com> <57714034.4020102@kitware.com> Message-ID: He everybody, sorry, I am currently not making the progress I want. Qt Creator has feature freeze coming up and I need to push some patches and fix some bugs. Brad, Daniel: You both mentioned wanting to use libuv. Is somebody already looking into merging this into cmake? So far I just link against the library and am done with it... Stephen said 3rd party libraries would need to be checked into cmake and that scripts exist to keep these libraries up-to-date. What can I do to help getting this library available to all cmake users (so that I can further shrink my patch set;-)? On Mon, Jun 27, 2016 at 5:03 PM, Brad King wrote: > On 06/23/2016 05:19 PM, Tobias Hunger wrote: >> I'll create a task to rename it to "server" then. > > Sounds good. > >>> Would each type of query have a known type of response? >> >> It has a type: "reply" (or "error"). I so far use the inReplyTo field to >> specify what the request a reply refers to. Stephen thinks that is not >> necessary as there is always one request in flight and the client can just >> figure things out without additional information. > > Okay. If the field makes debugging or other use cases easier I see no reason > not to include it. Good, I'll keep inReplyTo for now. >>> Also, doesn't the cookie allow the query/response pairs to be matched? >> >> In theory yes. But a protocol should work without having to reply on cookies. > > Yes, I see. > >> The header currently is the type, inReplyTo and the cookie. I did not see >> the need to separate those. > > Okay. This may be easier to review in context when the time comes. Ok, I'll keep things the way they are for now then. Changing that should not be too hard anyway. >>> Currently cmake-gui supports switching generators, build trees, etc., so >>> there is some precedent for such switching within a single process. If >>> we have (re-)initialization bugs they should simply be fixed. >> >> So you think we should keep that? > > No. See response in another branch of this thread. OK, going for the command line switching model then. >>> I'm not sure we have that information. IIRC CMake only adds settings to the >>> generated build system to tell the tools where to put the .pdb and what to >>> call it if it happens to be created. >> >> I think CMake should know what is generated and should not leave decisions >> like that up to generators. > > Yes, but that will take some additional investigation and work to achieve. > CMake will have to be taught more about which tools/platforms actually > produce the .pdb files. They are not first-class artifacts in CMake's > model right now. I currently list the PDB files in the artifacts (if there is a .lib file). I'll keep that for the time being. Best Regards, Tobias From brad.king at kitware.com Mon Jun 27 13:18:50 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 27 Jun 2016 13:18:50 -0400 Subject: [cmake-developers] daemon-mode meeting last Tuesday In-Reply-To: References: <1466684840.811.269.camel@qt.io> <576C4AB8.9040408@kitware.com> <57714034.4020102@kitware.com> Message-ID: <57715FFA.4030005@kitware.com> On 06/27/2016 11:49 AM, Tobias Hunger wrote: > Brad, Daniel: You both mentioned wanting to use libuv. Is somebody > already looking into merging this into cmake? So far I just link > against the library and am done with it... > > Stephen said 3rd party libraries would need to be checked into cmake > and that scripts exist to keep these libraries up-to-date. What can I > do to help getting this library available to all cmake users (so that > I can further shrink my patch set;-)? I will take care of making libuv available within CMake's implementation prior to merging the server mode work. See the "libuv in cmake" branch of this thread. -Brad From tobias.hunger at gmail.com Tue Jun 28 03:47:11 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Tue, 28 Jun 2016 09:47:11 +0200 Subject: [cmake-developers] daemon-mode meeting last Tuesday In-Reply-To: <57715FFA.4030005@kitware.com> References: <1466684840.811.269.camel@qt.io> <576C4AB8.9040408@kitware.com> <57714034.4020102@kitware.com> <57715FFA.4030005@kitware.com> Message-ID: Hi Brad, Am 27.06.2016 7:18 nachm. schrieb "Brad King" : > I will take care of making libuv available within CMake's implementation > prior to merging the server mode work. See the "libuv in cmake" branch > of this thread. Perfect. Sorry, I only noticed the other thread after sending my mail. Best regards, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From roman.wueger at gmx.at Tue Jun 28 17:01:56 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Tue, 28 Jun 2016 23:01:56 +0200 Subject: [cmake-developers] [CMake] [iOS] What is the correct way to add resources to an XCode project In-Reply-To: <21D325C1-601B-4393-8BBB-7D82B36456E7@gmx.at> References: <21D325C1-601B-4393-8BBB-7D82B36456E7@gmx.at> Message-ID: No one? The target property RESOURCE does only allow files but no directories. Regards Roman > Am 22.06.2016 um 17:22 schrieb Roman W?ger : > > Hello, > > I read the mailing list but did find a way which works. > > At the moment I use Xcode 7.3.1 and CMake 3.5.2 which creates a project for iOS 9.3. > > All I want is to add the directory "Images.xcassets" and a second directory structure to be copied to the Resource folder listed in XCode. > > When I manually drag'n drop the directories into the Resource folder as reference or as group everything is working. How can I archive this with CMake? > > Thanks and 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 From daniel at pfeifer-mail.de Tue Jun 28 17:24:22 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Tue, 28 Jun 2016 23:24:22 +0200 Subject: [cmake-developers] Script to update liblzma from upstream. Message-ID: Hi Brad, I have attached a patch that adds a script to update liblzma from upstream (closely modeled after the other update scripts). I am not sure how these kinds of scripts need to be run. We currently have a copy of liblzma version 5.0.5. The latest version on the 5.0 branch is 5.0.8. Once the script is introduced, we may consider switching to the 5.2 branch. Cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-script-to-update-liblzma-from-upstream.patch Type: text/x-patch Size: 1192 bytes Desc: not available URL: From steveire at gmail.com Tue Jun 28 18:41:49 2016 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 29 Jun 2016 00:41:49 +0200 Subject: [cmake-developers] daemon-mode meeting last Tuesday References: <1466684840.811.269.camel@qt.io> Message-ID: Tobias Hunger wrote: > Hello CMake Developers, > > Stephen Kelly and me met last Tuesday to talk about the daemon-mode patch > we both have been working on. It was a very productive meeting: We managed > to resolve almost all the differences of opinion we had. Thanks Tobias for the summary and everyone else for the discussion. Here are a few additional notes that I took when meeting Tobias last week. These notes don't change anything in the discussion, but expands on a few things to put some meat on the bones and lists some discarded design options. cmMessenger ----------- > * Having cmMessanger would be nice and will make things easier. In particular - a cmMessenger class can have some virtual methods implemented to print to the console as cmake::IssueMessage currently does. It would be inherited by a cmServerMessenger which would override the virtual methods to send them over the server IPC protocol instead of printing them on stdout. This has the advantage of not losing semantic information - a backtrace becomes a JSON array, meaning clients don't have to try to parse the backtrace out of the stdout message as they currently do. That becomes possible with just a IssueMessage virtual. See http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15607 Additionally, the cmMessenger can have additional high-level virtual methods, such as for find_package results making it easier for user tools and IDEs to get a list of packages searched for and make it possible to give users use-case specific ways of specifying where packages are. Similarly it can have a virtual method for try_compile results (somehow - this might require extending the message type for scripting API) which also give user tools more opportunities to present the user with semantic information and not discard the intent of the person writing the buildsystem. Another place where a virtual method on cmMessenger would make sense is for policy warnings, giving user tools a chance to present them to the user without trying to parse them from stdout. There may be other messages which have semantics whose meaning we currently discard by printing to stdout. All of this is currently blocked by a clean-up in the parser needing further review and perhaps further implementation work: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15607/focus=16663 Name ---- Last year before publication I was calling this feature a 'metadata server' (class called cmMetadataServer etc). I probably made a mistake renaming it to a daemon. Now, 'metadata server' might be better and more specific than 'server' alone. Change Notification ------------------- I wrote previously that I think change notification is an essential feature of the first version of the protocol - otherwise the output is no better than a static generated file. http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/16589/focus=16648 Tobias was concerned that implementing filesystem watching for all necessary platforms is an unreasonable burden and he would prefer something like QFileSystemWatcher. libuv has a portable abstraction for filesystem change notification similar in a way to QFileSystemWatcher. I implemented a basic use of the libuv API fs notification API last year. Action item for me is to dig out that work or do it again. Then the metadata server can emit a message on the protocol when the source directory content changes. Feature Flags ------------- > 1.2 Protocol versions > > * We need the daemon-mode to support different protocol versions. > > * We want to have the option to mark protocol versions as experimental. As far as I know, Chrome has a development model whereby unfinished features are checked into master immediately and developed there, instead of being developed in a branch. The new/experimental features are disabled by default with 'feature flags' so that people/CI can enable and test features which are candidates to be enabled by default to everyone. We discussed whether this would make sense for the server instead of 'experimental' protocol versions. We decided that such feature flags would make sense if there would be many experimental features in flight from multiple contributors over multiple cmake releases. We don't expect this to be the case, so we consider feature flags to be over-engineered for the server for now. InReplyTo --------- > * Currently a reply (and error and all other messages in response to a > request) contain a "inReplyTo" with the type string from the request > triggering the reply. > > Stephen thinks that is not necessary and argues anything that is not > strictly necessary should not be in the first version of the protocol. Tobias told me that the only reason for this is to make it easier for people developing the actual protocol to paste blocks of text which contain multiple server messages. For example a developer could paste a 'configure' and a 'compute' and a 'codeModel' message over and over while implementing the 'codeModel' message. If the 'configure' or 'compute' fail for some reason with an error Tobias thinks it is confusing to figure out which one had the error after the fact. I don't agree that that is hard or confusing. To be clear: The inReplyTo will never be used by client tools. It is only for the above use-case. My concern is that if we add something only for a use-case like that, client tools will start to use it for something it is not designed for. Then we will regret that we did not design something better for the clients actual need (because inReplyTo isn't exactly what they actually need). So, I am strongly in favor of keeping the protocol content to the absolute minimum - only include things which we know client use-cases for. Downstreams abusing CMake script APIs for things they were not intended for is a long term problem for CMake. We should avoid introducing that problem in the server protocol. Especially as inReplyTo, even in its current form is 'fuzzy' to me: Is it in spontaneous messages which are not in response to anything (message() output, change notifications etc)? Does it have 'special' values? Initialization Granularity -------------------------- We talked about what should happen when a client starts the metadata server and what sequence of protocol commands the client has to send to set things up properly. In my implementation, the initial handshake causes the configure step and the compute step to be executed. The client can't cause only the configure step to be executed. This means that an out-of-process cmake-gui or other cache editor: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/16550/focus=16556 using the metadata server would have to do a full handshake instead of 'just' the configure part for example, making it not analogous to the current cmake-gui. So, a granular approach allows the use-case of partial initialization while also making it possible for a client to do 'full initialization' by requesting the 'configure', 'compute' and 'generate' steps explicitly. As with the cmake-gui, it might make sense to specify the 'generate' command as implying the dependee two. We might benefit from some state-machine diagram telling users (and us) what protocol commands are possible in which state. Capabilities ------------ > * Move generators and other static information into a separate cmake > commandline invocation (http://public.kitware.com/Bug/view.php?id=15462): Previously Tobias wanted this only as part of the protocol, not as something that can be emitted with a regular command line request in the same manner as --help for example. I think such capabilities information should be available easily to anyone writing scripts which invoke cmake. Tobias needs that information for Qt Creator because it needs to know what generators are available for example. That is determined when Creator is started each time. Tobias mentioned that such capability queries should be fast - executing lots of tools to find out their versions and capabilities is something that slows down the start up of QtCreator. He reasoned that he should only have to run one cmake - start the server only - not run cmake first to get the capabilities, then run it a second time in server mode. I noted that starting the server just for a query like this is very much likely to be slower than just getting the information on the command line. Additionally, the server can be started later when loading a project instead of when starting QtCreator itself. Tobias was convinced by that. > TODO: Figure out how to get all the generator information, e.g. which > values the flags some generator taken can have (architecture, etc.). > Stephen volunteered to check into this. This is about toolsets, platforms, architectures which I think can be passed to cmake when executing it with Visual Studio generators. I'm not very clear on that stuff. Brad, do you have an overview? Use-case Driven Design ---------------------- > 2.6) project (Return project structure) > > * Rename to "codemodel" to make the use-case for the data more clear. One of the differences between the protocol proposed by Tobias is that he has one protocol command which returns a structure of all targets, their files and the includes, defines and flags of the files. In contrast, I had implemented an approach which provides multiple protocol commands returning more-granular structures: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/16589/focus=16640 In the discussion we realized that the two approaches satisfy two different use-cases. Tobias needs to get all C++ source files and the includes, defines and flags in order to populate a C++ code model for the project. That allows things like 'find usages of this symbol in the project' etc. A granular way of returning this information to the client would be inconvenient and ineffective. Whereas the use-case for the structure Tobias wants has a use-case of populating a C++ code model, my proposed protocol commands for target_info, file_info etc are for the use-case of understanding the CMake code. That is why the 'codeModel' in Tobias' proposal does not list include directories, compile definitions etc of targets, but only of files. The code model cares about compilations. It is not concerned with targets. The protocol commands I proposed are for helping the user to understand what the effect of CMake code like target_include_directories(MyTarget ${SOME_VAR}) target_compile_definitions(MyTarget ${SOME_OTHER_VAR}) target_link_libraries(MyTarget ${YET_ANOTHER_VAR}) means. The variables (and transitive usage requirements) make the impact of those lines invisible in the code, as my video demonstrates. Those kinds of protocol commands and features are in scope for the protocol, and perhaps also for QtCreator some day, but they are out of scope for now. As a result of that part of the discussion, I think it might make sense to try to use 'use-case driven design' when trying to decide what should be in the protocol. There may be some element of 'redundancy' occurring in the protocol as a result. For example, both the 'codeModel' protocol command and the 'target_info' would return 'stuff (including object sources in both cases) associated with a target'. We don't yet know if that is a problem. Cache ----- > 2.7 cache (report contents of CMakeCache.txt file) > > * Review by other potential users would be appreciated, but no obvious > problems seen. We thought this would be useful for the work of Daniel on his cache-editor tool, and so feedback from him and Clinton (as cmake-gui is potentially another user of this stuff) would be valued. Other Movers ------------ Microsoft just published a JSON protocol for language servers to get information into VSCode, and for other user tools to do the same. https://www.reddit.com/r/programming/comments/4qad14 This could be interesting to learn from. Although they say the protocol is JSON, I can only seem to find TypeScript protocol stuff. Presumably that gets translated to JSON for wire communication, but that's not clear from their docs. https://github.com/google/xi-editor is another editor based on a JSON protocol with a language server. Neovim too: https://github.com/neovim/neovim/wiki/Plugin-UI-architecture These and other examples indicate that user tools are moving towards multi- process with some defined protocols. I don't think the generic protocol from Microsoft is a replacement for the cmake metadata server protocol, but there are certainly going to be lessons to learn from there. C++11 ----- One central difference between the cmake metadata server code and the rest of CMake is that I used cxx_auto_type and cxx_range_for extensively for my sanity and productivity. I don't see any problem with requiring CMake to be built with a recent compiler in order to conditionally support server mode. QtCreator also requires some C++11 features and it is likely the first user of the protocol and the only major one for some time. Thanks, Steve. From roman.wueger at gmx.at Wed Jun 29 01:15:18 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Wed, 29 Jun 2016 07:15:18 +0200 Subject: [cmake-developers] Patch for CM_OVERRIDE Message-ID: Hello, I've attached a patch for the CM_OVERRIDE commit Best Regards Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-fixup-CM_OVERRIDE-Visual-Studio-2010-and-below-do-no.patch Type: application/octet-stream Size: 825 bytes Desc: not available URL: -------------- next part -------------- From tobias.hunger at gmail.com Wed Jun 29 02:58:44 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Wed, 29 Jun 2016 08:58:44 +0200 Subject: [cmake-developers] daemon-mode meeting last Tuesday In-Reply-To: References: <1466684840.811.269.camel@qt.io> Message-ID: Hello everyone, On Wed, Jun 29, 2016 at 12:41 AM, Stephen Kelly wrote: > Tobias Hunger wrote: > Name > ---- > > Last year before publication I was calling this feature a 'metadata server' > (class called cmMetadataServer etc). I probably made a mistake renaming it > to a daemon. Now, 'metadata server' might be better and more specific than > 'server' alone. I do not care what we end up calling the baby, but considering that I do not expect more server modes to pop up in cmake (and considering that we do not yet fully know where we will end up with our little server), I think server is a fine name. > Change Notification > ------------------- > > I wrote previously that I think change notification is an essential feature > of the first version of the protocol - otherwise the output is no better > than a static generated file. > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/16589/focus=16648 > > Tobias was concerned that implementing filesystem watching for all necessary > platforms is an unreasonable burden and he would prefer something like > QFileSystemWatcher. > > libuv has a portable abstraction for filesystem change notification similar > in a way to QFileSystemWatcher. I implemented a basic use of the libuv API > fs notification API last year. > > Action item for me is to dig out that work or do it again. Then the metadata > server can emit a message on the protocol when the source directory content > changes. Creator will watch files itself. It has rather nice logic to save file descriptors when doing that. And since file descriptors are a scarce system resource I will need to turn file watching in server mode off. I do see a use-case where having the cmake server do the watching for its users. I am in no way opposed to doing that, but for me it is definitely not a feature required for the first version. > Feature Flags > ------------- > >> 1.2 Protocol versions >> >> * We need the daemon-mode to support different protocol versions. >> >> * We want to have the option to mark protocol versions as experimental. > > As far as I know, Chrome has a development model whereby unfinished features > are checked into master immediately and developed there, instead of being > developed in a branch. The new/experimental features are disabled by default > with 'feature flags' so that people/CI can enable and test features which > are candidates to be enabled by default to everyone. > > We discussed whether this would make sense for the server instead of > 'experimental' protocol versions. We decided that such feature flags would > make sense if there would be many experimental features in flight from > multiple contributors over multiple cmake releases. We don't expect this to > be the case, so we consider feature flags to be over-engineered for the > server for now. Thanks for documenting that:-) I remembered that I had forgot to mention something we agreed on to not do, but I totally forgot what that was. > InReplyTo > --------- > > Tobias told me that the only reason for this is to make it easier for people > developing the actual protocol to paste blocks of text which contain > multiple server messages. For example a developer could paste a 'configure' > and a 'compute' and a 'codeModel' message over and over while implementing > the 'codeModel' message. If the 'configure' or 'compute' fail for some > reason with an error Tobias thinks it is confusing to figure out which one > had the error after the fact. I don't agree that that is hard or confusing. > > To be clear: The inReplyTo will never be used by client tools. It is only > for the above use-case. > > My concern is that if we add something only for a use-case like that, client > tools will start to use it for something it is not designed for. Then we > will regret that we did not design something better for the clients actual > need (because inReplyTo isn't exactly what they actually need). > > So, I am strongly in favor of keeping the protocol content to the absolute > minimum - only include things which we know client use-cases for. > Downstreams abusing CMake script APIs for things they were not intended for > is a long term problem for CMake. We should avoid introducing that problem > in the server protocol. > > Especially as inReplyTo, even in its current form is 'fuzzy' to me: Is it in > spontaneous messages which are not in response to anything (message() > output, change notifications etc)? Does it have 'special' values? "inReplyTo" is set in all messages generated by the server in reply to a request received by the client. If the server sends a signal that is not in reply to a request by the client (e.g. filesystem notification), then that will not have inReplyTo set. Considering that some requests trigger a whole lot of messages (e.g. "configure" triggers messages and progress notifications to be sent before the final reply), I find this field highly useful. > Initialization Granularity > -------------------------- > > We talked about what should happen when a client starts the metadata server > and what sequence of protocol commands the client has to send to set things > up properly. > > In my implementation, the initial handshake causes the configure step and > the compute step to be executed. The client can't cause only the configure > step to be executed. This means that an out-of-process cmake-gui or other > cache editor: > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/16550/focus=16556 > > using the metadata server would have to do a full handshake instead of > 'just' the configure part for example, making it not analogous to the > current cmake-gui. > > So, a granular approach allows the use-case of partial initialization while > also making it possible for a client to do 'full initialization' by > requesting the 'configure', 'compute' and 'generate' steps explicitly. > > As with the cmake-gui, it might make sense to specify the 'generate' command > as implying the dependee two. We might benefit from some state-machine > diagram telling users (and us) what protocol commands are possible in which > state. I would prefer to have simple building blocks in the server that applications can combine in useful ways to bigger blocks that can be used in exactly one way. We need the individual steps anyway, and the target audience for the server interface is technically savvy enough to figure out that they need to do "configure" and "compute" to get to a state where the required information is available. Personally I would find figuring out what the difference between "initializeCMakeFully" and the "configure"/"compute" sequence is more annoying than just having the latter. > Capabilities > ------------ > >> * Move generators and other static information into a separate cmake >> commandline invocation (http://public.kitware.com/Bug/view.php?id=15462): > > Previously Tobias wanted this only as part of the protocol, not as something > that can be emitted with a regular command line request in the same manner > as --help for example. > > I think such capabilities information should be available easily to anyone > writing scripts which invoke cmake. > > Tobias needs that information for Qt Creator because it needs to know what > generators are available for example. That is determined when Creator is > started each time. > > Tobias mentioned that such capability queries should be fast - executing > lots of tools to find out their versions and capabilities is something that > slows down the start up of QtCreator. He reasoned that he should only have > to run one cmake - start the server only - not run cmake first to get the > capabilities, then run it a second time in server mode. > > I noted that starting the server just for a query like this is very much > likely to be slower than just getting the information on the command line. > Additionally, the server can be started later when loading a project instead > of when starting QtCreator itself. Tobias was convinced by that. We did agree here, but I was not convinced by this argument:-) Starting up applications is expensive, especially in the case where something goes wrong and locks up. I would greatly prefer just starting the server mode and extract all information from there. That is one application startup and I have a way to retrieve everything I need from there. But this approach requires kind of implies that I can also configure the daemon *after* it was started. You convinced me that would not work well. With having to give generators at startup, a pre-daemon-mode way to retrieve the generator data is necessary. > Use-case Driven Design > ---------------------- > >> 2.6) project (Return project structure) >> >> * Rename to "codemodel" to make the use-case for the data more clear. > > One of the differences between the protocol proposed by Tobias is that he > has one protocol command which returns a structure of all targets, their > files and the includes, defines and flags of the files. ... plus an interface for clients to filter the output (e.g. only return certain configurations, targets or even things like target types). > In contrast, I had > implemented an approach which provides multiple protocol commands returning > more-granular structures: > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/16589/focus=16640 > > In the discussion we realized that the two approaches satisfy two different > use-cases. Tobias needs to get all C++ source files and the includes, > defines and flags in order to populate a C++ code model for the project. > That allows things like 'find usages of this symbol in the project' etc. > > A granular way of returning this information to the client would be > inconvenient and ineffective. > > Whereas the use-case for the structure Tobias wants has a use-case of > populating a C++ code model, my proposed protocol commands for target_info, > file_info etc are for the use-case of understanding the CMake code. > > That is why the 'codeModel' in Tobias' proposal does not list include > directories, compile definitions etc of targets, but only of files. The code > model cares about compilations. It is not concerned with targets. The > protocol commands I proposed are for helping the user to understand what the > effect of CMake code like > > target_include_directories(MyTarget ${SOME_VAR}) > target_compile_definitions(MyTarget ${SOME_OTHER_VAR}) > target_link_libraries(MyTarget ${YET_ANOTHER_VAR}) > > means. The variables (and transitive usage requirements) make the impact of > those lines invisible in the code, as my video demonstrates. > > Those kinds of protocol commands and features are in scope for the protocol, > and perhaps also for QtCreator some day, but they are out of scope for now. > > As a result of that part of the discussion, I think it might make sense to > try to use 'use-case driven design' when trying to decide what should be in > the protocol. > > There may be some element of 'redundancy' occurring in the protocol as a > result. For example, both the 'codeModel' protocol command and the > 'target_info' would return 'stuff (including object sources in both cases) > associated with a target'. We don't yet know if that is a problem. I still think that having one command to query everything cmake knows about the project structure with ways to limit the information returned is way better than having five different commands that each return a subset of that information. Any such subset-based interface I ever ended up using return what the developers of the interface thought would make sense for me to know, not what I actually need. This discussion is for later though. For now I just removed all the code to limit the selection and just return everything creator needs, so for the time being this is very use-case driven design. We can descent into this particular rabbits hole whenever we want *after* the first version is merged:-) > Other Movers > ------------ This section is actually new information we did not discuss in person:-) > Microsoft just published a JSON protocol for language servers to get > information into VSCode, and for other user tools to do the same. > > https://www.reddit.com/r/programming/comments/4qad14 > > This could be interesting to learn from. Although they say the protocol is > JSON, I can only seem to find TypeScript protocol stuff. Presumably that > gets translated to JSON for wire communication, but that's not clear from > their docs. > > https://github.com/google/xi-editor The protocols defined by microsoft seem to be more interesting later, when we actually get to the language handling parts. > C++11 > ----- > > One central difference between the cmake metadata server code and the rest > of CMake is that I used cxx_auto_type and cxx_range_for extensively for my > sanity and productivity. I just followed Stephen's style and used those, too. Actually I did not even realize that they were not used anywhere else in cmake till Stephen mentioned this:-). These are so easy to get used to:-) Best Regards, Tobias From Tobias.Hunger at qt.io Wed Jun 29 03:35:50 2016 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Wed, 29 Jun 2016 07:35:50 +0000 Subject: [cmake-developers] Please apply patch from https://github.com/hunger/CMake/commits/for-upstream to master Message-ID: <1467185747.811.274.camel@qt.io> Hello Brad, I currently get more than 2000 warnings when building cmake master, all about missing overrides. Could you please take the fix warning patch from https://github.com/hunger/CMake/commits/for-upstream?and apply it to master? That fixes all those pesky override warnings. Best Regards, Tobias -- Tobias Hunger,?Senior?Software Engineer?| The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From eike at sf-mail.de Wed Jun 29 03:54:06 2016 From: eike at sf-mail.de (Rolf Eike Beer) Date: Wed, 29 Jun 2016 09:54:06 +0200 Subject: [cmake-developers] Please apply patch from https://github.com/hunger/CMake/commits/for-upstream to master In-Reply-To: <1467185747.811.274.camel@qt.io> References: <1467185747.811.274.camel@qt.io> Message-ID: Am 2016-06-29 09:35, schrieb Tobias Hunger: > Hello Brad, > > I currently get more than 2000 warnings when building cmake master, all > about > missing overrides. > > Could you please take the fix warning patch from > https://github.com/hunger/CMake/commits/for-upstream?and apply it to > master? > That fixes all those pesky override warnings. This should be CM_OVERRIDE. Eike From Tobias.Hunger at qt.io Wed Jun 29 04:17:12 2016 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Wed, 29 Jun 2016 08:17:12 +0000 Subject: [cmake-developers] Please apply patch from https://github.com/hunger/CMake/commits/for-upstream to master In-Reply-To: References: <1467185747.811.274.camel@qt.io> Message-ID: <1467188231.811.277.camel@qt.io> On Mi, 2016-06-29 at 09:54 +0200, Rolf Eike Beer wrote: > Am 2016-06-29 09:35, schrieb Tobias Hunger: > > Hello Brad, > > > > I currently get more than 2000 warnings when building cmake master, all? > > about > > missing overrides. > > > > Could you please take the fix warning patch from > > https://github.com/hunger/CMake/commits/for-upstream?and apply it to? > > master? > > That fixes all those pesky override warnings. > > This should be CM_OVERRIDE. Changed. Best Regards, Tobias -- Tobias Hunger,?Senior?Software Engineer?| The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From farbos.arnaud at gmail.com Wed Jun 29 05:02:30 2016 From: farbos.arnaud at gmail.com (Farbos a) Date: Wed, 29 Jun 2016 11:02:30 +0200 Subject: [cmake-developers] adding FindJsonCpp Message-ID: Hi, I would like to add a find module: FindJsonCpp.cmake that I attached. the library github: https://github.com/open-source-parsers/jsoncpp. This library allows JSON manipulation. It's used by more than one person and I think it could useful to add a find module for this library. Thanks, -- Arnaud FARBOS -------------- next part -------------- A non-text attachment was scrubbed... Name: FindJsonCpp.cmake Type: application/octet-stream Size: 2782 bytes Desc: not available URL: From daniel at pfeifer-mail.de Wed Jun 29 05:22:58 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Wed, 29 Jun 2016 11:22:58 +0200 Subject: [cmake-developers] Patch for CM_OVERRIDE In-Reply-To: References: Message-ID: On Wed, Jun 29, 2016 at 7:15 AM, Roman W?ger wrote: > Hello, > > I've attached a patch for the CM_OVERRIDE commit Hi Roman, I added "override" to the destructor on purpose. The intent is to make the check fail in Visual Studio 10. See the commit message here: https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=9e2d6f0c4d19e1ae1652071ea783ad577ea93e28 cheers, Daniel From daniel at pfeifer-mail.de Wed Jun 29 05:56:09 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Wed, 29 Jun 2016 11:56:09 +0200 Subject: [cmake-developers] Please apply patch from https://github.com/hunger/CMake/commits/for-upstream to master In-Reply-To: <1467188231.811.277.camel@qt.io> References: <1467185747.811.274.camel@qt.io> <1467188231.811.277.camel@qt.io> Message-ID: On Wed, Jun 29, 2016 at 10:17 AM, Tobias Hunger wrote: > On Mi, 2016-06-29 at 09:54 +0200, Rolf Eike Beer wrote: >> Am 2016-06-29 09:35, schrieb Tobias Hunger: >> > Hello Brad, >> > >> > I currently get more than 2000 warnings when building cmake master, all >> > about >> > missing overrides. >> > >> > Could you please take the fix warning patch from >> > https://github.com/hunger/CMake/commits/for-upstream and apply it to >> > master? >> > That fixes all those pesky override warnings. >> >> This should be CM_OVERRIDE. > > Changed. Thanks. I merged it to next. From ben.boeckel at kitware.com Wed Jun 29 08:09:05 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 29 Jun 2016 08:09:05 -0400 Subject: [cmake-developers] adding FindJsonCpp In-Reply-To: References: Message-ID: <20160629120905.GB5811@megas.kitware.com> On Wed, Jun 29, 2016 at 11:02:30 +0200, Farbos a wrote: > I would like to add a find module: FindJsonCpp.cmake that I attached. > the library github: https://github.com/open-source-parsers/jsoncpp. > > This library allows JSON manipulation. It's used by more than one > person and I think it could useful to add a find module for this > library. The library builds using CMake and rather than using more code to find itself, it should instead create a package configuration file which contains the exact information CMake needs to use its install tree. See the docs: https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-packages Please consider contributing such support to the upstream project. Thanks, --Ben From ben.boeckel at kitware.com Wed Jun 29 08:52:48 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 29 Jun 2016 08:52:48 -0400 Subject: [cmake-developers] [CMake] [iOS] What is the correct way to add resources to an XCode project In-Reply-To: References: <21D325C1-601B-4393-8BBB-7D82B36456E7@gmx.at> Message-ID: <20160629125248.GA17842@megas.kitware.com> On Tue, Jun 28, 2016 at 23:01:56 +0200, Roman W?ger wrote: > The target property RESOURCE does only allow files but no directories. There's an open issue for this: https://gitlab.kitware.com/cmake/cmake/issues/14743 --Ben From ben.boeckel at kitware.com Wed Jun 29 09:02:29 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 29 Jun 2016 09:02:29 -0400 Subject: [cmake-developers] Script to update liblzma from upstream. In-Reply-To: References: Message-ID: <20160629130229.GB17842@megas.kitware.com> On Tue, Jun 28, 2016 at 23:24:22 +0200, Daniel Pfeifer wrote: > I have attached a patch that adds a script to update liblzma from > upstream (closely modeled after the other update scripts). I am not > sure how these kinds of scripts need to be run. Thanks! Looks like Brad hadn't imported the docs for it. Here's VTK's copy: https://gitlab.kitware.com/vtk/vtk/blob/master/ThirdParty/UPDATING.md > +readonly ownership="liblzma upstream " This should probably use kwrobot at kitware.com as the email. The oddball I see in the repo now is libarchive. Brad, why is that not kwrobot? > +readonly paths=" > + src/common/sysdefs.h > + src/common/tuklib_integer.h > + src/liblzma I'd recommend adding a trailing slash to this to indicate that it is a directory (at least this is the style I'd have used for VTK imports had I needed to import any directories in those I ported to use this setup). --Ben From brad.king at kitware.com Wed Jun 29 09:06:25 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 29 Jun 2016 09:06:25 -0400 Subject: [cmake-developers] Script to update liblzma from upstream. In-Reply-To: <20160629130229.GB17842@megas.kitware.com> References: <20160629130229.GB17842@megas.kitware.com> Message-ID: <5773C7D1.6000605@kitware.com> On 06/29/2016 09:02 AM, Ben Boeckel wrote: >> +readonly ownership="liblzma upstream " > > This should probably use kwrobot at kitware.com as the email. The oddball I > see in the repo now is libarchive. Brad, why is that not kwrobot? If there is a developer mailing list I typically use that. Otherwise I use kwrobot. -Brad From ben.boeckel at kitware.com Wed Jun 29 09:12:21 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 29 Jun 2016 09:12:21 -0400 Subject: [cmake-developers] Script to update liblzma from upstream. In-Reply-To: <5773C7D1.6000605@kitware.com> References: <20160629130229.GB17842@megas.kitware.com> <5773C7D1.6000605@kitware.com> Message-ID: <20160629131221.GD17842@megas.kitware.com> On Wed, Jun 29, 2016 at 09:06:25 -0400, Brad King wrote: > If there is a developer mailing list I typically use that. > Otherwise I use kwrobot. Ah, makes sense. --Ben From chuck.atkins at kitware.com Wed Jun 29 09:40:08 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Wed, 29 Jun 2016 09:40:08 -0400 Subject: [cmake-developers] adding FindJsonCpp In-Reply-To: <20160629120905.GB5811@megas.kitware.com> References: <20160629120905.GB5811@megas.kitware.com> Message-ID: > > The library builds using CMake and rather than using more code to find > itself, it should instead create a package configuration file which > contains the exact information CMake needs to use its install tree. See > the docs: > > > https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-packages > > Please consider contributing such support to the upstream project. > It already does. There used to be a FindJsonCpp.cmake module but it was dropped from the install once the project started generating package configs. See CMake commit https://gitlab.kitware.com/cmake/cmake/commit/a5768442636c7fe909e8afc205fd19ac13b9fbc2 Unfortunately, the cmake package generation is disabled by default. On top of that, it supports both cmake and scons and it seems like most distributions build their packages from scons. Both of these make it incredibly unlikely that the upstream package config will be available in an install even though it's provided by the project. Given these issues, how about we "bring back" the FindJsonCpp module, and alter it to explicitly look for the package config first. It's still in the Modules tree and is actually used by CMake to build itself, it'd just not installed. Thoughts? - Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Jun 29 09:45:36 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 29 Jun 2016 09:45:36 -0400 Subject: [cmake-developers] adding FindJsonCpp In-Reply-To: References: <20160629120905.GB5811@megas.kitware.com> Message-ID: <5773D100.1040301@kitware.com> On 06/29/2016 09:40 AM, Chuck Atkins wrote: > Given these issues, how about we "bring back" the FindJsonCpp module, > and alter it to explicitly look for the package config first. > It's still in the Modules tree and is actually used by CMake to build > itself, it'd just not installed. It is in Source/Modules/FindJsonCpp.cmake right now. I'd be fine with moving it to Modules and distributing it given the upstream situation. -Brad From brad.king at kitware.com Wed Jun 29 10:21:02 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 29 Jun 2016 10:21:02 -0400 Subject: [cmake-developers] Script to update liblzma from upstream. In-Reply-To: References: Message-ID: <5773D94E.4050809@kitware.com> On 06/28/2016 05:24 PM, Daniel Pfeifer wrote: > I have attached a patch that adds a script to update liblzma from > upstream (closely modeled after the other update scripts). I am not > sure how these kinds of scripts need to be run. > > We currently have a copy of liblzma version 5.0.5. The latest version > on the 5.0 branch is 5.0.8. Once the script is introduced, we may > consider switching to the 5.2 branch. I've merged an `update-libarchive` topic to `next`: Merge topic 'update-liblzma' into next https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4e7bb44e that uses your update script with minor tweaks. First I re-imported the existing version with it to transition the infrastructure. I manually edited the parent of the new import root commit to connect to the old import branch. Then I ran the update to 5.0.8 and resolved the conflicts. Once that is in `master` please look at following the pattern to update to 5.2.2. Just resolve conflicts on the first merge and then follow up with changes to port back to C90 in separate commits. See the log of the Utilities/cmliblzma directory for how this was done before. Thanks, -Brad From roman.wueger at gmx.at Wed Jun 29 10:48:10 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Wed, 29 Jun 2016 16:48:10 +0200 Subject: [cmake-developers] [CMake] [iOS] What is the correct way to add resources to an XCode project In-Reply-To: <20160629125248.GA17842@megas.kitware.com> References: <21D325C1-601B-4393-8BBB-7D82B36456E7@gmx.at> <20160629125248.GA17842@megas.kitware.com> Message-ID: <2CE602FB-9C41-4D77-856F-ED148765CC08@gmx.at> Thanks Ben, I know because I wrote this ticket. I thought this was "closed/want fixed" because of the implementation for RESOURCE a few days ago. Regards Roman > Am 29.06.2016 um 14:52 schrieb Ben Boeckel : > >> On Tue, Jun 28, 2016 at 23:01:56 +0200, Roman W?ger wrote: >> The target property RESOURCE does only allow files but no directories. > > There's an open issue for this: > > https://gitlab.kitware.com/cmake/cmake/issues/14743 > > --Ben From ben.boeckel at kitware.com Wed Jun 29 11:27:31 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 29 Jun 2016 11:27:31 -0400 Subject: [cmake-developers] [CMake] [iOS] What is the correct way to add resources to an XCode project In-Reply-To: <2CE602FB-9C41-4D77-856F-ED148765CC08@gmx.at> References: <21D325C1-601B-4393-8BBB-7D82B36456E7@gmx.at> <20160629125248.GA17842@megas.kitware.com> <2CE602FB-9C41-4D77-856F-ED148765CC08@gmx.at> Message-ID: <20160629152731.GB4279@megas.kitware.com> On Wed, Jun 29, 2016 at 16:48:10 +0200, Roman W?ger wrote: > I know because I wrote this ticket. Ah. I didn't check the Mantis side. > I thought this was "closed/want fixed" because of the implementation > for RESOURCE a few days ago. Hmm. I don't see that. Do you have a link? --Ben From farbos.arnaud at gmail.com Wed Jun 29 11:36:45 2016 From: farbos.arnaud at gmail.com (Farbos a) Date: Wed, 29 Jun 2016 17:36:45 +0200 Subject: [cmake-developers] adding FindJsonCpp In-Reply-To: <5773D100.1040301@kitware.com> References: <20160629120905.GB5811@megas.kitware.com> <5773D100.1040301@kitware.com> Message-ID: I have a concern with generating package configs: 1 It seems to contain absolute path, so not really portable with git. 2 It does not respect the naming of imported targets with `::`. As you can see here: https://cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#a-sample-find-module The fact that it produces an appropriate diagnostic messages if that target does not exist is really helpful. Thanks, 2016-06-29 15:45 GMT+02:00 Brad King : > On 06/29/2016 09:40 AM, Chuck Atkins wrote: >> Given these issues, how about we "bring back" the FindJsonCpp module, >> and alter it to explicitly look for the package config first. >> It's still in the Modules tree and is actually used by CMake to build >> itself, it'd just not installed. > > It is in Source/Modules/FindJsonCpp.cmake right now. I'd be fine with > moving it to Modules and distributing it given the upstream situation. > > -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 -- Arnaud FARBOS From konstantin at podsvirov.pro Wed Jun 29 12:28:16 2016 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Wed, 29 Jun 2016 19:28:16 +0300 Subject: [cmake-developers] [PATCH] Merge Request 26 and 27 Message-ID: <321561467217696@web29o.yandex.ru> Hello, Brad! Some time ago I created two merge request: https://gitlab.kitware.com/cmake/cmake/merge_requests/26 https://gitlab.kitware.com/cmake/cmake/merge_requests/27 I received some comments from Ben Boeckel and resolve them. Please consider the possibility of a merge it. -- Regards, Konstantin Podsvirov From ben.boeckel at kitware.com Wed Jun 29 13:31:47 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 29 Jun 2016 13:31:47 -0400 Subject: [cmake-developers] adding FindJsonCpp In-Reply-To: References: <20160629120905.GB5811@megas.kitware.com> <5773D100.1040301@kitware.com> Message-ID: <20160629173147.GA10033@rotor> On Wed, Jun 29, 2016 at 17:36:45 +0200, Farbos a wrote: > I have a concern with generating package configs: > > 1 It seems to contain absolute path, so not really portable with git. The actual config files are generated at build time, not committed to the source control (template files with @variable@ spots to insert values are committed). > 2 It does not respect the naming of imported targets with `::`. As you > can see here: https://cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#a-sample-find-module > The fact that it produces an appropriate diagnostic messages if that > target does not exist is really helpful. Not sure exactly what you mean when the config file approach "does not respect" imported target names, but the file that CMake generates is not the direct config file, but is usually included (I have CMake generate ${pkg}-targets.cmake). Checking for targets in the top-level script is certainly possible. --Ben From robert.maynard at kitware.com Wed Jun 29 15:30:45 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 29 Jun 2016 15:30:45 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.6.0-rc4 now ready for testing! Message-ID: I am proud to announce the fourth CMake 3.6 release candidate. Sources and binaries are available at: https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.6 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.6/release/3.6.html Some of the more significant features of CMake 3.6 are: * The "Visual Studio 14 2015" generator learned to support the Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This feature is experimental. * The "list()" command gained a "FILTER" sub-command to filter list elements by regular expression. * A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally tell the "try_compile()" command to build a static library instead of an executable. This is useful for cross-compiling toolchains that cannot link binaries without custom flags or scripts. * A "_CLANG_TIDY" target property and supporting "CMAKE__CLANG_TIDY" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "clang-tidy" along with the compiler for "C" and "CXX" languages. * The "ExternalProject" module leared the "GIT_SHALLOW 1" option to perform a shallow clone of a Git repository. * The "ExternalProject" module learned to initialize Git submodules recursively and also to initialize new submodules on updates. Use the "GIT_SUBMODULES" option to restrict which submodules are initalized and updated. * The "InstallRequiredSystemLibraries" module learned a new "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment of the Windows Universal CRT libraries with Visual Studio 2015. * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX platforms. Deprecated and Removed Features =============================== * The "CMakeForceCompiler" module and its macros are now deprecated. See module documentation for an explanation. * The "Visual Studio 7 .NET 2003" generator is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 7" generator (for VS .NET 2002) has been removed. It had been deprecated since CMake 3.3. * The "Visual Studio 6" generator has been removed. It had been deprecated since CMake 3.3. CMake 3.6 Release Notes *********************** Changes made since CMake 3.5 include the following. New Features ============ Generators ---------- * The "Ninja" generator learned to produce phony targets of the form "sub/dir/all" to drive the build of a subdirectory. This is equivalent to "cd sub/dir; make all" with Makefile Generators. * The "Ninja" generator now includes system header files in build dependencies to ensure correct re-builds when system packages are updated. * The "Visual Studio 14 2015" generator learned to support the Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This feature is experimental. Commands -------- * The "add_custom_command()" and "add_custom_target()" commands learned how to use the "CROSSCOMPILING_EMULATOR" executable target property. * The "install()" command learned a new "EXCLUDE_FROM_ALL" option to leave installation rules out of the default installation. * The "list()" command gained a "FILTER" sub-command to filter list elements by regular expression. * The "string(TIMESTAMP)" and "file(TIMESTAMP)" commands gained support for the "%s" placeholder. This is the number of seconds since the UNIX Epoch. Variables --------- * A "CMAKE_DEPENDS_IN_PROJECT_ONLY" variable was introduced to tell Makefile Generators to limit dependency scanning only to files in the project source and build trees. * A new "CMAKE_HOST_SOLARIS" variable was introduced to indicate when CMake is running on an Oracle Solaris host. * A "CMAKE__STANDARD_INCLUDE_DIRECTORIES" variable was added for use by toolchain files to specify system include directories to be appended to all compiler command lines. * The "CMAKE__STANDARD_LIBRARIES" variable is now documented. It is intended for use by toolchain files to specify system libraries to be added to all linker command lines. * A "CMAKE_NINJA_OUTPUT_PATH_PREFIX" variable was introduced to tell the "Ninja" generator to configure the generated "build.ninja" file for use as a "subninja". * A "CMAKE_TRY_COMPILE_PLATFORM_VARIABLES" variable was added for use by toolchain files to specify platform-specific variables that must be propagated by the "try_compile()" command into test projects. * A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally tell the "try_compile()" command to build a static library instead of an executable. This is useful for cross-compiling toolchains that cannot link binaries without custom flags or scripts. Properties ---------- * A "DEPLOYMENT_REMOTE_DIRECTORY" target property was introduced to tell the "Visual Studio 9 2008" and "Visual Studio 8 2005" generators to generate the "remote directory" for WinCE project deployment and debugger settings. * A "_CLANG_TIDY" target property and supporting "CMAKE__CLANG_TIDY" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "clang-tidy" along with the compiler for "C" and "CXX" languages. * A "TIMEOUT_AFTER_MATCH" test property was introduced to optionally tell CTest to enforce a secondary timeout after matching certain output from a test. * A "VS_CONFIGURATION_TYPE" target property was introduced to specify a custom project file type for Visual Studio Generators supporting VS 2010 and above. * A "VS_STARTUP_PROJECT" directory property was introduced to specify for Visual Studio Generators the default startup project for generated solutions (".sln" files). Modules ------- * The "CMakePushCheckState" module now pushes/pops/resets the variable "CMAKE_EXTRA_INCLUDE_FILE" used in "CheckTypeSize". * The "ExternalProject" module leared the "GIT_SHALLOW 1" option to perform a shallow clone of a Git repository. * The "ExternalProject" module learned to initialize Git submodules recursively and also to initialize new submodules on updates. Use the "GIT_SUBMODULES" option to restrict which submodules are initalized and updated. * The "ExternalProject" module leared the "DOWNLOAD_NO_EXTRACT 1" argument to skip extracting the file that is downloaded (e.g., for self-extracting shell installers or ".msi" files). * The "ExternalProject" module now uses "TLS_VERIFY" when fetching from git repositories. * The "FindBLAS" and "FindLAPACK" modules learned to support OpenBLAS. * The "FindCUDA" module learned to find the "cublas_device" library. * The "FindGTest" module "gtest_add_tests" function now causes CMake to automatically re-run when test sources change so that they can be re-scanned. * The "FindLTTngUST" module was introduced to find the LTTng-UST library. * The "FindPkgConfig" module learned to optionally create imported targets for the libraries it has found. * The "FindProtobuf" module learned to provide a "Protobuf_VERSION" variable and check the version number requested in a "find_package()" call. * The "InstallRequiredSystemLibraries" module learned a new "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment of the Windows Universal CRT libraries with Visual Studio 2015. Platforms --------- * The Clang compiler is now supported on CYGWIN. * Support was added for the Bruce C Compiler with compiler id "Bruce". CTest ----- * The "ctest_update()" command now looks at the "CTEST_GIT_INIT_SUBMODULES" variable to determine whether submodules should be updated or not before updating. * The "ctest_update()" command will now synchronize submodules on an update. Updates which add submodules or change a submodule's URL will now be pulled properly. CPack ----- * The "CPackDeb" module learned how to handle "$ORIGIN" in "CMAKE_INSTALL_RPATH" when "CPACK_DEBIAN_PACKAGE_SHLIBDEPS" is used for dependency auto detection. * The "CPackDeb" module learned how to generate "DEBIAN/shlibs" contorl file when package contains shared libraries. * The "CPackDeb" module learned how to generate "DEBIAN/postinst" and "DEBIAN/postrm" files if the package installs libraries in ldconfig- controlled locations (e.g. "/lib/", "/usr/lib/"). * The "CPackDeb" module learned how to generate dependencies between Debian packages if multi-component setup is used and "CPACK_COMPONENT__DEPENDS" variables are set. For backward compatibility this feature is disabled by default. See "CPACK_DEBIAN_ENABLE_COMPONENT_DEPENDS". * The "CPackDeb" module learned how to set custom package file names including how to generate properly-named Debian packages: _-_.deb For backward compatibility this feature is disabled by default. See "CPACK_DEBIAN_FILE_NAME" and "CPACK_DEBIAN__FILE_NAME". * The "CPackDeb" module learned how to set the package release number ("DebianRevisionNumber" in package file name when used in combination with "DEB-DEFAULT" value set by "CPACK_DEBIAN_FILE_NAME"). See "CPACK_DEBIAN_PACKAGE_RELEASE". * The "CPackDeb" module learned how to set the package architecture per-component. See "CPACK_DEBIAN__PACKAGE_ARCHITECTURE". * The "CPackDMG" module learned a new option to tell the CPack "DragNDrop" generaor to skip the "/Applications" symlink. See the "CPACK_DMG_DISABLE_APPLICATIONS_SYMLINK" variable. * The "CPackIFW" module gained a new "cpack_ifw_update_repository()" command to update a QtIFW-specific repository from a remote repository. * The "CPackRPM" module learned how to set RPM "dist" tag as part of RPM "Release:" tag when enabled (mandatory on some Linux distributions for e.g. on Fedora). See "CPACK_RPM_PACKAGE_RELEASE_DIST". * The "CPackRPM" module learned how to set default values for owning user/group and file/directory permissions of package content. See "CPACK_RPM_DEFAULT_USER", "CPACK_RPM_DEFAULT_GROUP", "CPACK_RPM_DEFAULT_FILE_PERMISSIONS", "CPACK_RPM_DEFAULT_DIR_PERMISSIONS" and their per component counterparts. * The "CPackRPM" module learned how to set user defined package file names, how to specify that rpmbuild should decide on file name format as well as handling of multiple rpm packages generated by a single user defined spec file. See "CPACK_RPM_PACKAGE_NAME" and "CPACK_RPM__PACKAGE_NAME". * The "CPackRPM" module learned how to correctly handle symlinks that are pointing outside generated packages. Other ----- * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX platforms. Deprecated and Removed Features =============================== * The "CMakeForceCompiler" module and its macros are now deprecated. See module documentation for an explanation. * The "find_library()", "find_path()", and "find_file()" commands no longer search in installation prefixes derived from the "PATH" environment variable on non-Windows platforms. This behavior was added in CMake 3.3 to support Windows hosts but has proven problematic on UNIX hosts. Users that keep some "/bin" directories in the "PATH" just for their tools do not necessarily want any supporting "/lib" directories searched. One may set the "CMAKE_PREFIX_PATH" environment variable with a ;-list of prefixes that are to be searched. * The "Visual Studio 7 .NET 2003" generator is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 7" generator (for VS .NET 2002) has been removed. It had been deprecated since CMake 3.3. * The "Visual Studio 6" generator has been removed. It had been deprecated since CMake 3.3. Other Changes ============= * The precompiled OS X binary provided on "cmake.org" now requires OS X 10.7 or newer. * On Linux and FreeBSD platforms, when building CMake itself from source and not using a system-provided libcurl, OpenSSL is now used by default if it is found on the system. This enables SSL/TLS support for commands supporting network communication via "https", such as "file(DOWNLOAD)", "file(UPLOAD)", and "ctest_submit()". * The "cmake(1)" "--build" command-line tool now rejects multiple "-- target" options with an error instead of silently ignoring all but the last one. * "AUTOMOC" now diagnoses name collisions when multiple source files in different directories use "#include " with the same name (because the generated "moc_foo.cpp" files would collide). * The "FindBISON" module "BISON_TARGET" macro now supports special characters by passing the "VERBATIM" option to internal "add_custom_command()" calls. This may break clients that added escaping manually to work around the bug. * The "FindFLEX" module "FLEX_TARGET" macro now supports special characters by passing the "VERBATIM" option to internal "add_custom_command()" calls. This may break clients that added escaping manually to work around the bug. * The "FindProtobuf" module input and output variables were all renamed from "PROTOBUF_" to "Protobuf_" for consistency with other find modules. Input variables of the old case will be honored if provided, and output variables of the old case are always provided. * The "CPackRPM" module now supports upper cased component names in per component CPackRPM specific variables. E.g. component named "foo" now expects component specific variable to be "CPACK_RPM_FOO_PACKAGE_NAME" while before it expected "CPACK_RPM_foo_PACKAGE_NAME". Upper cased component name part in variables is compatible with convention used for other CPack variables. For back compatibility old format of variables is still valid and preferred if both versions of variable are set, but the preferred future use is upper cased component names in variables. New variables that will be added to CPackRPM in later versions will only support upper cased component variable format. ---------------------------------------------------------------------------- Changes made since CMake 3.6.0-rc3: Bartosz Kosiorek (1): Help: Describe VERSION and SOVERSION meanings for Mach-O binaries Ben Boeckel (1): ninja, rc: ignore CMAKE_NINJA_FORCE_RESPONSE_FILE for RC files Brad King (2): Revert "try_compile: Honor CMAKE__FLAGS_ changes" CMake 3.6.0-rc4 Gregor Jasny (1): Help: Cross reference CXX_STANDARD and CXX_EXTENSIONS (#16162) Robert Maynard (5): FindHDF5: correctly add lang to each component target name. FindHDF5: Handle HDF5 builds with non-suffixed components FindHDF5: When component targets not found fallback to compiler wrappers FindHDF5: cache the correct path to the high level libraries FindHDF5: create all the *_LIBRARIES when using hdf5-config.cmake Rolf Eike Beer (1): GetPrerequisites: fix typo in comment From farbos.arnaud at gmail.com Thu Jun 30 04:24:01 2016 From: farbos.arnaud at gmail.com (Farbos a) Date: Thu, 30 Jun 2016 10:24:01 +0200 Subject: [cmake-developers] adding FindJsonCpp In-Reply-To: <20160629173147.GA10033@rotor> References: <20160629120905.GB5811@megas.kitware.com> <5773D100.1040301@kitware.com> <20160629173147.GA10033@rotor> Message-ID: Hi, 2016-06-29 19:31 GMT+02:00 Ben Boeckel : > On Wed, Jun 29, 2016 at 17:36:45 +0200, Farbos a wrote: >> I have a concern with generating package configs: >> >> 1 It seems to contain absolute path, so not really portable with git. > > The actual config files are generated at build time, not committed to > the source control (template files with @variable@ spots to insert > values are committed). I am not sure to understand what you are saying, did they do something wrong or could we add some stuff in order to make in work with a source control software. Just to be sure we are talking about these lines: https://github.com/open-source-parsers/jsoncpp/blob/master/CMakeLists.txt#L144 >> 2 It does not respect the naming of imported targets with `::`. As you >> can see here: https://cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#a-sample-find-module >> The fact that it produces an appropriate diagnostic messages if that >> target does not exist is really helpful. > > Not sure exactly what you mean when the config file approach "does not > respect" imported target names, but the file that CMake generates is not > the direct config file, but is usually included (I have CMake generate > ${pkg}-targets.cmake). Checking for targets in the top-level script is > certainly possible. When I look at the generated file here jsoncppConfig.cmake, you find these lines: ``` # Create imported target jsoncpp_lib add_library(jsoncpp_lib SHARED IMPORTED) set_target_properties(jsoncpp_lib PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "/home/hevy/jsoncpp/0.10.5/include" ) ... ``` The thing here is the library name is jsoncpp_lib and not something like jsoncpp::jsoncpp_lib. And like I said earlier the name "::" is a lot more helpful. Thanks, -- Arnaud FARBOS From Tobias.Hunger at qt.io Thu Jun 30 09:51:57 2016 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Thu, 30 Jun 2016 13:51:57 +0000 Subject: [cmake-developers] cmake -E capabilities Message-ID: <1467294716.811.298.camel@qt.io> Hello CMake Developers! As laid out in the last mail thread about daemon-mode in CMake (for your reference:?http://public.kitware.com/pipermail/cmake-developers/2016-June/028777 .html?), Stephen and me agreed that we needed a way for IDEs to figure out which generators are available to cmake and more static information built into CMake. There is actually a bug report about the need for this feature here: https://gitlab.kitware.com/cmake/cmake/issues/15462 This is my attempt to solve the issue: https://github.com/hunger/CMake/commits/cmake-capabilities The output looks like this: > cmake -E capabilities --pretty-print { ???"generators" : [ ??????{ ?????????"extraGenerators" : [], ?????????"name" : "Watcom WMake", ?????????"toolSetSupport" : false ??????}, ??????{ ?????????"extraGenerators" : [ "CodeBlocks", "CodeLite", "Eclipse CDT4", "Kate", "Sublime Text 2" ], ?????????"name" : "Ninja", ?????????"toolSetSupport" : false ??????}, ??????{ ?????????"extraGenerators" : [ ????????????"CodeBlocks", ????????????"CodeLite", ????????????"Eclipse CDT4", ????????????"KDevelop3", ????????????"Kate", ????????????"Sublime Text 2" ?????????], ?????????"name" : "Unix Makefiles", ?????????"toolSetSupport" : false ??????} ???], ???"server-mode" : false, ???"version" : { ??????"major" : 3, ??????"minor" : 6, ??????"patch" : 20160630, ??????"string" : "3.6.20160630-g2c759-dirty" ???} } This is running on my Linux machine. What do you think? What else should we report here? Compared to the bug report mentioned above the fields "multiconfig" and "recursive" are missing. I could not figure out how to get that information:-/ I could also not yet figure out a way to retrieve information on supported platforms and toolsets. At least I did get whether a generator supports toolsets, but nothing similar seems to exist for the platform part. Does anyone have an idea how I could retrieve this information? I would also welcome some code review on the patch. The remaining items on my server-mode todo list are all about removing similar information from the server-mode commands:-) Best Regards, Tobias -- Tobias Hunger,?Senior?Software Engineer?| The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From robert.maynard at kitware.com Thu Jun 30 14:16:05 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 30 Jun 2016 14:16:05 -0400 Subject: [cmake-developers] cmake -E capabilities In-Reply-To: <1467294716.811.298.camel@qt.io> References: <1467294716.811.298.camel@qt.io> Message-ID: It might be worthwhile to have the version section to have an explicit dirty key instead of having to parse the string key to find that information out. Also wouldn't you want server-mode to be an empty dictionary, as in the future that would contain information like the wire format version, etc. On Thu, Jun 30, 2016 at 9:51 AM, Tobias Hunger wrote: > Hello CMake Developers! > > As laid out in the last mail thread about daemon-mode in CMake (for your > reference: http://public.kitware.com/pipermail/cmake-developers/2016-June/028777 > .html ), Stephen and me agreed that we needed a way for IDEs to figure out which > generators are available to cmake and more static information built into CMake. > > There is actually a bug report about the need for this feature here: > https://gitlab.kitware.com/cmake/cmake/issues/15462 > > This is my attempt to solve the issue: > https://github.com/hunger/CMake/commits/cmake-capabilities > > The output looks like this: >> cmake -E capabilities --pretty-print > { > "generators" : [ > { > "extraGenerators" : [], > "name" : "Watcom WMake", > "toolSetSupport" : false > }, > { > "extraGenerators" : [ "CodeBlocks", "CodeLite", "Eclipse CDT4", "Kate", > "Sublime Text 2" ], > "name" : "Ninja", > "toolSetSupport" : false > }, > { > "extraGenerators" : [ > "CodeBlocks", > "CodeLite", > "Eclipse CDT4", > "KDevelop3", > "Kate", > "Sublime Text 2" > ], > "name" : "Unix Makefiles", > "toolSetSupport" : false > } > ], > "server-mode" : false, > "version" : { > "major" : 3, > "minor" : 6, > "patch" : 20160630, > "string" : "3.6.20160630-g2c759-dirty" > } > } > > This is running on my Linux machine. > > What do you think? What else should we report here? > > Compared to the bug report mentioned above the fields "multiconfig" and > "recursive" are missing. I could not figure out how to get that information:-/ > > I could also not yet figure out a way to retrieve information on supported > platforms and toolsets. At least I did get whether a generator supports > toolsets, but nothing similar seems to exist for the platform part. > > Does anyone have an idea how I could retrieve this information? > > I would also welcome some code review on the patch. The remaining items on my > server-mode todo list are all about removing similar information from the > server-mode commands:-) > > Best Regards, > Tobias > > -- > Tobias Hunger, Senior Software Engineer | The Qt Company > The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin > Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius, Mika Harjuaho. Sitz der > Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/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 Thu Jun 30 15:00:17 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 30 Jun 2016 15:00:17 -0400 Subject: [cmake-developers] cmake -E capabilities In-Reply-To: <1467294716.811.298.camel@qt.io> References: <1467294716.811.298.camel@qt.io> Message-ID: <57756C41.5070001@kitware.com> On 06/30/2016 09:51 AM, Tobias Hunger wrote: > Compared to the bug report mentioned above the fields "multiconfig" and > "recursive" are missing. I could not figure out how to get that information:-/ There is no "recursive" generator, so that does not belong in the example anyway. The Makefile generator does not produce recursive makefiles: https://cmake.org/Wiki/CMake_FAQ#Why_does_CMake_generate_recursive_Makefiles.3F For "multiconfig", there is the cmGlobalGenerator::IsMultiConfig method. Something similar will have to be added to the generator factory APIs so that we can ask for this information without creating a generator. > I could also not yet figure out a way to retrieve information on supported > platforms and toolsets. At least I did get whether a generator supports > toolsets, but nothing similar seems to exist for the platform part. We don't have any information on supported platforms or toolsets. The CMAKE_GENERATOR_PLATFORM and CMAKE_GENERATOR_TOOLSET settings take user-specified values and we pass them through to native tools. It is up to the user to provide valid values. However, we can at least report whether the platform/toolset options are supported by a given generator. For this one could add APIs to generator factories as mentioned above for multiconfig. -Brad From ruslan_baratov at yahoo.com Thu Jun 30 15:23:38 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Thu, 30 Jun 2016 22:23:38 +0300 Subject: [cmake-developers] [patch] Document -H and -B Message-ID: Hi, Patch with undocumented options -H/-B. Ruslo -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Document-H-and-B-options.patch Type: text/x-patch Size: 1741 bytes Desc: not available URL: From brad.king at kitware.com Thu Jun 30 15:31:27 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 30 Jun 2016 15:31:27 -0400 Subject: [cmake-developers] [patch] Document -H and -B In-Reply-To: References: Message-ID: <5775738F.8000709@kitware.com> On 06/30/2016 03:23 PM, Ruslan Baratov via cmake-developers wrote: > Patch with undocumented options -H/-B. These are undocumented because they are internal options that are not meant for public use. -Brad From ruslan_baratov at yahoo.com Thu Jun 30 15:56:05 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Thu, 30 Jun 2016 22:56:05 +0300 Subject: [cmake-developers] [patch] Document -H and -B In-Reply-To: <5775738F.8000709@kitware.com> References: <5775738F.8000709@kitware.com> Message-ID: On 30-Jun-16 22:31, Brad King wrote: > On 06/30/2016 03:23 PM, Ruslan Baratov via cmake-developers wrote: >> Patch with undocumented options -H/-B. > These are undocumented because they are internal options that > are not meant for public use. What is the public-use way to specify source-tree and build-tree by cmake options simultaneously? If there is no such, what is the problem with making existing options public? Ruslo From brad.king at kitware.com Thu Jun 30 16:18:03 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 30 Jun 2016 16:18:03 -0400 Subject: [cmake-developers] [patch] Document -H and -B In-Reply-To: References: <5775738F.8000709@kitware.com> Message-ID: <57757E7B.9050904@kitware.com> On 06/30/2016 03:56 PM, Ruslan Baratov wrote: > What is the public-use way to specify source-tree and build-tree by > cmake options simultaneously? cd $build && cmake $src -Brad From ruslan_baratov at yahoo.com Thu Jun 30 16:28:29 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Thu, 30 Jun 2016 23:28:29 +0300 Subject: [cmake-developers] [patch] Document -H and -B In-Reply-To: <57757E7B.9050904@kitware.com> References: <5775738F.8000709@kitware.com> <57757E7B.9050904@kitware.com> Message-ID: <29b0ce9f-77e0-9019-1f5b-c027786211f0@yahoo.com> On 30-Jun-16 23:18, Brad King wrote: > On 06/30/2016 03:56 PM, Ruslan Baratov wrote: >> What is the public-use way to specify source-tree and build-tree by >> cmake options simultaneously? > cd $build && cmake $src Will not work if $build not exists. From brad.king at kitware.com Thu Jun 30 16:40:10 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 30 Jun 2016 16:40:10 -0400 Subject: [cmake-developers] [patch] Document -H and -B In-Reply-To: <29b0ce9f-77e0-9019-1f5b-c027786211f0@yahoo.com> References: <5775738F.8000709@kitware.com> <57757E7B.9050904@kitware.com> <29b0ce9f-77e0-9019-1f5b-c027786211f0@yahoo.com> Message-ID: <577583AA.90006@kitware.com> On 06/30/2016 04:28 PM, Ruslan Baratov wrote: > On 30-Jun-16 23:18, Brad King wrote: >> On 06/30/2016 03:56 PM, Ruslan Baratov wrote: >>> What is the public-use way to specify source-tree and build-tree by >>> cmake options simultaneously? >> cd $build && cmake $src > > Will not work if $build not exists. mkdir -p "$build" && cd "$build" && cmake "$src" -Brad From ruslan_baratov at yahoo.com Thu Jun 30 16:54:42 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Thu, 30 Jun 2016 23:54:42 +0300 Subject: [cmake-developers] [patch] Document -H and -B In-Reply-To: <577583AA.90006@kitware.com> References: <5775738F.8000709@kitware.com> <57757E7B.9050904@kitware.com> <29b0ce9f-77e0-9019-1f5b-c027786211f0@yahoo.com> <577583AA.90006@kitware.com> Message-ID: <18d3adb8-9119-531b-adf4-09b79d174bf3@yahoo.com> On 30-Jun-16 23:40, Brad King wrote: > On 06/30/2016 04:28 PM, Ruslan Baratov wrote: >> On 30-Jun-16 23:18, Brad King wrote: >>> On 06/30/2016 03:56 PM, Ruslan Baratov wrote: >>>> What is the public-use way to specify source-tree and build-tree by >>>> cmake options simultaneously? >>> cd $build && cmake $src >> Will not work if $build not exists. > mkdir -p "$build" && cd "$build" && cmake "$src" Next issue is that this command change directory, how can I move back to the directory where I was working on? From eike at sf-mail.de Thu Jun 30 16:57:11 2016 From: eike at sf-mail.de (Rolf Eike Beer) Date: Thu, 30 Jun 2016 22:57:11 +0200 Subject: [cmake-developers] [patch] Document -H and -B In-Reply-To: <18d3adb8-9119-531b-adf4-09b79d174bf3@yahoo.com> References: <577583AA.90006@kitware.com> <18d3adb8-9119-531b-adf4-09b79d174bf3@yahoo.com> Message-ID: <5895197.6gv5HuBqj0@caliban.sf-tec.de> Am Donnerstag, 30. Juni 2016, 23:54:42 schrieb Ruslan Baratov via cmake- developers: > On 30-Jun-16 23:40, Brad King wrote: > > On 06/30/2016 04:28 PM, Ruslan Baratov wrote: > >> On 30-Jun-16 23:18, Brad King wrote: > >>> On 06/30/2016 03:56 PM, Ruslan Baratov wrote: > >>>> What is the public-use way to specify source-tree and build-tree by > >>>> cmake options simultaneously? > >>> > >>> cd $build && cmake $src > >> > >> Will not work if $build not exists. > > > > mkdir -p "$build" && cd "$build" && cmake "$src" > > Next issue is that this command change directory, how can I move back to > the directory where I was working on? pushd/popd or do the cd/cmake call in a subshell. 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 shawn.waldon at kitware.com Thu Jun 30 16:57:30 2016 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Thu, 30 Jun 2016 16:57:30 -0400 Subject: [cmake-developers] [patch] Document -H and -B In-Reply-To: <18d3adb8-9119-531b-adf4-09b79d174bf3@yahoo.com> References: <5775738F.8000709@kitware.com> <57757E7B.9050904@kitware.com> <29b0ce9f-77e0-9019-1f5b-c027786211f0@yahoo.com> <577583AA.90006@kitware.com> <18d3adb8-9119-531b-adf4-09b79d174bf3@yahoo.com> Message-ID: On Thu, Jun 30, 2016 at 4:54 PM, Ruslan Baratovwrote: > On 30-Jun-16 23:40, Brad King wrote: > >> On 06/30/2016 04:28 PM, Ruslan Baratov wrote: >> >>> On 30-Jun-16 23:18, Brad King wrote: >>> >>>> On 06/30/2016 03:56 PM, Ruslan Baratov wrote: >>>> >>>>> What is the public-use way to specify source-tree and build-tree by >>>>> cmake options simultaneously? >>>>> >>>> cd $build && cmake $src >>>> >>> Will not work if $build not exists. >>> >> mkdir -p "$build" && cd "$build" && cmake "$src" >> > > Next issue is that this command change directory, how can I move back to > the directory where I was working on? mkdir -p "$build" && pushd "$build" && cmake "$src" && popd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Jun 30 17:02:04 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 30 Jun 2016 17:02:04 -0400 Subject: [cmake-developers] [patch] Document -H and -B In-Reply-To: References: <5775738F.8000709@kitware.com> <57757E7B.9050904@kitware.com> <29b0ce9f-77e0-9019-1f5b-c027786211f0@yahoo.com> <577583AA.90006@kitware.com> <18d3adb8-9119-531b-adf4-09b79d174bf3@yahoo.com> Message-ID: <577588CC.30906@kitware.com> On 06/30/2016 04:57 PM, Shawn Waldon wrote: > mkdir -p "$build" && pushd "$build" && cmake "$src" && popd Or use a ()-enclosed subshell: (mkdir -p "$build" && cd "$build" && cmake "$src") -Brad From ruslan_baratov at yahoo.com Thu Jun 30 17:10:42 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Fri, 1 Jul 2016 00:10:42 +0300 Subject: [cmake-developers] [patch] Document -H and -B In-Reply-To: References: <5775738F.8000709@kitware.com> <57757E7B.9050904@kitware.com> <29b0ce9f-77e0-9019-1f5b-c027786211f0@yahoo.com> <577583AA.90006@kitware.com> <18d3adb8-9119-531b-adf4-09b79d174bf3@yahoo.com> Message-ID: On 30-Jun-16 23:57, Shawn Waldon wrote: > On Thu, Jun 30, 2016 at 4:54 PM, Ruslan Baratovwrote: > > On 30-Jun-16 23:40, Brad King wrote: > > On 06/30/2016 04:28 PM, Ruslan Baratov wrote: > > On 30-Jun-16 23:18, Brad King wrote: > > On 06/30/2016 03:56 PM, Ruslan Baratov wrote: > > What is the public-use way to specify source-tree > and build-tree by > cmake options simultaneously? > > cd $build && cmake $src > > Will not work if $build not exists. > > mkdir -p "$build" && cd "$build" && cmake "$src" > > > Next issue is that this command change directory, how can I move > back to the directory where I was working on? > > > mkdir -p "$build" && pushd "$build" && cmake "$src" && popd > Doesn't go back if `cmake "$src"` failed -------------- next part -------------- An HTML attachment was scrubbed... URL: From shawn.waldon at kitware.com Thu Jun 30 17:14:52 2016 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Thu, 30 Jun 2016 17:14:52 -0400 Subject: [cmake-developers] [patch] Document -H and -B In-Reply-To: References: <5775738F.8000709@kitware.com> <57757E7B.9050904@kitware.com> <29b0ce9f-77e0-9019-1f5b-c027786211f0@yahoo.com> <577583AA.90006@kitware.com> <18d3adb8-9119-531b-adf4-09b79d174bf3@yahoo.com> Message-ID: On Thu, Jun 30, 2016 at 5:10 PM, Ruslan Baratov wrote: > On 30-Jun-16 23:57, Shawn Waldon wrote: > > On Thu, Jun 30, 2016 at 4:54 PM, Ruslan Baratovwrote: > >> On 30-Jun-16 23:40, Brad King wrote: >> >>> On 06/30/2016 04:28 PM, Ruslan Baratov wrote: >>> >>>> On 30-Jun-16 23:18, Brad King wrote: >>>> >>>>> On 06/30/2016 03:56 PM, Ruslan Baratov wrote: >>>>> >>>>>> What is the public-use way to specify source-tree and build-tree by >>>>>> cmake options simultaneously? >>>>>> >>>>> cd $build && cmake $src >>>>> >>>> Will not work if $build not exists. >>>> >>> mkdir -p "$build" && cd "$build" && cmake "$src" >>> >> >> Next issue is that this command change directory, how can I move back to >> the directory where I was working on? > > > mkdir -p "$build" && pushd "$build" && cmake "$src" && popd >> > Doesn't go back if `cmake "$src"` failed > I think Brad may have a better idea with the subshell. But to modify this to work even if `cmake "$src"` failed: mkdir -p "$build" && pushd "$build" && cmake "$src"; popd -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruslan_baratov at yahoo.com Thu Jun 30 17:28:16 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Fri, 1 Jul 2016 00:28:16 +0300 Subject: [cmake-developers] [patch] Document -H and -B In-Reply-To: <577588CC.30906@kitware.com> References: <5775738F.8000709@kitware.com> <57757E7B.9050904@kitware.com> <29b0ce9f-77e0-9019-1f5b-c027786211f0@yahoo.com> <577583AA.90006@kitware.com> <18d3adb8-9119-531b-adf4-09b79d174bf3@yahoo.com> <577588CC.30906@kitware.com> Message-ID: <319fbdd8-4757-3a73-198a-4e740e6483b2@yahoo.com> On 01-Jul-16 00:02, Brad King wrote: > On 06/30/2016 04:57 PM, Shawn Waldon wrote: >> mkdir -p "$build" && pushd "$build" && cmake "$src" && popd > Or use a ()-enclosed subshell: > > (mkdir -p "$build" && cd "$build" && cmake "$src") > > -Brad > Okay, this one seems to work. Also you haven't show how `src` defined, e.g. I can't do 'src=.' so it should be src="`pwd`" So instead of "cmake -H. -B_builds" we have (src="`pwd`" build=_builds mkdir -p "$build" && cd "$build" && cmake "$src") And it's only for *nix. What about Windows? Such options definitely would be useful in CMake. Ruslo From ruslan_baratov at yahoo.com Thu Jun 30 17:31:01 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Fri, 1 Jul 2016 00:31:01 +0300 Subject: [cmake-developers] [patch] Document -H and -B In-Reply-To: References: <5775738F.8000709@kitware.com> <57757E7B.9050904@kitware.com> <29b0ce9f-77e0-9019-1f5b-c027786211f0@yahoo.com> <577583AA.90006@kitware.com> <18d3adb8-9119-531b-adf4-09b79d174bf3@yahoo.com> Message-ID: <0b85240a-2f44-2d92-ff75-6f246a654148@yahoo.com> On 01-Jul-16 00:14, Shawn Waldon wrote: > On Thu, Jun 30, 2016 at 5:10 PM, Ruslan Baratov > > wrote: > > On 30-Jun-16 23:57, Shawn Waldon wrote: >> On Thu, Jun 30, 2016 at 4:54 PM, Ruslan Baratovwrote: >> >> On 30-Jun-16 23:40, Brad King wrote: >> >> On 06/30/2016 04:28 PM, Ruslan Baratov wrote: >> >> On 30-Jun-16 23:18, Brad King wrote: >> >> On 06/30/2016 03:56 PM, Ruslan Baratov wrote: >> >> What is the public-use way to specify >> source-tree and build-tree by >> cmake options simultaneously? >> >> cd $build && cmake $src >> >> Will not work if $build not exists. >> >> mkdir -p "$build" && cd "$build" && cmake "$src" >> >> >> Next issue is that this command change directory, how can I >> move back to the directory where I was working on? >> >> >> mkdir -p "$build" && pushd "$build" && cmake "$src" && popd >> > Doesn't go back if `cmake "$src"` failed > > I think Brad may have a better idea with the subshell. But to modify > this to work even if `cmake "$src"` failed: > > mkdir -p "$build" && pushd "$build" && cmake "$src"; popd > echo $? 0 for the CMakeLists.txt with errors -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.gittins at gmail.com Thu Jun 30 17:35:32 2016 From: dave.gittins at gmail.com (Dave Gittins) Date: Fri, 1 Jul 2016 07:35:32 +1000 Subject: [cmake-developers] [patch] Document -H and -B In-Reply-To: <0b85240a-2f44-2d92-ff75-6f246a654148@yahoo.com> References: <5775738F.8000709@kitware.com> <57757E7B.9050904@kitware.com> <29b0ce9f-77e0-9019-1f5b-c027786211f0@yahoo.com> <577583AA.90006@kitware.com> <18d3adb8-9119-531b-adf4-09b79d174bf3@yahoo.com> <0b85240a-2f44-2d92-ff75-6f246a654148@yahoo.com> Message-ID: I don't understand the harm of documenting the options and making them public. Brad can you explain? I have worked with numerous colleagues who use them. So far nothing bad happened to them! Seems to me that they are a) used b) useful c) safe Is there context I am missing? Dave On 1 Jul 2016 7:31 a.m., "Ruslan Baratov via cmake-developers" < cmake-developers at cmake.org> wrote: > On 01-Jul-16 00:14, Shawn Waldon wrote: > > On Thu, Jun 30, 2016 at 5:10 PM, Ruslan Baratov > wrote: > >> On 30-Jun-16 23:57, Shawn Waldon wrote: >> >> On Thu, Jun 30, 2016 at 4:54 PM, Ruslan Baratovwrote: >> >>> On 30-Jun-16 23:40, Brad King wrote: >>> >>>> On 06/30/2016 04:28 PM, Ruslan Baratov wrote: >>>> >>>>> On 30-Jun-16 23:18, Brad King wrote: >>>>> >>>>>> On 06/30/2016 03:56 PM, Ruslan Baratov wrote: >>>>>> >>>>>>> What is the public-use way to specify source-tree and build-tree by >>>>>>> cmake options simultaneously? >>>>>>> >>>>>> cd $build && cmake $src >>>>>> >>>>> Will not work if $build not exists. >>>>> >>>> mkdir -p "$build" && cd "$build" && cmake "$src" >>>> >>> >>> Next issue is that this command change directory, how can I move back to >>> the directory where I was working on? >> >> >> mkdir -p "$build" && pushd "$build" && cmake "$src" && popd >>> >> Doesn't go back if `cmake "$src"` failed >> > I think Brad may have a better idea with the subshell. But to modify this > to work even if `cmake "$src"` failed: > > mkdir -p "$build" && pushd "$build" && cmake "$src"; popd > > > echo $? > 0 > > for the CMakeLists.txt with errors > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/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 davispuh at gmail.com Thu Jun 30 22:18:13 2016 From: davispuh at gmail.com (=?UTF-8?q?D=C4=81vis=20Mos=C4=81ns?=) Date: Fri, 1 Jul 2016 05:18:13 +0300 Subject: [cmake-developers] [PATCH] Improve encoding handling on Windows Message-ID: <20160701021813.28657-1-davispuh@gmail.com> On Windows getenv uses ANSI codepage so it needs to be encoded to internally used encoding (eg. UTF-8). Here we use _wgetenv instead and encode that. Also typically Windows applications (eg. MSVC compiler) use current console's codepage for output to pipes so we need to encode that to internally used encoding (KWSYS_ENCODING_DEFAULT_CODEPAGE). Next, when we're outputing to console need to use wide functions. This change allows that compilers such as MSVC on Windows can be installed in non-ASCII path and will work correctly for all console's codepages which supports that path's characters. --- Source/cmBuildCommand.cxx | 4 ++-- Source/cmCommandArgumentParserHelper.cxx | 4 ++-- Source/cmExtraEclipseCDT4Generator.cxx | 2 +- Source/cmSetCommand.cxx | 2 +- Source/cmSystemTools.cxx | 5 +++++ Source/cmake.cxx | 6 +++--- Source/cmakemain.cxx | 29 ++++++++++++++++++++++++++--- Source/kwsys/CMakeLists.txt | 2 ++ Source/kwsys/Directory.cxx | 2 +- Source/kwsys/FStream.hxx.in | 19 +++++++++++++++++-- Source/kwsys/ProcessWin32.c | 21 ++++++++++++++++++++- Source/kwsys/SystemInformation.cxx | 8 +++++--- Source/kwsys/SystemTools.cxx | 28 ++++++++++++++++++++-------- 13 files changed, 105 insertions(+), 27 deletions(-) diff --git a/Source/cmBuildCommand.cxx b/Source/cmBuildCommand.cxx index fb143a2..16771cc 100644 --- a/Source/cmBuildCommand.cxx +++ b/Source/cmBuildCommand.cxx @@ -77,7 +77,7 @@ bool cmBuildCommand::MainSignature(std::vector const& args) // as the original 2-arg build_command signature: // if (!configuration || !*configuration) { - configuration = getenv("CMAKE_CONFIG_TYPE"); + configuration = cmSystemTools::GetEnv("CMAKE_CONFIG_TYPE"); } if (!configuration || !*configuration) { configuration = "Release"; @@ -109,7 +109,7 @@ bool cmBuildCommand::TwoArgsSignature(std::vector const& args) const char* cacheValue = this->Makefile->GetDefinition(define); std::string configType = "Release"; - const char* cfg = getenv("CMAKE_CONFIG_TYPE"); + const char* cfg = cmSystemTools::GetEnv("CMAKE_CONFIG_TYPE"); if (cfg && *cfg) { configType = cfg; } diff --git a/Source/cmCommandArgumentParserHelper.cxx b/Source/cmCommandArgumentParserHelper.cxx index 294117c..5c615c4 100644 --- a/Source/cmCommandArgumentParserHelper.cxx +++ b/Source/cmCommandArgumentParserHelper.cxx @@ -71,12 +71,12 @@ char* cmCommandArgumentParserHelper::ExpandSpecialVariable(const char* key, return this->EmptyVariable; } if (strcmp(key, "ENV") == 0) { - char* ptr = getenv(var); + const char* ptr = cmSystemTools::GetEnv(var); if (ptr) { if (this->EscapeQuotes) { return this->AddString(cmSystemTools::EscapeQuotes(ptr)); } else { - return ptr; + return (char *)ptr; } } return this->EmptyVariable; diff --git a/Source/cmExtraEclipseCDT4Generator.cxx b/Source/cmExtraEclipseCDT4Generator.cxx index 16cb082..6c9e9a1 100644 --- a/Source/cmExtraEclipseCDT4Generator.cxx +++ b/Source/cmExtraEclipseCDT4Generator.cxx @@ -208,7 +208,7 @@ void cmExtraEclipseCDT4Generator::AddEnvVar(std::ostream& out, // get the variables from the environment and from the cache and then // figure out which one to use: - const char* envVarValue = getenv(envVar); + const char* envVarValue = cmSystemTools::GetEnv(envVar); std::string cacheEntryName = "CMAKE_ECLIPSE_ENVVAR_"; cacheEntryName += envVar; diff --git a/Source/cmSetCommand.cxx b/Source/cmSetCommand.cxx index 1484368..c0f8ab6 100644 --- a/Source/cmSetCommand.cxx +++ b/Source/cmSetCommand.cxx @@ -31,7 +31,7 @@ bool cmSetCommand::InitialPass(std::vector const& args, putEnvArg += "="; // what is the current value if any - const char* currValue = getenv(varName); + const char* currValue = cmSystemTools::GetEnv(varName); delete[] varName; // will it be set to something, then set it diff --git a/Source/cmSystemTools.cxx b/Source/cmSystemTools.cxx index 2d463f3..d8a1437 100644 --- a/Source/cmSystemTools.cxx +++ b/Source/cmSystemTools.cxx @@ -333,7 +333,12 @@ void cmSystemTools::Message(const char* m1, const char* title) s_MessageCallbackClientData); return; } else { +#if defined(_WIN32) + std::wstring wm1 = cmsys::Encoding::ToWide(m1); + std::wcerr << wm1 << std::endl << std::flush; +#else std::cerr << m1 << std::endl << std::flush; +#endif } } diff --git a/Source/cmake.cxx b/Source/cmake.cxx index c597605..94ecd81 100644 --- a/Source/cmake.cxx +++ b/Source/cmake.cxx @@ -955,8 +955,8 @@ void cmake::SetGlobalGenerator(cmGlobalGenerator* gg) cmSystemTools::SetForceUnixPaths(this->GlobalGenerator->GetForceUnixPaths()); // Save the environment variables CXX and CC - const char* cxx = getenv("CXX"); - const char* cc = getenv("CC"); + const char* cxx = cmSystemTools::GetEnv("CXX"); + const char* cc = cmSystemTools::GetEnv("CC"); if (cxx) { this->CXXEnvironment = cxx; } else { @@ -1429,7 +1429,7 @@ int cmake::Run(const std::vector& args, bool noconfigure) // should fail (if "-i" is an option). We cannot simply test // whether "-i" is given and remove it because some make programs // encode the MAKEFLAGS variable in a strange way. - if (getenv("MAKEFLAGS")) { + if (cmSystemTools::GetEnv("MAKEFLAGS")) { cmSystemTools::PutEnv("MAKEFLAGS="); } diff --git a/Source/cmakemain.cxx b/Source/cmakemain.cxx index 521a5bf..8708a36 100644 --- a/Source/cmakemain.cxx +++ b/Source/cmakemain.cxx @@ -127,7 +127,13 @@ static std::string cmakemainGetStack(void* clientdata) static void cmakemainMessageCallback(const char* m, const char*, bool&, void* clientdata) { +#if defined(_WIN32) + std::wstring wm = cmsys::Encoding::ToWide(m); + std::wstring wstack = cmsys::Encoding::ToWide(cmakemainGetStack(clientdata).c_str()); + std::wcerr << wm << wstack << std::endl << std::flush; +#else std::cerr << m << cmakemainGetStack(clientdata) << std::endl << std::flush; +#endif } static void cmakemainProgressCallback(const char* m, float prog, @@ -144,15 +150,32 @@ static void cmakemainProgressCallback(const char* m, float prog, } if ((prog < 0) || (!dir.empty())) { +#if defined(_WIN32) + std::wstring wm = cmsys::Encoding::ToWide(m); + std::wstring wdir = cmsys::Encoding::ToWide(dir.c_str()); + std::wstring wstack = cmsys::Encoding::ToWide(cmakemainGetStack(clientdata).c_str()); + std::wcout << L"-- " << wm << wdir << wstack << std::endl << std::flush; +#else std::cout << "-- " << m << dir << cmakemainGetStack(clientdata) - << std::endl; + << std::endl << std::flush; +#endif } - - std::cout.flush(); } int main(int ac, char const* const* av) { +#if defined(_WIN32) + // Kinda hack, with MSVC (and MinGW) for some reason std::wcout + // (and all other std::w*) fails once it encounters non-ASCII + // string unless locale is set. + // Note that even with this, seems it can't output characters + // which aren't present in ANSI codepage no matter what encoding + // is used for console. + // Also once any character outside of ANSI codepage is tried to + // be outputed then after there anymore won't be output from + // any of std::w* functions. + _wsetlocale(LC_ALL, L""); +#endif cmsys::Encoding::CommandLineArguments args = cmsys::Encoding::CommandLineArguments::Main(ac, av); ac = args.argc(); diff --git a/Source/kwsys/CMakeLists.txt b/Source/kwsys/CMakeLists.txt index 8b15394..cab7f38 100644 --- a/Source/kwsys/CMakeLists.txt +++ b/Source/kwsys/CMakeLists.txt @@ -709,6 +709,8 @@ IF(KWSYS_USE_Process) IF(NOT UNIX) # Use the Windows implementation. SET(KWSYS_C_SRCS ${KWSYS_C_SRCS} ProcessWin32.c) + SET_PROPERTY(SOURCE ProcessWin32.c APPEND PROPERTY COMPILE_DEFINITIONS + KWSYS_ENCODING_DEFAULT_CODEPAGE=${KWSYS_ENCODING_DEFAULT_CODEPAGE}) ELSE() # Use the UNIX implementation. SET(KWSYS_C_SRCS ${KWSYS_C_SRCS} ProcessUNIX.c) diff --git a/Source/kwsys/Directory.cxx b/Source/kwsys/Directory.cxx index c549792..659c559 100644 --- a/Source/kwsys/Directory.cxx +++ b/Source/kwsys/Directory.cxx @@ -86,7 +86,7 @@ void Directory::Clear() // First microsoft compilers -#if defined(_MSC_VER) || defined(__WATCOMC__) +#if defined(_WIN32) || defined(__WATCOMC__) #include #include #include diff --git a/Source/kwsys/FStream.hxx.in b/Source/kwsys/FStream.hxx.in index 681e4d8..842148d 100644 --- a/Source/kwsys/FStream.hxx.in +++ b/Source/kwsys/FStream.hxx.in @@ -17,7 +17,7 @@ namespace @KWSYS_NAMESPACE@ { -#if defined(_MSC_VER) && _MSC_VER >= 1400 +#if defined(_WIN32) # if defined(_NOEXCEPT) # define @KWSYS_NAMESPACE at _FStream_NOEXCEPT _NOEXCEPT # else @@ -30,8 +30,23 @@ namespace @KWSYS_NAMESPACE@ typedef std::basic_filebuf my_base_type; basic_filebuf *open(char const *s,std::ios_base::openmode mode) { + std::wstring wstr = Encoding::ToWide(s); + const wchar_t *ws = wstr.c_str(); +#if defined(_MSC_VER) && _MSC_VER >= 1400 + const wchar_t *ss = ws; +#else + const char *ss = 0; + size_t length = std::wcstombs(0, ws, 0); + if (length != size_t(-1)) { + std::vector str(length + 1); + ss = str.data(); + std::wcstombs((char *)ss, ws, str.size()); + } else { + ss = s; + } +#endif return static_cast( - my_base_type::open(Encoding::ToWide(s).c_str(), mode) + my_base_type::open(ss, mode) ); } }; diff --git a/Source/kwsys/ProcessWin32.c b/Source/kwsys/ProcessWin32.c index 2b93e69..208e725 100644 --- a/Source/kwsys/ProcessWin32.c +++ b/Source/kwsys/ProcessWin32.c @@ -181,7 +181,7 @@ struct kwsysProcessPipeData_s /* ------------- Data managed per call to Execute ------------- */ /* Buffer for data read in this pipe's thread. */ - char DataBuffer[KWSYSPE_PIPE_BUFFER_SIZE]; + char DataBuffer[KWSYSPE_PIPE_BUFFER_SIZE*2]; /* The length of the data stored in the buffer. */ DWORD DataLength; @@ -1626,6 +1626,25 @@ void kwsysProcessPipeThreadReadPipe(kwsysProcess* cp, kwsysProcessPipeData* td) KWSYSPE_DEBUG((stderr, "read closed %d\n", td->Index)); } + if (td->DataLength > 0) { + UINT codepage = GetConsoleCP(); + if (!codepage) { + codepage = GetACP(); + } + if (codepage != KWSYS_ENCODING_DEFAULT_CODEPAGE) { + int wlength = MultiByteToWideChar(codepage, 0, td->DataBuffer, td->DataLength, NULL, 0); + wchar_t* wdata = malloc(wlength * sizeof(wchar_t)); + int r = MultiByteToWideChar(codepage, 0, td->DataBuffer, td->DataLength, wdata, wlength); + if (r > 0) { + r = WideCharToMultiByte(KWSYS_ENCODING_DEFAULT_CODEPAGE, 0, wdata, wlength, td->DataBuffer, KWSYSPE_PIPE_BUFFER_SIZE * 2, NULL, NULL); + if (r > 0) { + td->DataLength = r; + } + } + free(wdata); + } + } + KWSYSPE_DEBUG((stderr, "read %d\n", td->Index)); /* Wait for our turn to be handled by the main thread. */ diff --git a/Source/kwsys/SystemInformation.cxx b/Source/kwsys/SystemInformation.cxx index 81fb2f9..d82c635 100644 --- a/Source/kwsys/SystemInformation.cxx +++ b/Source/kwsys/SystemInformation.cxx @@ -219,6 +219,8 @@ typedef struct rlimit ResourceLimitType; # define USE_CPUID 0 #endif +#include + #if USE_CPUID #define CPUID_AWARE_COMPILER @@ -3476,7 +3478,7 @@ SystemInformationImplementation::GetHostMemoryAvailable(const char *hostLimitEnv // apply a limit across a set of processes. Units are in KiB. if (hostLimitEnvVarName) { - const char *hostLimitEnvVarValue=getenv(hostLimitEnvVarName); + const char *hostLimitEnvVarValue=SystemTools::GetEnv(hostLimitEnvVarName); if (hostLimitEnvVarValue) { SystemInformation::LongLong hostLimit=atoLongLong(hostLimitEnvVarValue); @@ -3506,7 +3508,7 @@ SystemInformationImplementation::GetProcMemoryAvailable( // are not employed. Units are in KiB. if (procLimitEnvVarName) { - const char *procLimitEnvVarValue=getenv(procLimitEnvVarName); + const char *procLimitEnvVarValue=SystemTools::GetEnv(procLimitEnvVarName); if (procLimitEnvVarValue) { SystemInformation::LongLong procLimit=atoLongLong(procLimitEnvVarValue); @@ -5408,7 +5410,7 @@ bool SystemInformationImplementation::QueryOSInformation() } this->Hostname = name; - const char* arch = getenv("PROCESSOR_ARCHITECTURE"); + const char* arch = SystemTools::GetEnv("PROCESSOR_ARCHITECTURE"); if(arch) { this->OSPlatform = arch; diff --git a/Source/kwsys/SystemTools.cxx b/Source/kwsys/SystemTools.cxx index c6e668d..afc7ca1 100644 --- a/Source/kwsys/SystemTools.cxx +++ b/Source/kwsys/SystemTools.cxx @@ -458,7 +458,19 @@ void SystemTools::GetPath(std::vector& path, const char* env) const char* SystemTools::GetEnv(const char* key) { - return getenv(key); + const char* v = 0; +#if defined(_WIN32) + std::wstring wkey = Encoding::ToWide(key); + wchar_t* wv = _wgetenv(wkey.c_str()); + if (wv) { + std::string str = Encoding::ToNarrow(wv); + v = new char[str.length() + 1]; + memcpy((void *)v, str.c_str(), str.length() + 1); + } +#else + v = getenv(key); +#endif + return v; } const char* SystemTools::GetEnv(const std::string& key) @@ -468,7 +480,7 @@ const char* SystemTools::GetEnv(const std::string& key) bool SystemTools::GetEnv(const char* key, std::string& result) { - const char* v = getenv(key); + const char* v = SystemTools::GetEnv(key); if(v) { result = v; @@ -4061,13 +4073,13 @@ void SystemTools::SplitPath(const std::string& p, if(root.size() == 1) { #if defined(_WIN32) && !defined(__CYGWIN__) - if(const char* userp = getenv("USERPROFILE")) + if(const char* userp = SystemTools::GetEnv("USERPROFILE")) { homedir = userp; } else #endif - if(const char* h = getenv("HOME")) + if(const char* h = SystemTools::GetEnv("HOME")) { homedir = h; } @@ -4820,7 +4832,7 @@ int SystemTools::GetTerminalWidth() { width = -1; } - columns = getenv("COLUMNS"); + columns = SystemTools::GetEnv("COLUMNS"); if(columns && *columns) { long t; @@ -5435,7 +5447,7 @@ void SystemTools::ClassInitialize() // If the current working directory is a logical path then keep the // logical name. - if(const char* pwd = getenv("PWD")) + if(const char* pwd = SystemTools::GetEnv("PWD")) { char buf[2048]; if(const char* cwd = Getcwd(buf, 2048)) @@ -5505,8 +5517,8 @@ static int SystemToolsDebugReport(int, char* message, int*) void SystemTools::EnableMSVCDebugHook() { - if (getenv("DART_TEST_FROM_DART") || - getenv("DASHBOARD_TEST_FROM_CTEST")) + if (SystemTools::GetEnv("DART_TEST_FROM_DART") || + SystemTools::GetEnv("DASHBOARD_TEST_FROM_CTEST")) { _CrtSetReportHook(SystemToolsDebugReport); } -- 2.9.0