From ono at java.pl Sun Mar 1 05:44:07 2015 From: ono at java.pl (Adam Strzelecki) Date: Sun, 1 Mar 2015 11:44:07 +0100 Subject: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation In-Reply-To: <54F21406.9060809@reactos.org> References: <54F21406.9060809@reactos.org> Message-ID: <341E0E34-6181-4DFA-82CF-9B4F5D1A6476@java.pl> > Does your solution support Ninja generator? I ask because any existing solution based on upstream CMake won't work with the Ninja generator. Peter's solution is the only existing solution we know about. Yes, it was meant to work with Makefiles and Ninja. > Does your solution support C source files/targets? you mentioned "meta C++ compiler" so it seems to be C++ centric IIUC. Not at the moment, but C support double be just copy&paste replacing "CXX" with "C". I'll add it to the TODO. -- Adam From amine.khaldi at reactos.org Sun Mar 1 06:12:45 2015 From: amine.khaldi at reactos.org (Amine Khaldi) Date: Sun, 01 Mar 2015 12:12:45 +0100 Subject: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation In-Reply-To: <341E0E34-6181-4DFA-82CF-9B4F5D1A6476@java.pl> References: <54F21406.9060809@reactos.org> <341E0E34-6181-4DFA-82CF-9B4F5D1A6476@java.pl> Message-ID: <54F2F42D.6020206@reactos.org> > Yes, it was meant to work with Makefiles and Ninja. Okay, I'll give it a shot with Ninja and report back. > Not at the moment, but C support double be just copy&paste replacing "CXX" with "C". I'll add it to the TODO. Thank you. ReactOS is mostly C so lack of its support prevents us from testing it on ReactOS. I noticed two things so far: * It seems target centric, what about targets where we want PCH to cover a specific set of source files, not all the source files of a target? I ask because in ReactOS, for example, we are forced to compile GUID related source files without PCH in order for them to work. Other cases can be when some source files requires flags/defines applied to headers that belong to the PCH but are not present in other source files. Is there a way to achieve that? * The shared idea means you can create a target just to hold a PCH, then make the rest of targets share that PCH? Regards, Amine. From ono at java.pl Sun Mar 1 09:11:29 2015 From: ono at java.pl (Adam Strzelecki) Date: Sun, 1 Mar 2015 15:11:29 +0100 Subject: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation In-Reply-To: <54F2F42D.6020206@reactos.org> References: <54F21406.9060809@reactos.org> <341E0E34-6181-4DFA-82CF-9B4F5D1A6476@java.pl> <54F2F42D.6020206@reactos.org> Message-ID: >> Yes, it was meant to work with Makefiles and Ninja. > Okay, I'll give it a shot with Ninja and report back. Thanks. >> Not at the moment, but C support double be just copy&paste replacing "CXX" with "C". I'll add it to the TODO. > Thank you. ReactOS is mostly C so lack of its support prevents us from testing it on ReactOS. I've pushed new change that adds plain C language support. > I noticed two things so far: > * It seems target centric, what about targets where we want PCH to cover a specific set of source files, not all the source files of a target? I ask because in ReactOS, for example, we are forced to compile GUID related source files without PCH in order for them to work. Other cases can be when some source files requires flags/defines applied to headers that belong to the PCH but are not present in other source files. Is there a way to achieve that? Nope. But let's say I'll add such setting: target_precompiled_header(target SOURCES ) Then instead of applying precompiled header to all target sources, it will apply just for these specified here. However this may generate suboptimal Makefiles/Ninja files since for many (thousands of) files, every file will have separate flags specified which is IMHO pretty bad. It would be better to separate guid non-PCH sources into separate object only library via: add_library(target_guid_files OBJECT sources) And then add these output files to main target using PCH via $ > * The shared idea means you can create a target just to hold a PCH, then make the rest of targets share that PCH? Yes! But unfortunately this may NOT work for MSVC. Since this implies we would need to share PDB. But this is somehow Microsoft specific stuff. -- Adam From matt.mccormick at kitware.com Sun Mar 1 10:49:01 2015 From: matt.mccormick at kitware.com (Matt McCormick) Date: Sun, 1 Mar 2015 10:49:01 -0500 Subject: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation In-Reply-To: References: Message-ID: Hi Adam, Thank you for working on this! This would be a killer feature. > I also want to suggest to put native precompiled header support somewhere high on the TODO list and I propose this simple API for specifying precompiled header for given target: > > target_precompiled_header( ) > > target_precompiled_header( SHARED > ) > I think the use of the "SHARED" specifier here should be avoided since SHARED is used in add_library, and it has a completely different meaning there. An improvement in the API (although maybe not perfect): target_precomplied_header( [PREFIX ] [FROM ]) This way we do not need to specify all the targets to shared the precompiled header with at one time and in one call. Thanks, Matt From ono at java.pl Sun Mar 1 12:32:26 2015 From: ono at java.pl (Adam Strzelecki) Date: Sun, 1 Mar 2015 18:32:26 +0100 Subject: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation In-Reply-To: References: Message-ID: <567843F3-A3F3-48C4-A3D2-3A5EA09CF379@java.pl> > An improvement in the API (although maybe not perfect): > > target_precomplied_header( > [PREFIX ] > [FROM > ]) > > This way we do not need to specify all the targets to shared the > precompiled header with at one time and in one call. You mean we can specify header for multiple targets in one call? So maybe such one: target_precompiled_header( [...] [REUSE []] [TYPE ]) I don't like PREFIX word, since this maybe misleading since in other places it means a path prefix. So I would leave it as last non-optional parameter. I agree SHARED maybe confusing, so maybe we can call it REUSE? And then if they are multiple targets, one may specify REUSE without value, i.e.: target_precompiled_header(app lib1 lib2 src/prefix.h REUSE) Which is equal to: target_precompiled_header(app src/prefix.h) target_precompiled_header(lib1 src/prefix.h REUSE app) target_precompiled_header(lib2 src/prefix.h REUSE app) WDYT? -- Adam From ono at java.pl Sun Mar 1 12:57:10 2015 From: ono at java.pl (Adam Strzelecki) Date: Sun, 1 Mar 2015 18:57:10 +0100 Subject: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation In-Reply-To: <567843F3-A3F3-48C4-A3D2-3A5EA09CF379@java.pl> References: <567843F3-A3F3-48C4-A3D2-3A5EA09CF379@java.pl> Message-ID: <3D2E08EB-0B4F-42A0-A7A6-57E20D739D42@java.pl> Okie, seems cmake_parse_arguments does not like option with optional value, so REUSE needs always parameter. Now on HEAD: target_precompiled_header(app lib1 lib2 src/prefix.h REUSE app) Which is equal to: target_precompiled_header(app src/prefix.h) target_precompiled_header(lib1 src/prefix.h REUSE app) target_precompiled_header(lib2 src/prefix.h REUSE app) -- Adam From domen.vrankar at gmail.com Sun Mar 1 16:38:54 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Sun, 1 Mar 2015 22:38:54 +0100 Subject: [cmake-developers] KWSys patches In-Reply-To: <54EDE868.406@kitware.com> References: <54E20763.2070306@kitware.com> <54E24B99.3010709@kitware.com> <54EB6985.6020200@kitware.com> <54EDE868.406@kitware.com> Message-ID: > For the other two changes, please refactor things to avoid > use of function-local classes. They will likely not work > on the older compilers KWSys supports. > > Also, please use the coding style of "this->Member" when > referencing class members from method code. Attached are refactored patches. Thanks, Domen -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-glob-recurse-cyclic-recursion-handling.patch Type: text/x-diff Size: 7741 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-glob-support-for-directory-listing.patch Type: text/x-diff Size: 3959 bytes Desc: not available URL: From ben.boeckel at kitware.com Sun Mar 1 20:02:09 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Sun, 1 Mar 2015 20:02:09 -0500 Subject: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation In-Reply-To: References: Message-ID: <20150302010209.GC17534@bronto-burt.dev.benboeckel.net> On Sat, Feb 28, 2015 at 17:59:55 +0100, Adam Strzelecki wrote: > target_precompiled_header( ) > > target_precompiled_header( SHARED > ) Could we rename this? Currently target_* functions are all related to usage requirements and these are not usage requirements. --Ben From brad.king at kitware.com Mon Mar 2 09:06:30 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 02 Mar 2015 09:06:30 -0500 Subject: [cmake-developers] [PATCH] CPack: be more stringent when selecting variables to encode In-Reply-To: <1425166732-6388-1-git-send-email-dpb@corrigendum.ru> References: <1425166732-6388-1-git-send-email-dpb@corrigendum.ru> Message-ID: <54F46E66.7000001@kitware.com> On 02/28/2015 06:38 PM, ????? ???????? wrote: > The old version would admit, for example, a variable named "xxxCPACK". Applied, thanks: CPack: be more stringent when selecting variables to encode http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3b9f963f -Brad From brad.king at kitware.com Mon Mar 2 09:07:46 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 02 Mar 2015 09:07:46 -0500 Subject: [cmake-developers] KWSys patches In-Reply-To: References: <54E20763.2070306@kitware.com> <54E24B99.3010709@kitware.com> <54EB6985.6020200@kitware.com> <54EDE868.406@kitware.com> Message-ID: <54F46EB2.9050601@kitware.com> On 03/01/2015 04:38 PM, Domen Vrankar wrote: > Attached are refactored patches. Thanks. I've placed them in KWSys for testing here: http://review.source.kitware.com/#/c/19377/ http://review.source.kitware.com/#/c/19378/ -Brad From brad.king at kitware.com Mon Mar 2 09:47:54 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 02 Mar 2015 09:47:54 -0500 Subject: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support In-Reply-To: References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com> <544E4C9F.3050408@kitware.com> <64abd7ba273245b686146aa67acb7e8a@DM2PR0701MB1020.namprd07.prod.outlook.com> <545A7C44.6040305@kitware.com> <5474E132.2010705@kitware.com> <54D129E3.60101@kitware.com> <54E365F4.3030104@kitware.com> <54E7542D.6050808@kitware.com> <54EB68C8.7030504@kitware.com> <54F0952B.5070809@kitware.com> Message-ID: <54F4781A.80708@kitware.com> On 02/27/2015 11:29 AM, Geoffrey Viola wrote: >> set(ENV{PATH} "c:\\Windows\\system32;c:\\Windows") >> We should test with at least the basic Windows PATH set. > I made the change just now. I'll rerun the tests. I haven't seen "glv.asi" submit in a few days. Is it running nightly? > Let me know if there is anything more I can do. I've looked more through the patch sent here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/11260/focus=12469 > +void > +cmGlobalGhsMultiGenerator::EnableLanguage(std::vector const &l, > + cmMakefile *mf, bool optional) { > + mf->AddDefinition("CMAKE_C_COMPILER", "${CMAKE_GENERATOR_CC}"); > + mf->AddDefinition("CMAKE_C_COMPILER_ID_RUN", "TRUE"); > + mf->AddDefinition("CMAKE_C_COMPILER_ID", "GhsMultiArmC"); > + mf->AddDefinition("CMAKE_C_COMPILER_FORCED", "TRUE"); > + > + mf->AddDefinition("CMAKE_CXX_COMPILER", "${CMAKE_GENERATOR_CXX}"); > + mf->AddDefinition("CMAKE_CXX_COMPILER_ID_RUN", "TRUE"); > + mf->AddDefinition("CMAKE_CXX_COMPILER_ID", "GhsMultiArmCXX"); > + mf->AddDefinition("CMAKE_CXX_COMPILER_FORCED", "TRUE"); > + > + mf->AddDefinition("GHSMULTI", "1"); // identifier for user CMake files > + this->cmGlobalGenerator::EnableLanguage(l, mf, optional); > +} This looks based on my suggestion from an earlier review: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/11260/focus=11538 so I think this is the right place for such code. However, the hunk above needs some work. First, the changes to Modules/CMakeCompilerIdDetection.cmake indicate that the compiler id is "GHS", so the CMAKE__COMPILER_ID should be set to that in the code above. The compiler path values are set to literal "${...}" strings but that will not be interpreted. Alternatives: * Set CMAKE_GENERATOR_CC and CMAKE_GENERATOR_CXX to ccarm and cxarm in the above code and let the normal compiler search logic in CMakeDetermine*Compiler.cmake actually find the compiler instead of using find_program in CMakeGreenHillsFindMake. * Have EnableLanguage compute the exact path to the compiler tools itself, possibly using GHS_COMP_ROOT. Most of the code in CMakeGreenHillsFindMake actually belongs in "Modules/Platform/GHS-MULTI.cmake". The EnableLanguage method should set CMAKE_SYSTEM_NAME and CMAKE_SYSTEM_PROCESSOR. It could even have C++-implemented logic to find GHS_COMP_ROOT (are there registry values for it?). Then CMakeGreenHillsFindMake should have the minimum code needed to find the make tool given GHS_COMP_ROOT. Then I think everything else can go in Modules/Platform/GHS-MULTI-Initialize.cmake Modules/Platform/GHS-MULTI.cmake The -Initialize module will be loaded pretty early and is the place to find platform-specific SDKs and such. This is likely the place for all those GHS_* cache options. Thanks, -Brad From Geoffrey.Viola at asirobots.com Mon Mar 2 11:30:59 2015 From: Geoffrey.Viola at asirobots.com (Geoffrey Viola) Date: Mon, 2 Mar 2015 16:30:59 +0000 Subject: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support In-Reply-To: <54F4781A.80708@kitware.com> References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com> <544E4C9F.3050408@kitware.com> <64abd7ba273245b686146aa67acb7e8a@DM2PR0701MB1020.namprd07.prod.outlook.com> <545A7C44.6040305@kitware.com> <5474E132.2010705@kitware.com> <54D129E3.60101@kitware.com> <54E365F4.3030104@kitware.com> <54E7542D.6050808@kitware.com> <54EB68C8.7030504@kitware.com> <54F0952B.5070809@kitware.com> <54F4781A.80708@kitware.com> Message-ID: > I made the change just now. I'll rerun the tests. > > I haven't seen "glv.asi" submit in a few days. Is it running nightly? It should be. The past weekend was an exception. I forgot the power cord for that computer. I hoped for less CMake development on the weekend. When I reran the experimental test with my patch, I noticed that my tests weren't passing. I'm still working on it. >I've looked more through the patch sent here: > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/11260/focus=12469 > >> +void >> +cmGlobalGhsMultiGenerator::EnableLanguage(std::vector const &l, >> + cmMakefile *mf, bool >> +optional) { >> + mf->AddDefinition("CMAKE_C_COMPILER", "${CMAKE_GENERATOR_CC}"); >> + mf->AddDefinition("CMAKE_C_COMPILER_ID_RUN", "TRUE"); >> + mf->AddDefinition("CMAKE_C_COMPILER_ID", "GhsMultiArmC"); >> + mf->AddDefinition("CMAKE_C_COMPILER_FORCED", "TRUE"); >> + >> + mf->AddDefinition("CMAKE_CXX_COMPILER", "${CMAKE_GENERATOR_CXX}"); >> + mf->AddDefinition("CMAKE_CXX_COMPILER_ID_RUN", "TRUE"); >> + mf->AddDefinition("CMAKE_CXX_COMPILER_ID", "GhsMultiArmCXX"); >> + mf->AddDefinition("CMAKE_CXX_COMPILER_FORCED", "TRUE"); >> + >> + mf->AddDefinition("GHSMULTI", "1"); // identifier for user CMake >> +files >> + this->cmGlobalGenerator::EnableLanguage(l, mf, optional); } > >This looks based on my suggestion from an earlier review: > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/11260/focus=11538 > >so I think this is the right place for such code. However, the hunk above needs some work. First, the changes to Modules/CMakeCompilerIdDetection.cmake indicate that the compiler id is "GHS", so the CMAKE__COMPILER_ID should be set to that in the code above. > >The compiler path values are set to literal "${...}" >strings but that will not be interpreted. Alternatives: > >* Set CMAKE_GENERATOR_CC and CMAKE_GENERATOR_CXX to ccarm > and cxarm in the above code and let the normal compiler > search logic in CMakeDetermine*Compiler.cmake actually > find the compiler instead of using find_program in > CMakeGreenHillsFindMake. > >* Have EnableLanguage compute the exact path to the compiler > tools itself, possibly using GHS_COMP_ROOT. > >Most of the code in CMakeGreenHillsFindMake actually belongs in "Modules/Platform/GHS-MULTI.cmake". The EnableLanguage method should set CMAKE_SYSTEM_NAME and CMAKE_SYSTEM_PROCESSOR. >It could even have C++-implemented logic to find GHS_COMP_ROOT (are there registry values for it?). Then CMakeGreenHillsFindMake should have the minimum code needed to find the make tool given GHS_COMP_ROOT. Then I think everything else can go in > > Modules/Platform/GHS-MULTI-Initialize.cmake > Modules/Platform/GHS-MULTI.cmake > >The -Initialize module will be loaded pretty early and is the place to find platform-specific SDKs and such. This is likely the place for all those GHS_* cache options. Good feedback. I should have time to dig into it sometime this week. Geoffrey Viola SOFTWARE ENGINEER asirobots.com -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Monday, March 02, 2015 7:48 AM To: Geoffrey Viola Cc: cmake-developers at cmake.org Subject: Re: FW: FW: [cmake-developers] Initial Attempt at Green Hill MULTI IDE Generator Support On 02/27/2015 11:29 AM, Geoffrey Viola wrote: >> set(ENV{PATH} "c:\\Windows\\system32;c:\\Windows") >> We should test with at least the basic Windows PATH set. > I made the change just now. I'll rerun the tests. I haven't seen "glv.asi" submit in a few days. Is it running nightly? > Let me know if there is anything more I can do. I've looked more through the patch sent here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/11260/focus=12469 > +void > +cmGlobalGhsMultiGenerator::EnableLanguage(std::vector const &l, > + cmMakefile *mf, bool > +optional) { > + mf->AddDefinition("CMAKE_C_COMPILER", "${CMAKE_GENERATOR_CC}"); > + mf->AddDefinition("CMAKE_C_COMPILER_ID_RUN", "TRUE"); > + mf->AddDefinition("CMAKE_C_COMPILER_ID", "GhsMultiArmC"); > + mf->AddDefinition("CMAKE_C_COMPILER_FORCED", "TRUE"); > + > + mf->AddDefinition("CMAKE_CXX_COMPILER", "${CMAKE_GENERATOR_CXX}"); > + mf->AddDefinition("CMAKE_CXX_COMPILER_ID_RUN", "TRUE"); > + mf->AddDefinition("CMAKE_CXX_COMPILER_ID", "GhsMultiArmCXX"); > + mf->AddDefinition("CMAKE_CXX_COMPILER_FORCED", "TRUE"); > + > + mf->AddDefinition("GHSMULTI", "1"); // identifier for user CMake > +files > + this->cmGlobalGenerator::EnableLanguage(l, mf, optional); } This looks based on my suggestion from an earlier review: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/11260/focus=11538 so I think this is the right place for such code. However, the hunk above needs some work. First, the changes to Modules/CMakeCompilerIdDetection.cmake indicate that the compiler id is "GHS", so the CMAKE__COMPILER_ID should be set to that in the code above. The compiler path values are set to literal "${...}" strings but that will not be interpreted. Alternatives: * Set CMAKE_GENERATOR_CC and CMAKE_GENERATOR_CXX to ccarm and cxarm in the above code and let the normal compiler search logic in CMakeDetermine*Compiler.cmake actually find the compiler instead of using find_program in CMakeGreenHillsFindMake. * Have EnableLanguage compute the exact path to the compiler tools itself, possibly using GHS_COMP_ROOT. Most of the code in CMakeGreenHillsFindMake actually belongs in "Modules/Platform/GHS-MULTI.cmake". The EnableLanguage method should set CMAKE_SYSTEM_NAME and CMAKE_SYSTEM_PROCESSOR. It could even have C++-implemented logic to find GHS_COMP_ROOT (are there registry values for it?). Then CMakeGreenHillsFindMake should have the minimum code needed to find the make tool given GHS_COMP_ROOT. Then I think everything else can go in Modules/Platform/GHS-MULTI-Initialize.cmake Modules/Platform/GHS-MULTI.cmake The -Initialize module will be loaded pretty early and is the place to find platform-specific SDKs and such. This is likely the place for all those GHS_* cache options. Thanks, -Brad This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. From mantis at public.kitware.com Mon Mar 2 14:29:30 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 2 Mar 2015 14:29:30 -0500 Subject: [cmake-developers] [CMake 0015428]: InstallRequiredSystemLibraries.cmake does not work when installing with component Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15428 ====================================================================== Reported By: johan andruejol Assigned To: ====================================================================== Project: CMake Issue ID: 15428 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-02 14:29 EST Last Modified: 2015-03-02 14:29 EST ====================================================================== Summary: InstallRequiredSystemLibraries.cmake does not work when installing with component Description: The libraries found with the InstallRequiredSystemLibraries.cmake always have the "Unspecified" component since no component is specified. This makes project that package with the component option (CPACK_INSTALL_CMAKE_PROJECTS) not install those libraries. I included a patch that could be a solution to this problem. Steps to Reproduce: For example, Slicer as of https://github.com/Slicer/Slicer/commit/454fed0f5f2f8ea18269f2bfdfc4733326c4c6d7 does not package the windows redistributable libraries. (See also download.slicer.org/bitstream/325826) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-02 14:29 johan andruejolNew Issue 2015-03-02 14:29 johan andruejolFile Added: 0001-Modules-Add-component-option-for-InstallRequiredSyst.patch ====================================================================== From aleixpol at kde.org Mon Mar 2 20:15:31 2015 From: aleixpol at kde.org (Aleix Pol) Date: Tue, 3 Mar 2015 02:15:31 +0100 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <3598487.BMqLxZv4oP@tuxedo.neundorf.net> References: <3598487.BMqLxZv4oP@tuxedo.neundorf.net> Message-ID: On Mon, Feb 16, 2015 at 10:44 PM, Alexander Neundorf wrote: > On Monday, February 16, 2015 21:31:45 Aleix Pol wrote: >> On Sat, Feb 14, 2015 at 1:02 PM, Stephen Kelly wrote: >> > Aleix Pol wrote: >> >> Hi guys, >> >> It's been since August with this. I understand we're all busy but this >> >> step is important for KDevelop as well as for other IDE's and I >> >> wouldn't like this to rot. >> >> >> >> Please, let's keep it moving forward. >> > >> > As far as I'm aware, it needs to move forward from this point: >> > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/fo >> > cus=12151> >> > I'm not certain the design is finished (eg what the file should contain >> > now >> > or eventually). I asked for tests/documentation as a way to trigger >> > getting >> > the design finished. Having either would give us a list of use-cases and >> > we >> > would know what's in scope and what's not in scope (eg whether compile >> > options/link options are in scope and why). >> >> I can look further into documentation, if that's what holding us back. >> >> > Another question: do you have any opinion about whether this should be one >> > global file or one file per directory? I don't know - it seems like >> > something that might or might not be relevant for tooling. Is the size of >> > the generated file a consideration? >> >> I think the best is to have it all in 1 directory. You don't really >> want to have watchers on many files over there. >> >> > How well does this feature work with large projects like VTK or a combined >> > build of LLVM/Clang/lldb/libcxx/other ll projects. >> >> I just generated the file for LLVM: https://paste.kde.org/pxl8ozwah >> It's a 127KiB file, I don't think it's too mental considering it's a >> 330 MiB repository. > > I didn't follow the whole thread, just a few quick questions from looking at > the file: > > > { > "name": "obj2yaml", > "type": "EXECUTABLE", > "configs": [ > ], > "directory": "/home/kde-devel/tmp/llvm/build/bin", > "location": "/home/kde-devel/tmp/llvm/build/bin/obj2yaml", > "backtrace": ["/home/kde-devel/tmp/llvm/cmake/modules/AddLLVM.cmake:452", > "/home/kde-devel/tmp/llvm/cmake/modules/AddLLVM.cmake:485", > "/home/kde-devel/tmp/llvm/tools/obj2yaml/CMakeLists.txt:6"], > "installed": true > }, > > > I guess "name" is the name of the target, type, configs, location, backtrace > and installed seem to be clear. > > What about "directory" ? > This is not the build dir where the target is defined (i.e. > cmake_binary_dir(llvm/tools/obj2yaml/), is it ? > This directory would seem useful to me, e.g. you can run "make help" there to > get the list of targets to compile/assemble/preprocess the files for that > target. Or you can run the clean-script for that target. You are correct, it would be more useful indeed. Do you know how to get the value? I've been trying to figure it out but I can't find the correct method in cmTarget. Aleix From aleixpol at kde.org Mon Mar 2 20:26:58 2015 From: aleixpol at kde.org (Aleix Pol) Date: Tue, 3 Mar 2015 02:26:58 +0100 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: <3598487.BMqLxZv4oP@tuxedo.neundorf.net> Message-ID: On Tue, Mar 3, 2015 at 2:15 AM, Aleix Pol wrote: > On Mon, Feb 16, 2015 at 10:44 PM, Alexander Neundorf wrote: >> On Monday, February 16, 2015 21:31:45 Aleix Pol wrote: >>> On Sat, Feb 14, 2015 at 1:02 PM, Stephen Kelly wrote: >>> > Aleix Pol wrote: >>> >> Hi guys, >>> >> It's been since August with this. I understand we're all busy but this >>> >> step is important for KDevelop as well as for other IDE's and I >>> >> wouldn't like this to rot. >>> >> >>> >> Please, let's keep it moving forward. >>> > >>> > As far as I'm aware, it needs to move forward from this point: >>> > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/fo >>> > cus=12151> >>> > I'm not certain the design is finished (eg what the file should contain >>> > now >>> > or eventually). I asked for tests/documentation as a way to trigger >>> > getting >>> > the design finished. Having either would give us a list of use-cases and >>> > we >>> > would know what's in scope and what's not in scope (eg whether compile >>> > options/link options are in scope and why). >>> >>> I can look further into documentation, if that's what holding us back. >>> >>> > Another question: do you have any opinion about whether this should be one >>> > global file or one file per directory? I don't know - it seems like >>> > something that might or might not be relevant for tooling. Is the size of >>> > the generated file a consideration? >>> >>> I think the best is to have it all in 1 directory. You don't really >>> want to have watchers on many files over there. >>> >>> > How well does this feature work with large projects like VTK or a combined >>> > build of LLVM/Clang/lldb/libcxx/other ll projects. >>> >>> I just generated the file for LLVM: https://paste.kde.org/pxl8ozwah >>> It's a 127KiB file, I don't think it's too mental considering it's a >>> 330 MiB repository. >> >> I didn't follow the whole thread, just a few quick questions from looking at >> the file: >> >> >> { >> "name": "obj2yaml", >> "type": "EXECUTABLE", >> "configs": [ >> ], >> "directory": "/home/kde-devel/tmp/llvm/build/bin", >> "location": "/home/kde-devel/tmp/llvm/build/bin/obj2yaml", >> "backtrace": ["/home/kde-devel/tmp/llvm/cmake/modules/AddLLVM.cmake:452", >> "/home/kde-devel/tmp/llvm/cmake/modules/AddLLVM.cmake:485", >> "/home/kde-devel/tmp/llvm/tools/obj2yaml/CMakeLists.txt:6"], >> "installed": true >> }, >> >> >> I guess "name" is the name of the target, type, configs, location, backtrace >> and installed seem to be clear. >> >> What about "directory" ? >> This is not the build dir where the target is defined (i.e. >> cmake_binary_dir(llvm/tools/obj2yaml/), is it ? >> This directory would seem useful to me, e.g. you can run "make help" there to >> get the list of targets to compile/assemble/preprocess the files for that >> target. Or you can run the clean-script for that target. > > You are correct, it would be more useful indeed. Do you know how to > get the value? I've been trying to figure it out but I can't find the > correct method in cmTarget. > > Aleix If I'm not correct this can be provided through GetMakefile()->GetCurrentOutputDirectory(). I'll upload in a moment a new version with this implemented (and some other things). Aleix From aleixpol at kde.org Mon Mar 2 21:10:04 2015 From: aleixpol at kde.org (Aleix Pol) Date: Tue, 3 Mar 2015 03:10:04 +0100 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: Message-ID: On Fri, Aug 29, 2014 at 4:20 AM, Aleix Pol wrote: > Dear cmake'rs, > I'm rewriting the KDevelop plugin from scratch to fetch the information from > the build directory. > > Now in the first implementation I'm using the compile_commands.json file > that cmake already can generate for some time. It works quite well already, > given how data just comes out ready to be consumed (almost). The problem now > is that we're lacking some information, namely information about the > targets, their location and such *. > > To that end, I wrote a little patch to be taken as a proof of concept, that > generates (some of) the needed information. I would like to know if you > think it's an approach that would be accepted in the cmake code-base or if I > need to take a different approach. > > Patch http://proli.net/meu/kdevelop/cmake-targetsdata.patch > Output: http://proli.net/meu/kdevelop/AwesomeTargets.json > > Cheers! > Aleix > > * Yes, I'm aware of generators, but I'm not comfortable with the idea of > tying a build directory to an editor (even if it's my editor). Our users > usually build the projects with different tools and asking them to re-create > their build only for being comfortable with KDevelop sometimes is a burden. > It would be for me too! I created a new version of the patch: http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE-v2.patch Main differences are: * Uses JsonCpp to generate json (makes the code much easier to read!). * Adds a CMAKE_EXPORT_PROJECT_METADATA.rst file for documentation. * Adds a test that checks some of the parameters in the file. * Uses for directory the directory where the target was generated rather than the output directory. I hope this helps. Aleix Samples: LLVM: https://paste.kde.org/pelr1ditp A small random KDE project: https://paste.kde.org/pgkbecv5p From ono at java.pl Tue Mar 3 07:43:18 2015 From: ono at java.pl (Adam Strzelecki) Date: Tue, 3 Mar 2015 13:43:18 +0100 Subject: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation In-Reply-To: <20150302010209.GC17534@bronto-burt.dev.benboeckel.net> References: <20150302010209.GC17534@bronto-burt.dev.benboeckel.net> Message-ID: <5BB62C37-0B76-4CA9-9529-3E3FCB5D151E@java.pl> > Could we rename this? Currently target_* functions are all related to > usage requirements and these are not usage requirements. Honestly I don't understand your request. What would be then the name that better represents what the function does. Also please note this is proposed API to be handled directly by CMake, once there is a green light I'll propose patches to CMake itself. In meantime https://github.com/nanoant/CMakePCHCompiler is just an implementation that "emulates" desired behavior using many tricks. But I don't want this to be a part of CMake, but instead I want this to be handled natively adding some extra variables: CMAKE__PRECOMPILE_HEADER GCC, Clang: same as CMAKE__COMPILE_OBJECT MSVC: CMAKE__COMPILE_OBJECT with "-c" replaced with "/FoNUL /Yc /Fp" CMAKE__PRECOMPILED_HEADER_EXTENSION GCC: .gch MSVC, Clang: .pch CMAKE_PRECOMPILED_HEADER_FLAG_ GCC, Clang: -include MSVC: /Yu /Fp /FI$ And extending CMake to generate proper build commands for Makefile, Ninja targets, and also Xcode, MSVC generators. -- Adam From dpb at corrigendum.ru Tue Mar 3 13:33:55 2015 From: dpb at corrigendum.ru (=?UTF-8?q?=D0=A0=D0=BE=D0=BC=D0=B0=D0=BD=20=D0=94=D0=BE=D0=BD=D1=87=D0=B5=D0=BD=D0=BA=D0=BE?=) Date: Tue, 3 Mar 2015 21:33:55 +0300 Subject: [cmake-developers] [PATCH] CPack: change cpack_set_if_not_set into a function Message-ID: <1425407635-1116-1-git-send-email-dpb@corrigendum.ru> Since it's currently a macro, then due to macro processing rules, special characters inside the value are interpreted by the parser, which can result in syntax errors or a mismatch between the given default and the value the variable is actually set to. Remove existing local workarounds for this issue, which are no longer required. --- Modules/CPack.cmake | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/Modules/CPack.cmake b/Modules/CPack.cmake index 532596d..4b10723 100644 --- a/Modules/CPack.cmake +++ b/Modules/CPack.cmake @@ -298,12 +298,12 @@ endif() # Include CPackComponent macros if it has not already been included before. include(CPackComponent) -# Macro for setting values if a user did not overwrite them -macro(cpack_set_if_not_set name value) +# Function for setting values if a user did not overwrite them +function(cpack_set_if_not_set name value) if(NOT DEFINED "${name}") - set(${name} "${value}") + set(${name} "${value}" PARENT_SCOPE) endif() -endmacro() +endfunction() # cpack_encode_variables - Macro to encode variables for the configuration file # find any variable that starts with CPACK and create a variable @@ -534,9 +534,7 @@ endif() cpack_set_if_not_set(CPACK_NSIS_DISPLAY_NAME "${CPACK_PACKAGE_INSTALL_DIRECTORY}") if(CPACK_NSIS_DISPLAY_NAME_SET) - string(REPLACE "\\" "\\\\" - _NSIS_DISPLAY_NAME_TMP "${CPACK_NSIS_DISPLAY_NAME}") - cpack_set_if_not_set(CPACK_NSIS_PACKAGE_NAME "${_NSIS_DISPLAY_NAME_TMP}") + cpack_set_if_not_set(CPACK_NSIS_PACKAGE_NAME "${CPACK_NSIS_DISPLAY_NAME}") else() cpack_set_if_not_set(CPACK_NSIS_PACKAGE_NAME "${CPACK_PACKAGE_INSTALL_DIRECTORY}") endif() @@ -604,7 +602,7 @@ cpack_set_if_not_set(CPACK_SOURCE_TOPLEVEL_TAG "${CPACK_SYSTEM_NAME}-Source") cpack_set_if_not_set(CPACK_SOURCE_PACKAGE_FILE_NAME "${CPACK_PACKAGE_NAME}-${CPACK_PACKAGE_VERSION}-Source") cpack_set_if_not_set(CPACK_SOURCE_IGNORE_FILES - "/CVS/;/\\\\\\\\.svn/;/\\\\\\\\.bzr/;/\\\\\\\\.hg/;/\\\\\\\\.git/;\\\\\\\\.swp$;\\\\\\\\.#;/#") + "/CVS/;/\\\\.svn/;/\\\\.bzr/;/\\\\.hg/;/\\\\.git/;\\\\.swp$;\\\\.#;/#") set(CPACK_INSTALL_CMAKE_PROJECTS "${CPACK_SOURCE_INSTALL_CMAKE_PROJECTS}") set(CPACK_INSTALLED_DIRECTORIES "${CPACK_SOURCE_INSTALLED_DIRECTORIES}") set(CPACK_GENERATOR "${CPACK_SOURCE_GENERATOR}") -- 2.1.4 From brad.king at kitware.com Tue Mar 3 15:02:51 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 03 Mar 2015 15:02:51 -0500 Subject: [cmake-developers] [PATCH] CPack: change cpack_set_if_not_set into a function In-Reply-To: <1425407635-1116-1-git-send-email-dpb@corrigendum.ru> References: <1425407635-1116-1-git-send-email-dpb@corrigendum.ru> Message-ID: <54F6136B.8030300@kitware.com> On 03/03/2015 01:33 PM, ????? ???????? wrote: > Since it's currently a macro, then due to macro processing rules, special > characters inside the value are interpreted by the parser, which can > result in syntax errors or a mismatch between the given default and the > value the variable is actually set to. > > Remove existing local workarounds for this issue, which are no longer > required. Thanks. As nice as it would be to do that, the reason it has not been done is that this API is exposed publicly. Any existing calls within other projects would also have such workarounds and they would be broken by this change. Instead one could introduce a new API function for this, e.g. cpack_maybe_set(...) Existing calls to cpack_set_if_not_set within CMake itself can be ported in an immediately following patch. The macro can be documented as deprecated with a suggestion to use the function instead. If you work on that, please include tests (perhaps in the form of a new Tests/RunCMake/CPack directory), documentation updates, and a release note in a file such as 'Help/release/dev/cpack-maybe-set.rst'. Thanks, -Brad From matt.mccormick at kitware.com Wed Mar 4 01:40:01 2015 From: matt.mccormick at kitware.com (Matt McCormick) Date: Wed, 4 Mar 2015 01:40:01 -0500 Subject: [cmake-developers] A CMAKE_EMULATOR variable Message-ID: Hi, I have pushed to stage [1] support for a CMAKE_EMULATOR variable to help when cross-compiling. The goal is to improve cross compiling with CMake by making it easier to build and run tests. In principle, the commands cmake -DCMAKE_TOOLCHAIN_FILE=/path/to/toolchain.cmake -DCMAKE_EMULATOR=/path/to/emulator ~/src/project cmake -D Experimental are all that is needed generate a dashboard report, complete with test results. This should inch C/C++ closer to being the "write once, run anywhere" languages :-). The emulator is used to run try_run results, which avoids manual population of TryRunResults.cmake. This can be a painful, time-consuming process otherwise. It is also used to run tests on executables that are built for the target system. Without this approach, it is difficult to know which tests should be executed on the target system. Tests are often passed absolute paths to input on the host system. The use of an emulator is a way to avoid complexities and transfer overhead related to reproducing the host filesystem on the target filesystem to run the tests. With some fixes to ITK [2], this was used to build and test for four cases of interest. The emulator approach works best with MinGW and WINE to build and test on Linux for Windows [3]. The qemu-arm emulator provided by QEMU User Mode can be used with the Android NDK toolchain [4]. A gotcha is that Android tries to be fancy and uses its own dynamic loader. To get around this, I tested with completely static executables. Also, QEMU User Mode does not currently support multi-threading well, so tests were run single-threaded. An alternative approach may be to use an emulator script that is a wrapper around adb. The qemu-arm emulator was used again with the Raspberry Pi toolchain [5]. A symbolic link was created in the expected location for ld-linux-armhf.so.3, and dynamic loading works. To run the tests, LD_LIBRARY_PATH was populated with the path to libc and libstdcxx. One of the most interesting combinations is the Emscripten toolchain with NodeJS as the emulator [6]. There are some WIP workarounds to get Emscripten to configure cleanly for scientific libraries [7], and code had to be injected into the test driver to mount local filesystems for node, but this works surprisingly well. Testing and feedback are appreciated. Thanks, Matt [1] http://www.cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/emulator [2] https://github.com/thewtex/ITK/tree/cmake-emulator [3] https://open.cdash.org/buildSummary.php?buildid=3694578 [4] https://open.cdash.org/buildSummary.php?buildid=3694810 [5] https://open.cdash.org/buildSummary.php?buildid=3694810 [6] https://open.cdash.org/buildSummary.php?buildid=3705525 [7] https://github.com/thewtex/emscripten/tree/test-big-endian From domen.vrankar at gmail.com Wed Mar 4 03:07:59 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Wed, 4 Mar 2015 09:07:59 +0100 Subject: [cmake-developers] [PATCH] CPack: change cpack_set_if_not_set into a function In-Reply-To: <54F6136B.8030300@kitware.com> References: <1425407635-1116-1-git-send-email-dpb@corrigendum.ru> <54F6136B.8030300@kitware.com> Message-ID: > If you work on that, please include tests (perhaps in the form of a > new Tests/RunCMake/CPack directory), documentation updates, and a > release note in a file such as 'Help/release/dev/cpack-maybe-set.rst'. For that you could rename Tests/RunCMake/CPackRPM to CPack and add your tests there - CMakeLists.txt and RunCMakeTest.cmake files should be what you need. Regards, Domen From DLRdave at aol.com Wed Mar 4 06:49:25 2015 From: DLRdave at aol.com (David Cole) Date: Wed, 4 Mar 2015 06:49:25 -0500 Subject: [cmake-developers] A CMAKE_EMULATOR variable In-Reply-To: References: Message-ID: What does CMAKE_EMULATOR emulate? >From its name, it sounds like it emulates CMake. But from your description, I'm thinking that doesn't make sense... Because you actually run CMake and pass it CMAKE_EMULATOR. So it must be emulating something else while running CMake? I'm guessing it emulates the target system when cross-compiling, and executables built for the target system can be run when passed to the emulator? Is that right? D On Wednesday, March 4, 2015, Matt McCormick wrote: > Hi, > > I have pushed to stage [1] support for a CMAKE_EMULATOR variable to > help when cross-compiling. The goal is to improve cross compiling > with CMake by making it easier to build and run tests. In principle, > the commands > > cmake -DCMAKE_TOOLCHAIN_FILE=/path/to/toolchain.cmake > -DCMAKE_EMULATOR=/path/to/emulator ~/src/project > cmake -D Experimental > > are all that is needed generate a dashboard report, complete with test > results. This should inch C/C++ closer to being the "write once, run > anywhere" languages :-). > > The emulator is used to run try_run results, which avoids manual > population of TryRunResults.cmake. This can be a painful, > time-consuming process otherwise. > > It is also used to run tests on executables that are built for the > target system. Without this approach, it is difficult to know which > tests should be executed on the target system. Tests are often passed > absolute paths to input on the host system. The use of an emulator is > a way to avoid complexities and transfer overhead related to > reproducing the host filesystem on the target filesystem to run the > tests. > > > With some fixes to ITK [2], this was used to build and test for four > cases of interest. > > The emulator approach works best with MinGW and WINE to build and test > on Linux for Windows [3]. > > The qemu-arm emulator provided by QEMU User Mode can be used with the > Android NDK toolchain [4]. A gotcha is that Android tries to be fancy > and uses its own dynamic loader. To get around this, I tested with > completely static executables. Also, QEMU User Mode does not > currently support multi-threading well, so tests were run > single-threaded. An alternative approach may be to use an emulator > script that is a wrapper around adb. > > The qemu-arm emulator was used again with the Raspberry Pi toolchain > [5]. A symbolic link was created in the expected location for > ld-linux-armhf.so.3, and dynamic loading works. To run the tests, > LD_LIBRARY_PATH was populated with the path to libc and libstdcxx. > > One of the most interesting combinations is the Emscripten toolchain > with NodeJS as the emulator [6]. There are some WIP workarounds to get > Emscripten to configure cleanly for scientific libraries [7], and code > had to be injected into the test driver to mount local filesystems for > node, but this works surprisingly well. > > > Testing and feedback are appreciated. > > Thanks, > Matt > > > [1] > http://www.cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/emulator > > [2] https://github.com/thewtex/ITK/tree/cmake-emulator > > [3] https://open.cdash.org/buildSummary.php?buildid=3694578 > > [4] https://open.cdash.org/buildSummary.php?buildid=3694810 > > [5] https://open.cdash.org/buildSummary.php?buildid=3694810 > > [6] https://open.cdash.org/buildSummary.php?buildid=3705525 > > [7] https://github.com/thewtex/emscripten/tree/test-big-endian > -- > > 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 matt.mccormick at kitware.com Wed Mar 4 11:06:43 2015 From: matt.mccormick at kitware.com (Matt McCormick) Date: Wed, 4 Mar 2015 11:06:43 -0500 Subject: [cmake-developers] A CMAKE_EMULATOR variable In-Reply-To: References: Message-ID: Yes: > it emulates the target system when cross-compiling, and > executables built for the target system can be run when passed to the > emulator. is exactly correct. Perhaps the name CMAKE_TARGET_SYSTEM_EMULATOR is necessary to resolve the ambiguity. Or... Thanks, Matt On Wed, Mar 4, 2015 at 6:49 AM, David Cole wrote: > What does CMAKE_EMULATOR emulate? > > From its name, it sounds like it emulates CMake. But from your description, > I'm thinking that doesn't make sense... Because you actually run CMake and > pass it CMAKE_EMULATOR. So it must be emulating something else while running > CMake? > > I'm guessing it emulates the target system when cross-compiling, and > executables built for the target system can be run when passed to the > emulator? Is that right? > > > D > > > > On Wednesday, March 4, 2015, Matt McCormick > wrote: >> >> Hi, >> >> I have pushed to stage [1] support for a CMAKE_EMULATOR variable to >> help when cross-compiling. The goal is to improve cross compiling >> with CMake by making it easier to build and run tests. In principle, >> the commands >> >> cmake -DCMAKE_TOOLCHAIN_FILE=/path/to/toolchain.cmake >> -DCMAKE_EMULATOR=/path/to/emulator ~/src/project >> cmake -D Experimental >> >> are all that is needed generate a dashboard report, complete with test >> results. This should inch C/C++ closer to being the "write once, run >> anywhere" languages :-). >> >> The emulator is used to run try_run results, which avoids manual >> population of TryRunResults.cmake. This can be a painful, >> time-consuming process otherwise. >> >> It is also used to run tests on executables that are built for the >> target system. Without this approach, it is difficult to know which >> tests should be executed on the target system. Tests are often passed >> absolute paths to input on the host system. The use of an emulator is >> a way to avoid complexities and transfer overhead related to >> reproducing the host filesystem on the target filesystem to run the >> tests. >> >> >> With some fixes to ITK [2], this was used to build and test for four >> cases of interest. >> >> The emulator approach works best with MinGW and WINE to build and test >> on Linux for Windows [3]. >> >> The qemu-arm emulator provided by QEMU User Mode can be used with the >> Android NDK toolchain [4]. A gotcha is that Android tries to be fancy >> and uses its own dynamic loader. To get around this, I tested with >> completely static executables. Also, QEMU User Mode does not >> currently support multi-threading well, so tests were run >> single-threaded. An alternative approach may be to use an emulator >> script that is a wrapper around adb. >> >> The qemu-arm emulator was used again with the Raspberry Pi toolchain >> [5]. A symbolic link was created in the expected location for >> ld-linux-armhf.so.3, and dynamic loading works. To run the tests, >> LD_LIBRARY_PATH was populated with the path to libc and libstdcxx. >> >> One of the most interesting combinations is the Emscripten toolchain >> with NodeJS as the emulator [6]. There are some WIP workarounds to get >> Emscripten to configure cleanly for scientific libraries [7], and code >> had to be injected into the test driver to mount local filesystems for >> node, but this works surprisingly well. >> >> >> Testing and feedback are appreciated. >> >> Thanks, >> Matt >> >> >> [1] >> http://www.cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/emulator >> >> [2] https://github.com/thewtex/ITK/tree/cmake-emulator >> >> [3] https://open.cdash.org/buildSummary.php?buildid=3694578 >> >> [4] https://open.cdash.org/buildSummary.php?buildid=3694810 >> >> [5] https://open.cdash.org/buildSummary.php?buildid=3694810 >> >> [6] https://open.cdash.org/buildSummary.php?buildid=3705525 >> >> [7] https://github.com/thewtex/emscripten/tree/test-big-endian >> -- >> >> 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 florent.castelli at gmail.com Wed Mar 4 11:40:59 2015 From: florent.castelli at gmail.com (Florent Castelli) Date: Wed, 4 Mar 2015 17:40:59 +0100 Subject: [cmake-developers] A CMAKE_EMULATOR variable In-Reply-To: References: Message-ID: Sometimes, it?s not just about an emulator but a wrapper script that can run the target binary on a remote host or with the right environment (or use valgrind, helgrind, whatevergrind...). I?d be nice to have the option in ctest to use some script to run a test program and an option to set it from CMake globally or when running ctest directly. /Orphis > On 04 Mar 2015, at 17:06, Matt McCormick wrote: > > Yes: > >> it emulates the target system when cross-compiling, and >> executables built for the target system can be run when passed to the >> emulator. > > is exactly correct. > > Perhaps the name CMAKE_TARGET_SYSTEM_EMULATOR is necessary to resolve > the ambiguity. Or... > > Thanks, > Matt > > On Wed, Mar 4, 2015 at 6:49 AM, David Cole wrote: >> What does CMAKE_EMULATOR emulate? >> >> From its name, it sounds like it emulates CMake. But from your description, >> I'm thinking that doesn't make sense... Because you actually run CMake and >> pass it CMAKE_EMULATOR. So it must be emulating something else while running >> CMake? >> >> I'm guessing it emulates the target system when cross-compiling, and >> executables built for the target system can be run when passed to the >> emulator? Is that right? >> >> >> D >> >> >> >> On Wednesday, March 4, 2015, Matt McCormick >> wrote: >>> >>> Hi, >>> >>> I have pushed to stage [1] support for a CMAKE_EMULATOR variable to >>> help when cross-compiling. The goal is to improve cross compiling >>> with CMake by making it easier to build and run tests. In principle, >>> the commands >>> >>> cmake -DCMAKE_TOOLCHAIN_FILE=/path/to/toolchain.cmake >>> -DCMAKE_EMULATOR=/path/to/emulator ~/src/project >>> cmake -D Experimental >>> >>> are all that is needed generate a dashboard report, complete with test >>> results. This should inch C/C++ closer to being the "write once, run >>> anywhere" languages :-). >>> >>> The emulator is used to run try_run results, which avoids manual >>> population of TryRunResults.cmake. This can be a painful, >>> time-consuming process otherwise. >>> >>> It is also used to run tests on executables that are built for the >>> target system. Without this approach, it is difficult to know which >>> tests should be executed on the target system. Tests are often passed >>> absolute paths to input on the host system. The use of an emulator is >>> a way to avoid complexities and transfer overhead related to >>> reproducing the host filesystem on the target filesystem to run the >>> tests. >>> >>> >>> With some fixes to ITK [2], this was used to build and test for four >>> cases of interest. >>> >>> The emulator approach works best with MinGW and WINE to build and test >>> on Linux for Windows [3]. >>> >>> The qemu-arm emulator provided by QEMU User Mode can be used with the >>> Android NDK toolchain [4]. A gotcha is that Android tries to be fancy >>> and uses its own dynamic loader. To get around this, I tested with >>> completely static executables. Also, QEMU User Mode does not >>> currently support multi-threading well, so tests were run >>> single-threaded. An alternative approach may be to use an emulator >>> script that is a wrapper around adb. >>> >>> The qemu-arm emulator was used again with the Raspberry Pi toolchain >>> [5]. A symbolic link was created in the expected location for >>> ld-linux-armhf.so.3, and dynamic loading works. To run the tests, >>> LD_LIBRARY_PATH was populated with the path to libc and libstdcxx. >>> >>> One of the most interesting combinations is the Emscripten toolchain >>> with NodeJS as the emulator [6]. There are some WIP workarounds to get >>> Emscripten to configure cleanly for scientific libraries [7], and code >>> had to be injected into the test driver to mount local filesystems for >>> node, but this works surprisingly well. >>> >>> >>> Testing and feedback are appreciated. >>> >>> Thanks, >>> Matt >>> >>> >>> [1] >>> http://www.cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/emulator >>> >>> [2] https://github.com/thewtex/ITK/tree/cmake-emulator >>> >>> [3] https://open.cdash.org/buildSummary.php?buildid=3694578 >>> >>> [4] https://open.cdash.org/buildSummary.php?buildid=3694810 >>> >>> [5] https://open.cdash.org/buildSummary.php?buildid=3694810 >>> >>> [6] https://open.cdash.org/buildSummary.php?buildid=3705525 >>> >>> [7] https://github.com/thewtex/emscripten/tree/test-big-endian >>> -- >>> >>> 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 From brad.king at kitware.com Wed Mar 4 12:00:05 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 04 Mar 2015 12:00:05 -0500 Subject: [cmake-developers] A CMAKE_EMULATOR variable In-Reply-To: References: Message-ID: <54F73A15.7070306@kitware.com> >> On 04 Mar 2015, at 17:06, Matt McCormick wrote: >> >> Perhaps the name CMAKE_TARGET_SYSTEM_EMULATOR is necessary to resolve >> the ambiguity. The name "target" is overloaded. It usually refers to build targets. Only in a few places does it refer to a cross-compile target platform. Since this behavior is activated by CMAKE_CROSSCOMPILING, perhaps it should be named as such: CMAKE_CROSSCOMPILING_TARGET_LAUNCHER. However, I do not think a global setting like this makes sense. We cannot unconditionally add the cross-compiling target launcher in front of all tests. Some tests may be running host tools. See below. We already have variables like CMAKE_TRY_COMPILE_CONFIGURATION CMAKE_TRY_COMPILE_OSX_ARCHITECTURES to control behavior of try_compile calls. One could add a CMAKE_TRY_RUN_LAUNCHER to control try_run. If set it should be used whether we are cross compiling or not. This can be used when cross compiling to get the proposed behavior for try_run. Tests are another story. On 03/04/2015 11:40 AM, Florent Castelli wrote: > not just about an emulator but a wrapper Wrapping or launching almost always has to be configurable on a per-test basis. Any kind of global setting will always need a local setting to override it. That raises the question of which one should take precedence. There are too many possible semantics here for "standard" wrapper interfaces to be defined cleanly IMO. Wrappers can be added directly in the add_test calls. In particular the add_test(NAME) signature makes it easy by allowing one to use generator expressions to refer to the real executable targets: add_test(NAME MyTest COMMAND ${mylauncher} $) This basic primitive allows projects to configure any semantics they want. -Brad From brad.king at kitware.com Wed Mar 4 14:53:55 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 04 Mar 2015 14:53:55 -0500 Subject: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation In-Reply-To: <5BB62C37-0B76-4CA9-9529-3E3FCB5D151E@java.pl> References: <20150302010209.GC17534@bronto-burt.dev.benboeckel.net> <5BB62C37-0B76-4CA9-9529-3E3FCB5D151E@java.pl> Message-ID: <54F762D3.8080608@kitware.com> On 03/03/2015 07:43 AM, Adam Strzelecki wrote: > On 03/01/2015 08:02 PM, Ben Boeckel wrote: >> On 02/28/2015 11:59 AM, Adam Strzelecki wrote: >> target_precompiled_header( ) >> >> target_precompiled_header( SHARED >> ) >> Could we rename this? Currently target_* functions are all related to >> usage requirements and these are not usage requirements. > > Honestly I don't understand your request. What would be then the name > that better represents what the function does. Currently the target_* commands are: target_compile_definitions target_compile_features target_compile_options target_include_directories target_link_libraries target_sources They all have the general signature target_command( [options] [ ...]...) where is INTERFACE, PUBLIC, or PRIVATE and affects whether the settings apply to sources in the target itself and/or its dependents. The proposed target_precompiled_header signature does not fit into this layout. Either a different command name is needed or one needs to define the command signature and semantics to fit the above layout. Do PCHs fit into usage requirements in any way? There is discussion elsewhere in this thread is about re-using precompiled headers across multiple targets. Since every target can have its own preprocessor definitions and other flags for the same sources, this functionality needs to be used with care. The interface design should make this hard to do wrong if possible. There is also discussion about consuming a PCH only in a subset of sources for a target. In principle the selection has to be separate for each target/source pair. The decision of whether to use an approach that ends up with separate rules for specific source files or to use an OBJECT library should be left up to the project author. CMake should provide options for both alternatives. > I want this to be handled natively adding some extra variables: > > CMAKE__PRECOMPILE_HEADER > > GCC, Clang: same as CMAKE__COMPILE_OBJECT > MSVC: CMAKE__COMPILE_OBJECT with "-c" replaced with "/FoNUL /Yc /Fp" > > CMAKE__PRECOMPILED_HEADER_EXTENSION > > GCC: .gch > MSVC, Clang: .pch > > CMAKE_PRECOMPILED_HEADER_FLAG_ I think the name still start in "CMAKE__". > GCC, Clang: -include > MSVC: /Yu /Fp /FI$ > > And extending CMake to generate proper build commands for Makefile, > Ninja targets, and also Xcode, MSVC generators. Yes, please. Thanks for offering to work on this. This has been a long-missing feature. However, we need to get the abstractions and interfaces right so a few rounds of discussion will be needed first. -Brad From brad.king at kitware.com Wed Mar 4 15:05:06 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 04 Mar 2015 15:05:06 -0500 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: Message-ID: <54F76572.9000206@kitware.com> On 03/02/2015 09:10 PM, Aleix Pol wrote: > I created a new version of the patch: > http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE-v2.patch Thanks. > Samples: > LLVM: https://paste.kde.org/pelr1ditp > A small random KDE project: https://paste.kde.org/pgkbecv5p The "location" values need to be inside the "configs" elements because they can vary with the configuration in multi-config generators. Also the name "location" may not be specific enough. Some targets may have multiple output files (e.g. .dll, .lib). See the breakdown of $ generator expressions: http://www.cmake.org/cmake/help/v3.2/manual/cmake-generator-expressions.7.html#informational-expressions Some set of values like that will be more useful. If the the "directory" value is GetCurrentOutputDirectory, the build tree location of the project file, then that does not need to be per-configuration. In that case perhaps the name should be something like "build_directory" or "project_directory". Thanks, -Brad From mantis at public.kitware.com Wed Mar 4 15:23:43 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 4 Mar 2015 15:23:43 -0500 Subject: [cmake-developers] [CMake 0015429]: Emacs: Please, inherit `cmake-mode' from `prog-mode' Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15429 ====================================================================== Reported By: Haroogan Assigned To: ====================================================================== Project: CMake Issue ID: 15429 Category: CMake Reproducibility: always Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-04 15:23 EST Last Modified: 2015-03-04 15:23 EST ====================================================================== Summary: Emacs: Please, inherit `cmake-mode' from `prog-mode' Description: The title speaks for itself. Is there any particular reason that you decided not to make any inheritance for `cmake-mode'? Some people (including me) have things like (add-hook 'text-mode-hook 'fci-mode) (add-hook 'prog-mode-hook 'fci-mode) which make life easier, and that's exactly one of those features what proper mode inheritance was intended for. Please, consider using proper way of Emacs major mode definition, i.e. (define-derived-mode cmake-mode prog-mode "CMAKE" ... Thank you. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-04 15:23 Haroogan New Issue ====================================================================== From matt.mccormick at kitware.com Wed Mar 4 20:15:13 2015 From: matt.mccormick at kitware.com (Matt McCormick) Date: Wed, 4 Mar 2015 20:15:13 -0500 Subject: [cmake-developers] A CMAKE_EMULATOR variable In-Reply-To: <54F73A15.7070306@kitware.com> References: <54F73A15.7070306@kitware.com> Message-ID: On Wed, Mar 4, 2015 at 12:00 PM, Brad King wrote: > However, > I do not think a global setting like this makes sense. We cannot > unconditionally add the cross-compiling target launcher in front of > all tests. Some tests may be running host tools. See below. This set of patches does not globally and unconditionally add a launcher in front of all tests. It uses build system knowledge to add the emulator commands in front of target executables only. Test with host executables run with the host command. This is why it is advantageous to use the emulator in this way. > On 03/04/2015 11:40 AM, Florent Castelli wrote: >> not just about an emulator but a wrapper > > Wrapping or launching almost always has to be configurable on a > per-test basis. Any kind of global setting will always need a local > setting to override it. That raises the question of which one should > take precedence. There are too many possible semantics here for > "standard" wrapper interfaces to be defined cleanly IMO. Wrappers are difficult and take tweaking, but wrappers are a diversion here -- this is intended to be used with emulators or programs that act very close to emulators. It has been shown to work with ITK, a very large and complex project, and with a number of diverse cross-compiling toolchains and targets. No per-test tweaks were made in ITK's over 2500 tests. The point about the overloaded meaning of "targets" is a good one. I think the best name is then CMAKE_CROSSCOMPILING_EMULATOR. Thanks, Matt From mantis at public.kitware.com Thu Mar 5 05:51:31 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 5 Mar 2015 11:51:31 +0100 Subject: [cmake-developers] [CMake 0015430]: Search when "Grouped" is selected misbehaves in CMake GUI Message-ID: <0fdbde752eb613379f7859f9f8c45d4a@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15430 ====================================================================== Reported By: Daniele E. Domenichelli Assigned To: ====================================================================== Project: CMake Issue ID: 15430 Category: QtDialog Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-05 11:51 CET Last Modified: 2015-03-05 11:51 CET ====================================================================== Summary: Search when "Grouped" is selected misbehaves in CMake GUI Description: When "grouped" is selected, if you start a search, the arrow for expanding the group disappears and the item cannot be expanded, therefore the results of the search cannot be selected. If you disable "grouped" and enable it again the arrow appears. The expected behaviour would be to always have the arrow. Steps to Reproduce: Start CMake Gui, open a project, select "grouped" and start a search ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-05 11:51 Daniele E. DomenichelliNew Issue ====================================================================== From brad.king at kitware.com Thu Mar 5 09:51:15 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 05 Mar 2015 09:51:15 -0500 Subject: [cmake-developers] A CMAKE_EMULATOR variable In-Reply-To: References: <54F73A15.7070306@kitware.com> Message-ID: <54F86D63.8040709@kitware.com> On 03/04/2015 08:15 PM, Matt McCormick wrote: > On Wed, Mar 4, 2015 at 12:00 PM, Brad King wrote: >> I do not think a global setting like this makes sense. We cannot >> unconditionally add the cross-compiling target launcher in front of >> all tests. Some tests may be running host tools. See below. > > This set of patches does not globally and unconditionally add a > launcher in front of all tests. It uses build system knowledge to add > the emulator commands in front of target executables only. Good, but it may take more work. I see the key logic here: > cmTarget* target = mf->FindTargetToUse(exe); > if(target && target->GetType() == cmTarget::EXECUTABLE) > { > // Use the target file on disk. > exe = target->GetFullPath(config); > + > + // Prepend with the emulator when cross compiling if required. This if() condition is not sufficient to know that the executable is for the target architecture. The cmTarget could be IMPORTED, in which case we don't know whether it references a host tool or one built for the target architecture. Some kind of target property may be needed to say "use the emulator to run me" more explicitly. Once we have such a property, then it might as well refer to the tool to be used, e.g. add_executable(myexe ...) set_property(TARGET myexe PROPERTY CROSSCOMPILING_EMULATOR ${emulator}) > The point about the overloaded meaning of "targets" is a good one. I > think the best name is then CMAKE_CROSSCOMPILING_EMULATOR. Sounds good. This variable could be used to initialize the above property on target creation (see SetPropertyDefault calls). In try_run we simply need to pass the value into the inner project and its executable will pick it up too. -Brad From mantis at public.kitware.com Thu Mar 5 10:08:43 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 5 Mar 2015 10:08:43 -0500 Subject: [cmake-developers] [CMake 0015431]: Skipped tests (SKIP_RETURN_CODE) cause non-zero exit code Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15431 ====================================================================== Reported By: hansmi Assigned To: ====================================================================== Project: CMake Issue ID: 15431 Category: CTest Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-05 10:08 EST Last Modified: 2015-03-05 10:08 EST ====================================================================== Summary: Skipped tests (SKIP_RETURN_CODE) cause non-zero exit code Description: Issue http://public.kitware.com/Bug/view.php?id=8466 implemented a property named SKIP_RETURN_CODE for tests. It works as intended, but CTest's exit status is non-zero when one or more tests were skipped. CMake's support for CTest automatically generates a target which relies on the exit code of CTest to indicate success. There should probably be a flag (and/or environment variable) to indicate that skipped tests are acceptable. Steps to Reproduce: Add a skipped test: add_test(NAME mytest COMMAND bash -c "exit 77") set_property(TEST mytest PROPERTY SKIP_RETURN_CODE 77) Then run ?cmake --build . --target test?. At least with GNU make this causes a failure. 1/1 Test http://public.kitware.com/Bug/view.php?id=1: mytest ...............***Skipped 0.00 sec ? The following tests FAILED: 1 - mytest (Not Run) Errors while running CTest Makefile:117: recipe for target 'test' failed make: *** [test] Error 8 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-05 10:08 hansmi New Issue ====================================================================== From nilsgladitz at gmail.com Fri Mar 6 06:57:04 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 06 Mar 2015 12:57:04 +0100 Subject: [cmake-developers] [CMake] Wrong behavior with 3.2.0-rc2 In-Reply-To: References: Message-ID: <54F99610.7070503@gmail.com> On 03/06/2015 10:22 AM, Pere Mato Vila wrote: > Using version 3.2.0-rc2 on the Mac OS X 10.10 with the make generator. > The following example executes the custom to create A.txt and B.txt > twice when building with make -jN > > ????????- > cmake_minimum_required(VERSION 2.8.8 FATAL_ERROR) > add_custom_target(Main ALL DEPENDS A.txt B.txt) > add_custom_command(OUTPUT A.txt B.txt > COMMAND touch A.txt > COMMAND touch B.txt) > > ????????- > $ make clean > $ make -j10 > -- Configuring done > -- Generating done > -- Build files have been written to: > /Users/mato/Development/ROOT/build.master/temp > [100%] [100%] *Generating A.txt, B.txt* > *Generating A.txt, B.txt* > [100%] Built target Main > > > This is not the case for version 3.1.3. This seems to be the case since [644b4688d71cc52f8499d6103495de0909319557] Makefile: Fix rebuild with multiple custom command outputs (#15116) Nils From mantis at public.kitware.com Fri Mar 6 08:01:44 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 6 Mar 2015 08:01:44 -0500 Subject: [cmake-developers] [CMake 0015432]: FindHDF5 HDF5_USE_STATIC_LIBRARIES should only apply to HD5 specific libraries Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15432 ====================================================================== Reported By: Sascha Kratky Assigned To: ====================================================================== Project: CMake Issue ID: 15432 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-06 08:01 EST Last Modified: 2015-03-06 08:01 EST ====================================================================== Summary: FindHDF5 HDF5_USE_STATIC_LIBRARIES should only apply to HD5 specific libraries Description: When HDF5_USE_STATIC_LIBRARIES is set to ON, i.e.: set (HDF5_USE_STATIC_LIBRARIES ON) find_package (HDF5) the module also links system libraries like libm, librt, libdl and libpthread statically. This does not work for shared libraries under Linux. The HDF5_USE_STATIC_LIBRARIES should only affect the linking of HDF5 related libraries libhdf5, libhdf5_hl libhdf5_cpp.a. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-06 08:01 Sascha Kratky New Issue ====================================================================== From mantis at public.kitware.com Fri Mar 6 08:08:54 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 6 Mar 2015 08:08:54 -0500 Subject: [cmake-developers] [CMake 0015433]: CPack WIX creates incorrect .wixobj filenames for CPACK_WIX_EXTRA_SOURCES Message-ID: <3d70634bb6e13e5d7a48f0ac9a1ab7cb@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15433 ====================================================================== Reported By: Mark Stijnman Assigned To: ====================================================================== Project: CMake Issue ID: 15433 Category: CPack Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-06 08:08 EST Last Modified: 2015-03-06 08:08 EST ====================================================================== Summary: CPack WIX creates incorrect .wixobj filenames for CPACK_WIX_EXTRA_SOURCES Description: When using CPACK_WIX_EXTRA_SOURCES with filenames like MyProject.fragment1.wxs and MyProject.fragment2.wxs, in both cases the filename generated for the .wixobj file for the candle command is MyProject.wixobj, stripping both extensions. When you do this, the light command will therefore be trying to link MyProject.wixobj twice, leading to duplicate definition errors. Steps to Reproduce: Run the attached minimal test case, which includes two fragments that each define a single property, 'Fragment1Prop' and 'Fragment2Prop'. When you build the PACKAGE target, it will fail with an error "error LGHT0091 : Duplicate symbol 'Property:Fragment2Prop' found." Additional Information: The solution is to change the call to cmSystemTools::GetFilenameWithoutExtension, in cmCPackWIXGenerator.cxx, line 274, to a call to cmSystemTools::GetFilenameWithoutLastExtension. A workaround currently is to just use a different naming convention, like MyProject_fragment1.wxs. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-06 08:08 Mark Stijnman New Issue 2015-03-06 08:08 Mark Stijnman File Added: testcase.zip ====================================================================== From gaetan.lehmann at gmail.com Fri Mar 6 09:17:26 2015 From: gaetan.lehmann at gmail.com (Gaetan Lehmann) Date: Fri, 6 Mar 2015 15:17:26 +0100 Subject: [cmake-developers] location tag substitution in external project BUILD_BYPRODUCTS Message-ID: Hi, BUILD_BYPRODUCTS works very well with external projects and ninja :-) I'd like to propose a small enhancement: replace the location tags like by their real path in BUILD_BYPRODUCTS, in order to let the developer specify the byproducts without explicitly setting the external project binary dir. See the attached patch. Exposing _ep_replace_location_tags with a prettier name would also be nice. An example using that feature: https://github.com/glehmann/gtest-external/blob/byproduct-subst/gtest.cmake Thanks, Ga?tan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-replace-location-tags-in-external-project-byproducts.patch Type: application/octet-stream Size: 2710 bytes Desc: not available URL: From mantis at public.kitware.com Fri Mar 6 10:38:17 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 6 Mar 2015 10:38:17 -0500 Subject: [cmake-developers] [CMake 0015434]: Multiple add_custom_command with the same MAIN_DEPENDENCY causes duplicate rule invokations Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15434 ====================================================================== Reported By: Ben Boeckel Assigned To: ====================================================================== Project: CMake Issue ID: 15434 Category: CMake Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-06 10:38 EST Last Modified: 2015-03-06 10:38 EST ====================================================================== Summary: Multiple add_custom_command with the same MAIN_DEPENDENCY causes duplicate rule invokations Description: Latest report: https://bugzilla.redhat.com/show_bug.cgi?id=1199360 AFAIK, I've only heard of this with the Unix Makefiles generator. Minimal test case wanted. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-06 10:38 Ben Boeckel New Issue ====================================================================== From aleixpol at kde.org Fri Mar 6 11:12:57 2015 From: aleixpol at kde.org (Aleix Pol) Date: Fri, 6 Mar 2015 17:12:57 +0100 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <54F76572.9000206@kitware.com> References: <54F76572.9000206@kitware.com> Message-ID: On Wed, Mar 4, 2015 at 9:05 PM, Brad King wrote: > On 03/02/2015 09:10 PM, Aleix Pol wrote: >> I created a new version of the patch: >> http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE-v2.patch > > Thanks. > >> Samples: >> LLVM: https://paste.kde.org/pelr1ditp >> A small random KDE project: https://paste.kde.org/pgkbecv5p > > The "location" values need to be inside the "configs" elements because > they can vary with the configuration in multi-config generators. > Also the name "location" may not be specific enough. Some targets > may have multiple output files (e.g. .dll, .lib). See the breakdown > of $ generator expressions: > > http://www.cmake.org/cmake/help/v3.2/manual/cmake-generator-expressions.7.html#informational-expressions > > Some set of values like that will be more useful. Good point, I changed it to use $. Showing a directory didn't make much sense anyway as we have more information with the full file path. > > If the the "directory" value is GetCurrentOutputDirectory, the > build tree location of the project file, then that does not need > to be per-configuration. In that case perhaps the name should be > something like "build_directory" or "project_directory". Used output_directory to match internal cmake naming. https://paste.kde.org/p5ogjqi2n https://paste.kde.org/puzgrgkzy And the new version of the patch (sorry my hosting seems down and I can't connect). https://paste.kde.org/pq0xungvq Aleix From brad.king at kitware.com Fri Mar 6 15:38:32 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 06 Mar 2015 15:38:32 -0500 Subject: [cmake-developers] [CMake] Wrong behavior with 3.2.0-rc2 In-Reply-To: <54F99610.7070503@gmail.com> References: <54F99610.7070503@gmail.com> Message-ID: <54FA1048.5070008@kitware.com> On 03/06/2015 06:57 AM, Nils Gladitz wrote: > On 03/06/2015 10:22 AM, Pere Mato Vila wrote: >> [100%] [100%] *Generating A.txt, B.txt* >> *Generating A.txt, B.txt* Thanks for trying the release candidate and reporting this. > This seems to be the case since > [644b4688d71cc52f8499d6103495de0909319557] Makefile: Fix rebuild with > multiple custom command outputs (#15116) Yes. I've re-opened the corresponding issue with a note about this: http://www.cmake.org/Bug/view.php?id=15116#c38168 Please follow that issue for further updates. We've already tagged v3.2.0 but it was not announced yet. It looks like 3.2.0 is DOA and we will have to skip to 3.2.1 to fix this. Thanks, -Brad From brad.king at kitware.com Fri Mar 6 15:56:48 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 06 Mar 2015 15:56:48 -0500 Subject: [cmake-developers] location tag substitution in external project BUILD_BYPRODUCTS In-Reply-To: References: Message-ID: <54FA1490.4090405@kitware.com> On 03/06/2015 09:17 AM, Gaetan Lehmann wrote: > I'd like to propose a small enhancement: replace the location > tags like by their real path in BUILD_BYPRODUCTS Good idea, thanks. I'll test the patch and integrate when I get a chance. -Brad From tobias.hunger at gmail.com Sat Mar 7 05:46:23 2015 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Sat, 7 Mar 2015 11:46:23 +0100 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: <54F76572.9000206@kitware.com> Message-ID: Hi Aleix, thank you for the ping:-) Since I am not fully fluent with cmake (have not really used it in a couple of years) and sometimes have a bit of trouble following the discussion about the details of this patch, I took the liberty to copy/paste (and part of) one of the example files you put up on KDEs codepaster, commenting on what I understood each section to mean. I think that is the best way for me to contribute to this discussion at this point. What are you actually building here? /home/kde-devel/tmp/llvm/CMakeLists.txt? > { How about adding some information on what this is you are actually building here? CMake has the PROJECT command that does provide quite a bit of information that could go here. Where are the sources this thing here is building? How were those sources configured? CMake supports quite a few generators, so which ones where used? Do I need to run ninja or make to build this (or should I use "cmake build" anyway)? Creator does allow existing qmake builds to be imported and that kind of information does help a lot with that functionality. > "dependencies" : > [ "/home/kde-devel/tmp/llvm/build/CMakeFiles/3.2.20150306-g139588/CMakeSystem.cmake", "/lots/more/files", ... ] So these are all the files I need to watch for changes? If they change then I should re-run cmake? > "targets" : > [ So now comes a list of the possible things I can build... > { > "backtrace" : > [ > "/home/kde-devel/tmp/llvm/cmake/modules/AddLLVM.cmake:312", > "/home/kde-devel/tmp/llvm/cmake/modules/AddLLVM.cmake:399", > "/home/kde-devel/tmp/llvm/lib/Target/PowerPC/TargetInfo/CMakeLists.txt:1" > ], That backtrace is nice! > "configs" : > [ > { > "name" : "", Why is the name empty? > "output" : "/home/kde-devel/tmp/llvm/build/lib/libLLVMPowerPCInfo.a", Can this be a list? > "sources" : [ "/list/of/cpp/files, ] Any way to also get the headers? Do you see any option to hint where new sources would need to be added to make them a part of this target? > } > ], > "installed" : "true", I guess this means "make install" will install it. Where will this file end up? > "name" : "LLVMPowerPCInfo", > "output_directory" : "/home/kde-devel/tmp/llvm/build/lib/Target/PowerPC/TargetInfo", For what is the output directory relevant? The output above does implicitly list that already, doesn't it? > "type" : "STATIC_LIBRARY" Which types are possible here? > }, There is a lot of useful information here! Thanks for pushing into this direction. I am sure this will help a lot. Ideally this file would be enough to provide all information we need as an IDE to: * Present the project structure as seen by the build system. * Generate the code model * Build the project * Deploy the project * Run and debug parts of the project * Adding and removing files to a project For the project structure this does help: It provides us with a list of all the build targets, which is already nice. CMake does support more structure with Projects and subprojects IIRC and that information is lost. Would it be much work to get that information back? For the code model this is not much help at all: There is no information on compiler used, include directories nor Defines or compiler flags. Where am I supposed to get that information from? Do I need to generate and parse the list of commands run and extract that information from there? Having that information available right in the sources array of each target would be so much more convenient and would also make IDE integration so much easier: You would need to know about one file only and won't need to figure out several. Building the project should be fine with the information provided. Explicitly stating the generators used would help a little bit (even better just giving the command necessary to build, e.g. make or ninja or whatnot. Then we would not need to hard-code the mapping of generators->build tools, which makes it much easier for you to support new things:-) Running/Debugging is a bit tricky again: All the information used for linking the binaries is gone. So there is no way to figure out which LD_LIBRARY_PATH needs to be set or anything. There also seems to be no information where files are going to get installed to. Would it be possible to add that information? I do not see any way to provide a reliable automatic way to add sources to a cmake build system (the others are unfortunately not better:-). For removing the files it would be nice to know where in which file/line the sources were added to the target. Not sure whether it is even possible to get that information... The backtrace you have is already great piece of information: At least that way we should be able to open the right file and have the user edit that manually. Does this help? Best Regards, Tobias From mantis at public.kitware.com Sat Mar 7 06:24:22 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 7 Mar 2015 06:24:22 -0500 Subject: [cmake-developers] [CMake 0015436]: ninja generator fails to produce include statement for rules Message-ID: <0095390447b663e4dfa1298a4eadc4d2@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15436 ====================================================================== Reported By: Benjamin Schindler Assigned To: ====================================================================== Project: CMake Issue ID: 15436 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-07 06:24 EST Last Modified: 2015-03-07 06:24 EST ====================================================================== Summary: ninja generator fails to produce include statement for rules Description: I tried now cmake-3.0, 2.8.11 and 3.1 and all exhibit this issue: I have a very simple project (helloworld would suffice) and use the ninja generator. The project fails to build with: ninja: error: build.ninja:20: unknown build rule 'CXX_COMPILER' Upon inspection, I noted that on the top, older generators produced this line in the ninja generator: ############################################# # Include rules file. include rules.ninja This is not present in the tested versions thus leading to the described bug. Steps to Reproduce: Create hello world project, produce ninja file and build. Should lead to: ninja: error: build.ninja:20: unknown build rule 'CXX_COMPILER' ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-07 06:24 Benjamin SchindlerNew Issue ====================================================================== From aleixpol at kde.org Sat Mar 7 12:05:15 2015 From: aleixpol at kde.org (Aleix Pol) Date: Sat, 7 Mar 2015 18:05:15 +0100 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: Message-ID: On Fri, Aug 29, 2014 at 4:20 AM, Aleix Pol wrote: > Dear cmake'rs, > I'm rewriting the KDevelop plugin from scratch to fetch the information from > the build directory. > > Now in the first implementation I'm using the compile_commands.json file > that cmake already can generate for some time. It works quite well already, > given how data just comes out ready to be consumed (almost). The problem now > is that we're lacking some information, namely information about the > targets, their location and such *. > > To that end, I wrote a little patch to be taken as a proof of concept, that > generates (some of) the needed information. I would like to know if you > think it's an approach that would be accepted in the cmake code-base or if I > need to take a different approach. > > Patch http://proli.net/meu/kdevelop/cmake-targetsdata.patch > Output: http://proli.net/meu/kdevelop/AwesomeTargets.json > > Cheers! > Aleix > > * Yes, I'm aware of generators, but I'm not comfortable with the idea of > tying a build directory to an editor (even if it's my editor). Our users > usually build the projects with different tools and asking them to re-create > their build only for being comfortable with KDevelop sometimes is a burden. > It would be for me too! I just pushed my change into a github clone for easier testing and reviewing. https://github.com/aleixpol/CMake Aleix From gjasny at googlemail.com Sat Mar 7 16:20:25 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Sat, 7 Mar 2015 22:20:25 +0100 Subject: [cmake-developers] [PATCH 1/2] Fix deprecation warning about non-writeable strings Message-ID: <1425763226-55531-1-git-send-email-gjasny@googlemail.com> Signed-off-by: Gregor Jasny --- Tests/Environment/main.cxx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Tests/Environment/main.cxx b/Tests/Environment/main.cxx index 2e1bf4c..b54a664 100644 --- a/Tests/Environment/main.cxx +++ b/Tests/Environment/main.cxx @@ -3,7 +3,7 @@ int main(int argc, char *argv[]) { - char* var = getenv("CMAKE_ENVIRONMENT_TEST_VAR"); + const char* var = getenv("CMAKE_ENVIRONMENT_TEST_VAR"); if (!var) { var = "(null)"; -- 2.3.0 From gjasny at googlemail.com Sat Mar 7 16:20:26 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Sat, 7 Mar 2015 22:20:26 +0100 Subject: [cmake-developers] [PATCH 2/2] Add test for generater expressions in test properties In-Reply-To: <1425763226-55531-1-git-send-email-gjasny@googlemail.com> References: <1425763226-55531-1-git-send-email-gjasny@googlemail.com> Message-ID: <1425763226-55531-2-git-send-email-gjasny@googlemail.com> Suprisingly "new-style" tests support generater expressions also within all test properties. Add a test for that. Signed-off-by: Gregor Jasny --- Tests/Environment/CMakeLists.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/Tests/Environment/CMakeLists.txt b/Tests/Environment/CMakeLists.txt index 2b18d24..1cccc3d 100644 --- a/Tests/Environment/CMakeLists.txt +++ b/Tests/Environment/CMakeLists.txt @@ -2,6 +2,7 @@ cmake_minimum_required(VERSION 2.6) project(EnvironmentProj) add_executable(Environment main.cxx) +set_property(TARGET Environment PROPERTY FOO Bar) enable_testing() @@ -24,3 +25,14 @@ set_tests_properties(Environment1 EchoEnvironment1 PROPERTIES set_tests_properties(Environment2 EchoEnvironment2 PROPERTIES FAIL_REGULAR_EXPRESSION "CMAKE_ENV.*Happy Thanksgiving" ) + +# Test with generator expression +# Note: this requires a "new-style" add_test signature +# +add_test(NAME Environment3 COMMAND Environment) +add_test(NAME EchoEnvironment3 COMMAND ${CMAKE_COMMAND} -E environment) + +set_tests_properties(Environment3 EchoEnvironment3 PROPERTIES + ENVIRONMENT "CMAKE_ENVIRONMENT_TEST_VAR=$" + PASS_REGULAR_EXPRESSION "CMAKE_ENV.*Bar" +) -- 2.3.0 From gjasny at googlemail.com Sat Mar 7 16:26:56 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Sat, 07 Mar 2015 22:26:56 +0100 Subject: [cmake-developers] [PATCH 2/2] Add test for generater expressions in test properties In-Reply-To: <1425763226-55531-2-git-send-email-gjasny@googlemail.com> References: <1425763226-55531-1-git-send-email-gjasny@googlemail.com> <1425763226-55531-2-git-send-email-gjasny@googlemail.com> Message-ID: <54FB6D20.1070002@googlemail.com> On 07/03/15 22:20, Gregor Jasny wrote: > Surprisingly "new-style" tests support generator expressions > also within all test properties. Add a test for that. This still lacks documentation. The question is what would be the proper place(s) for this. I'd add extend the genex note here: http://www.cmake.org/cmake/help/git-next/command/add_test.html?highlight=add_test But I also think all test properties should receive an individual note. What do you think? If the "old-style" add_test lacks functionality how about deprecating it? Thanks, Gregor From mantis at public.kitware.com Sun Mar 8 05:51:45 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 8 Mar 2015 05:51:45 -0400 Subject: [cmake-developers] [CMake 0015437]: CMake 3.2.0-rc2 produces no console output when `cmake.exe --build .` is used. Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15437 ====================================================================== Reported By: zalewa Assigned To: ====================================================================== Project: CMake Issue ID: 15437 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-08 05:51 EDT Last Modified: 2015-03-08 05:51 EDT ====================================================================== Summary: CMake 3.2.0-rc2 produces no console output when `cmake.exe --build .` is used. Description: I have a Visual Studio 2008 project configured. When I use cmake 2.8.12 and go in to the project's directory and run `cmake --build .` command I get the output from the compiler (errors, progress, summary, and so on). When I do the same with CMake 3.2.0-rc2 the project gets compiled but there's no output at all. Steps to Reproduce: 1. Install CMake 3.2.0-rc2 2. Run cmd.exe 3. cd into a directory where a Visual Studio 2008 solution is configured. 4. Run `cmake --build .`. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-08 05:51 zalewa New Issue ====================================================================== From mantis at public.kitware.com Mon Mar 9 04:13:11 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 9 Mar 2015 04:13:11 -0400 Subject: [cmake-developers] [CMake 0015438]: project([...] C) for Objective-C Message-ID: <232031e207b68f468294e1c10af33843@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15438 ====================================================================== Reported By: Mathieu Malaterre Assigned To: ====================================================================== Project: CMake Issue ID: 15438 Category: (No Category) Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-09 04:13 EDT Last Modified: 2015-03-09 04:13 EDT ====================================================================== Summary: project([...] C) for Objective-C Description: The following cmake scripts has an implicit (working) behavior for Objective-C++: project(bla CXX) add_executable(foo foo.c foo.mm) However the following (equivalent) code does not seems to be working as I would expect: project(bla C) add_executable(foo foo.c foo.m) Additional Information: While Objective-C has never been documented in CMake, it is a required behavior on MacOSX as so many of its API are only accessible through Objective-C. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-09 04:13 Mathieu MalaterreNew Issue ====================================================================== From ben.boeckel at kitware.com Mon Mar 9 09:38:10 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 9 Mar 2015 09:38:10 -0400 Subject: [cmake-developers] [PATCH 2/2] Add test for generater expressions in test properties In-Reply-To: <1425763226-55531-2-git-send-email-gjasny@googlemail.com> References: <1425763226-55531-1-git-send-email-gjasny@googlemail.com> <1425763226-55531-2-git-send-email-gjasny@googlemail.com> Message-ID: <20150309133810.GA12932@megas.kitwarein.com> On Sat, Mar 07, 2015 at 22:20:26 +0100, Gregor Jasny wrote: > Suprisingly "new-style" tests support generater expressions > also within all test properties. Add a test for that. This patch isn't necessary. The docs mention that here: http://www.cmake.org/cmake/help/v3.0/command/add_test.html and here: http://www.cmake.org/cmake/help/v3.0/command/set_tests_properties.html > Generator expressions will be expanded the same as supported by the > test?s add_test call. Tests for both are here: https://github.com/Kitware/CMake/blob/master/Tests/GeneratorExpression/CMakeLists.txt --Ben From brad.king at kitware.com Mon Mar 9 10:08:26 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 09 Mar 2015 10:08:26 -0400 Subject: [cmake-developers] location tag substitution in external project BUILD_BYPRODUCTS In-Reply-To: References: Message-ID: <54FDA95A.80405@kitware.com> On 03/06/2015 09:17 AM, Gaetan Lehmann wrote: > replace the location tags like by their real path > in BUILD_BYPRODUCTS Applied with minor updates, thanks: ExternalProject: Replace placeholder tokens in BYPRODUCTS http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=86032ae0 -Brad From gaetan.lehmann at gmail.com Mon Mar 9 12:29:46 2015 From: gaetan.lehmann at gmail.com (Gaetan Lehmann) Date: Mon, 9 Mar 2015 17:29:46 +0100 Subject: [cmake-developers] location tag substitution in external project BUILD_BYPRODUCTS In-Reply-To: <54FDA95A.80405@kitware.com> References: <54FDA95A.80405@kitware.com> Message-ID: Thanks! 2015-03-09 15:08 GMT+01:00 Brad King : > On 03/06/2015 09:17 AM, Gaetan Lehmann wrote: > > replace the location tags like by their real path > > in BUILD_BYPRODUCTS > > Applied with minor updates, thanks: > > ExternalProject: Replace placeholder tokens in BYPRODUCTS > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=86032ae0 > > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Mar 9 10:36:04 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 09 Mar 2015 10:36:04 -0400 Subject: [cmake-developers] [PATCH 2/2] Add test for generater expressions in test properties In-Reply-To: <54FB6D20.1070002@googlemail.com> References: <1425763226-55531-1-git-send-email-gjasny@googlemail.com> <1425763226-55531-2-git-send-email-gjasny@googlemail.com> <54FB6D20.1070002@googlemail.com> Message-ID: <54FDAFD4.1080804@kitware.com> On 03/07/2015 04:26 PM, Gregor Jasny wrote: > On 07/03/15 22:20, Gregor Jasny wrote: >> Surprisingly "new-style" tests support generator expressions >> also within all test properties. Add a test for that. As Ben pointed out there is already a test for it: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Tests/GeneratorExpression/CMakeLists.txt;hb=v3.2.0-rc2#l228 Even though there is some documentation it is not covered in enough places as you point out. > This still lacks documentation. The question is what would be the proper > place(s) for this. > > I'd add extend the genex note here: > http://www.cmake.org/cmake/help/git-next/command/add_test.html?highlight=add_test > > But I also think all test properties should receive an individual note. > What do you think? I don't think the individual properties need it because the support is not specific to them. The set_tests_properties command documentation already mentions it, though it could be cleaned up with proper reST markup so it is indexed and has a link. The set_property documentation should be extended to mention it for the TEST mode. > If the "old-style" add_test lacks functionality how about deprecating it? The old style test signature is likely used far too widely to deprecate. One could extend the implementation of the old signature to warn if it sees something that looks like a genex. Thanks, -Brad From roman.wueger at gmx.at Mon Mar 9 14:50:05 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Mon, 9 Mar 2015 19:50:05 +0100 Subject: [cmake-developers] [CMake] Wrong behavior with 3.2.0-rc2 In-Reply-To: <54FA1048.5070008@kitware.com> References: <54F99610.7070503@gmail.com> <54FA1048.5070008@kitware.com> Message-ID: <5607B801-2E43-45AD-A9BD-C85ADD109103@gmx.at> Hello Brad, if CMake 3.2.0 will not be released, when is the expected release date for CMake 3.2.1? Regards Roman > Am 06.03.2015 um 21:38 schrieb Brad King : > >> On 03/06/2015 06:57 AM, Nils Gladitz wrote: >>> On 03/06/2015 10:22 AM, Pere Mato Vila wrote: >>> [100%] [100%] *Generating A.txt, B.txt* >>> *Generating A.txt, B.txt* > > Thanks for trying the release candidate and reporting this. > >> This seems to be the case since >> [644b4688d71cc52f8499d6103495de0909319557] Makefile: Fix rebuild with >> multiple custom command outputs (#15116) > > Yes. I've re-opened the corresponding issue with a note about this: > > http://www.cmake.org/Bug/view.php?id=15116#c38168 > > Please follow that issue for further updates. > > We've already tagged v3.2.0 but it was not announced yet. It looks > like 3.2.0 is DOA and we will have to skip to 3.2.1 to fix this. > > 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 From brad.king at kitware.com Mon Mar 9 15:02:39 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 09 Mar 2015 15:02:39 -0400 Subject: [cmake-developers] [CMake] Wrong behavior with 3.2.0-rc2 In-Reply-To: <5607B801-2E43-45AD-A9BD-C85ADD109103@gmx.at> References: <54F99610.7070503@gmail.com> <54FA1048.5070008@kitware.com> <5607B801-2E43-45AD-A9BD-C85ADD109103@gmx.at> Message-ID: <54FDEE4F.1010109@kitware.com> On 03/09/2015 02:50 PM, Roman W?ger wrote: > if CMake 3.2.0 will not be released, when is the expected release date for CMake 3.2.1? Technically 3.2.0 has been released (there is a signed tag in the source tree for it, created after a drought in feedback on 3.2.0-rc2). We just never published binaries or announced it because this report came in first and is pretty significant. Now 3.2.1 will be done as soon as possible to replace 3.2.0. We never announce specific dates because another regression could be reported at any time and delay things further. -Brad From pasanen.tuukka at gmail.com Mon Mar 9 02:45:08 2015 From: pasanen.tuukka at gmail.com (Tuukka Pasanen) Date: Mon, 09 Mar 2015 08:45:08 +0200 Subject: [cmake-developers] [PATCH] UseSWIG.cmake CMP0054 fix Message-ID: <54FD4174.60806@gmail.com> Hello, As CMP0054 changes the way IF() works this patch fixes it in UseSWIG.cmake. PERL seems to be reserved word so work around this every language get x fore them. so you compare xPERL not bare word PERL. This should fix CMP0054 requirements. Sincerely, Tuukka -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-CMP0054-error-on-UseSWIG.patch Type: text/x-patch Size: 2616 bytes Desc: not available URL: From brad.king at kitware.com Mon Mar 9 16:38:38 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 09 Mar 2015 16:38:38 -0400 Subject: [cmake-developers] [PATCH] UseSWIG.cmake CMP0054 fix In-Reply-To: <54FD4174.60806@gmail.com> References: <54FD4174.60806@gmail.com> Message-ID: <54FE04CE.7040006@kitware.com> On 03/09/2015 02:45 AM, Tuukka Pasanen wrote: > As CMP0054 changes the way IF() works this patch fixes it in UseSWIG.cmake. Actually CMP0054 fixes behavior that caused subtle logic breakage, and the associated warning catches cases with potential breakage. This is one such case. Fixed: UseSWIG: Avoid if() auto-dereferene in quoted arguments http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=458c9e95 Thanks, -Brad From steveire at gmail.com Mon Mar 9 20:16:08 2015 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 10 Mar 2015 01:16:08 +0100 Subject: [cmake-developers] Extracting target metadata, IDE integration References: Message-ID: Aleix Pol wrote: > I just pushed my change into a github clone for easier testing and > reviewing. https://github.com/aleixpol/CMake Hi Aleix, Thanks for your efforts. Here are some things that are required before a feature like this can be committed to the cmake repo: * Discuss the feature with collaborators on the mailing list. * Design the feature. Determine at least the following: * Target use cases * How files are produced * What files are produced * Features required by various tools and IDEs * What is in the files * What is not in the files * Why ^ * Write documentation describing the file format and how to consume it. * More exact unit testing * Unit testing for 'interesting' cases. * Implement the feature satisfying the design for all of the targets IDEs and all relevant features of CMake. * Testing with existing third party cmake-using projects. All of the above must be done before cmake can accept a branch implementing metadata generation. Because this is important to get right, and because it requires up-to-date knowledge of the current cmake implementation and features in the master branch, I'm going to take over the 'ownership' of this feature and drive it myself. I'll start soon by creating a new mailing list thread to determine the design of the feature in collaboration with you, Tobias and Anton. We can iterate on the design, tests and implementation until it is complete. Thanks, Steve. From aleixpol at kde.org Mon Mar 9 20:25:16 2015 From: aleixpol at kde.org (Aleix Pol) Date: Tue, 10 Mar 2015 01:25:16 +0100 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: <54F76572.9000206@kitware.com> Message-ID: Hi Tobias, Thank you for taking some of your time. On Sat, Mar 7, 2015 at 11:46 AM, Tobias Hunger wrote: > Hi Aleix, > > thank you for the ping:-) > > Since I am not fully fluent with cmake (have not really used it in a > couple of years) and sometimes have a bit of trouble following the > discussion about the details of this patch, I took the liberty to > copy/paste (and part of) one of the example files you put up on KDEs > codepaster, commenting on what I understood each section to mean. I > think that is the best way for me to contribute to this discussion at > this point. > > What are you actually building here? /home/kde-devel/tmp/llvm/CMakeLists.txt? Thats an LLVM code clone. It's a big CMake-based project, that's why I chose it, that's all. > >> { > > How about adding some information on what this is you are actually > building here? CMake has the PROJECT command that does provide quite a > bit of information that could go here. I can look into that, I can see if I can extract the projects tree somehow and dispose them like it's doing with the targets. > > Where are the sources this thing here is building? How were those > sources configured? CMake supports quite a few generators, so which > ones where used? Do I need to run ninja or make to build this (or > should I use "cmake build" anyway)? The sources are listed within the targets, separately for each configuration (as you can have different sources for debug builds and release). Regarding ninja/make, in KDevelop we just check if there's a rules.ninja file or a Makefile. Alternatively you can also check the CMAKE_GENERATOR value in the CMakeCache.txt. Or we can introduce it if you find it useful. I don't have a strong opinion there. > > Creator does allow existing qmake builds to be imported and that kind > of information does help a lot with that functionality. > >> "dependencies" : >> [ "/home/kde-devel/tmp/llvm/build/CMakeFiles/3.2.20150306-g139588/CMakeSystem.cmake", "/lots/more/files", ... ] > > So these are all the files I need to watch for changes? If they change > then I should re-run cmake? Yes, also they are the files that will be providing the relevant information for the current file. It can be important at some point. > >> "targets" : >> [ > > So now comes a list of the possible things I can build... > >> { >> "backtrace" : >> [ >> "/home/kde-devel/tmp/llvm/cmake/modules/AddLLVM.cmake:312", >> "/home/kde-devel/tmp/llvm/cmake/modules/AddLLVM.cmake:399", >> "/home/kde-devel/tmp/llvm/lib/Target/PowerPC/TargetInfo/CMakeLists.txt:1" >> ], > > That backtrace is nice! > >> "configs" : >> [ >> { >> "name" : "", > > Why is the name empty? Because it was built without specifying any name. (i.e. it didn't pass -DCMAKE_BUILD_TYPE=...). > >> "output" : "/home/kde-devel/tmp/llvm/build/lib/libLLVMPowerPCInfo.a", > > Can this be a list? It's 1 output per target, no? > >> "sources" : [ "/list/of/cpp/files, ] > > Any way to also get the headers? Do you see any option to hint where > new sources would need to be added to make them a part of this target? I looked into how the CodeBlocks did it to provide the header files. It's just brute-forcing to see if the file renamed to *.h/*.hpp/*.hxx is present. CMake doesn't have this kind of information, so I think it's better that the IDE's do the hacky parts than cmake. Also we don't really have information about where to put them. You can use the minimum common denominator among the sources I guess. > >> } >> ], >> "installed" : "true", > > I guess this means "make install" will install it. Where will this file end up? Yes. I tried to figure it out but didn't manage to find the correct way to query it. I can try harder. :D > >> "name" : "LLVMPowerPCInfo", >> "output_directory" : "/home/kde-devel/tmp/llvm/build/lib/Target/PowerPC/TargetInfo", > > For what is the output directory relevant? The output above does > implicitly list that already, doesn't it? It's important in case the output path is overriden, see last e-mail by Alexander Neundorf. > >> "type" : "STATIC_LIBRARY" > > Which types are possible here? It's an enum internal to cmake. At the moment: EXECUTABLE, STATIC_LIBRARY, SHARED_LIBRARY, MODULE_LIBRARY, OBJECT_LIBRARY, UTILITY, GLOBAL_TARGET, INTERFACE_LIBRARY, UNKNOWN_LIBRARY. > >> }, > > > There is a lot of useful information here! Thanks for pushing into > this direction. I am sure this will help a lot. > > Ideally this file would be enough to provide all information we need > as an IDE to: > > * Present the project structure as seen by the build system. > * Generate the code model > * Build the project > * Deploy the project > * Run and debug parts of the project > * Adding and removing files to a project > > For the project structure this does help: It provides us with a list > of all the build targets, which is already nice. CMake does support > more structure with Projects and subprojects IIRC and that information > is lost. Would it be much work to get that information back? as discussed above, I'll look into that next thing. > > For the code model this is not much help at all: There is no > information on compiler used, include directories nor Defines or > compiler flags. Where am I supposed to get that information from? Do I > need to generate and parse the list of commands run and extract that > information from there? Having that information available right in the > sources array of each target would be so much more convenient and > would also make IDE integration so much easier: You would need to know > about one file only and won't need to figure out several. We can do that, I mentioned earlier in this thread that currently we're using compile_commands.json for that ( CMAKE_EXPORT_COMPILE_COMMANDS). I agree it could be interesting to add it. In other words, if nobody disagrees, I'll add it although I see how this will make the output grow a lot. > > Building the project should be fine with the information provided. > Explicitly stating the generators used would help a little bit (even > better just giving the command necessary to build, e.g. make or ninja > or whatnot. Then we would not need to hard-code the mapping of > generators->build tools, which makes it much easier for you to support > new things:-) > > Running/Debugging is a bit tricky again: All the information used for > linking the binaries is gone. So there is no way to figure out which > LD_LIBRARY_PATH needs to be set or anything. There also seems to be no > information where files are going to get installed to. Would it be > possible to add that information? I ignore it, on the other hand I'm quite a n00b when it comes to cmake codebase and internals. I'm sure if somebody knows where to get that information, he is reading this mailing list. (hello) > > I do not see any way to provide a reliable automatic way to add > sources to a cmake build system (the others are unfortunately not > better:-). For removing the files it would be nice to know where in > which file/line the sources were added to the target. Not sure whether > it is even possible to get that information... The backtrace you have > is already great piece of information: At least that way we should be > able to open the right file and have the user edit that manually. Well, what I did in kdevelop 4 (before adopting all of this) was going to the last CMakeLists.txt on the backtrace and looking for the filename in the arguments there (and recursively through the variable definitons, which we don't have the information in here) and removing it. It usually worked and when it didn't, we just didn't know what to do, but it wasn't essentially wrong. You don't want file references of a file you're removing anyway. > > Does this help? Yes, a lot. It's what I was looking for. > > Best Regards, > Tobias Thanks for taking your time. Aleix From Geoffrey.Viola at asirobots.com Tue Mar 10 00:57:16 2015 From: Geoffrey.Viola at asirobots.com (Geoffrey Viola) Date: Tue, 10 Mar 2015 04:57:16 +0000 Subject: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support In-Reply-To: <54F4781A.80708@kitware.com> References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com> <544E4C9F.3050408@kitware.com> <64abd7ba273245b686146aa67acb7e8a@DM2PR0701MB1020.namprd07.prod.outlook.com> <545A7C44.6040305@kitware.com> <5474E132.2010705@kitware.com> <54D129E3.60101@kitware.com> <54E365F4.3030104@kitware.com> <54E7542D.6050808@kitware.com> <54EB68C8.7030504@kitware.com> <54F0952B.5070809@kitware.com> <54F4781A.80708@kitware.com> Message-ID: Sorry for the delay. I have the experimental tests compiling again. Now, that I had a chance to dig into it, I have some questions. > so I think this is the right place for such code. However, the hunk above needs some work. First, the changes to Modules/CMakeCompilerIdDetection.cmake indicate that the compiler id is "GHS", so the CMAKE__COMPILER_ID should be set to that in the code above. Actually, I deleted that line and noticed that the tests still passed. Should I still set CMAKE_GHS_COMPILER_ID? >The compiler path values are set to literal "${...}" >strings but that will not be interpreted. Alternatives: > >* Set CMAKE_GENERATOR_CC and CMAKE_GENERATOR_CXX to ccarm > and cxarm in the above code and let the normal compiler > search logic in CMakeDetermine*Compiler.cmake actually > find the compiler instead of using find_program in > CMakeGreenHillsFindMake. > >* Have EnableLanguage compute the exact path to the compiler > tools itself, possibly using GHS_COMP_ROOT. I prefer the latter approach, because it will work without the user setting their PATH. >Most of the code in CMakeGreenHillsFindMake actually belongs in "Modules/Platform/GHS-MULTI.cmake". The EnableLanguage method should set CMAKE_SYSTEM_NAME and CMAKE_SYSTEM_PROCESSOR. >It could even have C++-implemented logic to find GHS_COMP_ROOT (are there registry values for it?). Then CMakeGreenHillsFindMake should have the minimum code needed to find the make tool given GHS_COMP_ROOT. Then I think everything else can go in > > Modules/Platform/GHS-MULTI-Initialize.cmake > Modules/Platform/GHS-MULTI.cmake This sounds good. Unfortunately, finding the comp root is a bit complicated. The registry keys change per version and their does not seem to be a pattern. Also, the file names change per version, but start with a standard sequence. My previous method involved searching all the folders in a certain directory and doing a regex search on them. The list of matches is ordered in reverse to get the latest version. Some known registry keys are also read in case the directory is set to something not default. I'm in the process of converting the previous script code which was half of CMakeGreenHillsFindMake, to C++: function(SUBDIRLIST curdir result) file(GLOB children RELATIVE ${curdir} ${curdir}/*) set(dirlist "") foreach(child ${children}) if(IS_DIRECTORY ${curdir}/${child}) list(APPEND dirlist ${child}) endif() endforeach() set(${result} ${dirlist} PARENT_SCOPE) endfunction() set(GHS_DEFAULT_ROOT "C:/ghs") SUBDIRLIST(${GHS_DEFAULT_ROOT} GHS_POT_DIRS) string(REGEX MATCHALL "comp_[^;]+" GHS_REL_DIRS "${GHS_POT_DIRS}") #Order the list so that the most recent version is searched first list(SORT GHS_REL_DIRS) list(REVERSE GHS_REL_DIRS) #Make the paths absolute set(GHS_ABS_DIRS) foreach(GHS_REL_DIR ${GHS_REL_DIRS}) string(CONCAT GHS_ABS_DIR ${GHS_DEFAULT_ROOT} "/" ${GHS_REL_DIR}) list(APPEND GHS_ABS_DIRS ${GHS_ABS_DIR}) endforeach() #Find gbuild to ensure a working path to a GHS installation set(GHS_MAKE_PROGRAM_NAME "gbuild.exe") find_program(CMAKE_MAKE_PROGRAM ${GHS_MAKE_PROGRAM_NAME} PATHS ${GHS_COMP_ROOT} "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\GreenHillsSoftwared771f1b4;InstallLocation]" #201414 "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\GreenHillsSoftware9881cef6;InstallLocation]" #201254 ${GHS_ABS_DIRS} ) string(REGEX REPLACE "/${GHS_MAKE_PROGRAM_NAME}" "" GHS_COMP_ROOT_T ${CMAKE_MAKE_PROGRAM}) set(GHS_COMP_ROOT ${GHS_COMP_ROOT_T} CACHE PATH "Root of Green Hills Integrity executables") > The -Initialize module will be loaded pretty early and is the place to find platform-specific SDKs and such. This is likely the place for all those GHS_* cache options. Seems like a straight forward move. I'll let you know how things work out, after I implement the above. Geoffrey Viola SOFTWARE ENGINEER asirobots.com -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Monday, March 02, 2015 7:48 AM To: Geoffrey Viola Cc: cmake-developers at cmake.org Subject: Re: FW: FW: [cmake-developers] Initial Attempt at Green Hill MULTI IDE Generator Support On 02/27/2015 11:29 AM, Geoffrey Viola wrote: >> set(ENV{PATH} "c:\\Windows\\system32;c:\\Windows") >> We should test with at least the basic Windows PATH set. > I made the change just now. I'll rerun the tests. I haven't seen "glv.asi" submit in a few days. Is it running nightly? > Let me know if there is anything more I can do. I've looked more through the patch sent here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/11260/focus=12469 > +void > +cmGlobalGhsMultiGenerator::EnableLanguage(std::vector const &l, > + cmMakefile *mf, bool > +optional) { > + mf->AddDefinition("CMAKE_C_COMPILER", "${CMAKE_GENERATOR_CC}"); > + mf->AddDefinition("CMAKE_C_COMPILER_ID_RUN", "TRUE"); > + mf->AddDefinition("CMAKE_C_COMPILER_ID", "GhsMultiArmC"); > + mf->AddDefinition("CMAKE_C_COMPILER_FORCED", "TRUE"); > + > + mf->AddDefinition("CMAKE_CXX_COMPILER", "${CMAKE_GENERATOR_CXX}"); > + mf->AddDefinition("CMAKE_CXX_COMPILER_ID_RUN", "TRUE"); > + mf->AddDefinition("CMAKE_CXX_COMPILER_ID", "GhsMultiArmCXX"); > + mf->AddDefinition("CMAKE_CXX_COMPILER_FORCED", "TRUE"); > + > + mf->AddDefinition("GHSMULTI", "1"); // identifier for user CMake > +files > + this->cmGlobalGenerator::EnableLanguage(l, mf, optional); } This looks based on my suggestion from an earlier review: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/11260/focus=11538 so I think this is the right place for such code. However, the hunk above needs some work. First, the changes to Modules/CMakeCompilerIdDetection.cmake indicate that the compiler id is "GHS", so the CMAKE__COMPILER_ID should be set to that in the code above. The compiler path values are set to literal "${...}" strings but that will not be interpreted. Alternatives: * Set CMAKE_GENERATOR_CC and CMAKE_GENERATOR_CXX to ccarm and cxarm in the above code and let the normal compiler search logic in CMakeDetermine*Compiler.cmake actually find the compiler instead of using find_program in CMakeGreenHillsFindMake. * Have EnableLanguage compute the exact path to the compiler tools itself, possibly using GHS_COMP_ROOT. Most of the code in CMakeGreenHillsFindMake actually belongs in "Modules/Platform/GHS-MULTI.cmake". The EnableLanguage method should set CMAKE_SYSTEM_NAME and CMAKE_SYSTEM_PROCESSOR. It could even have C++-implemented logic to find GHS_COMP_ROOT (are there registry values for it?). Then CMakeGreenHillsFindMake should have the minimum code needed to find the make tool given GHS_COMP_ROOT. Then I think everything else can go in Modules/Platform/GHS-MULTI-Initialize.cmake Modules/Platform/GHS-MULTI.cmake The -Initialize module will be loaded pretty early and is the place to find platform-specific SDKs and such. This is likely the place for all those GHS_* cache options. Thanks, -Brad This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. From raffi.enficiaud at mines-paris.org Tue Mar 10 09:08:04 2015 From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud) Date: Tue, 10 Mar 2015 14:08:04 +0100 Subject: [cmake-developers] Introduction and volunteering for the Matlab package In-Reply-To: <54EF82F9.4000305@kitware.com> References: <98EDE7BE-00E7-4EFE-8D74-E51F41B49535@free.fr> <08F24DF8-41E7-4FD8-837E-5FC514C65338@free.fr> <54D128BE.9030109@kitware.com> <54D222A4.7090500@kitware.com> <2F7B25D2-7E72-44C1-B371-16F9399071BC@free.fr> <54DE0B41.5080000@kitware.com> <66AF3BFE-070C-4A57-BCBC-4184DB1EB387@free.fr> <54DE1A19.8050403@kitware.com> <54E49E02.5030105@kitware.com> <54E5F072.3090903@kitware.com> <06983E90-D75E-4335-8D02-1D40DF89B9C2@free.fr> <54EB694A.9030605@kitware.com> <7BCB5D1E-275E-43B2-B0FF-0ECEE0A78585@free.fr> <54EDCF04.2000909@kitware.com> <442BD016-E925-4186-9FBA-DA566C5C5886@free.fr> <54EF5D61.8010708@kitware.co m> <61974444-FEDF-4FE0-9FCE-2797CC7DE528@free.fr> <54EF82F9.4000305@kitware.com> Message-ID: Le 26/02/15 21:32, Brad King a ?crit : > On 02/26/2015 03:23 PM, Raffi Enficiaud wrote: > We never specified explicitly which name to use. I think it > should be Matlab_ROOT_DIR because that makes sense whether the > user specified it or not. Right, so I made the changes and updated the documentation. A kind person tested my module and proposed to change the behaviour in order to be able to change the Matlab_ROOT_DIR after the first configuration The workflow would be: - I start without Matlab_ROOT_DIR, - Matlab_ROOT_DIR is automatically determined, - I change Matlab_ROOT_DIR I am expecting all dependent variables (cached or not) be updated to reflect this change. Apparently this is something that is done in eg. wxWidget. The question is: should also this be implemented? The way I am seeing this is to clear all variables when another Matlab_ROOT_DIR than the cached/internal one is set. > We shouldn't have to disable the test. It can still be an > error for the MAIN_PROGRAM component to not be requested. > You can separate the name of the cache variable used as > the "one" search for "matlab" from the name of the result > variable used to provide the MAIN_PROGRAM component. That > will be consistent with the view that finding "matlab" is > an implementation detail on some platforms even when the > MAIN_PROGRAM component is not requested. > > Please revise this patch further for the above. Will do. Another question: may the test be dependent on a particular site? For instance, on one of the builders, I have several versions of Matlab. Is testing against the current build site something that would be acceptable? Best, Raffi From brad.king at kitware.com Tue Mar 10 09:29:37 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 10 Mar 2015 09:29:37 -0400 Subject: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support In-Reply-To: References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com> <5474E132.2010705@kitware.com> <54D129E3.60101@kitware.com> <54E365F4.3030104@kitware.com> <54E7542D.6050808@kitware.com> <54EB68C8.7030504@kitware.com> <54F0952B.5070809@kitware.com> <54F4781A.80708@kitware.com> Message-ID: <54FEF1C1.4030106@kitware.com> On 03/10/2015 12:57 AM, Geoffrey Viola wrote: > Should I still set CMAKE_GHS_COMPILER_ID? I don't see any reason to set a variable by that name. >> * Have EnableLanguage compute the exact path to the compiler >> tools itself, possibly using GHS_COMP_ROOT. > > I prefer the latter approach [snip] > finding the comp root is a bit complicated. The registry keys > change per version and their does not seem to be a pattern. This should be achievable in C++ inside a helper method called from EnableLanguage. There is no reason to have to use the CMake language to code it. > I'll let you know how things work out, after I implement the above. Great, thanks. -Brad From brad.king at kitware.com Tue Mar 10 09:34:26 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 10 Mar 2015 09:34:26 -0400 Subject: [cmake-developers] Introduction and volunteering for the Matlab package In-Reply-To: References: <08F24DF8-41E7-4FD8-837E-5FC514C65338@free.fr> <54D128BE.9030109@kitware.com> <54D222A4.7090500@kitware.com> <2F7B25D2-7E72-44C1-B371-16F9399071BC@free.fr> <54DE0B41.5080000@kitware.com> <66AF3BFE-070C-4A57-BCBC-4184DB1EB387@free.fr> <54DE1A19.8050403@kitware.com> <54E49E02.5030105@kitware.com> <54E5F072.3090903@kitware.com> <06983E90-D75E-4335-8D02-1D40DF89B9C2@free.fr> <54EB694A.9030605@kitware.com> <7BCB5D1E-275E-43B2-B0FF-0ECEE0A78585@free.fr> <54EDCF04.2000909@kitware.com> <442BD016-E925-4186-9FBA-DA566C5C5886@free.fr> <54EF5D61.8010708@kitware.co m> <61974444-FEDF-4FE0-9FCE-2797CC7DE528@free.fr> <54EF82F9.4000305@kitware.com> Message-ID: <54FEF2E2.1000403@kitware.com> On 03/10/2015 09:08 AM, Raffi Enficiaud wrote: > - I change Matlab_ROOT_DIR > > I am expecting all dependent variables (cached or not) be updated > > The question is: should also this be implemented? Yes. See the FindBoost module for similar behavior with respect to the library directory. > Will do. Another question: may the test be dependent on a particular > site? For instance, on one of the builders, I have several versions of > Matlab. Is testing against the current build site something that would > be acceptable? The per-site information should not be hard-coded in the source tree. However, you can use cache entries to hold the local configuration. -Brad From mantis at public.kitware.com Tue Mar 10 16:54:30 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 10 Mar 2015 16:54:30 -0400 Subject: [cmake-developers] [CMake 0015439]: ninja: no possibility to control type of path delimiter and line break for linker response file Message-ID: <01db6ae1cbb450e68b2e6416658cb299@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15439 ====================================================================== Reported By: Thomas Herz Assigned To: ====================================================================== Project: CMake Issue ID: 15439 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-10 16:54 EDT Last Modified: 2015-03-10 16:54 EDT ====================================================================== Summary: ninja: no possibility to control type of path delimiter and line break for linker response file Description: I'm working with the Windriver VxWorks GNU tool chain on Windows host. Compiler Version: ccpentium.exe (Wind River VxWorks G++ DWARF-EH 4.1-131) 4.1.2 --host=i686-mingw32 --target=i586-wrs-vxworks I adapted our existing 'unix makefile' project to ninja builder and I'm getting following linker error: @CMakeFiles/myLib.rsp: No such file or directory Finally, I figured out the reason. Actually, there are two of them: 1) The linker response file uses '\' for path delimiters, but this version of GCC can't handle them, even if it is running on Windows host. It only handles '/' or '\\' correctly. I managed to work around this problem by setting 'CMAKE_COMPILER_IS_MINGW' to '1'. But, I guess, this may have some unwanted side effects. Related bug report: 0015278 2) The linker response file uses Windows style line-breaks (CR-LF) to separate individual object paths. This version of GCC can't handle them. It works fine with Unix style (LF) or without any line breaks and whitespace instead. The behaviour of ninja generator was changed with commit a55d5ca48179d3be4d8406028c0992d45ada8882. I think, this patch is too 'global'. According to commit message 'Avoid LNK1170 linker error' this commit should solve Microsoft compiler/linker problems. Furthermore LNK1170 is not listed anymore for VS2010 and above. Anyhow, for both issues, some kind of automagic with the possibility to change the automagic decision with a particular cmake-variable would be the best solution for such kind of problems. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-10 16:54 Thomas Herz New Issue ====================================================================== From raffi.enficiaud at mines-paris.org Tue Mar 10 19:12:34 2015 From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud) Date: Wed, 11 Mar 2015 00:12:34 +0100 Subject: [cmake-developers] Introduction and volunteering for the Matlab package In-Reply-To: <54FEF2E2.1000403@kitware.com> References: <08F24DF8-41E7-4FD8-837E-5FC514C65338@free.fr> <54D128BE.9030109@kitware.com> <54D222A4.7090500@kitware.com> <2F7B25D2-7E72-44C1-B371-16F9399071BC@free.fr> <54DE0B41.5080000@kitware.com> <66AF3BFE-070C-4A57-BCBC-4184DB1EB387@free.fr> <54DE1A19.8050403@kitware.com> <54E49E02.5030105@kitware.com> <54E5F072.3090903@kitware.com> <06983E90-D75E-4335-8D02-1D40DF89B9C2@free.fr> <54EB694A.9030605@kitware.com> <7BCB5D1E-275E-43B2-B0FF-0ECEE0A78585@free.fr> <54EDCF04.2000909@kitware.com> <442BD016-E925-4186-9FBA-DA566C5C5886@free.fr> <54EF5D61.8010708@kitware.co m> <61974444-FEDF-4FE0-9FCE-2797CC7DE528@free.fr> <54EF82F9.4000305@kitware.com> <54FEF2E2.1000403@kitware.com> Message-ID: Le 10/03/15 14:34, Brad King a ?crit : > On 03/10/2015 09:08 AM, Raffi Enficiaud wrote: >> - I change Matlab_ROOT_DIR >> >> I am expecting all dependent variables (cached or not) be updated >> >> The question is: should also this be implemented? > > Yes. See the FindBoost module for similar behavior with respect to > the library directory. > >> Will do. Another question: may the test be dependent on a particular >> site? For instance, on one of the builders, I have several versions of >> Matlab. Is testing against the current build site something that would >> be acceptable? > > The per-site information should not be hard-coded in the source tree. > However, you can use cache entries to hold the local configuration. > > -Brad > Hi Brad, Please find the attached patch addressing the issues. In the current implementation, if the Matlab_ROOT_DIR is changed by the user, the cached variables are all cleared. Also, Matlab_ROOT_DIR is now the only variable that is seen as non advanced. Best, Raffi -------------- next part -------------- >From 4f73bd38849a67ef4e677e223fbb43af9d09f976 Mon Sep 17 00:00:00 2001 From: Raffi Enficiaud Date: Wed, 11 Mar 2015 00:08:42 +0100 Subject: [PATCH] * Simplified workflow, better isolation of the code when Matlab is to be found from the PATH * Removing the "which matlab" as the find_program was erroneous * MATLAB_USER_ROOT renamed to Matlab_ROOT_DIR, which now reflects the found root, removed Matlab_ROOT * Reduced the number of find_program(matlab) * Nulled the input stream of the execute_process in order to avoid the troubleshooting with the terminal * Clearing all the cached variables in case the Matlab_ROOT_DIR is changed by the user * Marking all but Matlab_ROOT_DIR variable as advanced * Hiding all internal cache entries * Avoiding the computation of the version (Matlab_ROOT_DIR set) if the first pass produced the version automatically --- Modules/FindMatlab.cmake | 487 ++++++++++++--------- Modules/MatlabTestsRedirect.cmake | 8 + Tests/FindMatlab/cmake_matlab_unit_tests_timeout.m | 3 +- Tests/RunCMake/CMakeLists.txt | 1 + 4 files changed, 286 insertions(+), 213 deletions(-) diff --git a/Modules/FindMatlab.cmake b/Modules/FindMatlab.cmake index 9686a76..c637df4 100644 --- a/Modules/FindMatlab.cmake +++ b/Modules/FindMatlab.cmake @@ -28,14 +28,15 @@ # :command:`matlab_get_release_name_from_version` allow a mapping # from the release name to the version. # -# The variable :variable:`MATLAB_USER_ROOT` may be specified in order to give +# The variable :variable:`Matlab_ROOT_DIR` may be specified in order to give # the path of the desired Matlab version. Otherwise, the behaviour is platform # specific: # # * Windows: The installed versions of Matlab are retrieved from the # Windows registry # * OS X: The installed versions of Matlab are given by the MATLAB -# paths in ``/Application`` +# paths in ``/Application``. If no such application is found, it falls back +# to the one that might be accessible from the PATH. # * Unix: The desired Matlab should be accessible from the PATH. # # Additional information is provided when :variable:`MATLAB_FIND_DEBUG` is set. @@ -59,7 +60,7 @@ # Users or projects may set the following variables to configure the module # behaviour: # -# :variable:`MATLAB_USER_ROOT` +# :variable:`Matlab_ROOT_DIR` # the root of the Matlab installation. # :variable:`MATLAB_FIND_DEBUG` # outputs debug information @@ -77,14 +78,15 @@ # ``TRUE`` if the Matlab installation is found, ``FALSE`` # otherwise. All variable below are defined if Matlab is found. # ``Matlab_ROOT_DIR`` -# the root of the Matlab installation determined by the FindMatlab module. +# the final root of the Matlab installation determined by the FindMatlab +# module. # ``Matlab_MAIN_PROGRAM`` # the Matlab binary program. Available only if the component ``MAIN_PROGRAM`` # is given in the :command:`find_package` directive. # ``Matlab_INCLUDE_DIRS`` # the path of the Matlab libraries headers # ``Matlab_MEX_LIBRARY`` -# library for mex +# library for mex, always available. # ``Matlab_MX_LIBRARY`` # mx library of Matlab (arrays). Available only if the component # ``MX_LIBRARY`` has been requested. @@ -102,6 +104,9 @@ # # ``Matlab_MEX_EXTENSION`` # the extension of the mex files for the current platform (given by Matlab). +# ``Matlab_ROOT_DIR`` +# the location of the root of the Matlab installation found. If this value +# is changed by the user, the result variables are recomputed. # # Provided macros # --------------- @@ -162,10 +167,11 @@ # Reference # -------------- # -# .. variable:: MATLAB_USER_ROOT +# .. variable:: Matlab_ROOT_DIR # -# The root folder of the Matlab installation. This is set before the call to -# :command:`find_package`. If not set, then an automatic search of Matlab +# The root folder of the Matlab installation. If set before the call to +# :command:`find_package`, the module will look for the components in that +# path. If not set, then an automatic search of Matlab # will be performed. If set, it should point to a valid version of Matlab. # # .. variable:: MATLAB_FIND_DEBUG @@ -176,7 +182,6 @@ # .. variable:: MATLAB_ADDITIONAL_VERSIONS # # If set, specifies additional versions of Matlab that may be looked for. -# This variable will be used if :variable:`MATLAB_USER_ROOT` is not set. # The variable should be a list of strings, organised by pairs of release # name and versions, such as follows:: # @@ -192,6 +197,10 @@ # "R2013b=8.2" # "R2013a=8.1" # "R2012b=8.0") +# +# The order of entries in this list matters when several versions of +# Matlab are installed. The priority is set according to the ordering in +# this list. #============================================================================= # Copyright 2014-2015 Raffi Enficiaud, Max Planck Society @@ -254,6 +263,7 @@ macro (matlab_get_version_from_release_name release_name version_name) else() message(WARNING "The release name ${release_name} is not registered") endif() + unset(_matched) endmacro() @@ -356,8 +366,8 @@ function(matlab_extract_all_installed_versions_from_registry win64 matlab_versio RESULT_VARIABLE resultMatlab OUTPUT_VARIABLE varMatlab ERROR_VARIABLE errMatlab + INPUT_FILE NUL ) - #message("Matlabs = ${varMatlab} | ${resultMatlab}") set(matlabs_from_registry) @@ -508,7 +518,7 @@ function(matlab_get_mex_suffix matlab_root mex_suffix) # we first try without suffix, since cmake does not understand a list with # one empty string element find_program( - MATLAB_MEXEXTENSIONS_PROG + Matlab_MEXEXTENSIONS_PROG NAMES mexext PATHS ${matlab_root}/bin DOC "Matlab MEX extension provider" @@ -516,10 +526,10 @@ function(matlab_get_mex_suffix matlab_root mex_suffix) ) foreach(current_mexext_suffix IN LISTS mexext_suffix) - if(NOT DEFINED MATLAB_MEXEXTENSIONS_PROG OR NOT MATLAB_MEXEXTENSIONS_PROG) + if(NOT DEFINED Matlab_MEXEXTENSIONS_PROG OR NOT Matlab_MEXEXTENSIONS_PROG) # this call should populate the cache automatically find_program( - MATLAB_MEXEXTENSIONS_PROG + Matlab_MEXEXTENSIONS_PROG "mexext${current_mexext_suffix}" PATHS ${matlab_root}/bin DOC "Matlab MEX extension provider" @@ -530,22 +540,31 @@ function(matlab_get_mex_suffix matlab_root mex_suffix) # the program has been found? - if((NOT MATLAB_MEXEXTENSIONS_PROG) OR (NOT EXISTS ${MATLAB_MEXEXTENSIONS_PROG})) + if((NOT Matlab_MEXEXTENSIONS_PROG) OR (NOT EXISTS ${Matlab_MEXEXTENSIONS_PROG})) if(MATLAB_FIND_DEBUG) message(WARNING "[MATLAB] Cannot found mexext program. Matlab root is ${matlab_root}") endif() + unset(Matlab_MEXEXTENSIONS_PROG CACHE) return() endif() set(_matlab_mex_extension) + set(devnull) + if(UNIX) + set(devnull INPUT_FILE /dev/null) + elseif(WIN32) + set(devnull INPUT_FILE NUL) + endif() execute_process( - COMMAND ${MATLAB_MEXEXTENSIONS_PROG} + COMMAND ${Matlab_MEXEXTENSIONS_PROG} OUTPUT_VARIABLE _matlab_mex_extension - ERROR_VARIABLE _matlab_mex_extension_error) + ERROR_VARIABLE _matlab_mex_extension_error + ${devnull}) string(STRIP ${_matlab_mex_extension} _matlab_mex_extension) + unset(Matlab_MEXEXTENSIONS_PROG CACHE) set(${mex_suffix} ${_matlab_mex_extension} PARENT_SCOPE) endfunction() @@ -592,6 +611,13 @@ function(matlab_get_version_from_matlab_run matlab_binary_program matlab_list_ve if(WIN32) set(_matlab_additional_commands "-wait") endif() + + set(devnull) + if(UNIX) + set(devnull INPUT_FILE /dev/null) + elseif(WIN32) + set(devnull INPUT_FILE NUL) + endif() # timeout set to 30 seconds, in case it does not start # note as said before OUTPUT_VARIABLE cannot be used in a platform @@ -604,6 +630,7 @@ function(matlab_get_version_from_matlab_run matlab_binary_program matlab_list_ve ERROR_VARIABLE _matlab_result_version_call_error TIMEOUT 30 WORKING_DIRECTORY "${_matlab_temporary_folder}" + ${devnull} ) @@ -918,245 +945,287 @@ function(matlab_add_mex ) endfunction() +# (internal) +# Used to get the version of matlab, using caching. This basically transforms the +# output of the root list, with possible unknown version, to a version +# +function(_Matlab_get_version_from_root matlab_root matlab_known_version matlab_final_version) + + # if the version is not trivial, we query matlab for that + # we keep track of the location of matlab that induced this version + #if(NOT DEFINED Matlab_PROG_VERSION_STRING_AUTO_DETECT) + # set(Matlab_PROG_VERSION_STRING_AUTO_DETECT "" CACHE INTERNAL "internal matlab location for the discovered version") + #endif() + + if(NOT ${matlab_known_version} STREQUAL "NOTFOUND") + # the version is known, we just return it + set(${matlab_final_version} ${matlab_known_version} PARENT_SCOPE) + set(Matlab_VERSION_STRING_INTERNAL ${matlab_known_version} CACHE INTERNAL "Matlab version (automatically determined)" FORCE) + return() + endif() + # + set(_matlab_current_program ${Matlab_MAIN_PROGRAM}) + + # do we already have a matlab program? + if(NOT _matlab_current_program) + + set(_find_matlab_options) + if(matlab_root AND EXISTS ${matlab_root}) + set(_find_matlab_options PATHS ${matlab_root} ${matlab_root}/bin NO_DEFAULT_PATH) + endif() + + find_program( + _matlab_current_program + matlab + ${_find_matlab_options} + DOC "Matlab main program" + ) + endif() + if(NOT _matlab_current_program OR NOT EXISTS ${_matlab_current_program}) + # if not found, clear the dependent variables + if(MATLAB_FIND_DEBUG) + message(WARNING "[MATLAB] Cannot find the main matlab program under ${matlab_root}") + endif() + set(Matlab_PROG_VERSION_STRING_AUTO_DETECT "" CACHE INTERNAL "internal matlab location for the discovered version" FORCE) + set(Matlab_VERSION_STRING_INTERNAL "" CACHE INTERNAL "internal matlab location for the discovered version" FORCE) + unset(_matlab_current_program) + unset(_matlab_current_program CACHE) + return() + endif() + # full real path for path comparison + get_filename_component(_matlab_main_real_path_tmp "${_matlab_current_program}" REALPATH) + unset(_matlab_current_program) + unset(_matlab_current_program CACHE) + # is it the same as the previous one? + if(_matlab_main_real_path_tmp STREQUAL Matlab_PROG_VERSION_STRING_AUTO_DETECT) + set(${matlab_final_version} ${Matlab_VERSION_STRING_INTERNAL} PARENT_SCOPE) + return() + endif() + # update the location of the program + set(Matlab_PROG_VERSION_STRING_AUTO_DETECT ${_matlab_main_real_path_tmp} CACHE INTERNAL "internal matlab location for the discovered version" FORCE) + + set(matlab_list_of_all_versions) + matlab_get_version_from_matlab_run("${Matlab_PROG_VERSION_STRING_AUTO_DETECT}" matlab_list_of_all_versions) + + list(GET matlab_list_of_all_versions 0 _matlab_version_tmp) + + # set the version into the cache + set(Matlab_VERSION_STRING_INTERNAL ${_matlab_version_tmp} CACHE INTERNAL "Matlab version (automatically determined)" FORCE) + + # warning, just in case several versions found (should not happen) + list(LENGTH matlab_list_of_all_versions list_of_all_versions_length) + if((${list_of_all_versions_length} GREATER 1) AND MATLAB_FIND_DEBUG) + message(WARNING "[MATLAB] Found several versions, taking the first one (versions found ${matlab_list_of_all_versions})") + endif() + + # return the updated value + set(${matlab_final_version} ${Matlab_VERSION_STRING_INTERNAL} PARENT_SCOPE) -# this variable will get all Matlab installations found in the current system. -set(_matlab_possible_roots) - - -# listing the Matlab versions installed on the WIN machine if MATLAB_USER_ROOT -# is not set -if(WIN32) +endfunction() + + - # for windows - if(NOT MATLAB_USER_ROOT) - # if MATLAB_USER_ROOT not specified, we look for Matlab installation in - # the registry - # if unsuccessful, we look for all known revision and filter the existing - # ones. - # testing if we are able to extract the needed information from the registry - set(matlab_versions_from_registry) - matlab_extract_all_installed_versions_from_registry(CMAKE_CL_64 matlab_versions_from_registry) - # the returned list is empty, doing the search on all known versions - if(NOT matlab_versions_from_registry) - - if(MATLAB_FIND_DEBUG) - message(STATUS "[MATLAB] Search for Matlab from the registry unsuccessful, testing all supported versions") - endif() - - extract_matlab_versions_from_registry_brute_force(matlab_versions_from_registry) - endif() - - # filtering the results with the registry keys - matlab_get_all_valid_matlab_roots_from_registry("${matlab_versions_from_registry}" _matlab_possible_roots) +# ################################### +# Exploring the possible Matlab_ROOTS +# this variable will get all Matlab installations found in the current system. +set(_matlab_possible_roots) - elseif(NOT EXISTS ${MATLAB_USER_ROOT}) - # if MATLAB_USER_ROOT specified but erroneous +if(Matlab_ROOT_DIR) + # if the user specifies a possible root, we keep this one + + if(NOT EXISTS ${Matlab_ROOT_DIR}) + # if Matlab_ROOT_DIR specified but erroneous if(MATLAB_FIND_DEBUG) - message(WARNING "[MATLAB] the specified path for MATLAB_USER_ROOT does not exist (${MATLAB_USER_ROOT})") + message(WARNING "[MATLAB] the specified path for Matlab_ROOT_DIR does not exist (${Matlab_ROOT_DIR})") endif() else() - list(APPEND _matlab_possible_roots "NOTFOUND" ${MATLAB_USER_ROOT}) # empty version + # NOTFOUND indicates the code below to search for the version automatically + if(NOT DEFINED Matlab_VERSION_STRING_INTERNAL) + list(APPEND _matlab_possible_roots "NOTFOUND" ${Matlab_ROOT_DIR}) # empty version + else() + list(APPEND _matlab_possible_roots ${Matlab_VERSION_STRING_INTERNAL} ${Matlab_ROOT_DIR}) # cached version + endif() endif() else() - # for linux/osx + + # if the user does not specify the possible installation root, we look for + # one installation using the appropriate heuristics - if(NOT MATLAB_USER_ROOT) - - # if MATLAB_USER_ROOT not specified, we look for Matlab from the command - # line PATH - # maybe using CMAKE_PROGRAM_PATH to add some more hints + if(WIN32) - set(_matlab_main_tmp "") - if(Matlab_MAIN_PROGRAM) - set(_matlab_main_tmp ${Matlab_MAIN_PROGRAM}) - endif() + # On WIN32, we look for Matlab installation in the registry + # if unsuccessful, we look for all known revision and filter the existing + # ones. - if(NOT _matlab_main_tmp) + # testing if we are able to extract the needed information from the registry + set(_matlab_versions_from_registry) + matlab_extract_all_installed_versions_from_registry(CMAKE_CL_64 _matlab_versions_from_registry) - find_program( - _matlab_main_tmp - NAMES matlab) - - if(NOT _matlab_main_tmp) - execute_process( - COMMAND "which" matlab - OUTPUT_VARIABLE _matlab_main_tmp - ERROR_VARIABLE _matlab_main_tmp_err) - # the output should be cleaned up - string(STRIP "${_matlab_main_tmp}" _matlab_main_tmp) - endif() + # the returned list is empty, doing the search on all known versions + if(NOT _matlab_versions_from_registry) - if(EXISTS ${_matlab_main_tmp}) - if(MATLAB_FIND_DEBUG) - message(STATUS "[MATLAB] matlab found from PATH: ${_matlab_main_tmp}") - endif() - else() - # found candidate is not good, we remove it - unset(_matlab_main_tmp) - unset(_matlab_main_tmp CACHE) + if(MATLAB_FIND_DEBUG) + message(STATUS "[MATLAB] Search for Matlab from the registry unsuccessful, testing all supported versions") endif() - endif() # if(NOT _matlab_main_tmp) - - if(_matlab_main_tmp AND EXISTS ${_matlab_main_tmp}) - # resolve symlinks - get_filename_component(_matlab_current_location "${_matlab_main_tmp}" REALPATH) - set(_directory_alias DIRECTORY) - - # get the directory (the command below has to be run twice) - get_filename_component(_matlab_current_location "${_matlab_current_location}" ${_directory_alias}) - get_filename_component(_matlab_current_location "${_matlab_current_location}" ${_directory_alias}) # Matlab should be in bin - list(APPEND _matlab_possible_roots "NOTFOUND" ${_matlab_current_location}) # empty version + extract_matlab_versions_from_registry_brute_force(_matlab_versions_from_registry) endif() + # filtering the results with the registry keys + matlab_get_all_valid_matlab_roots_from_registry("${_matlab_versions_from_registry}" _matlab_possible_roots) + unset(_matlab_versions_from_registry) + elseif(APPLE) + # on mac, we look for the /Application paths # this corresponds to the behaviour on Windows. On Linux, we do not have # any other guess. - if((NOT _matlab_possible_roots) AND APPLE) + matlab_get_supported_releases(_matlab_releases) + if(MATLAB_FIND_DEBUG) + message(STATUS "[MATLAB] Matlab supported versions ${_matlab_releases}. If more version should be supported " + "the variable MATLAB_ADDITIONAL_VERSIONS can be set according to the documentation") + endif() - matlab_get_supported_releases(_matlab_releases) - if(MATLAB_FIND_DEBUG) - message(STATUS "[MATLAB] Matlab supported versions ${_matlab_releases}. If more version should be supported " - "the variable MATLAB_ADDITIONAL_VERSIONS can be set according to the documentation") + foreach(_matlab_current_release IN LISTS _matlab_releases) + set(_matlab_full_string "/Applications/MATLAB_${_matlab_current_release}.app") + if(EXISTS ${_matlab_full_string}) + set(_matlab_current_version) + matlab_get_version_from_release_name("${_matlab_current_release}" _matlab_current_version) + if(MATLAB_FIND_DEBUG) + message(STATUS "[MATLAB] Found version ${_matlab_current_release} (${_matlab_current_version}) in ${_matlab_full_string}") + endif() + list(APPEND _matlab_possible_roots ${_matlab_current_version} ${_matlab_full_string}) + unset(_matlab_current_version) endif() - foreach(_matlab_current_release IN LISTS _matlab_releases) - set(_matlab_full_string "/Applications/MATLAB_${_matlab_current_release}.app") - if(EXISTS ${_matlab_full_string}) - set(_matlab_current_version) - matlab_get_version_from_release_name("${_matlab_current_release}" _matlab_current_version) - if(MATLAB_FIND_DEBUG) - message(STATUS "[MATLAB] Found version ${_matlab_current_release} (${_matlab_current_version}) in ${_matlab_full_string}") - endif() - list(APPEND _matlab_possible_roots ${_matlab_current_version}) - list(APPEND _matlab_possible_roots ${_matlab_full_string}) - unset(_matlab_current_version) - endif() + unset(_matlab_full_string) + endforeach(_matlab_current_release) + + unset(_matlab_current_release) + unset(_matlab_releases) + + endif() - unset(_matlab_full_string) - endforeach(_matlab_current_release) - unset(_matlab_current_release) - unset(_matlab_releases) - endif() +endif() - # we need to clear _matlab_main_tmp here - unset(_matlab_main_tmp CACHE) - unset(_matlab_main_tmp) - elseif(NOT EXISTS ${MATLAB_USER_ROOT}) - # if MATLAB_USER_ROOT specified but erroneous + +list(LENGTH _matlab_possible_roots _numbers_of_matlab_roots) +if(_numbers_of_matlab_roots EQUAL 0) + # if we have not found anything, we fall back on the PATH + + + # At this point, we have no other choice than trying to find it from PATH. + # If set by the user, this wont change + find_program( + _matlab_main_tmp + NAMES matlab) + + + if(_matlab_main_tmp) + # we then populate the list of roots, with empty version if(MATLAB_FIND_DEBUG) - message(WARNING "[MATLAB] the specified path for MATLAB_USER_ROOT does not exist (${MATLAB_USER_ROOT})") + message(STATUS "[MATLAB] matlab found from PATH: ${_matlab_main_tmp}") endif() - else() - list(APPEND _matlab_possible_roots "NOTFOUND" ${MATLAB_USER_ROOT}) # empty version + + # resolve symlinks + get_filename_component(_matlab_current_location "${_matlab_main_tmp}" REALPATH) + + # get the directory (the command below has to be run twice) + # this will be the matlab root + get_filename_component(_matlab_current_location "${_matlab_current_location}" DIRECTORY) + get_filename_component(_matlab_current_location "${_matlab_current_location}" DIRECTORY) # Matlab should be in bin + + list(APPEND _matlab_possible_roots "NOTFOUND" ${_matlab_current_location}) + + unset(_matlab_current_location) + endif() + unset(_matlab_main_tmp CACHE) + endif() + + + if(MATLAB_FIND_DEBUG) message(STATUS "[MATLAB] Matlab root folders are ${_matlab_possible_roots}") endif() -if(DEFINED Matlab_ROOT_DIR) - unset(Matlab_ROOT_DIR) -endif() + # take the first possible Matlab root -if(_matlab_possible_roots) +list(LENGTH _matlab_possible_roots _numbers_of_matlab_roots) +set(Matlab_VERSION_STRING "NOTFOUND") +if(_numbers_of_matlab_roots GREATER 0) list(GET _matlab_possible_roots 0 Matlab_VERSION_STRING) list(GET _matlab_possible_roots 1 Matlab_ROOT_DIR) - list(LENGTH _matlab_possible_roots numbers_of_matlab_roots) # adding a warning in case of ambiguity - if(numbers_of_matlab_roots GREATER 2 AND MATLAB_FIND_DEBUG) + if(_numbers_of_matlab_roots GREATER 2 AND MATLAB_FIND_DEBUG) message(WARNING "[MATLAB] Found several distributions of Matlab. Setting the current version to ${Matlab_VERSION_STRING} (located ${Matlab_ROOT_DIR})." " If this is not the desired behaviour, provide the -DMATLAB_USER_ROOT on the command line") endif() endif() -if((NOT (DEFINED Matlab_VERSION_STRING)) OR (NOT Matlab_VERSION_STRING)) - set(Matlab_VERSION_STRING "NOTFOUND") -endif() - - - -# if the version is not trivial, we query matlab for that -# we keep track of the location of matlab that induced this version -set(Matlab_VERSION_STRING_AUTO_DETECT "" CACHE INTERNAL "internal matlab location for the discovered version") - -set(_matlab_version_should_be_recomputed FALSE) -if(${Matlab_VERSION_STRING} STREQUAL "NOTFOUND") - set(_matlab_version_should_be_recomputed TRUE) -elseif((NOT Matlab_MAIN_PROGRAM) OR (NOT EXISTS ${Matlab_MAIN_PROGRAM})) - set(_matlab_version_should_be_recomputed TRUE) -else() - # just in case the variable is modified to a symlink - get_filename_component(_matlab_main_tmp "${Matlab_MAIN_PROGRAM}" REALPATH) - if(NOT (_matlab_main_tmp STREQUAL Matlab_VERSION_STRING_AUTO_DETECT)) - set(_matlab_version_should_be_recomputed TRUE) +# check if the root changed against the previous defined one, if so +# clear all the cached variables +if(DEFINED Matlab_ROOT_DIR_LAST_CACHED) + + if(NOT Matlab_ROOT_DIR_LAST_CACHED STREQUAL Matlab_ROOT_DIR) + message(FATAL_ERROR "clearing") + set(_Matlab_cached_vars + Matlab_INCLUDE_DIRS + Matlab_MEX_LIBRARY + Matlab_MEX_COMPILER + Matlab_MAIN_PROGRAM + Matlab_MX_LIBRARY + Matlab_ENG_LIBRARY + Matlab_MEX_EXTENSION + + # internal + Matlab_MEXEXTENSIONS_PROG + Matlab_ROOT_DIR_LAST_CACHED + #Matlab_PROG_VERSION_STRING_AUTO_DETECT + Matlab_VERSION_STRING_INTERNAL + ) + foreach(_var IN LISTS _Matlab_cached_vars) + if(DEFINED ${_var}) + unset(${_var} CACHE) + endif() + endforeach() endif() endif() -if(_matlab_version_should_be_recomputed) - if(MATLAB_FIND_DEBUG) - message(STATUS "[MATLAB] querying for version from Matlab root = ${Matlab_ROOT_DIR}") - endif() - - if(Matlab_MAIN_PROGRAM) - set(_matlab_main_tmp ${Matlab_MAIN_PROGRAM}) - else() - find_program( - _matlab_main_tmp - matlab - PATHS ${Matlab_ROOT_DIR} ${Matlab_ROOT_DIR}/bin - DOC "Matlab main program" - NO_DEFAULT_PATH - ) - endif() +set(Matlab_ROOT_DIR_LAST_CACHED ${Matlab_ROOT_DIR} CACHE INTERNAL "last Matlab root dir location") +set(Matlab_ROOT_DIR ${Matlab_ROOT_DIR} CACHE PATH "Matlab installation root path" FORCE) - if(_matlab_main_tmp) - set(matlab_list_of_all_versions) - matlab_get_version_from_matlab_run("${_matlab_main_tmp}" matlab_list_of_all_versions) +# Fix the version, in case this one is NOTFOUND +_Matlab_get_version_from_root( + "${Matlab_ROOT_DIR}" + ${Matlab_VERSION_STRING} + Matlab_VERSION_STRING +) - list(GET matlab_list_of_all_versions 0 MATLAB_VERSION_tmp) - # set the version into the cache - set(Matlab_VERSION_STRING ${MATLAB_VERSION_tmp} CACHE INTERNAL "Matlab version (automatically determined)" FORCE) - list(LENGTH list_of_all_versions list_of_all_versions_length) - if((${list_of_all_versions_length} GREATER 1) AND MATLAB_FIND_DEBUG) - message(WARNING "[MATLAB] Found several versions, taking the first one (versions found ${list_of_all_versions})") - endif() - - # update the location of Matlab that produced this value - # we store the real path for comparison - get_filename_component(_matlab_main_tmp1 "${_matlab_main_tmp}" REALPATH) - set(Matlab_VERSION_STRING_AUTO_DETECT ${_matlab_main_tmp1} CACHE INTERNAL "internal matlab location for the discovered version" FORCE) - - # these are internal variables - unset(_matlab_main_tmp) - unset(_matlab_main_tmp CACHE) - unset(_matlab_main_tmp1) - endif() -endif() if(MATLAB_FIND_DEBUG) @@ -1289,16 +1358,15 @@ unset(_matlab_find_mex_compiler) # component Matlab program list(FIND Matlab_FIND_COMPONENTS MAIN_PROGRAM _matlab_find_matlab_program) if(_matlab_find_matlab_program GREATER -1) - # todo cleanup with code above - if(NOT DEFINED Matlab_MAIN_PROGRAM) - find_program( - Matlab_MAIN_PROGRAM - matlab - PATHS ${Matlab_ROOT_DIR} ${Matlab_ROOT_DIR}/bin - DOC "Matlab main program" - NO_DEFAULT_PATH - ) - endif() + + find_program( + Matlab_MAIN_PROGRAM + matlab + PATHS ${Matlab_ROOT_DIR} ${Matlab_ROOT_DIR}/bin + DOC "Matlab main program" + NO_DEFAULT_PATH + ) + if(Matlab_MAIN_PROGRAM) set(Matlab_MAIN_PROGRAM_FOUND TRUE) endif() @@ -1349,19 +1417,13 @@ unset(_matlab_lib_dir_for_search) set(Matlab_LIBRARIES ${Matlab_MEX_LIBRARY} ${Matlab_MX_LIBRARY} ${Matlab_ENG_LIBRARY}) -if(CMAKE_VERSION VERSION_LESS "2.8.11") - find_package_handle_standard_args( - Matlab - REQUIRED_VARS ${_matlab_required_variables} - VERSION_VAR Matlab_VERSION_STRING) -else() - find_package_handle_standard_args( - Matlab - FOUND_VAR Matlab_FOUND - REQUIRED_VARS ${_matlab_required_variables} #MATLAB_REQUIRED_PROGRAMS MATLAB_REQUIRED_LIBRARIES MATLAB_REQUIRED_INCLUDE_DIRS - VERSION_VAR Matlab_VERSION_STRING - HANDLE_COMPONENTS) -endif() + +find_package_handle_standard_args( + Matlab + FOUND_VAR Matlab_FOUND + REQUIRED_VARS ${_matlab_required_variables} + VERSION_VAR Matlab_VERSION_STRING + HANDLE_COMPONENTS) unset(_matlab_required_variables) unset(_matlab_bin_prefix) @@ -1373,17 +1435,18 @@ unset(_matlab_lib_prefix_for_search) if(Matlab_INCLUDE_DIRS AND Matlab_LIBRARIES) mark_as_advanced( - Matlab_LIBRARIES + #Matlab_LIBRARIES Matlab_MEX_LIBRARY Matlab_MX_LIBRARY Matlab_ENG_LIBRARY Matlab_INCLUDE_DIRS Matlab_FOUND - MATLAB_USER_ROOT - Matlab_ROOT_DIR - Matlab_VERSION_STRING + #Matlab_ROOT_DIR + #Matlab_VERSION_STRING Matlab_MAIN_PROGRAM + #Matlab_MEX_EXTENSION + Matlab_MEXEXTENSIONS_PROG Matlab_MEX_EXTENSION - Matlab_BINARIES_DIR + #Matlab_BINARIES_DIR ) endif() diff --git a/Modules/MatlabTestsRedirect.cmake b/Modules/MatlabTestsRedirect.cmake index 804101c..ebccbf6 100644 --- a/Modules/MatlabTestsRedirect.cmake +++ b/Modules/MatlabTestsRedirect.cmake @@ -62,12 +62,20 @@ set(Matlab_SCRIPT_TO_RUN set(Matlab_LOG_FILE "${output_directory}/${test_name}.log") +set(devnull) +if(UNIX) + set(devnull INPUT_FILE /dev/null) +elseif(WIN32) + set(devnull INPUT_FILE NUL) +endif() + execute_process( COMMAND "${Matlab_PROGRAM}" ${Matlab_UNIT_TESTS_CMD} -logfile "${test_name}.log" -r "${Matlab_SCRIPT_TO_RUN}" RESULT_VARIABLE res TIMEOUT ${test_timeout} OUTPUT_QUIET # we do not want the output twice WORKING_DIRECTORY "${output_directory}" + ${devnull} ) if(NOT EXISTS ${Matlab_LOG_FILE}) diff --git a/Tests/FindMatlab/cmake_matlab_unit_tests_timeout.m b/Tests/FindMatlab/cmake_matlab_unit_tests_timeout.m index 66be1bb..11d5e9e 100644 --- a/Tests/FindMatlab/cmake_matlab_unit_tests_timeout.m +++ b/Tests/FindMatlab/cmake_matlab_unit_tests_timeout.m @@ -9,7 +9,8 @@ classdef cmake_matlab_unit_tests_timeout < matlab.unittest.TestCase function testCallHangsShouldBeTimedOut(testCase) cmake_matlab_mex1(rand(3,3)); disp('Will now wait.'); - input('Testing the cmake Matlab package timeout - do not press anything'); + disp('Testing the cmake Matlab package timeout - do not kill'); + pause(20); % supposed to be killed after 15s end end end diff --git a/Tests/RunCMake/CMakeLists.txt b/Tests/RunCMake/CMakeLists.txt index 7715f1c..5f1471e 100644 --- a/Tests/RunCMake/CMakeLists.txt +++ b/Tests/RunCMake/CMakeLists.txt @@ -203,3 +203,4 @@ endif() if(CMake_TEST_FindMatlab) add_RunCMake_test(FindMatlab) endif() + -- 2.0.1 From steveire at gmail.com Wed Mar 11 06:10:30 2015 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 11 Mar 2015 11:10:30 +0100 Subject: [cmake-developers] Generating buildsystem metadata from CMake Message-ID: Hi, Following from the thread here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12394 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12650 I'm starting to gather requirements and make sure the feature is well designed to satisfy the needs we're already aware of, and fits with the features CMake currently has. The aim is to generate a structured file containing metadata relating the buildsystem. To help with completing the design of this feature, I've written documentation (documentation driven design), and a unit test containing a CMakeLists.txt file which exercises many modern CMake features in the "generate-metadata" branch in my clone. Mostly the design I propose can be read in the documentation I wrote. I'm interested in any feedback. https://gitorious.org/cmake/steveires-cmake/source/generate-metadata:Tests/Metadata/CMakeLists.txt http://www.steveire.com/cmake-future/manual/cmake-metadata-generation.7.html I expect to require a few iterations to figure out what the metadata files should contain in the end. Note that there are already some differences between my design and Aleix's implementation, such as that my design proposes one metadata file per config. There are also some things missing like location, because it is not yet clear to me whether build or install locations are needed etc. The content of the metadata file is determined by the build properties, and is necessarily similar to the compile-related content created when generating the actual buildsystem. It additionally contains information about the output locations of build artifacts and information relating to the cmake description itself. Goals include: * Make it possible for IDEs to access the compile-related information for autocompletion and code navigation etc purposes. * Remove the need for IDEs to parse generated Makefiles or Ninja files to access compile-related information. The structure of those files is not 'stable', while the content of the metadata file is stable. http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/48412 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11081 * Remove the need for users to create a new build directory and new build in order to use or switch IDEs. QtCreator requires that the C::B 'extra generator is used as it parses compile information from that. Other 'extra generators' such as for eclipse, sublime, kate etc also require fresh/new build directories, although the actual buildsystem they create is identical (assuming using all Makefile based or all Ninja based 'extra generators') * Make it possible to write a plugin for the editors/IDEs such as sublime which consumes the metadata file and invokes the build using whatever buildsystem the user already has a build directory for, instead of writing an 'extra generator' and maintaining it in the cmake repo. http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9004 * Make it possible for editors/IDEs to allow specifying the configuration at build-time, where the IDE has that feature, and where a multi-config generator is available. That is, QtCreator provides user-interface for choosing debug/release config to build. Currently it can't offer that when using cmake, because it only allows the use of Makefile or Ninja generators, in order to make use of the C::B file. QtCreator should be able to use the Xcode or Visual Studio generators, generate the metadata file(s), and invoke `cmake --build . --config ${CONFIG}` as appropriate. Eclipse, Sublime and other editors have similar abilities to invoke config-specific builds after generation. * Provide a list of 'build targets', which can be listed and invoked in IDE/editor user interface. Build targets for all linked binaries and utilties are provided. The tooling is expected to perform filtering on the target types to show only executables and utilities for execution, for example. * Provide a list of source files per target per type of source file, eg object sources, header files, generated files, files excluded from the active configuration/platform/compiler, non-compiled files. * Make it more easy for an IDE to support actions such as 'remove file from the project', which requires removing it from the CMakeLists.txt at the appropriate place, and 'add new file/class to target', which involves adding code to the CMakeLists.txt file at the appropriate place. Most likely the easiest way to do the latter is using the target_sources() command, and to support the former, the location of the declaration of the target, and all target_sources() calls would need to be recorded. Even that is not enough because of transitive consumption of source files through the link interface, but that is likely irrelevant. * Provide information about the entire build graph of link-dependencies for visulization and dependency analysis http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/4042 * Provide enough information about runtime link dependencies for IDEs to be able to properly invoke targets with debuggers, profilers and other tools. http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11011 The CMAKE_EXPORT_COMPILE_COMMANDS variable already exists to generate compile command lines, but that is a file whose format is defined by Clang, not by CMake, and other tools in the Clang ecosystem also support it. It is not extensible or versioned in the way that a CMake-defined file format is, so I don't propose using it as a starting point. Notes: * I deliberately didn't push an implementation to my repo, so that this discussion can focus on the design of the feature and contents of the file first. * In the documentation and the test I didn't mention that the metadata file is JSON. I'm not opposed to it, but I think there should be some kind of schema defining how to read the metadata file. If we go with JSON (instead of xml, say), then we'd have to define our own schema format, which is not impossible. My proposal is to generate the schema beside the metadata file instead of writing a metadata version into the metadata file itself. Does anyone feel strongly about the file being JSON? I just want to record the reason for everything in this design phase - we don't have to spend a lot of time on it. * I didn't document the location or directory. I'm not clear on whether it is supposed to be the build location, or the install location(s!), or all of those. * I don't generate 'dependencies' (actually the list of files which the buildsystem re-generation depends on) as Aleix did, because there is no well-defined usefulness for that list yet. * I documented the 'name' for the targets, and the TARGET_FILE_NAME etc information, and can push an implementation which generates them. http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12619 * If it is useful to preprocess/compile/assemble individual files from IDEs, as made possible by the Makefiles and Ninja generators, we'll need to design that. http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12429 * Some more information from project() may be relevant, but it's not clear yet. We will likely know more when we have decided the file format and generated some 'interesting' metadata files. * We might need backtraces for not only all add_library and add_executable calls, but also all target_sources() calls. * We list the Generator used to configure the build. That way IDEs know which build output parser to use. * I propose to generate one metadata file per configuration active in the buildsystem. That means that the Makefile and Ninja generators would generate only one file, and the multi-config generators would generate multiple files. When changing the 'active configuration', IDEs would then read whatever metadata file is relevant to the active configuration. This also means that conditions don't need to be added inside the metadata file for configurations in order to show files 'excluded' by being part of a non-active configuration. The code implementing discovery of excluded files is in the generate-metadata branch in my clone. http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11323 "At least Qt Creator does not need information on which conditions to be met for a file to become part of the current build." * I propose generating language-specific source lists, because CMake can build files with compilers which do not match their file extension. * I propose generating language-specific compile properties in the metadata file if there a language specific variant groups. For example if the compile options themselves are language-specific (the feature enabling that was merged to CMake master this week), then a property for each language is specified. Otherwise only a language-agnostic property is generated. This can vary per-configuration for a multi-config generator, so each metadata file for a multi-config generator could have different properties present. Consumers read the language specific property if it is present, and read the language agnostic version otherwise. * Generating metadata only (without generating buildsystem files) is not currently in scope. This was requested several times, but it is not clear why. * How much information does tooling need about installation? Targets can use different include directories and compile definitions in their install locations compared to their build locations. If IDEs want to provide some user interface related to the project files in their install location, perhaps a separate solution based on cmExportFile* is needed. For future investigation. Thanks, Steve. From mantis at public.kitware.com Wed Mar 11 07:05:28 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 11 Mar 2015 07:05:28 -0400 Subject: [cmake-developers] [CMake 0015440]: "Visual Studio Version Selector" launches incorrect version when opening generated UTF-8 solution file. Message-ID: <2de612208bcf377e54f946d375a6acb4@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15440 ====================================================================== Reported By: Felix Bruns Assigned To: ====================================================================== Project: CMake Issue ID: 15440 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-11 07:05 EDT Last Modified: 2015-03-11 07:05 EDT ====================================================================== Summary: "Visual Studio Version Selector" launches incorrect version when opening generated UTF-8 solution file. Description: Since solution (*.sln) files are encoded as UTF-8 (with signature), "Visual Studio Version Selector" doesn't detect the file format version correctly. Opening the file with an editor, then saving it as UTF-8 (without signature) fixes the problem. Steps to Reproduce: 1. Install "Visual Studio 12 2013" 2. Install "Visual Studio 14 2015" 3. Install "CMake 3.2.0-rc2" 4. Generate a solution file using the "Visual Studio 12 2013" generator. 5. Double-click solution file in Explorer. Actual: 6. "Visual Studio 14 2015" is launched. 7. Solution file icon shows no version number in Explorer. Expected: 6. "Visual Studio 12 2013" is launched. 7. Solution file icon shows correct version number in Explorer. Workaround: 1. Use Notepad2 to open/save solution file with encoding "UTF-8" (_not_ "UTF-8 with Signature") 2. Double-click solution file in Explorer. 3. "Visual Studio 12 2013" is launched. 4. Solution file icon shows correct version number in Explorer. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-11 07:05 Felix Bruns New Issue ====================================================================== From aklitzing at gmail.com Wed Mar 11 08:21:58 2015 From: aklitzing at gmail.com (A. Klitzing) Date: Wed, 11 Mar 2015 13:21:58 +0100 Subject: [cmake-developers] Support of codesign In-Reply-To: <2830805.x682EbQycE@stryke> References: <1678645.2J7lYulytt@stryke> <2830805.x682EbQycE@stryke> Message-ID: Hi there! I added another improvement to the codesign feature. Sometimes it is helpful to overwrite or pass additional parameters like "--timestamp=none" to codesign. But this shouldn't be the default for everyone. So I added the variable CPACK_BUNDLE_APPLE_CODESIGN_PARAMETER. Hope you like it. Regards Andr? 2015-02-20 16:20 GMT+01:00 Clinton Stimpson : > On Friday, February 20, 2015 12:07:55 PM A. Klitzing wrote: > > Hi Clint, > > > > I have another patch to tweak the error output a little bit. If codesign > > fails it won't be possible to get the error message of codesign itself. > > That is a little bit confusing because it just fails without an > > understandable reason. > > > > This patch will print the output of codesign if it fails. > > > > Thanks. > > > > Clint > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-CPack-Add-support-to-overwrite-or-pass-additional-pa.patch Type: text/x-diff Size: 3331 bytes Desc: not available URL: From robert.maynard at kitware.com Wed Mar 11 09:19:24 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 11 Mar 2015 09:19:24 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.2.1 Released! Message-ID: I am proud to announce that CMake 3.2.1 is now available for download at: http://www.cmake.org/download/ Documentation is available at: http://www.cmake.org/cmake/help/v3.2 Release notes appear below and are also published at http://www.cmake.org/cmake/help/v3.2/release/3.2.html Some of the more significant features of CMake 3.2 are: * CMake learned to support unicode characters *encoded as UTF-8* on Windows. This was already supported on platforms whose system APIs accept UTF-8 encoded strings. Unicode characters may now be used in CMake code, paths to source files, configured files such as ".h.in" files, and other files read and written by CMake. Note that because CMake interoperates with many other tools, there may still be some limitations when using certain unicode characters. * The "Compile Features" functionality is now aware of features supported by more compilers, including: * Apple Clang ("AppleClang") for Xcode versions 4.4 though 6.1. * GNU compiler versions 4.4 through 5.0 on UNIX and Apple ("GNU"). * Microsoft Visual Studio ("MSVC") for versions 2010 through 2015. * Oracle SolarisStudio ("SunPro") version 12.4. * The "add_custom_command()" and "add_custom_target()" commands learned a new "BYPRODUCTS" option to specify files produced as side effects of the custom commands. These are not outputs because they do not always have to be newer than inputs. * The "file(GENERATE)" command can now generate files which are used as source files for buildsystem targets. Generated files automatically get their "GENERATED" property set to "TRUE". Deprecated and Removed Features: * Files written in the "cmake-language(7)", such as "CMakeLists.txt" or "*.cmake" files, are now expected to be encoded as UTF-8. If files are already ASCII, they will be compatible. If files were in a different encoding, including Latin 1, they will need to be converted. * The "FindOpenGL" module no longer explicitly searches for any dependency on X11 libraries with the "FindX11" module. Such dependencies should not need to be explicit. Applications using X11 APIs themselves should find and link to X11 libraries explicitly. CMake 3.2 Release Notes *********************** Changes made since CMake 3.1 include the following. New Features ============ Syntax ------ * CMake learned to support unicode characters *encoded as UTF-8* on Windows. This was already supported on platforms whose system APIs accept UTF-8 encoded strings. Unicode characters may now be used in CMake code, paths to source files, configured files such as ".h.in" files, and other files read and written by CMake. Note that because CMake interoperates with many other tools, there may still be some limitations when using certain unicode characters. Commands -------- * The "add_custom_command()" and "add_custom_target()" commands learned a new "BYPRODUCTS" option to specify files produced as side effects of the custom commands. These are not outputs because they do not always have to be newer than inputs. * The "add_custom_command()" and "add_custom_target()" commands learned a new "USES_TERMINAL" option to request that the command be given direct access to the terminal if possible. The "Ninja" generator will places such commands in the "console" "pool". Build targets provided by CMake that are meant for individual interactive use, such as "install", are now placed in this pool. * A new "continue()" command was added that can be called inside loop contexts to end the current iteration and start the next one at the top of the loop block. * The "file(LOCK)" subcommand was created to allow CMake processes to synchronize through file and directory locks. * The "file(STRINGS)" now supports UTF-16LE, UTF-16BE, UTF-32LE, UTF- 32BE as "ENCODING" options. * The "install(EXPORT)" command now works with an absolute "DESTINATION" even if targets in the export set are installed with a destination or *usage requirements* specified relative to the install prefix. The value of the "CMAKE_INSTALL_PREFIX" variable is hard-coded into the installed export file as the base for relative references. * The "try_compile()" command source file signature now honors link flags (e.g. "CMAKE_EXE_LINKER_FLAGS") in the generated test project. See policy "CMP0056". * The "try_run()" command learned to honor the "LINK_LIBRARIES" option just as "try_compile()" already does. * The "file(GENERATE)" command now generates the output file with the same permissions as the input file if set. * The "file(GENERATE)" command can now generate files which are used as source files for buildsystem targets. Generated files automatically get their "GENERATED" property set to "TRUE". Variables --------- * The "CMAKE_MATCH_COUNT" variable was introduced to record the number of matches made in the last regular expression matched in an "if()" command or a "string()" command. Properties ---------- * An "ANDROID_API_MIN" target property was introduced to specify the minimum version to be targeted by the toolchain. * A "VS_SHADER_FLAGS" source file property was added to specify additional shader flags to ".hlsl" files, for the Visual Studio generators. Modules ------- * The "ExternalData" module learned to support *Custom Fetch Scripts*. This allows projects to specify custom ".cmake" scripts for fetching data objects during the build. * The "ExternalProject" module learned options to create independent external project step targets that do not depend on the builtin steps. * The "ExternalProject" module "ExternalProject_Add()" command learned a new "CMAKE_CACHE_DEFAULT_ARGS" option to initialize cache values in the external project without setting them on future builds. * The "ExternalProject" module "ExternalProject_Add()" command learned a new "TEST_EXCLUDE_FROM_MAIN" option to exclude tests from the main build. * The "ExternalProject" module "ExternalProject_Add()" command learned a new "UPDATE_DISCONNECTED" option to avoid automatically updating the source tree checkout from version control. * The "FindCUDA" module learned about the "cusolver" library in CUDA 7.0. * The "FindGit" module learned to find the "git" command-line tool that comes with GitHub for Windows installed in user home directories. * A "FindGSL" module was introduced to find the GNU Scientific Library. * A "FindIntl" module was introduced to find the Gettext "libintl" library. * The "FindLATEX" module learned to support components. * The "FindMPI" module learned to find MS-MPI on Windows. * The "FindOpenSSL" module now reports "crypto" and "ssl" libraries separately in "OPENSSL_CRYPTO_LIBRARY" and "OPENSSL_SSL_LIBRARY", respectively, to allow applications to link to one without the other. * The "WriteCompilerDetectionHeader" module learned to create a define for portability of the "cxx_thread_local" feature. The define expands to either the C++11 "thread_local" keyword, or a pre- standardization compiler-specific equivalent, as appropriate. * The "WriteCompilerDetectionHeader" module learned to create multiple output files per compiler and per language, instead of creating one large file. CTest ----- * The "ctest_coverage()" command learned to support Delphi coverage. * The "ctest_coverage()" command learned to support Javascript coverage. * The "CTestCoverageCollectGCOV" module was introduced as an alternative to the "ctest_coverage()" command for collecting "gcov" results for submission to CDash. CPack ----- * The "CPackRPM" module learned options to set per-component descriptions and summaries. See the "CPACK_RPM__PACKAGE_DESCRIPTION" and "CPACK_RPM__PACKAGE_SUMMARY" variables. * The "CPackRPM" module learned options to specify requirements for pre- and post-install scripts. See the "CPACK_RPM_PACKAGE_REQUIRES_PRE" and "CPACK_RPM_PACKAGE_REQUIRES_POST" variables. * The "CPackRPM" module learned options to specify requirements for pre- and post-uninstall scripts. See the "CPACK_RPM_PACKAGE_REQUIRES_PREUN" and "CPACK_RPM_PACKAGE_REQUIRES_POSTUN" variables. * The "CPackRPM" module learned a new "CPACK_RPM__PACKAGE_PREFIX" variable to specify a component-specific value to use instead of "CPACK_PACKAGING_INSTALL_PREFIX". * The "CPackRPM" module learned a new "CPACK_RPM_RELOCATION_PATHS" variable to specify multiple relocation prefixes for a single rpm package. Other ----- * The "cmake(1)" "-E tar" command now supports creating ".xz"-compressed archives with the "J" flag. * The "cmake(1)" "-E tar" command learned a new "--files- from=" option to specify file names using lines in a file to overcome command-line length limits. * The "cmake(1)" "-E tar" command learned a new "--mtime=" option to specify the modification time recorded in tarball entries. * The "Compile Features" functionality is now aware of features supported by more compilers, including: * Apple Clang ("AppleClang") for Xcode versions 4.4 though 6.1. * GNU compiler versions 4.4 through 5.0 on UNIX and Apple ("GNU"). * Microsoft Visual Studio ("MSVC") for versions 2010 through 2015. * Oracle SolarisStudio ("SunPro") version 12.4. * The *AUTORCC* feature now tracks files listed in ".qrc" files as dependencies. If an input file to the "rcc" tool is changed, the tool is automatically re-run. New Diagnostics =============== * The "break()" command now rejects calls outside of a loop context or that pass arguments to the command. See policy "CMP0055". Deprecated and Removed Features =============================== * Files written in the "cmake-language(7)", such as "CMakeLists.txt" or "*.cmake" files, are now expected to be encoded as UTF-8. If files are already ASCII, they will be compatible. If files were in a different encoding, including Latin 1, they will need to be converted. * The "FindOpenGL" module no longer explicitly searches for any dependency on X11 libraries with the "FindX11" module. Such dependencies should not need to be explicit. Applications using X11 APIs themselves should find and link to X11 libraries explicitly. * The implementation of CMake now relies on some C++ compiler features which are not supported by some older compilers. As a result, those old compilers can no longer be used to build CMake itself. CMake continues to be able to generate Makefiles and project files for users of those old compilers however. Compilers known to no longer be capable of building CMake are: * Visual Studio 6 and 7.0 -- superseded by VisualStudio 7.1 and newer. * GCC 2.95 -- superseded by GCC 3 and newer compilers. * Borland compilers -- superseded by other Windows compilers. * Compaq compilers -- superseded by other compilers. * SGI compilers -- IRIX was dropped as a host platform. Other Changes ============= * On Windows and OS X, commands supporting network communication via "https", such as "file(DOWNLOAD)", "file(UPLOAD)", and "ctest_submit()", now support SSL/TLS even when CMake is not built against OpenSSL. The Windows or OS X native SSL/TLS implementation is used by default. OS-configured certificate authorities will be trusted automatically. On other platforms, when CMake is built with OpenSSL, these commands now search for OS-configured certificate authorities in a few "/etc" paths to be trusted automatically. * On OS X with Makefile and Ninja generators, when a compiler is found in "/usr/bin" it is now mapped to the corresponding compiler inside the Xcode application folder, if any. This allows such build trees to continue to work with their original compiler even when "xcode- select" switches to a different Xcode installation. * The Visual Studio generators now write solution and project files in UTF-8 instead of Windows-1252. Windows-1252 supported Latin 1 languages such as those found in North and South America and Western Europe. With UTF-8, additional languages are now supported. * The "Xcode" generator no longer requires a value for the "CMAKE_MAKE_PROGRAM" variable to be located up front. It now locates "xcodebuild" when needed at build time. * When building CMake itself using SolarisStudio 12, the default "libCStd" standard library is not sufficient to build CMake. The SolarisStudio distribution supports compiler options to use "STLPort4" or "libstdc++". An appropriate option to select the standard library is now added automatically when building CMake with SolarisStudio compilers. ----------------------------------------------------------------------------- CMake 3.2.0 was tagged but never announced due to a regression reported in 3.2.0-rc2 just prior to the announcement being sent. Changes in CMake 3.2.1 since 3.2.0 are: Brad King (6): Makefile: Fix multiple custom command outputs regression (#15116) configure_file: Do not warn about newline style arguments Tests: Add more signature tests to RunCMake.configure_file test Ninja: Improve internal check for generating at the top-level (#15436) UseSWIG: Avoid if() auto-dereferene in quoted arguments CMake 3.2.1 Changes in CMake 3.2.0 since 3.2.0-rc2 are: Brad King (3): VS: Do not generate a BOM in .sln files Diagnose invalid _STANDARD value instead of crashing (#15426) CMake 3.2.0 Domen Vrankar (1): CPackRPM: Fix handling of relocation prefix parent directories Paul Martin (1): KWSys SystemTools: Update CopyFileAlways stream library workarounds Robert Goulet (1): install: Write the entire installation manifest at once ----------------------------------------------------------------------------- From ben.boeckel at kitware.com Wed Mar 11 10:15:07 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 11 Mar 2015 10:15:07 -0400 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: <54F76572.9000206@kitware.com> Message-ID: <20150311141507.GA2109@megas.kitwarein.com> On Tue, Mar 10, 2015 at 01:25:16 +0100, Aleix Pol wrote: > >> "output" : "/home/kde-devel/tmp/llvm/build/lib/libLLVMPowerPCInfo.a", > > > > Can this be a list? > It's 1 output per target, no? Not on Windows with .dll and .lib splits. > >> "sources" : [ "/list/of/cpp/files, ] > > > > Any way to also get the headers? Do you see any option to hint where > > new sources would need to be added to make them a part of this target? > I looked into how the CodeBlocks did it to provide the header files. > It's just brute-forcing to see if the file renamed to *.h/*.hpp/*.hxx > is present. > CMake doesn't have this kind of information, so I think it's better > that the IDE's do the hacky parts than cmake. > Also we don't really have information about where to put them. You can > use the minimum common denominator among the sources I guess. There's the source_group() command which could be changed to affect this as well. > > Building the project should be fine with the information provided. > > Explicitly stating the generators used would help a little bit (even > > better just giving the command necessary to build, e.g. make or ninja > > or whatnot. Then we would not need to hard-code the mapping of > > generators->build tools, which makes it much easier for you to support > > new things:-) > > > > Running/Debugging is a bit tricky again: All the information used for > > linking the binaries is gone. So there is no way to figure out which > > LD_LIBRARY_PATH needs to be set or anything. There also seems to be no > > information where files are going to get installed to. Would it be > > possible to add that information? > I ignore it, on the other hand I'm quite a n00b when it comes to cmake > codebase and internals. I'm sure if somebody knows where to get that > information, he is reading this mailing list. (hello) CMake has options for RPATH for the relevant platforms. By default, binaries have the RPATH set for the build tree. Relevant CMake target properties (there are variables to set default values as well): - BUILD_WITH_INSTALL_RPATH - SKIP_BUILD_RPATH Without SKIP_BUILD_RPATH set, LD_LIBRARY_PATH should not be necessary for running targets. --Ben From Geoffrey.Viola at asirobots.com Wed Mar 11 13:39:41 2015 From: Geoffrey.Viola at asirobots.com (Geoffrey Viola) Date: Wed, 11 Mar 2015 17:39:41 +0000 Subject: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support In-Reply-To: <54FEF1C1.4030106@kitware.com> References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com> <5474E132.2010705@kitware.com> <54D129E3.60101@kitware.com> <54E365F4.3030104@kitware.com> <54E7542D.6050808@kitware.com> <54EB68C8.7030504@kitware.com> <54F0952B.5070809@kitware.com> <54F4781A.80708@kitware.com> <54FEF1C1.4030106@kitware.com> Message-ID: Attached is a patch with the recommended changes to add Green Hills MULTI support. The process of finding the GHS_COMP_ROOT variable is now programmed in cmGlobalGhsMultiGenerator::GetCompRoot. I ran a test with some of those changes: https://open.cdash.org/viewSite.php?siteid=11862&project=1¤ttime=1426035600. I'm currently rerunning them. Geoffrey Viola SOFTWARE ENGINEER asirobots.com -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Tuesday, March 10, 2015 7:30 AM To: Geoffrey Viola Cc: cmake-developers at cmake.org Subject: Re: FW: FW: [cmake-developers] Initial Attempt at Green Hill MULTI IDE Generator Support On 03/10/2015 12:57 AM, Geoffrey Viola wrote: > Should I still set CMAKE_GHS_COMPILER_ID? I don't see any reason to set a variable by that name. >> * Have EnableLanguage compute the exact path to the compiler tools >> itself, possibly using GHS_COMP_ROOT. > > I prefer the latter approach [snip] > finding the comp root is a bit complicated. The registry keys change > per version and their does not seem to be a pattern. This should be achievable in C++ inside a helper method called from EnableLanguage. There is no reason to have to use the CMake language to code it. > I'll let you know how things work out, after I implement the above. Great, thanks. -Brad This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Added-some-support-for-a-Green-Hills-MULTI.patch Type: application/octet-stream Size: 64665 bytes Desc: 0001-Added-some-support-for-a-Green-Hills-MULTI.patch URL: From neundorf at kde.org Wed Mar 11 15:21:57 2015 From: neundorf at kde.org (Alexander Neundorf) Date: Wed, 11 Mar 2015 20:21:57 +0100 Subject: [cmake-developers] Generating buildsystem metadata from CMake In-Reply-To: References: Message-ID: <2237969.q0muQAr2JF@tuxedo.neundorf.net> On Wednesday, March 11, 2015 11:10:30 Stephen Kelly wrote: > Hi, > > Following from the thread here: > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focu > s=12394 > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focu > s=12650 > > I'm starting to gather requirements and make sure the feature is > well designed to satisfy the needs we're already aware of, and fits with > the features CMake currently has. > > The aim is to generate a structured file containing metadata relating the > buildsystem. > > To help with completing the design of this feature, I've written > documentation (documentation driven design), and a unit test > containing a CMakeLists.txt file which exercises many modern CMake > features in the "generate-metadata" branch in my clone. > > Mostly the design I propose can be read in the documentation I wrote. I'm > interested in any feedback. > > https://gitorious.org/cmake/steveires-cmake/source/generate-metadata:Tests/ > Metadata/CMakeLists.txt > http://www.steveire.com/cmake-future/manual/cmake-metadata-generation.7.htm > l > > I expect to require a few iterations to figure out what the metadata files > should contain in the end. Note that there are already some differences > between my design and Aleix's implementation, such as that my design > proposes one metadata file per config. There are also some things > missing like location, because it is not yet clear to me whether build > or install locations are needed etc. > > The content of the metadata file is determined by the build properties, and > is necessarily similar to the compile-related content created when > generating the actual buildsystem. It additionally contains information > about the output locations of build artifacts and information relating to > the cmake description itself. > > Goals include: > > * Make it possible for IDEs to access the compile-related information for > autocompletion and code navigation etc purposes. > > * Remove the need for IDEs to parse generated Makefiles or Ninja files to > access compile-related information. The structure of those files is not > 'stable', while the content of the metadata file is stable. > http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/48412 > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus > =11081 > > * Remove the need for users to create a new build directory and new build > in order to use or switch IDEs. QtCreator requires that > the C::B 'extra generator is used as it parses compile information from > that. Other 'extra generators' such as for eclipse, sublime, kate etc > also require fresh/new build directories, although the actual buildsystem > they create is identical (assuming using all Makefile based or > all Ninja based 'extra generators') >From my POV, the json metadata is just another "extra generator", but one which can be always enabled additionally to other generators. You say that users don't need new build directories for switching IDEs, but this is only under the assumption that the different IDEs will actually start to use this new file format. See, users can use the C::B format and switch between CodeBlocks and QtCreator. If KDevelop and Kate would get plugins to read the C::B format (which is technically entirely possible) their users also would't have to create a new build directory. So instead of adding generators to cmake which generate what the IDEs expect, this is a change, now cmake will generate a file and the IDEs are expected to follow. My 2 cents Alex From mantis at public.kitware.com Wed Mar 11 16:17:26 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 11 Mar 2015 16:17:26 -0400 Subject: [cmake-developers] [CMake 0015441]: Xcode generator does not generate scheme Message-ID: <5342a131bac478c5d9cca3396b57ce44@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15441 ====================================================================== Reported By: Tom Hughes Assigned To: ====================================================================== Project: CMake Issue ID: 15441 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-11 16:17 EDT Last Modified: 2015-03-11 16:17 EDT ====================================================================== Summary: Xcode generator does not generate scheme Description: After generating an Xcode project with cmake, an xcode scheme is not created by cmake (https://developer.apple.com/library/ios/featuredarticles/XcodeConcepts/Concept-Schemes.html). When opening the project with Xcode, Xcode seems to automatically generate the scheme, but this makes it hard to use continuous integration to archive an iOS app using xcodebuild (archiving requires a scheme): xcodebuild -project generated_project.xcodeproj -configuration Release -scheme name_of_scheme archive ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-11 16:17 Tom Hughes New Issue ====================================================================== From roman.wueger at gmx.at Wed Mar 11 17:22:18 2015 From: roman.wueger at gmx.at (=?iso-8859-1?Q?Roman_W=FCger?=) Date: Wed, 11 Mar 2015 22:22:18 +0100 Subject: [cmake-developers] Problems with WriteCompilerDetectionHeader and cxx_nullptr Message-ID: <034401d05c41$7572ecc0$6058c640$@gmx.at> Hello, i tried to use the generated compiler detection header but get an error if I use the cxx_nullptr feature on a compiler which doesn?t support C++11. void doSomething(int n, bool *ok = 0) { if (ok) *ok = true; if (n != 0) { if (ok) *ok = false; } } This simple example produces the following error on Mac OS: error: cannot initialize a parameter of type 'bool *' with an rvalue of type 'void *' void doSomething(int n = 1, bool *ok = static_cast(0)) { ^ ~~~~~~~~~~~~~~~~~~~~~ However, if C++11 could be used then the ?nullptr? is working fine. Couldn?t ?static_cast(0)? simply be replaced with ?0?? Best Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjklaim at gmail.com Wed Mar 11 20:04:36 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Thu, 12 Mar 2015 01:04:36 +0100 Subject: [cmake-developers] Review request: FindTBB module In-Reply-To: <760431329.8616251.1396534879274.JavaMail.zimbra@phimeca.com> References: <55449383.8285824.1396511146242.JavaMail.zimbra@phimeca.com> <533D6317.4080807@kitware.com> <554041399.8571617.1396532317943.JavaMail.zimbra@phimeca.com> <760431329.8616251.1396534879274.JavaMail.zimbra@phimeca.com> Message-ID: ?Hi, did you manage to improve over the DaxToolkit FindTBB module? Thanks for your time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roman.wueger at gmx.at Thu Mar 12 06:59:50 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Thu, 12 Mar 2015 11:59:50 +0100 Subject: [cmake-developers] Problems with WriteCompilerDetectionHeader and cxx_nullptr Message-ID: Hello, I've attached a patch for this problem. Best Regards -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-WCDH-Fix-cxx_nullptr-for-compilers-which-doesn-t-sup 01.patch URL: -------------- next part -------------- From tobias.hunger at gmail.com Thu Mar 12 11:24:00 2015 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Thu, 12 Mar 2015 16:24:00 +0100 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: <54F76572.9000206@kitware.com> Message-ID: Hi Aleix, On Tue, Mar 10, 2015 at 1:25 AM, Aleix Pol wrote: > Thank you for taking some of your time. Thank you for doing the work:-) > On Sat, Mar 7, 2015 at 11:46 AM, Tobias Hunger wrote: >> How about adding some information on what this is you are actually >> building here? CMake has the PROJECT command that does provide quite a >> bit of information that could go here. > I can look into that, I can see if I can extract the projects tree > somehow and dispose them like it's doing with the targets. >> Where are the sources this thing here is building? How were those >> sources configured? CMake supports quite a few generators, so which >> ones where used? Do I need to run ninja or make to build this (or >> should I use "cmake build" anyway)? > The sources are listed within the targets, separately for each > configuration (as you can have different sources for debug builds and > release). No, which source directory was this created from? How was this build configured (e.g. which compiler is used, which Qt version does it link to, that kind of thing). For qmake projects you can point to some directories that you built when loading a project and that build is then imported into Qt Creator. That is rather convenient as it can save a lot of time rebuilding stuff just to make the IDE happy:-) For that we need to sanity check: Is this indeed a build-directory of the project we are opening? Which Kit (== configuration) was used to generate that build? > Regarding ninja/make, in KDevelop we just check if there's a > rules.ninja file or a Makefile. Alternatively you can also check the > CMAKE_GENERATOR value in the CMakeCache.txt. Or we can introduce it if > you find it useful. I don't have a strong opinion there. My -- maybe naive -- hope is that I can integrate cmake into an IDE *without looking outside this json-file*. I do not want to figure out which files are generated by which generators, how those are structured internally or under which set of conditions they may or may not be generated:-) Basically the less the IDE needs to know about the cmake implementation (outside of the IDE integration file) the more robust the support can be. >> Creator does allow existing qmake builds to be imported and that kind >> of information does help a lot with that functionality. >> >>> "dependencies" : >>> [ "/home/kde-devel/tmp/llvm/build/CMakeFiles/3.2.20150306-g139588/CMakeSystem.cmake", "/lots/more/files", ... ] What does that tell me? That file is even in the build directory, so it is most likely not the CMakeLists.txt you built. There are also more than one CMakeLists.txt in that file, so which one is "the one"? And there is no hint as to how the project is configured... That is probably available in CMakeCache.txt, but again, ideally I would not need to know about that file. >>> "configs" : >>> [ >>> { >>> "name" : "", >> >> Why is the name empty? > Because it was built without specifying any name. (i.e. it didn't pass > -DCMAKE_BUILD_TYPE=...). There is no default for CMAKE_BUILD_TYPE? >>> "sources" : [ "/list/of/cpp/files, ] >> >> Any way to also get the headers? Do you see any option to hint where >> new sources would need to be added to make them a part of this target? > I looked into how the CodeBlocks did it to provide the header files. > It's just brute-forcing to see if the file renamed to *.h/*.hpp/*.hxx > is present. > CMake doesn't have this kind of information, so I think it's better > that the IDE's do the hacky parts than cmake. A list of *all* headers used during the building of the target would be fine. There is no need to filter that list down in any way. CMake has that information: Without it cmake could not possibly know when a cpp file needs rebuilding. It would not be as successful a build system when it did not know that:-) > Also we don't really have information about where to put them. You can > use the minimum common denominator among the sources I guess. I don't understand that part, sorry. >> >>> } >>> ], >>> "installed" : "true", >> >> I guess this means "make install" will install it. Where will this file end up? > Yes. I tried to figure it out but didn't manage to find the correct > way to query it. I can try harder. :D > >> >>> "name" : "LLVMPowerPCInfo", >>> "output_directory" : "/home/kde-devel/tmp/llvm/build/lib/Target/PowerPC/TargetInfo", >> >> For what is the output directory relevant? The output above does >> implicitly list that already, doesn't it? > It's important in case the output path is overriden, see last e-mail > by Alexander Neundorf. > >> >>> "type" : "STATIC_LIBRARY" >> >> Which types are possible here? > It's an enum internal to cmake. At the moment: > EXECUTABLE, STATIC_LIBRARY, SHARED_LIBRARY, MODULE_LIBRARY, > OBJECT_LIBRARY, UTILITY, GLOBAL_TARGET, INTERFACE_LIBRARY, > UNKNOWN_LIBRARY. > >> >>> }, >> >> >> There is a lot of useful information here! Thanks for pushing into >> this direction. I am sure this will help a lot. >> >> Ideally this file would be enough to provide all information we need >> as an IDE to: >> >> * Present the project structure as seen by the build system. >> * Generate the code model >> * Build the project >> * Deploy the project >> * Run and debug parts of the project >> * Adding and removing files to a project >> >> For the project structure this does help: It provides us with a list >> of all the build targets, which is already nice. CMake does support >> more structure with Projects and subprojects IIRC and that information >> is lost. Would it be much work to get that information back? > as discussed above, I'll look into that next thing. I am a cmake noob, but maybe I can help? >> For the code model this is not much help at all: There is no >> information on compiler used, include directories nor Defines or >> compiler flags. Where am I supposed to get that information from? Do I >> need to generate and parse the list of commands run and extract that >> information from there? Having that information available right in the >> sources array of each target would be so much more convenient and >> would also make IDE integration so much easier: You would need to know >> about one file only and won't need to figure out several. > We can do that, I mentioned earlier in this thread that currently > we're using compile_commands.json for that ( > CMAKE_EXPORT_COMPILE_COMMANDS). > > I agree it could be interesting to add it. In other words, if nobody > disagrees, I'll add it although I see how this will make the output > grow a lot. I found parsing of compiler commands non-trivial: It gets messy when some file gets built twice, especially when different defines, etc. are set at the different times. E.g. once it is built with -DENABLE_TEST by some unit test and once it is built without any flags by the normal application. Best Regards, Tobias From tobias.hunger at gmail.com Thu Mar 12 11:31:17 2015 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Thu, 12 Mar 2015 16:31:17 +0100 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <20150311141507.GA2109@megas.kitwarein.com> References: <54F76572.9000206@kitware.com> <20150311141507.GA2109@megas.kitwarein.com> Message-ID: On Wed, Mar 11, 2015 at 3:15 PM, Ben Boeckel wrote: > On Tue, Mar 10, 2015 at 01:25:16 +0100, Aleix Pol wrote: >> >> "output" : "/home/kde-devel/tmp/llvm/build/lib/libLLVMPowerPCInfo.a", >> > >> > Can this be a list? >> It's 1 output per target, no? > > Not on Windows with .dll and .lib splits. So it needs to be a list:-) >> > Running/Debugging is a bit tricky again: All the information used for >> > linking the binaries is gone. So there is no way to figure out which >> > LD_LIBRARY_PATH needs to be set or anything. There also seems to be no >> > information where files are going to get installed to. Would it be >> > possible to add that information? >> I ignore it, on the other hand I'm quite a n00b when it comes to cmake >> codebase and internals. I'm sure if somebody knows where to get that >> information, he is reading this mailing list. (hello) > > CMake has options for RPATH for the relevant platforms. By default, > binaries have the RPATH set for the build tree. Relevant CMake target > properties (there are variables to set default values as well): > > - BUILD_WITH_INSTALL_RPATH > - SKIP_BUILD_RPATH > > Without SKIP_BUILD_RPATH set, LD_LIBRARY_PATH should not be necessary > for running targets. We try hard to have Creator "do the right thing", not "usually do the right thing". That may sound arrogant, but it is simply that we found that devs are highly suspicious folks: If something is not absolutely reliable they won't use it:-) Setting LD_LIBRARY_PATH will not hurt, even when unneeded, will it? So we should set it, just in case somebody tries to shoot himself into the foot by setting SKIP_BUILD_RPATH:-) Best Regards, Tobias From raffi.enficiaud at mines-paris.org Thu Mar 12 12:35:05 2015 From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud) Date: Thu, 12 Mar 2015 17:35:05 +0100 Subject: [cmake-developers] Introduction and volunteering for the Matlab package In-Reply-To: References: <54D128BE.9030109@kitware.com> <54D222A4.7090500@kitware.com> <2F7B25D2-7E72-44C1-B371-16F9399071BC@free.fr> <54DE0B41.5080000@kitware.com> <66AF3BFE-070C-4A57-BCBC-4184DB1EB387@free.fr> <54DE1A19.8050403@kitware.com> <54E49E02.5030105@kitware.com> <54E5F072.3090903@kitware.com> <06983E90-D75E-4335-8D02-1D40DF89B9C2@free.fr> <54EB694A.9030605@kitware.com> <7BCB5D1E-275E-43B2-B0FF-0ECEE0A78585@free.fr> <54EDCF04.2000909@kitware.com> <442BD016-E925-4186-9FBA-DA566C5C5886@free.fr> <54EF5D61.8010708@kitware.co m> <61974444-FEDF-4FE0-9FCE-2797CC7DE528@free.fr> <54EF82F9.4000305@kitware.com> <54FEF2E2.1000403@kitware.com> Message-ID: Le 11/03/15 00:12, Raffi Enficiaud a ?crit : > Hi Brad, > > Please find the attached patch addressing the issues. In the current > implementation, if the Matlab_ROOT_DIR is changed by the user, the > cached variables are all cleared. > Also, Matlab_ROOT_DIR is now the only variable that is seen as non > advanced. > > Best, > Raffi > Hi Brad, The attached patch replaces the previous one: now the versions on Windows are ordered starting the most recent (+ an ugly remaining FATAL_ERROR debug). Best, Raffi -------------- next part -------------- >From bca63b3669366d3d2db4438efe91c58d3a82fc40 Mon Sep 17 00:00:00 2001 From: Raffi Enficiaud Date: Thu, 12 Mar 2015 17:08:44 +0100 Subject: [PATCH] * Simplified workflow, better isolation of the code when Matlab is to be found from the PATH * Removing the "which matlab" as the find_program was erroneous * MATLAB_USER_ROOT renamed to Matlab_ROOT_DIR, which now reflects the found root, removed Matlab_ROOT * Reduced the number of find_program(matlab) * Nulled the input stream of the execute_process in order to avoid the troubleshooting with the terminal * Clearing all the cached variables in case the Matlab_ROOT_DIR is changed by the user * Marking all but Matlab_ROOT_DIR variable as advanced * Hiding all internal cache entries * Avoiding the computation of the version (Matlab_ROOT_DIR set) if the first pass produced the version automatically * Windows: now versions are ordered starting from the most recent --- Modules/FindMatlab.cmake | 490 ++++++++++++--------- Modules/MatlabTestsRedirect.cmake | 8 + Tests/FindMatlab/cmake_matlab_unit_tests_timeout.m | 3 +- Tests/RunCMake/CMakeLists.txt | 1 + 4 files changed, 289 insertions(+), 213 deletions(-) diff --git a/Modules/FindMatlab.cmake b/Modules/FindMatlab.cmake index 9686a76..b61c620 100644 --- a/Modules/FindMatlab.cmake +++ b/Modules/FindMatlab.cmake @@ -28,14 +28,15 @@ # :command:`matlab_get_release_name_from_version` allow a mapping # from the release name to the version. # -# The variable :variable:`MATLAB_USER_ROOT` may be specified in order to give +# The variable :variable:`Matlab_ROOT_DIR` may be specified in order to give # the path of the desired Matlab version. Otherwise, the behaviour is platform # specific: # # * Windows: The installed versions of Matlab are retrieved from the # Windows registry # * OS X: The installed versions of Matlab are given by the MATLAB -# paths in ``/Application`` +# paths in ``/Application``. If no such application is found, it falls back +# to the one that might be accessible from the PATH. # * Unix: The desired Matlab should be accessible from the PATH. # # Additional information is provided when :variable:`MATLAB_FIND_DEBUG` is set. @@ -59,7 +60,7 @@ # Users or projects may set the following variables to configure the module # behaviour: # -# :variable:`MATLAB_USER_ROOT` +# :variable:`Matlab_ROOT_DIR` # the root of the Matlab installation. # :variable:`MATLAB_FIND_DEBUG` # outputs debug information @@ -77,14 +78,15 @@ # ``TRUE`` if the Matlab installation is found, ``FALSE`` # otherwise. All variable below are defined if Matlab is found. # ``Matlab_ROOT_DIR`` -# the root of the Matlab installation determined by the FindMatlab module. +# the final root of the Matlab installation determined by the FindMatlab +# module. # ``Matlab_MAIN_PROGRAM`` # the Matlab binary program. Available only if the component ``MAIN_PROGRAM`` # is given in the :command:`find_package` directive. # ``Matlab_INCLUDE_DIRS`` # the path of the Matlab libraries headers # ``Matlab_MEX_LIBRARY`` -# library for mex +# library for mex, always available. # ``Matlab_MX_LIBRARY`` # mx library of Matlab (arrays). Available only if the component # ``MX_LIBRARY`` has been requested. @@ -102,6 +104,9 @@ # # ``Matlab_MEX_EXTENSION`` # the extension of the mex files for the current platform (given by Matlab). +# ``Matlab_ROOT_DIR`` +# the location of the root of the Matlab installation found. If this value +# is changed by the user, the result variables are recomputed. # # Provided macros # --------------- @@ -162,10 +167,11 @@ # Reference # -------------- # -# .. variable:: MATLAB_USER_ROOT +# .. variable:: Matlab_ROOT_DIR # -# The root folder of the Matlab installation. This is set before the call to -# :command:`find_package`. If not set, then an automatic search of Matlab +# The root folder of the Matlab installation. If set before the call to +# :command:`find_package`, the module will look for the components in that +# path. If not set, then an automatic search of Matlab # will be performed. If set, it should point to a valid version of Matlab. # # .. variable:: MATLAB_FIND_DEBUG @@ -176,7 +182,6 @@ # .. variable:: MATLAB_ADDITIONAL_VERSIONS # # If set, specifies additional versions of Matlab that may be looked for. -# This variable will be used if :variable:`MATLAB_USER_ROOT` is not set. # The variable should be a list of strings, organised by pairs of release # name and versions, such as follows:: # @@ -192,6 +197,10 @@ # "R2013b=8.2" # "R2013a=8.1" # "R2012b=8.0") +# +# The order of entries in this list matters when several versions of +# Matlab are installed. The priority is set according to the ordering in +# this list. #============================================================================= # Copyright 2014-2015 Raffi Enficiaud, Max Planck Society @@ -254,6 +263,7 @@ macro (matlab_get_version_from_release_name release_name version_name) else() message(WARNING "The release name ${release_name} is not registered") endif() + unset(_matched) endmacro() @@ -356,8 +366,8 @@ function(matlab_extract_all_installed_versions_from_registry win64 matlab_versio RESULT_VARIABLE resultMatlab OUTPUT_VARIABLE varMatlab ERROR_VARIABLE errMatlab + INPUT_FILE NUL ) - #message("Matlabs = ${varMatlab} | ${resultMatlab}") set(matlabs_from_registry) @@ -384,6 +394,10 @@ function(matlab_extract_all_installed_versions_from_registry win64 matlab_versio endforeach(match) endif() + + list(REMOVE_DUPLICATES matlabs_from_registry) + list(SORT matlabs_from_registry) + list(REVERSE matlabs_from_registry) set(${matlab_versions} ${matlabs_from_registry} PARENT_SCOPE) @@ -508,7 +522,7 @@ function(matlab_get_mex_suffix matlab_root mex_suffix) # we first try without suffix, since cmake does not understand a list with # one empty string element find_program( - MATLAB_MEXEXTENSIONS_PROG + Matlab_MEXEXTENSIONS_PROG NAMES mexext PATHS ${matlab_root}/bin DOC "Matlab MEX extension provider" @@ -516,10 +530,10 @@ function(matlab_get_mex_suffix matlab_root mex_suffix) ) foreach(current_mexext_suffix IN LISTS mexext_suffix) - if(NOT DEFINED MATLAB_MEXEXTENSIONS_PROG OR NOT MATLAB_MEXEXTENSIONS_PROG) + if(NOT DEFINED Matlab_MEXEXTENSIONS_PROG OR NOT Matlab_MEXEXTENSIONS_PROG) # this call should populate the cache automatically find_program( - MATLAB_MEXEXTENSIONS_PROG + Matlab_MEXEXTENSIONS_PROG "mexext${current_mexext_suffix}" PATHS ${matlab_root}/bin DOC "Matlab MEX extension provider" @@ -530,22 +544,31 @@ function(matlab_get_mex_suffix matlab_root mex_suffix) # the program has been found? - if((NOT MATLAB_MEXEXTENSIONS_PROG) OR (NOT EXISTS ${MATLAB_MEXEXTENSIONS_PROG})) + if((NOT Matlab_MEXEXTENSIONS_PROG) OR (NOT EXISTS ${Matlab_MEXEXTENSIONS_PROG})) if(MATLAB_FIND_DEBUG) message(WARNING "[MATLAB] Cannot found mexext program. Matlab root is ${matlab_root}") endif() + unset(Matlab_MEXEXTENSIONS_PROG CACHE) return() endif() set(_matlab_mex_extension) + set(devnull) + if(UNIX) + set(devnull INPUT_FILE /dev/null) + elseif(WIN32) + set(devnull INPUT_FILE NUL) + endif() execute_process( - COMMAND ${MATLAB_MEXEXTENSIONS_PROG} + COMMAND ${Matlab_MEXEXTENSIONS_PROG} OUTPUT_VARIABLE _matlab_mex_extension - ERROR_VARIABLE _matlab_mex_extension_error) + ERROR_VARIABLE _matlab_mex_extension_error + ${devnull}) string(STRIP ${_matlab_mex_extension} _matlab_mex_extension) + unset(Matlab_MEXEXTENSIONS_PROG CACHE) set(${mex_suffix} ${_matlab_mex_extension} PARENT_SCOPE) endfunction() @@ -592,6 +615,13 @@ function(matlab_get_version_from_matlab_run matlab_binary_program matlab_list_ve if(WIN32) set(_matlab_additional_commands "-wait") endif() + + set(devnull) + if(UNIX) + set(devnull INPUT_FILE /dev/null) + elseif(WIN32) + set(devnull INPUT_FILE NUL) + endif() # timeout set to 30 seconds, in case it does not start # note as said before OUTPUT_VARIABLE cannot be used in a platform @@ -604,6 +634,7 @@ function(matlab_get_version_from_matlab_run matlab_binary_program matlab_list_ve ERROR_VARIABLE _matlab_result_version_call_error TIMEOUT 30 WORKING_DIRECTORY "${_matlab_temporary_folder}" + ${devnull} ) @@ -918,245 +949,286 @@ function(matlab_add_mex ) endfunction() +# (internal) +# Used to get the version of matlab, using caching. This basically transforms the +# output of the root list, with possible unknown version, to a version +# +function(_Matlab_get_version_from_root matlab_root matlab_known_version matlab_final_version) + + # if the version is not trivial, we query matlab for that + # we keep track of the location of matlab that induced this version + #if(NOT DEFINED Matlab_PROG_VERSION_STRING_AUTO_DETECT) + # set(Matlab_PROG_VERSION_STRING_AUTO_DETECT "" CACHE INTERNAL "internal matlab location for the discovered version") + #endif() + + if(NOT ${matlab_known_version} STREQUAL "NOTFOUND") + # the version is known, we just return it + set(${matlab_final_version} ${matlab_known_version} PARENT_SCOPE) + set(Matlab_VERSION_STRING_INTERNAL ${matlab_known_version} CACHE INTERNAL "Matlab version (automatically determined)" FORCE) + return() + endif() + # + set(_matlab_current_program ${Matlab_MAIN_PROGRAM}) + + # do we already have a matlab program? + if(NOT _matlab_current_program) + + set(_find_matlab_options) + if(matlab_root AND EXISTS ${matlab_root}) + set(_find_matlab_options PATHS ${matlab_root} ${matlab_root}/bin NO_DEFAULT_PATH) + endif() + + find_program( + _matlab_current_program + matlab + ${_find_matlab_options} + DOC "Matlab main program" + ) + endif() + if(NOT _matlab_current_program OR NOT EXISTS ${_matlab_current_program}) + # if not found, clear the dependent variables + if(MATLAB_FIND_DEBUG) + message(WARNING "[MATLAB] Cannot find the main matlab program under ${matlab_root}") + endif() + set(Matlab_PROG_VERSION_STRING_AUTO_DETECT "" CACHE INTERNAL "internal matlab location for the discovered version" FORCE) + set(Matlab_VERSION_STRING_INTERNAL "" CACHE INTERNAL "internal matlab location for the discovered version" FORCE) + unset(_matlab_current_program) + unset(_matlab_current_program CACHE) + return() + endif() + # full real path for path comparison + get_filename_component(_matlab_main_real_path_tmp "${_matlab_current_program}" REALPATH) + unset(_matlab_current_program) + unset(_matlab_current_program CACHE) + # is it the same as the previous one? + if(_matlab_main_real_path_tmp STREQUAL Matlab_PROG_VERSION_STRING_AUTO_DETECT) + set(${matlab_final_version} ${Matlab_VERSION_STRING_INTERNAL} PARENT_SCOPE) + return() + endif() + # update the location of the program + set(Matlab_PROG_VERSION_STRING_AUTO_DETECT ${_matlab_main_real_path_tmp} CACHE INTERNAL "internal matlab location for the discovered version" FORCE) + + set(matlab_list_of_all_versions) + matlab_get_version_from_matlab_run("${Matlab_PROG_VERSION_STRING_AUTO_DETECT}" matlab_list_of_all_versions) + + list(GET matlab_list_of_all_versions 0 _matlab_version_tmp) + + # set the version into the cache + set(Matlab_VERSION_STRING_INTERNAL ${_matlab_version_tmp} CACHE INTERNAL "Matlab version (automatically determined)" FORCE) + + # warning, just in case several versions found (should not happen) + list(LENGTH matlab_list_of_all_versions list_of_all_versions_length) + if((${list_of_all_versions_length} GREATER 1) AND MATLAB_FIND_DEBUG) + message(WARNING "[MATLAB] Found several versions, taking the first one (versions found ${matlab_list_of_all_versions})") + endif() + + # return the updated value + set(${matlab_final_version} ${Matlab_VERSION_STRING_INTERNAL} PARENT_SCOPE) -# this variable will get all Matlab installations found in the current system. -set(_matlab_possible_roots) - - -# listing the Matlab versions installed on the WIN machine if MATLAB_USER_ROOT -# is not set -if(WIN32) +endfunction() + + - # for windows - if(NOT MATLAB_USER_ROOT) - # if MATLAB_USER_ROOT not specified, we look for Matlab installation in - # the registry - # if unsuccessful, we look for all known revision and filter the existing - # ones. - # testing if we are able to extract the needed information from the registry - set(matlab_versions_from_registry) - matlab_extract_all_installed_versions_from_registry(CMAKE_CL_64 matlab_versions_from_registry) - # the returned list is empty, doing the search on all known versions - if(NOT matlab_versions_from_registry) - - if(MATLAB_FIND_DEBUG) - message(STATUS "[MATLAB] Search for Matlab from the registry unsuccessful, testing all supported versions") - endif() - - extract_matlab_versions_from_registry_brute_force(matlab_versions_from_registry) - endif() - - # filtering the results with the registry keys - matlab_get_all_valid_matlab_roots_from_registry("${matlab_versions_from_registry}" _matlab_possible_roots) +# ################################### +# Exploring the possible Matlab_ROOTS +# this variable will get all Matlab installations found in the current system. +set(_matlab_possible_roots) - elseif(NOT EXISTS ${MATLAB_USER_ROOT}) - # if MATLAB_USER_ROOT specified but erroneous +if(Matlab_ROOT_DIR) + # if the user specifies a possible root, we keep this one + + if(NOT EXISTS ${Matlab_ROOT_DIR}) + # if Matlab_ROOT_DIR specified but erroneous if(MATLAB_FIND_DEBUG) - message(WARNING "[MATLAB] the specified path for MATLAB_USER_ROOT does not exist (${MATLAB_USER_ROOT})") + message(WARNING "[MATLAB] the specified path for Matlab_ROOT_DIR does not exist (${Matlab_ROOT_DIR})") endif() else() - list(APPEND _matlab_possible_roots "NOTFOUND" ${MATLAB_USER_ROOT}) # empty version + # NOTFOUND indicates the code below to search for the version automatically + if(NOT DEFINED Matlab_VERSION_STRING_INTERNAL) + list(APPEND _matlab_possible_roots "NOTFOUND" ${Matlab_ROOT_DIR}) # empty version + else() + list(APPEND _matlab_possible_roots ${Matlab_VERSION_STRING_INTERNAL} ${Matlab_ROOT_DIR}) # cached version + endif() endif() else() - # for linux/osx + + # if the user does not specify the possible installation root, we look for + # one installation using the appropriate heuristics - if(NOT MATLAB_USER_ROOT) - - # if MATLAB_USER_ROOT not specified, we look for Matlab from the command - # line PATH - # maybe using CMAKE_PROGRAM_PATH to add some more hints + if(WIN32) - set(_matlab_main_tmp "") - if(Matlab_MAIN_PROGRAM) - set(_matlab_main_tmp ${Matlab_MAIN_PROGRAM}) - endif() + # On WIN32, we look for Matlab installation in the registry + # if unsuccessful, we look for all known revision and filter the existing + # ones. - if(NOT _matlab_main_tmp) + # testing if we are able to extract the needed information from the registry + set(_matlab_versions_from_registry) + matlab_extract_all_installed_versions_from_registry(CMAKE_CL_64 _matlab_versions_from_registry) - find_program( - _matlab_main_tmp - NAMES matlab) - - if(NOT _matlab_main_tmp) - execute_process( - COMMAND "which" matlab - OUTPUT_VARIABLE _matlab_main_tmp - ERROR_VARIABLE _matlab_main_tmp_err) - # the output should be cleaned up - string(STRIP "${_matlab_main_tmp}" _matlab_main_tmp) - endif() + # the returned list is empty, doing the search on all known versions + if(NOT _matlab_versions_from_registry) - if(EXISTS ${_matlab_main_tmp}) - if(MATLAB_FIND_DEBUG) - message(STATUS "[MATLAB] matlab found from PATH: ${_matlab_main_tmp}") - endif() - else() - # found candidate is not good, we remove it - unset(_matlab_main_tmp) - unset(_matlab_main_tmp CACHE) + if(MATLAB_FIND_DEBUG) + message(STATUS "[MATLAB] Search for Matlab from the registry unsuccessful, testing all supported versions") endif() - endif() # if(NOT _matlab_main_tmp) - - if(_matlab_main_tmp AND EXISTS ${_matlab_main_tmp}) - # resolve symlinks - get_filename_component(_matlab_current_location "${_matlab_main_tmp}" REALPATH) - set(_directory_alias DIRECTORY) - - # get the directory (the command below has to be run twice) - get_filename_component(_matlab_current_location "${_matlab_current_location}" ${_directory_alias}) - get_filename_component(_matlab_current_location "${_matlab_current_location}" ${_directory_alias}) # Matlab should be in bin - list(APPEND _matlab_possible_roots "NOTFOUND" ${_matlab_current_location}) # empty version + extract_matlab_versions_from_registry_brute_force(_matlab_versions_from_registry) endif() + # filtering the results with the registry keys + matlab_get_all_valid_matlab_roots_from_registry("${_matlab_versions_from_registry}" _matlab_possible_roots) + unset(_matlab_versions_from_registry) + elseif(APPLE) + # on mac, we look for the /Application paths # this corresponds to the behaviour on Windows. On Linux, we do not have # any other guess. - if((NOT _matlab_possible_roots) AND APPLE) + matlab_get_supported_releases(_matlab_releases) + if(MATLAB_FIND_DEBUG) + message(STATUS "[MATLAB] Matlab supported versions ${_matlab_releases}. If more version should be supported " + "the variable MATLAB_ADDITIONAL_VERSIONS can be set according to the documentation") + endif() - matlab_get_supported_releases(_matlab_releases) - if(MATLAB_FIND_DEBUG) - message(STATUS "[MATLAB] Matlab supported versions ${_matlab_releases}. If more version should be supported " - "the variable MATLAB_ADDITIONAL_VERSIONS can be set according to the documentation") + foreach(_matlab_current_release IN LISTS _matlab_releases) + set(_matlab_full_string "/Applications/MATLAB_${_matlab_current_release}.app") + if(EXISTS ${_matlab_full_string}) + set(_matlab_current_version) + matlab_get_version_from_release_name("${_matlab_current_release}" _matlab_current_version) + if(MATLAB_FIND_DEBUG) + message(STATUS "[MATLAB] Found version ${_matlab_current_release} (${_matlab_current_version}) in ${_matlab_full_string}") + endif() + list(APPEND _matlab_possible_roots ${_matlab_current_version} ${_matlab_full_string}) + unset(_matlab_current_version) endif() - foreach(_matlab_current_release IN LISTS _matlab_releases) - set(_matlab_full_string "/Applications/MATLAB_${_matlab_current_release}.app") - if(EXISTS ${_matlab_full_string}) - set(_matlab_current_version) - matlab_get_version_from_release_name("${_matlab_current_release}" _matlab_current_version) - if(MATLAB_FIND_DEBUG) - message(STATUS "[MATLAB] Found version ${_matlab_current_release} (${_matlab_current_version}) in ${_matlab_full_string}") - endif() - list(APPEND _matlab_possible_roots ${_matlab_current_version}) - list(APPEND _matlab_possible_roots ${_matlab_full_string}) - unset(_matlab_current_version) - endif() + unset(_matlab_full_string) + endforeach(_matlab_current_release) + + unset(_matlab_current_release) + unset(_matlab_releases) + + endif() - unset(_matlab_full_string) - endforeach(_matlab_current_release) - unset(_matlab_current_release) - unset(_matlab_releases) - endif() +endif() - # we need to clear _matlab_main_tmp here - unset(_matlab_main_tmp CACHE) - unset(_matlab_main_tmp) - elseif(NOT EXISTS ${MATLAB_USER_ROOT}) - # if MATLAB_USER_ROOT specified but erroneous + +list(LENGTH _matlab_possible_roots _numbers_of_matlab_roots) +if(_numbers_of_matlab_roots EQUAL 0) + # if we have not found anything, we fall back on the PATH + + + # At this point, we have no other choice than trying to find it from PATH. + # If set by the user, this wont change + find_program( + _matlab_main_tmp + NAMES matlab) + + + if(_matlab_main_tmp) + # we then populate the list of roots, with empty version if(MATLAB_FIND_DEBUG) - message(WARNING "[MATLAB] the specified path for MATLAB_USER_ROOT does not exist (${MATLAB_USER_ROOT})") + message(STATUS "[MATLAB] matlab found from PATH: ${_matlab_main_tmp}") endif() - else() - list(APPEND _matlab_possible_roots "NOTFOUND" ${MATLAB_USER_ROOT}) # empty version + + # resolve symlinks + get_filename_component(_matlab_current_location "${_matlab_main_tmp}" REALPATH) + + # get the directory (the command below has to be run twice) + # this will be the matlab root + get_filename_component(_matlab_current_location "${_matlab_current_location}" DIRECTORY) + get_filename_component(_matlab_current_location "${_matlab_current_location}" DIRECTORY) # Matlab should be in bin + + list(APPEND _matlab_possible_roots "NOTFOUND" ${_matlab_current_location}) + + unset(_matlab_current_location) + endif() + unset(_matlab_main_tmp CACHE) + endif() + + + if(MATLAB_FIND_DEBUG) message(STATUS "[MATLAB] Matlab root folders are ${_matlab_possible_roots}") endif() -if(DEFINED Matlab_ROOT_DIR) - unset(Matlab_ROOT_DIR) -endif() + # take the first possible Matlab root -if(_matlab_possible_roots) +list(LENGTH _matlab_possible_roots _numbers_of_matlab_roots) +set(Matlab_VERSION_STRING "NOTFOUND") +if(_numbers_of_matlab_roots GREATER 0) list(GET _matlab_possible_roots 0 Matlab_VERSION_STRING) list(GET _matlab_possible_roots 1 Matlab_ROOT_DIR) - list(LENGTH _matlab_possible_roots numbers_of_matlab_roots) # adding a warning in case of ambiguity - if(numbers_of_matlab_roots GREATER 2 AND MATLAB_FIND_DEBUG) + if(_numbers_of_matlab_roots GREATER 2 AND MATLAB_FIND_DEBUG) message(WARNING "[MATLAB] Found several distributions of Matlab. Setting the current version to ${Matlab_VERSION_STRING} (located ${Matlab_ROOT_DIR})." " If this is not the desired behaviour, provide the -DMATLAB_USER_ROOT on the command line") endif() endif() -if((NOT (DEFINED Matlab_VERSION_STRING)) OR (NOT Matlab_VERSION_STRING)) - set(Matlab_VERSION_STRING "NOTFOUND") -endif() - - - -# if the version is not trivial, we query matlab for that -# we keep track of the location of matlab that induced this version -set(Matlab_VERSION_STRING_AUTO_DETECT "" CACHE INTERNAL "internal matlab location for the discovered version") - -set(_matlab_version_should_be_recomputed FALSE) -if(${Matlab_VERSION_STRING} STREQUAL "NOTFOUND") - set(_matlab_version_should_be_recomputed TRUE) -elseif((NOT Matlab_MAIN_PROGRAM) OR (NOT EXISTS ${Matlab_MAIN_PROGRAM})) - set(_matlab_version_should_be_recomputed TRUE) -else() - # just in case the variable is modified to a symlink - get_filename_component(_matlab_main_tmp "${Matlab_MAIN_PROGRAM}" REALPATH) - if(NOT (_matlab_main_tmp STREQUAL Matlab_VERSION_STRING_AUTO_DETECT)) - set(_matlab_version_should_be_recomputed TRUE) +# check if the root changed against the previous defined one, if so +# clear all the cached variables +if(DEFINED Matlab_ROOT_DIR_LAST_CACHED) + + if(NOT Matlab_ROOT_DIR_LAST_CACHED STREQUAL Matlab_ROOT_DIR) + set(_Matlab_cached_vars + Matlab_INCLUDE_DIRS + Matlab_MEX_LIBRARY + Matlab_MEX_COMPILER + Matlab_MAIN_PROGRAM + Matlab_MX_LIBRARY + Matlab_ENG_LIBRARY + Matlab_MEX_EXTENSION + + # internal + Matlab_MEXEXTENSIONS_PROG + Matlab_ROOT_DIR_LAST_CACHED + #Matlab_PROG_VERSION_STRING_AUTO_DETECT + Matlab_VERSION_STRING_INTERNAL + ) + foreach(_var IN LISTS _Matlab_cached_vars) + if(DEFINED ${_var}) + unset(${_var} CACHE) + endif() + endforeach() endif() endif() -if(_matlab_version_should_be_recomputed) - if(MATLAB_FIND_DEBUG) - message(STATUS "[MATLAB] querying for version from Matlab root = ${Matlab_ROOT_DIR}") - endif() - - if(Matlab_MAIN_PROGRAM) - set(_matlab_main_tmp ${Matlab_MAIN_PROGRAM}) - else() - find_program( - _matlab_main_tmp - matlab - PATHS ${Matlab_ROOT_DIR} ${Matlab_ROOT_DIR}/bin - DOC "Matlab main program" - NO_DEFAULT_PATH - ) - endif() +set(Matlab_ROOT_DIR_LAST_CACHED ${Matlab_ROOT_DIR} CACHE INTERNAL "last Matlab root dir location") +set(Matlab_ROOT_DIR ${Matlab_ROOT_DIR} CACHE PATH "Matlab installation root path" FORCE) - if(_matlab_main_tmp) - set(matlab_list_of_all_versions) - matlab_get_version_from_matlab_run("${_matlab_main_tmp}" matlab_list_of_all_versions) +# Fix the version, in case this one is NOTFOUND +_Matlab_get_version_from_root( + "${Matlab_ROOT_DIR}" + ${Matlab_VERSION_STRING} + Matlab_VERSION_STRING +) - list(GET matlab_list_of_all_versions 0 MATLAB_VERSION_tmp) - # set the version into the cache - set(Matlab_VERSION_STRING ${MATLAB_VERSION_tmp} CACHE INTERNAL "Matlab version (automatically determined)" FORCE) - list(LENGTH list_of_all_versions list_of_all_versions_length) - if((${list_of_all_versions_length} GREATER 1) AND MATLAB_FIND_DEBUG) - message(WARNING "[MATLAB] Found several versions, taking the first one (versions found ${list_of_all_versions})") - endif() - - # update the location of Matlab that produced this value - # we store the real path for comparison - get_filename_component(_matlab_main_tmp1 "${_matlab_main_tmp}" REALPATH) - set(Matlab_VERSION_STRING_AUTO_DETECT ${_matlab_main_tmp1} CACHE INTERNAL "internal matlab location for the discovered version" FORCE) - - # these are internal variables - unset(_matlab_main_tmp) - unset(_matlab_main_tmp CACHE) - unset(_matlab_main_tmp1) - endif() -endif() if(MATLAB_FIND_DEBUG) @@ -1289,16 +1361,15 @@ unset(_matlab_find_mex_compiler) # component Matlab program list(FIND Matlab_FIND_COMPONENTS MAIN_PROGRAM _matlab_find_matlab_program) if(_matlab_find_matlab_program GREATER -1) - # todo cleanup with code above - if(NOT DEFINED Matlab_MAIN_PROGRAM) - find_program( - Matlab_MAIN_PROGRAM - matlab - PATHS ${Matlab_ROOT_DIR} ${Matlab_ROOT_DIR}/bin - DOC "Matlab main program" - NO_DEFAULT_PATH - ) - endif() + + find_program( + Matlab_MAIN_PROGRAM + matlab + PATHS ${Matlab_ROOT_DIR} ${Matlab_ROOT_DIR}/bin + DOC "Matlab main program" + NO_DEFAULT_PATH + ) + if(Matlab_MAIN_PROGRAM) set(Matlab_MAIN_PROGRAM_FOUND TRUE) endif() @@ -1349,19 +1420,13 @@ unset(_matlab_lib_dir_for_search) set(Matlab_LIBRARIES ${Matlab_MEX_LIBRARY} ${Matlab_MX_LIBRARY} ${Matlab_ENG_LIBRARY}) -if(CMAKE_VERSION VERSION_LESS "2.8.11") - find_package_handle_standard_args( - Matlab - REQUIRED_VARS ${_matlab_required_variables} - VERSION_VAR Matlab_VERSION_STRING) -else() - find_package_handle_standard_args( - Matlab - FOUND_VAR Matlab_FOUND - REQUIRED_VARS ${_matlab_required_variables} #MATLAB_REQUIRED_PROGRAMS MATLAB_REQUIRED_LIBRARIES MATLAB_REQUIRED_INCLUDE_DIRS - VERSION_VAR Matlab_VERSION_STRING - HANDLE_COMPONENTS) -endif() + +find_package_handle_standard_args( + Matlab + FOUND_VAR Matlab_FOUND + REQUIRED_VARS ${_matlab_required_variables} + VERSION_VAR Matlab_VERSION_STRING + HANDLE_COMPONENTS) unset(_matlab_required_variables) unset(_matlab_bin_prefix) @@ -1373,17 +1438,18 @@ unset(_matlab_lib_prefix_for_search) if(Matlab_INCLUDE_DIRS AND Matlab_LIBRARIES) mark_as_advanced( - Matlab_LIBRARIES + #Matlab_LIBRARIES Matlab_MEX_LIBRARY Matlab_MX_LIBRARY Matlab_ENG_LIBRARY Matlab_INCLUDE_DIRS Matlab_FOUND - MATLAB_USER_ROOT - Matlab_ROOT_DIR - Matlab_VERSION_STRING + #Matlab_ROOT_DIR + #Matlab_VERSION_STRING Matlab_MAIN_PROGRAM + #Matlab_MEX_EXTENSION + Matlab_MEXEXTENSIONS_PROG Matlab_MEX_EXTENSION - Matlab_BINARIES_DIR + #Matlab_BINARIES_DIR ) endif() diff --git a/Modules/MatlabTestsRedirect.cmake b/Modules/MatlabTestsRedirect.cmake index 804101c..ebccbf6 100644 --- a/Modules/MatlabTestsRedirect.cmake +++ b/Modules/MatlabTestsRedirect.cmake @@ -62,12 +62,20 @@ set(Matlab_SCRIPT_TO_RUN set(Matlab_LOG_FILE "${output_directory}/${test_name}.log") +set(devnull) +if(UNIX) + set(devnull INPUT_FILE /dev/null) +elseif(WIN32) + set(devnull INPUT_FILE NUL) +endif() + execute_process( COMMAND "${Matlab_PROGRAM}" ${Matlab_UNIT_TESTS_CMD} -logfile "${test_name}.log" -r "${Matlab_SCRIPT_TO_RUN}" RESULT_VARIABLE res TIMEOUT ${test_timeout} OUTPUT_QUIET # we do not want the output twice WORKING_DIRECTORY "${output_directory}" + ${devnull} ) if(NOT EXISTS ${Matlab_LOG_FILE}) diff --git a/Tests/FindMatlab/cmake_matlab_unit_tests_timeout.m b/Tests/FindMatlab/cmake_matlab_unit_tests_timeout.m index 66be1bb..11d5e9e 100644 --- a/Tests/FindMatlab/cmake_matlab_unit_tests_timeout.m +++ b/Tests/FindMatlab/cmake_matlab_unit_tests_timeout.m @@ -9,7 +9,8 @@ classdef cmake_matlab_unit_tests_timeout < matlab.unittest.TestCase function testCallHangsShouldBeTimedOut(testCase) cmake_matlab_mex1(rand(3,3)); disp('Will now wait.'); - input('Testing the cmake Matlab package timeout - do not press anything'); + disp('Testing the cmake Matlab package timeout - do not kill'); + pause(20); % supposed to be killed after 15s end end end diff --git a/Tests/RunCMake/CMakeLists.txt b/Tests/RunCMake/CMakeLists.txt index 7715f1c..5f1471e 100644 --- a/Tests/RunCMake/CMakeLists.txt +++ b/Tests/RunCMake/CMakeLists.txt @@ -203,3 +203,4 @@ endif() if(CMake_TEST_FindMatlab) add_RunCMake_test(FindMatlab) endif() + -- 2.0.1 From brad.king at kitware.com Thu Mar 12 16:00:33 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 12 Mar 2015 16:00:33 -0400 Subject: [cmake-developers] Introduction and volunteering for the Matlab package In-Reply-To: References: <54D222A4.7090500@kitware.com> <2F7B25D2-7E72-44C1-B371-16F9399071BC@free.fr> <54DE0B41.5080000@kitware.com> <66AF3BFE-070C-4A57-BCBC-4184DB1EB387@free.fr> <54DE1A19.8050403@kitware.com> <54E49E02.5030105@kitware.com> <54E5F072.3090903@kitware.com> <06983E90-D75E-4335-8D02-1D40DF89B9C2@free.fr> <54EB694A.9030605@kitware.com> <7BCB5D1E-275E-43B2-B0FF-0ECEE0A78585@free.fr> <54EDCF04.2000909@kitware.com> <442BD016-E925-4186-9FBA-DA566C5C5886@free.fr> <54EF5D61.8010708@kitware.co m> <61974444-FEDF-4FE0-9FCE-2797CC7DE528@free.fr> <54EF82F9.4000305@kitware.com> <54FEF2E2.1000403@kitware.com> Message-ID: <5501F061.2050401@kitware.com> On 03/12/2015 12:35 PM, Raffi Enficiaud wrote: >> Please find the attached patch addressing the issues. In the current >> implementation, if the Matlab_ROOT_DIR is changed by the user, the >> cached variables are all cleared. >> Also, Matlab_ROOT_DIR is now the only variable that is seen as non >> advanced. > > The attached patch replaces the previous one: now the versions on > Windows are ordered starting the most recent (+ an ugly remaining > FATAL_ERROR debug). Great. I applied that on top of where we last left off and then rebased on 'master' to resolve conflicts. I also made a couple minor tweaks: * Renamed one more MATLAB_USER_ROOT => Matlab_ROOT_DIR * Do not call list(REMOVE_DUPLICATES/SORT/REVERSE) with no list The commits are now: FindMatlab: Rewrite module and provide a usage API http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3c025a5f FindMatlab: Further revisions http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=842ab109 FindMatlab: Further revisions http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3743aa11 I will squash all this together once everything is done. For now please base further work on commit 3743aa11. We'll see how this does on the nightly testing! Thanks, -Brad From brad.king at kitware.com Thu Mar 12 16:18:15 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 12 Mar 2015 16:18:15 -0400 Subject: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support In-Reply-To: References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com> <54D129E3.60101@kitware.com> <54E365F4.3030104@kitware.com> <54E7542D.6050808@kitware.com> <54EB68C8.7030504@kitware.com> <54F0952B.5070809@kitware.com> <54F4781A.80708@kitware.com> <54FEF1C1.4030106@kitware.com> Message-ID: <5501F487.10807@kitware.com> On 03/11/2015 01:39 PM, Geoffrey Viola wrote: > Attached is a patch with the recommended changes Thanks! The basic toolchain initialization is pretty close. Here are more comments. In Modules/Platform/GHS-MULTI-Initialize.cmake: > +#Setup consistent compiler executables > +find_program(CMAKE_GENERATOR_CC ccarm PATHS ${GHS_COMP_ROOT}) > +find_program(CMAKE_GENERATOR_CXX cxarm PATHS ${GHS_COMP_ROOT}) This should not be needed at all. The CMAKE_GENERATOR_* variables are just hints to the compiler detection logic. Since this generator hard-codes the compiler setting in C++ the logic that uses these variables is never executed anyway. > +string(REGEX MATCH "(comp_)([0-9]+)" CMAKE_SYSTEM_VERSION "${CMAKE_MAKE_PROGRAM}") > +string(REPLACE "comp_" "" CMAKE_SYSTEM_VERSION "${CMAKE_SYSTEM_VERSION}") EnableLanguage should be able to set CMAKE_SYSTEM_VERSION too now that it has code to find the comp root. > +mark_as_advanced(CMAKE_MAKE_PROGRAM) This should not be needed. > +include(Platform/WindowsPaths) This should move to Modules/Platform/GHS-MULTI.cmake In EnableLanguage: > + mf->AddDefinition("CMAKE_MAKE_PROGRAM", > + std::string(ghsCompRootStart + "gbuild.exe").c_str()); The VS and Xcode generators no longer put this in the cache. Take a look at how the Xcode generator now does this with cmGlobalXCodeGenerator::FindMakeProgram cmGlobalXCodeGenerator::GetXcodeBuildCommand cmGlobalXCodeGenerator::FindXcodeBuildCommand and its call to SelectMakeProgram in GenerateBuildCommand: this->SelectMakeProgram(makeProgram, this->GetXcodeBuildCommand()) Together this all allows the generator to compute the proper build tool without exposing any settings to the user. > + mf->AddDefinition("CMAKE_C_COMPILER_ID", "GhsMultiArmC"); [snip] > + mf->AddDefinition("CMAKE_CXX_COMPILER_ID", "GhsMultiArmCXX"); Instead of "GhsMultiArm*" these should be just "GHS", to be consistent with "Modules/Compiler/GHS-DetermineCompiler.cmake". ----------------------------------------------------------------- Please also look at modifying the Help/ directory to document the new generator. You'll need at least to create/update: Help/manual/cmake-generators.7.rst Help/generator/Green Hills MULTI.rst Help/variable/CMAKE_MAKE_PROGRAM.rst where the change to the last one depends on the above updates. Thanks, -Brad From brad.king at kitware.com Thu Mar 12 16:19:44 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 12 Mar 2015 16:19:44 -0400 Subject: [cmake-developers] [CMake] Problems with WriteCompilerDetectionHeader and cxx_nullptr In-Reply-To: References: Message-ID: <5501F4E0.6060901@kitware.com> On 03/11/2015 05:22 PM, Roman W?ger wrote: > This simple example produces the following error on Mac OS: > error: cannot initialize a parameter of type 'bool *' with an rvalue of type 'void *' > void doSomething(int n = 1, bool *ok = static_cast(0)) { > ^ ~~~~~~~~~~~~~~~~~~~~~ Indeed. It looks like it was written that way originally in the module: Add the WriteCompilerDetectionHeader module. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=62a4a67d There is a proposed library-only implementation of nullptr here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf "1.1 Alternative #1: A Library Implementation of nullptr" but that is probably too complicated for this compatibility macro that is just supposed to provide the advantages of C++11 when it is available but otherwise work as normal C++98. On 03/12/2015 06:59 AM, Roman W?ger wrote: > -# define ${def_value} static_cast(0) > +# ifdef NULL > +# define ${def_value} NULL > +# else > +# define ${def_value} 0 > +# endif In C++98, NULL is always just "0" AFAIK so the condition may not be needed. I think it is cleaner to not have the definition depend on the order of includes (whether a standard header provides NULL). Thanks, -Brad From mantis at public.kitware.com Fri Mar 13 03:18:59 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 13 Mar 2015 03:18:59 -0400 Subject: [cmake-developers] [CMake 0015442]: Test 124 fails, space before colon in check_file_match_expected_relocation_path Message-ID: <6f30657feb06d5e9f1e229fb247fdedc@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15442 ====================================================================== Reported By: Daniel TISCHER Assigned To: ====================================================================== Project: CMake Issue ID: 15442 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-13 03:18 EDT Last Modified: 2015-03-13 03:18 EDT ====================================================================== Summary: Test 124 fails, space before colon in check_file_match_expected_relocation_path Description: The following tests FAILED: 124 - CPackComponentsForAll-RPM-IgnoreGroup (Failed) 124: error: 124: '/home/quickbuild/workspace/root/packages/cmake/BUILD/cmake-3.2.1/build/Tests/CPackComponentsForAll/buildRPM-IgnoreGroup/MyLib-1.0.2-Linux-headers.rpm' 124: rpm package relocation path does not match expected value - regex 124: 'Relocations : /usr/foo/bar /usr/foo/bar/include'; RPM output: 'Name : 124: mylib-headers Relocations: /usr/foo/bar /usr/foo/bar/include [root at jawas ~]# rpm -qpi /home/quickbuild/workspace/root/packages/cmake/BUILD/cmake-3.2.1/build/Tests/CPackComponentsForAll/buildRPM-IgnoreGroup/MyLib-1.0.2-Linux-headers.rpm Name : mylib-headers Relocations: /usr/foo/bar /usr/foo/bar/include Version : 1.0.2 Vendor: CMake.org Release : 1 Build Date: Thu 12 Mar 2015 09:36:37 PM CET --> there is no space between "Relocations" and colon ":" Steps to Reproduce: run tests Additional Information: RunCPackVerifyResult.cmake lines 167, 174, 180, 186 set(check_file_match_expected_relocation_path "Relocations : ----------^ [root at jawas ~]# rpm --version RPM version 4.8.0 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-13 03:18 Daniel TISCHER New Issue ====================================================================== From mantis at public.kitware.com Fri Mar 13 04:42:32 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 13 Mar 2015 04:42:32 -0400 Subject: [cmake-developers] [CMake 0015443]: Unable to use target_compile_features with MinGW-w64 Message-ID: <1d16eb1a2193aff7c13c89a69bc12438@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15443 ====================================================================== Reported By: David Demelier Assigned To: ====================================================================== Project: CMake Issue ID: 15443 Category: CMake Reproducibility: always Severity: major Priority: high Status: new ====================================================================== Date Submitted: 2015-03-13 04:42 EDT Last Modified: 2015-03-13 04:42 EDT ====================================================================== Summary: Unable to use target_compile_features with MinGW-w64 Description: The following CMakeLists.txt generates an error on MinGW-w64: cmake_minimum_required(VERSION 3.2) project(test) add_executable(main main.cpp) target_compile_features( main PRIVATE cxx_constexpr ) This is the error: CMake Error at CMakeLists.txt:6 (target_compile_features): target_compile_features no known features for CXX compiler "GNU" version 4.9.2. Steps to Reproduce: 1. Try to use target_compile_features with MinGW-w64 Additional Information: It seems that Modules/Compiler/GNU-CXX.cmake has useless UNIX conditionals: Changing lines 47 and 50 to the following fix the problem: set(_result 0) if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.8) _get_gcc_features(${CMAKE_CXX14_STANDARD_COMPILE_OPTION} CMAKE_CXX14_COMPILE_FEATURES) endif() if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.4) if (_result EQUAL 0) _get_gcc_features(${CMAKE_CXX11_STANDARD_COMPILE_OPTION} CMAKE_CXX11_COMPILE_FEATURES) endif() if (_result EQUAL 0) _get_gcc_features(${CMAKE_CXX98_STANDARD_COMPILE_OPTION} CMAKE_CXX98_COMPILE_FEATURES) endif() endif() Please note that MinGW-w64 fully supports C++11 and C++14. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-13 04:42 David Demelier New Issue ====================================================================== From alex.merry at kde.org Fri Mar 13 06:04:28 2015 From: alex.merry at kde.org (Alex Merry) Date: Fri, 13 Mar 2015 10:04:28 +0000 Subject: [cmake-developers] RFC: Helper macros for writing Find modules Message-ID: <4542775.7tyAsShsiA@kyoshi> For the extra-cmake-modules package, I wrote some macros to help with writing component-based Find modules, which are non-trivial to get right. The documentation for them can be found here: http://api.kde.org/ecm/module/ECMFindModuleHelpers.html I've found them incredibly useful in writing classic Find modules, where you just want to find a bunch of libraries and their associated headers, but you also need to account for the dependencies between those libraries. The interface is a little unusual: you have to set up some information- providing variables before calling the macros to describe the information for each component. As an example, see http://quickgit.kde.org/?p=extra-cmake-modules.git&a=blob&h=c5a56c1635d03acdaf5ccd780b9a358d6f6655fd&hb=4f81d1a92e4ccc2ce7b33d2860397a526b1a4d2f&f=find-modules%2FFindWayland.cmake (which I would also submit for inclusion to CMake if this is accepted). Would this be something that might be included in CMake? I have some ideas about how to extend it to be able to account for debug vs release libraries as well (roughly following a simplified version of the pattern of the FindQt4 module). Alex From daniel at pfeifer-mail.de Fri Mar 13 08:44:31 2015 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Fri, 13 Mar 2015 13:44:31 +0100 Subject: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation In-Reply-To: <54F762D3.8080608@kitware.com> References: <20150302010209.GC17534@bronto-burt.dev.benboeckel.net> <5BB62C37-0B76-4CA9-9529-3E3FCB5D151E@java.pl> <54F762D3.8080608@kitware.com> Message-ID: On Wed, Mar 4, 2015 at 8:53 PM, Brad King wrote: > On 03/03/2015 07:43 AM, Adam Strzelecki wrote: > > On 03/01/2015 08:02 PM, Ben Boeckel wrote: > >> On 02/28/2015 11:59 AM, Adam Strzelecki wrote: > >> target_precompiled_header( ) > >> > >> target_precompiled_header( > SHARED > >> > ) > >> Could we rename this? Currently target_* functions are all related to > >> usage requirements and these are not usage requirements. > > > > Honestly I don't understand your request. What would be then the name > > that better represents what the function does. > > Currently the target_* commands are: > > target_compile_definitions > target_compile_features > target_compile_options > target_include_directories > target_link_libraries > target_sources > > They all have the general signature > > target_command( [options] [ ...]...) > > where is INTERFACE, PUBLIC, or PRIVATE and affects whether the > settings apply to sources in the target itself and/or its dependents. > The proposed target_precompiled_header signature does not fit into > this layout. Either a different command name is needed or one needs > to define the command signature and semantics to fit the above layout. > Do PCHs fit into usage requirements in any way? > That would be nice, right? I pushed some work to https://github.com/purpleKarrot/CMake/commits/pch Expect it to be incomplet and incorrekt. It certainly needs a couple of iterations, but the direction should be clear: add_library(foo foo.c) target_include_directories(foo PUBLIC include) target_precompile_headers(foo PUBLIC foo.h) add_library(bar INTERFACE) target_include_directories(bar INTERFACE include) target_precompile_headers(bar INTERFACE bar.h) add_executable(foobar foobar.c) target_link_libraries(foobar foo bar) There is a new command called "target_precompile_headers". This name is chosen carefully. * It says "precompile headers", not "precompiled header". This command is used to set a list of headers "to precompile". It is not used to specify a single prebuilt file. * It has a "target_" prefix, and the expectations about usage requirements should be satisfied. Things to keep in mind: * We probably want to precompile headers based on configuration. * For generators that support it (Makefile + Ninja), we want to precompile headers based on the compile language. * We probably want to enable/disable the use of PCH globally, on a per-target-level, and on a per-source-level. > In meantime https://github.com/nanoant/CMakePCHCompiler is just an implementation that "emulates" desired behavior using many tricks. But I don't want this to be a part of CMake, but instead I want this to be handled natively adding some extra variables: Good. That means we are on the same page. I was a little confused when I first saw your approach. :-) cheers, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Fri Mar 13 10:17:18 2015 From: steveire at gmail.com (Stephen Kelly) Date: Fri, 13 Mar 2015 15:17:18 +0100 Subject: [cmake-developers] Generating buildsystem metadata from CMake In-Reply-To: References: Message-ID: <5502F16E.8000805@gmail.com> On 03/11/2015 11:10 AM, Stephen Kelly wrote: > Hi, > > Following from the thread here: > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12394 > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12650 > The discussion in that thread is causing people confusion (eg regarding an obsolete approach to config and CMAKE_BUILD_TYPE). Please discontinue the discussion there. My branch is the way forward. I extended my branch to contain not only test and documentation but also an implementation and a generated file from my computer, so that you can read it/try it and give feedback. Obviously the branch needs to be broken up into multiple commits, but that something to do when this is not a prototype anymore. We are still in a design discussion. I pushed the implementation only because I know you guys won't discuss the design of the feature on its own and you want to have an implementation asap. However, this is still a design discussion, and all of the questions in my previous mail are still valid. Thanks, Steve. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Fri Mar 13 10:38:27 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 13 Mar 2015 15:38:27 +0100 Subject: [cmake-developers] Generating buildsystem metadata from CMake In-Reply-To: References: Message-ID: <5502F663.2050605@gmail.com> On 03/11/2015 11:10 AM, Stephen Kelly wrote: > I'm starting to gather requirements and make sure the feature is > well designed to satisfy the needs we're already aware of, and fits with > the features CMake currently has. Source file groups (as in defined by source_group()) and target folders (as in the FOLDER target property) may be of interest to IDEs to layout target and source file hierarchies. Nils From Geoffrey.Viola at asirobots.com Fri Mar 13 12:09:42 2015 From: Geoffrey.Viola at asirobots.com (Geoffrey Viola) Date: Fri, 13 Mar 2015 16:09:42 +0000 Subject: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support In-Reply-To: <5501F487.10807@kitware.com> References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com> <54D129E3.60101@kitware.com> <54E365F4.3030104@kitware.com> <54E7542D.6050808@kitware.com> <54EB68C8.7030504@kitware.com> <54F0952B.5070809@kitware.com> <54F4781A.80708@kitware.com> <54FEF1C1.4030106@kitware.com> <5501F487.10807@kitware.com> Message-ID: These sounds like easy changes, but I probably won't be able to update and test it until the middle of next week. Geoffrey Viola SOFTWARE ENGINEER asirobots.com -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Thursday, March 12, 2015 2:18 PM To: Geoffrey Viola Cc: cmake-developers at cmake.org Subject: Re: FW: FW: [cmake-developers] Initial Attempt at Green Hill MULTI IDE Generator Support On 03/11/2015 01:39 PM, Geoffrey Viola wrote: > Attached is a patch with the recommended changes Thanks! The basic toolchain initialization is pretty close. Here are more comments. In Modules/Platform/GHS-MULTI-Initialize.cmake: > +#Setup consistent compiler executables > +find_program(CMAKE_GENERATOR_CC ccarm PATHS ${GHS_COMP_ROOT}) > +find_program(CMAKE_GENERATOR_CXX cxarm PATHS ${GHS_COMP_ROOT}) This should not be needed at all. The CMAKE_GENERATOR_* variables are just hints to the compiler detection logic. Since this generator hard-codes the compiler setting in C++ the logic that uses these variables is never executed anyway. > +string(REGEX MATCH "(comp_)([0-9]+)" CMAKE_SYSTEM_VERSION > +"${CMAKE_MAKE_PROGRAM}") string(REPLACE "comp_" "" > +CMAKE_SYSTEM_VERSION "${CMAKE_SYSTEM_VERSION}") EnableLanguage should be able to set CMAKE_SYSTEM_VERSION too now that it has code to find the comp root. > +mark_as_advanced(CMAKE_MAKE_PROGRAM) This should not be needed. > +include(Platform/WindowsPaths) This should move to Modules/Platform/GHS-MULTI.cmake In EnableLanguage: > + mf->AddDefinition("CMAKE_MAKE_PROGRAM", > + std::string(ghsCompRootStart + > + "gbuild.exe").c_str()); The VS and Xcode generators no longer put this in the cache. Take a look at how the Xcode generator now does this with cmGlobalXCodeGenerator::FindMakeProgram cmGlobalXCodeGenerator::GetXcodeBuildCommand cmGlobalXCodeGenerator::FindXcodeBuildCommand and its call to SelectMakeProgram in GenerateBuildCommand: this->SelectMakeProgram(makeProgram, this->GetXcodeBuildCommand()) Together this all allows the generator to compute the proper build tool without exposing any settings to the user. > + mf->AddDefinition("CMAKE_C_COMPILER_ID", "GhsMultiArmC"); [snip] > + mf->AddDefinition("CMAKE_CXX_COMPILER_ID", "GhsMultiArmCXX"); Instead of "GhsMultiArm*" these should be just "GHS", to be consistent with "Modules/Compiler/GHS-DetermineCompiler.cmake". ----------------------------------------------------------------- Please also look at modifying the Help/ directory to document the new generator. You'll need at least to create/update: Help/manual/cmake-generators.7.rst Help/generator/Green Hills MULTI.rst Help/variable/CMAKE_MAKE_PROGRAM.rst where the change to the last one depends on the above updates. Thanks, -Brad This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. From mantis at public.kitware.com Fri Mar 13 13:40:25 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 13 Mar 2015 13:40:25 -0400 Subject: [cmake-developers] [CMake 0015444]: include_directories is case insensitive usually, but is case sensitive in files inside subfolders Message-ID: <4a78a7ce1488826534d057c3fe4ae0f2@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15444 ====================================================================== Reported By: alean79 Assigned To: ====================================================================== Project: CMake Issue ID: 15444 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-13 13:40 EDT Last Modified: 2015-03-13 13:40 EDT ====================================================================== Summary: include_directories is case insensitive usually, but is case sensitive in files inside subfolders Description: I have a project that was developed in Windows environment, so the #include sentences was developed in case insensitive way (there are a LOT of differences between the name of the .hpp included, and the real name of the .hpp file). I imported that project in a Linux environment, and configured cmake with the following clause: include_directories( SYSTEM ${PROJECT_SOURCE_DIR}/inc) Inside the "inc" folder there are .hpp files, but there are subfolders with aditional .hpp files. In my code, the .hpp files that are in the "inc" folder are recognized correctly, beside the case problems. But the files in the subfolders are NOT recognized if there are case differences. Example: ${PROJECT_SOURCE_DIR} | |-- inc | |-- vpp => subfolder | | | |-- vpp.hpp => header file | |-- flags.hpp => header file If I include the second header file with the following sentence, the file is recognized correctly: #include But, if I include the first header file with the following sentence, the file is NOT found: #include ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-13 13:40 alean79 New Issue 2015-03-13 13:40 alean79 File Added: CMakeLists.txt ====================================================================== From mantis at public.kitware.com Fri Mar 13 14:07:40 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 13 Mar 2015 14:07:40 -0400 Subject: [cmake-developers] [CMake 0015445]: Interface in Russian Language Message-ID: <3de96e5e536468828a3ae0ca78191e58@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15445 ====================================================================== Reported By: abductor Assigned To: ====================================================================== Project: CMake Issue ID: 15445 Category: CMake Reproducibility: N/A Severity: major Priority: low Status: new ====================================================================== Date Submitted: 2015-03-13 14:07 EDT Last Modified: 2015-03-13 14:07 EDT ====================================================================== Summary: Interface in Russian Language Description: I use CMake 2.8.10.2. And I will use 3.2.1 on next week. Cool, what file name in path maybe in Russian language in 3.2.1. I wont help to translate interface and message in russian language. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-13 14:07 abductor New Issue ====================================================================== From mantis at public.kitware.com Fri Mar 13 17:29:50 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 13 Mar 2015 17:29:50 -0400 Subject: [cmake-developers] [CMake 0015446]: In verbose mode, display env vars that were explicitly set for each test Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15446 ====================================================================== Reported By: Zach Mullen Assigned To: ====================================================================== Project: CMake Issue ID: 15446 Category: CTest Reproducibility: always Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-13 17:29 EDT Last Modified: 2015-03-13 17:29 EDT ====================================================================== Summary: In verbose mode, display env vars that were explicitly set for each test Description: We use set_property with the ENVIRONMENT property for many of our tests to control their runtime behavior. When running in verbose mode we see the full command line that is executed, but not the environment variables that were explicitly set for the test invocation. It would be nice to include those. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-13 17:29 Zach Mullen New Issue ====================================================================== From aleixpol at kde.org Fri Mar 13 19:21:51 2015 From: aleixpol at kde.org (Aleix Pol) Date: Sat, 14 Mar 2015 00:21:51 +0100 Subject: [cmake-developers] Generating buildsystem metadata from CMake In-Reply-To: References: Message-ID: On Wed, Mar 11, 2015 at 11:10 AM, Stephen Kelly wrote: > Hi, > > Following from the thread here: > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12394 > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12650 > > I'm starting to gather requirements and make sure the feature is > well designed to satisfy the needs we're already aware of, and fits with > the features CMake currently has. > > The aim is to generate a structured file containing metadata relating the > buildsystem. > > To help with completing the design of this feature, I've written > documentation (documentation driven design), and a unit test > containing a CMakeLists.txt file which exercises many modern CMake > features in the "generate-metadata" branch in my clone. > > Mostly the design I propose can be read in the documentation I wrote. I'm > interested in any feedback. > > https://gitorious.org/cmake/steveires-cmake/source/generate-metadata:Tests/Metadata/CMakeLists.txt > http://www.steveire.com/cmake-future/manual/cmake-metadata-generation.7.html > > I expect to require a few iterations to figure out what the metadata files > should contain in the end. Note that there are already some differences > between my design and Aleix's implementation, such as that my design > proposes one metadata file per config. There are also some things > missing like location, because it is not yet clear to me whether build > or install locations are needed etc. > > The content of the metadata file is determined by the build properties, and > is necessarily similar to the compile-related content created when > generating the actual buildsystem. It additionally contains information > about the output locations of build artifacts and information relating to > the cmake description itself. > > Goals include: > > * Make it possible for IDEs to access the compile-related information for > autocompletion and code navigation etc purposes. > > * Remove the need for IDEs to parse generated Makefiles or Ninja files to > access compile-related information. The structure of those files is not > 'stable', while the content of the metadata file is stable. > http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/48412 > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11081 > > * Remove the need for users to create a new build directory and new build > in order to use or switch IDEs. QtCreator requires that > the C::B 'extra generator is used as it parses compile information from > that. Other 'extra generators' such as for eclipse, sublime, kate etc > also require fresh/new build directories, although the actual buildsystem > they create is identical (assuming using all Makefile based or > all Ninja based 'extra generators') > > * Make it possible to write a plugin for the editors/IDEs such as sublime > which consumes the metadata file and invokes the build using whatever > buildsystem the user already has a build directory for, instead of > writing an 'extra generator' and maintaining it in the cmake repo. > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9004 > > * Make it possible for editors/IDEs to allow specifying the configuration > at build-time, where the IDE has that feature, and where a multi-config > generator is available. That is, QtCreator provides user-interface for > choosing debug/release config to build. Currently it can't offer that > when using cmake, because it only allows the use of Makefile or Ninja > generators, in order to make use of the C::B file. QtCreator should be > able to use the Xcode or Visual Studio generators, generate the metadata > file(s), and invoke `cmake --build . --config ${CONFIG}` as > appropriate. Eclipse, Sublime and other editors have similar abilities > to invoke config-specific builds after generation. > > * Provide a list of 'build targets', which can be listed and invoked in > IDE/editor user interface. Build targets for all linked binaries > and utilties are provided. The tooling is expected to perform filtering > on the target types to show only executables and utilities for > execution, for example. > > * Provide a list of source files per target per type of source file, eg > object sources, header files, generated files, files excluded from the > active configuration/platform/compiler, non-compiled files. > > * Make it more easy for an IDE to support actions such as 'remove file > from the project', which requires removing it from the CMakeLists.txt > at the appropriate place, and 'add new file/class to target', which > involves adding code to the CMakeLists.txt file at the appropriate > place. Most likely the easiest way to do the latter is using the > target_sources() command, and to support the former, the location of > the declaration of the target, and all target_sources() calls would > need to be recorded. Even that is not enough because of transitive > consumption of source files through the link interface, but that is > likely irrelevant. > > * Provide information about the entire build graph of link-dependencies > for visulization and dependency analysis > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/4042 > > * Provide enough information about runtime link dependencies for IDEs to > be able to properly invoke targets with debuggers, profilers and other > tools. > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11011 > > > The CMAKE_EXPORT_COMPILE_COMMANDS variable already exists to generate > compile command lines, but that is a file whose format is defined by > Clang, not by CMake, and other tools in the Clang ecosystem also support > it. It is not extensible or versioned in the way that a CMake-defined > file format is, so I don't propose using it as a starting point. > > Notes: > > * I deliberately didn't push an implementation to my repo, so that this > discussion can focus on the design of the feature and contents of the > file first. > > * In the documentation and the test I didn't mention that the metadata file > is JSON. I'm not opposed to it, but I think there should be some kind of > schema defining how to read the metadata file. If we go with JSON > (instead of xml, say), then we'd have to define our own schema format, which > is not impossible. My proposal is to generate the schema beside the metadata > file instead of writing a metadata version into the metadata file > itself. Does > anyone feel strongly about the file being JSON? I just want to record the > reason for everything in this design phase - we don't have to spend a lot > of time on it. [1] > > * I didn't document the location or directory. I'm not clear on whether > it is supposed to be the build location, or the install location(s!), > or all of those. > > * I don't generate 'dependencies' (actually the list of files which the > buildsystem re-generation depends on) as Aleix did, because there is no > well-defined usefulness for that list yet. [2] > > * I documented the 'name' for the targets, and the TARGET_FILE_NAME > etc information, and can push an implementation which generates them. > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12619 > > * If it is useful to preprocess/compile/assemble individual files from > IDEs, as made possible by the Makefiles and Ninja generators, we'll need > to design that. > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12429 > > * Some more information from project() may be relevant, but it's not clear > yet. We will likely know more when we have decided the file format and > generated some 'interesting' metadata files. > > * We might need backtraces for not only all add_library and add_executable > calls, but also all target_sources() calls. > > * We list the Generator used to configure the build. That way IDEs know > which build output parser to use. > > * I propose to generate one metadata file per configuration active in the > buildsystem. That means that the Makefile and Ninja generators would > generate only one file, and the multi-config generators would generate > multiple files. When changing the 'active configuration', IDEs would > then read whatever metadata file is relevant to the active configuration. > > This also means that conditions don't need to be added inside the metadata > file for configurations in order to show files 'excluded' by being part of > a non-active configuration. The code implementing discovery of excluded > files is in the generate-metadata branch in my clone. > > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11323 > "At least Qt Creator does not need information on which conditions to > be met for a file to become part of the current build." [3] > > * I propose generating language-specific source lists, because CMake can > build files with compilers which do not match their file extension. > > * I propose generating language-specific compile properties in the metadata > file if there a language specific variant groups. For example if the > compile options themselves are language-specific (the feature enabling that > was merged to CMake master this week), then a property for each language > is specified. Otherwise only a language-agnostic property is generated. This > can vary per-configuration for a multi-config generator, so each metadata > file for a multi-config generator could have different properties present. > Consumers read the language specific property if it is present, and read > the language agnostic version otherwise. > > * Generating metadata only (without generating buildsystem files) is not > currently in scope. This was requested several times, but it is not > clear why. [4] > > * How much information does tooling need about installation? Targets > can use different include directories and compile definitions in their > install locations compared to their build locations. If IDEs want to > provide some user interface related to the project files in their > install location, perhaps a separate solution based on cmExportFile* > is needed. For future investigation. [5] Hi, To be honest, I don't really understand why we're doing this here now, 7 months after the first e-mail with the proposal of the feature. I'm hoping we're doing this for transparency and, to be honest, all I want by now is this to be over. [1] About schema, you mean this, no? http://json-schema.org/examples.html I think it's fine to come up with a schema, can be useful to provide tests I guess? I don't think it's important. I think JSON is the format to use, but then anything that's easily parseable works for me. JSON is, much more than XML even. [2] Ok. The KDevelop implementation was using it for being able to know what files are in scope. I'm still planning to do some cmake parsing for code-completion and it seemed like a way to provide the information. We can consider this part of the second iteration of the project though, as it wasn't very useful as it was anyway. [3] This is the biggest problem I see with this proposal. This has 2 problems: * We will have to set up a file system watcher to keep track of new cmake-metadata*.ext files popping up at random times. * When the configs change, the file will remain there as cmake doesn't clean up stuff generated from previous builds. This will confuse the IDE since it will have available files that are not available anymore. [4] Because cmake is really slow and you often want to have the metadata file updated often, every time one of the cmake files in the project change. [5] In fact, installation information is more interesting for headers than targets, IMHO. Hope this helps, Aleix From syntheticpp at gmx.net Sat Mar 14 04:40:41 2015 From: syntheticpp at gmx.net (=?windows-1252?Q?Peter_K=FCmmel?=) Date: Sat, 14 Mar 2015 09:40:41 +0100 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: <54F76572.9000206@kitware.com> Message-ID: <5503F409.6010104@gmx.net> On 12.03.2015 16:24, Tobias Hunger wrote: > > A list of *all* headers used during the building of the target would > be fine. There is no need to filter that list down in any way. > > CMake has that information: Without it cmake could not possibly know > when a cpp file needs rebuilding. It would not be as successful a > build system when it did not know that:-) Even cmake does not know all headers need for compilation, this is done by the compiler providing the dependency files. Overall, wouldn't it be better cmake could parse something like a QBS syntax? Or is also QBS's description not complete enough for an IDE? Is it good enough for QtCreator? I don't think extending CMake's language until eternity is a good idea, the way should go away from it to a common scripting language, so that generating meta-files becomes superfluous. > >> Also we don't really have information about where to put them. You can >> use the minimum common denominator among the sources I guess. > > I don't understand that part, sorry. > >>> >>>> } >>>> ], >>>> "installed" : "true", >>> >>> I guess this means "make install" will install it. Where will this file end up? >> Yes. I tried to figure it out but didn't manage to find the correct >> way to query it. I can try harder. :D >> >>> >>>> "name" : "LLVMPowerPCInfo", >>>> "output_directory" : "/home/kde-devel/tmp/llvm/build/lib/Target/PowerPC/TargetInfo", >>> >>> For what is the output directory relevant? The output above does >>> implicitly list that already, doesn't it? >> It's important in case the output path is overriden, see last e-mail >> by Alexander Neundorf. >> >>> >>>> "type" : "STATIC_LIBRARY" >>> >>> Which types are possible here? >> It's an enum internal to cmake. At the moment: >> EXECUTABLE, STATIC_LIBRARY, SHARED_LIBRARY, MODULE_LIBRARY, >> OBJECT_LIBRARY, UTILITY, GLOBAL_TARGET, INTERFACE_LIBRARY, >> UNKNOWN_LIBRARY. >> >>> >>>> }, >>> >>> >>> There is a lot of useful information here! Thanks for pushing into >>> this direction. I am sure this will help a lot. >>> >>> Ideally this file would be enough to provide all information we need >>> as an IDE to: >>> >>> * Present the project structure as seen by the build system. >>> * Generate the code model >>> * Build the project >>> * Deploy the project >>> * Run and debug parts of the project >>> * Adding and removing files to a project >>> >>> For the project structure this does help: It provides us with a list >>> of all the build targets, which is already nice. CMake does support >>> more structure with Projects and subprojects IIRC and that information >>> is lost. Would it be much work to get that information back? >> as discussed above, I'll look into that next thing. > > I am a cmake noob, but maybe I can help? > >>> For the code model this is not much help at all: There is no >>> information on compiler used, include directories nor Defines or >>> compiler flags. Where am I supposed to get that information from? Do I >>> need to generate and parse the list of commands run and extract that >>> information from there? Having that information available right in the >>> sources array of each target would be so much more convenient and >>> would also make IDE integration so much easier: You would need to know >>> about one file only and won't need to figure out several. >> We can do that, I mentioned earlier in this thread that currently >> we're using compile_commands.json for that ( >> CMAKE_EXPORT_COMPILE_COMMANDS). >> >> I agree it could be interesting to add it. In other words, if nobody >> disagrees, I'll add it although I see how this will make the output >> grow a lot. > > I found parsing of compiler commands non-trivial: It gets messy when > some file gets built twice, especially when different defines, etc. > are set at the different times. E.g. once it is built with > -DENABLE_TEST by some unit test and once it is built without any flags > by the normal application. > > Best Regards, > Tobias > From steveire at gmail.com Sat Mar 14 05:02:12 2015 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 14 Mar 2015 10:02:12 +0100 Subject: [cmake-developers] Generating buildsystem metadata from CMake In-Reply-To: References: Message-ID: On Saturday, March 14, 2015, Aleix Pol wrote: > On Wed, Mar 11, 2015 at 11:10 AM, Stephen Kelly wrote: >> Hi, >> >> Following from the thread here: >> >> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12394 >> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12650 >> >> I'm starting to gather requirements and make sure the feature is >> well designed to satisfy the needs we're already aware of, and fits with >> the features CMake currently has. >> >> The aim is to generate a structured file containing metadata relating the >> buildsystem. >> >> To help with completing the design of this feature, I've written >> documentation (documentation driven design), and a unit test >> containing a CMakeLists.txt file which exercises many modern CMake >> features in the "generate-metadata" branch in my clone. >> >> Mostly the design I propose can be read in the documentation I wrote. I'm >> interested in any feedback. >> >> https://gitorious.org/cmake/steveires-cmake/source/generate-metadata:Tests/Metadata/CMakeLists.txt >> http://www.steveire.com/cmake-future/manual/cmake-metadata-generation.7.html >> >> I expect to require a few iterations to figure out what the metadata files >> should contain in the end. Note that there are already some differences >> between my design and Aleix's implementation, such as that my design >> proposes one metadata file per config. There are also some things >> missing like location, because it is not yet clear to me whether build >> or install locations are needed etc. >> >> The content of the metadata file is determined by the build properties, and >> is necessarily similar to the compile-related content created when >> generating the actual buildsystem. It additionally contains information >> about the output locations of build artifacts and information relating to >> the cmake description itself. >> >> Goals include: >> >> * Make it possible for IDEs to access the compile-related information for >> autocompletion and code navigation etc purposes. >> >> * Remove the need for IDEs to parse generated Makefiles or Ninja files to >> access compile-related information. The structure of those files is not >> 'stable', while the content of the metadata file is stable. >> http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/48412 >> >> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11081 >> >> * Remove the need for users to create a new build directory and new build >> in order to use or switch IDEs. QtCreator requires that >> the C::B 'extra generator is used as it parses compile information from >> that. Other 'extra generators' such as for eclipse, sublime, kate etc >> also require fresh/new build directories, although the actual buildsystem >> they create is identical (assuming using all Makefile based or >> all Ninja based 'extra generators') >> >> * Make it possible to write a plugin for the editors/IDEs such as sublime >> which consumes the metadata file and invokes the build using whatever >> buildsystem the user already has a build directory for, instead of >> writing an 'extra generator' and maintaining it in the cmake repo. >> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9004 >> >> * Make it possible for editors/IDEs to allow specifying the configuration >> at build-time, where the IDE has that feature, and where a multi-config >> generator is available. That is, QtCreator provides user-interface for >> choosing debug/release config to build. Currently it can't offer that >> when using cmake, because it only allows the use of Makefile or Ninja >> generators, in order to make use of the C::B file. QtCreator should be >> able to use the Xcode or Visual Studio generators, generate the metadata >> file(s), and invoke `cmake --build . --config ${CONFIG}` as >> appropriate. Eclipse, Sublime and other editors have similar abilities >> to invoke config-specific builds after generation. >> >> * Provide a list of 'build targets', which can be listed and invoked in >> IDE/editor user interface. Build targets for all linked binaries >> and utilties are provided. The tooling is expected to perform filtering >> on the target types to show only executables and utilities for >> execution, for example. >> >> * Provide a list of source files per target per type of source file, eg >> object sources, header files, generated files, files excluded from the >> active configuration/platform/compiler, non-compiled files. >> >> * Make it more easy for an IDE to support actions such as 'remove file >> from the project', which requires removing it from the CMakeLists.txt >> at the appropriate place, and 'add new file/class to target', which >> involves adding code to the CMakeLists.txt file at the appropriate >> place. Most likely the easiest way to do the latter is using the >> target_sources() command, and to support the former, the location of >> the declaration of the target, and all target_sources() calls would >> need to be recorded. Even that is not enough because of transitive >> consumption of source files through the link interface, but that is >> likely irrelevant. >> >> * Provide information about the entire build graph of link-dependencies >> for visulization and dependency analysis >> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/4042 >> >> * Provide enough information about runtime link dependencies for IDEs to >> be able to properly invoke targets with debuggers, profilers and other >> tools. >> >> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11011 >> >> >> The CMAKE_EXPORT_COMPILE_COMMANDS variable already exists to generate >> compile command lines, but that is a file whose format is defined by >> Clang, not by CMake, and other tools in the Clang ecosystem also support >> it. It is not extensible or versioned in the way that a CMake-defined >> file format is, so I don't propose using it as a starting point. >> >> Notes: >> >> * I deliberately didn't push an implementation to my repo, so that this >> discussion can focus on the design of the feature and contents of the >> file first. >> >> * In the documentation and the test I didn't mention that the metadata file >> is JSON. I'm not opposed to it, but I think there should be some kind of >> schema defining how to read the metadata file. If we go with JSON >> (instead of xml, say), then we'd have to define our own schema format, which >> is not impossible. My proposal is to generate the schema beside the metadata >> file instead of writing a metadata version into the metadata file >> itself. Does >> anyone feel strongly about the file being JSON? I just want to record the >> reason for everything in this design phase - we don't have to spend a lot >> of time on it. > [1] > >> >> * I didn't document the location or directory. I'm not clear on whether >> it is supposed to be the build location, or the install location(s!), >> or all of those. >> >> * I don't generate 'dependencies' (actually the list of files which the >> buildsystem re-generation depends on) as Aleix did, because there is no >> well-defined usefulness for that list yet. > [2] > >> >> * I documented the 'name' for the targets, and the TARGET_FILE_NAME >> etc information, and can push an implementation which generates them. >> >> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12619 >> >> * If it is useful to preprocess/compile/assemble individual files from >> IDEs, as made possible by the Makefiles and Ninja generators, we'll need >> to design that. >> >> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12429 >> >> * Some more information from project() may be relevant, but it's not clear >> yet. We will likely know more when we have decided the file format and >> generated some 'interesting' metadata files. >> >> * We might need backtraces for not only all add_library and add_executable >> calls, but also all target_sources() calls. >> >> * We list the Generator used to configure the build. That way IDEs know >> which build output parser to use. >> >> * I propose to generate one metadata file per configuration active in the >> buildsystem. That means that the Makefile and Ninja generators would >> generate only one file, and the multi-config generators would generate >> multiple files. When changing the 'active configuration', IDEs would >> then read whatever metadata file is relevant to the active configuration. >> >> This also means that conditions don't need to be added inside the metadata >> file for configurations in order to show files 'excluded' by being part of >> a non-active configuration. The code implementing discovery of excluded >> files is in the generate-metadata branch in my clone. >> >> >> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11323 >> "At least Qt Creator does not need information on which conditions to >> be met for a file to become part of the current build." > [3] > >> >> * I propose generating language-specific source lists, because CMake can >> build files with compilers which do not match their file extension. >> >> * I propose generating language-specific compile properties in the metadata >> file if there a language specific variant groups. For example if the >> compile options themselves are language-specific (the feature enabling that >> was merged to CMake master this week), then a property for each language >> is specified. Otherwise only a language-agnostic property is generated. This >> can vary per-configuration for a multi-config generator, so each metadata >> file for a multi-config generator could have different properties present. >> Consumers read the language specific property if it is present, and read >> the language agnostic version otherwise. >> >> * Generating metadata only (without generating buildsystem files) is not >> currently in scope. This was requested several times, but it is not >> clear why. > [4] > >> >> * How much information does tooling need about installation? Targets >> can use different include directories and compile definitions in their >> install locations compared to their build locations. If IDEs want to >> provide some user interface related to the project files in their >> install location, perhaps a separate solution based on cmExportFile* >> is needed. For future investigation. > [5] > > Hi, > To be honest, I don't really understand why we're doing this here now, > 7 months after the first e-mail with the proposal of the feature. I'm > hoping we're doing this for transparency and, to be honest, all I want > by now is this to be over. > > [1] About schema, you mean this, no? http://json-schema.org/examples.html > I think it's fine to come up with a schema, can be useful to provide > tests I guess? That looks great after a short glance, yes. It should be useful not only for unit tests, but for telling tools how to parse the metadata files when multiple different versions of the content can be generated by cmake. > I don't think it's important. > I think JSON is the format to use, but then anything that's easily > parseable works for me. JSON is, much more than XML even. OK, I'm happy with using json too. > [2] Ok. The KDevelop implementation was using it for being able to > know what files are in scope. By 'in scope' you mean 'used by the primary CMakeLists.txt files via include() or find_package()' or something like that? OK, let's see if that's the best source of that data or if we should add something new internally in cmake. > I'm still planning to do some cmake > parsing for code-completion and it seemed like a way to provide the > information. We can consider this part of the second iteration of the > project though, as it wasn't very useful as it was anyway. > > [3] This is the biggest problem I see with this proposal. This has 2 problems: > * We will have to set up a file system watcher to keep track of new > cmake-metadata*.ext files popping up at random times. The 'ext' was just a placeholder while I wasn't sure about the data format to generate. Let's call it cmake-metadata.json now. The Makefile and Ninja generators will only ever generate and keep up-to-date a single 'cmake-metadata.json' without any -debug or -release suffix, because those are 'single configuration generators'. Xcode and Visual Studio will generate the configuration specific files, but will always regenerate all of them. > * When the configs change, the file will remain there as cmake doesn't > clean up stuff generated from previous builds. This will confuse the > IDE since it will have available files that are not available anymore. I think the above explanation covers this. > [4] Because cmake is really slow and you often want to have the > metadata file updated often, every time one of the cmake files in the > project change. OK, maybe we can add something for that, but is it the generation stage that is the slow part? How much time would we gain by doing this? > > [5] In fact, installation information is more interesting for headers > than targets, IMHO. Can you say why? > > Hope this helps, > Aleix > Yes it does, thanks very much! Steve. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleixpol at kde.org Sat Mar 14 09:38:09 2015 From: aleixpol at kde.org (Aleix Pol) Date: Sat, 14 Mar 2015 14:38:09 +0100 Subject: [cmake-developers] Generating buildsystem metadata from CMake In-Reply-To: References: Message-ID: On Sat, Mar 14, 2015 at 10:02 AM, Stephen Kelly wrote: > > > On Saturday, March 14, 2015, Aleix Pol wrote: >> On Wed, Mar 11, 2015 at 11:10 AM, Stephen Kelly >> wrote: >>> Hi, >>> >>> Following from the thread here: >>> >>> >>> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12394 >>> >>> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12650 >>> >>> I'm starting to gather requirements and make sure the feature is >>> well designed to satisfy the needs we're already aware of, and fits with >>> the features CMake currently has. >>> >>> The aim is to generate a structured file containing metadata relating the >>> buildsystem. >>> >>> To help with completing the design of this feature, I've written >>> documentation (documentation driven design), and a unit test >>> containing a CMakeLists.txt file which exercises many modern CMake >>> features in the "generate-metadata" branch in my clone. >>> >>> Mostly the design I propose can be read in the documentation I wrote. I'm >>> interested in any feedback. >>> >>> >>> https://gitorious.org/cmake/steveires-cmake/source/generate-metadata:Tests/Metadata/CMakeLists.txt >>> >>> http://www.steveire.com/cmake-future/manual/cmake-metadata-generation.7.html >>> >>> I expect to require a few iterations to figure out what the metadata >>> files >>> should contain in the end. Note that there are already some differences >>> between my design and Aleix's implementation, such as that my design >>> proposes one metadata file per config. There are also some things >>> missing like location, because it is not yet clear to me whether build >>> or install locations are needed etc. >>> >>> The content of the metadata file is determined by the build properties, >>> and >>> is necessarily similar to the compile-related content created when >>> generating the actual buildsystem. It additionally contains information >>> about the output locations of build artifacts and information relating to >>> the cmake description itself. >>> >>> Goals include: >>> >>> * Make it possible for IDEs to access the compile-related information for >>> autocompletion and code navigation etc purposes. >>> >>> * Remove the need for IDEs to parse generated Makefiles or Ninja files to >>> access compile-related information. The structure of those files is >>> not >>> 'stable', while the content of the metadata file is stable. >>> http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/48412 >>> >>> >>> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11081 >>> >>> * Remove the need for users to create a new build directory and new build >>> in order to use or switch IDEs. QtCreator requires that >>> the C::B 'extra generator is used as it parses compile information from >>> that. Other 'extra generators' such as for eclipse, sublime, kate etc >>> also require fresh/new build directories, although the actual >>> buildsystem >>> they create is identical (assuming using all Makefile based or >>> all Ninja based 'extra generators') >>> >>> * Make it possible to write a plugin for the editors/IDEs such as sublime >>> which consumes the metadata file and invokes the build using whatever >>> buildsystem the user already has a build directory for, instead of >>> writing an 'extra generator' and maintaining it in the cmake repo. >>> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9004 >>> >>> * Make it possible for editors/IDEs to allow specifying the configuration >>> at build-time, where the IDE has that feature, and where a multi-config >>> generator is available. That is, QtCreator provides user-interface for >>> choosing debug/release config to build. Currently it can't offer that >>> when using cmake, because it only allows the use of Makefile or Ninja >>> generators, in order to make use of the C::B file. QtCreator should be >>> able to use the Xcode or Visual Studio generators, generate the >>> metadata >>> file(s), and invoke `cmake --build . --config ${CONFIG}` as >>> appropriate. Eclipse, Sublime and other editors have similar abilities >>> to invoke config-specific builds after generation. >>> >>> * Provide a list of 'build targets', which can be listed and invoked in >>> IDE/editor user interface. Build targets for all linked binaries >>> and utilties are provided. The tooling is expected to perform >>> filtering >>> on the target types to show only executables and utilities for >>> execution, for example. >>> >>> * Provide a list of source files per target per type of source file, eg >>> object sources, header files, generated files, files excluded from the >>> active configuration/platform/compiler, non-compiled files. >>> >>> * Make it more easy for an IDE to support actions such as 'remove file >>> from the project', which requires removing it from the CMakeLists.txt >>> at the appropriate place, and 'add new file/class to target', which >>> involves adding code to the CMakeLists.txt file at the appropriate >>> place. Most likely the easiest way to do the latter is using the >>> target_sources() command, and to support the former, the location of >>> the declaration of the target, and all target_sources() calls would >>> need to be recorded. Even that is not enough because of transitive >>> consumption of source files through the link interface, but that is >>> likely irrelevant. >>> >>> * Provide information about the entire build graph of link-dependencies >>> for visulization and dependency analysis >>> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/4042 >>> >>> * Provide enough information about runtime link dependencies for IDEs to >>> be able to properly invoke targets with debuggers, profilers and other >>> tools. >>> >>> >>> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11011 >>> >>> >>> The CMAKE_EXPORT_COMPILE_COMMANDS variable already exists to generate >>> compile command lines, but that is a file whose format is defined by >>> Clang, not by CMake, and other tools in the Clang ecosystem also support >>> it. It is not extensible or versioned in the way that a CMake-defined >>> file format is, so I don't propose using it as a starting point. >>> >>> Notes: >>> >>> * I deliberately didn't push an implementation to my repo, so that this >>> discussion can focus on the design of the feature and contents of the >>> file first. >>> >>> * In the documentation and the test I didn't mention that the metadata >>> file >>> is JSON. I'm not opposed to it, but I think there should be some kind >>> of >>> schema defining how to read the metadata file. If we go with JSON >>> (instead of xml, say), then we'd have to define our own schema format, >>> which >>> is not impossible. My proposal is to generate the schema beside the >>> metadata >>> file instead of writing a metadata version into the metadata file >>> itself. Does >>> anyone feel strongly about the file being JSON? I just want to record >>> the >>> reason for everything in this design phase - we don't have to spend a >>> lot >>> of time on it. >> [1] >> >>> >>> * I didn't document the location or directory. I'm not clear on whether >>> it is supposed to be the build location, or the install location(s!), >>> or all of those. >>> >>> * I don't generate 'dependencies' (actually the list of files which the >>> buildsystem re-generation depends on) as Aleix did, because there is no >>> well-defined usefulness for that list yet. >> [2] >> >>> >>> * I documented the 'name' for the targets, and the TARGET_FILE_NAME >>> etc information, and can push an implementation which generates them. >>> >>> >>> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12619 >>> >>> * If it is useful to preprocess/compile/assemble individual files from >>> IDEs, as made possible by the Makefiles and Ninja generators, we'll >>> need >>> to design that. >>> >>> >>> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12429 >>> >>> * Some more information from project() may be relevant, but it's not >>> clear >>> yet. We will likely know more when we have decided the file format and >>> generated some 'interesting' metadata files. >>> >>> * We might need backtraces for not only all add_library and >>> add_executable >>> calls, but also all target_sources() calls. >>> >>> * We list the Generator used to configure the build. That way IDEs know >>> which build output parser to use. >>> >>> * I propose to generate one metadata file per configuration active in the >>> buildsystem. That means that the Makefile and Ninja generators would >>> generate only one file, and the multi-config generators would generate >>> multiple files. When changing the 'active configuration', IDEs would >>> then read whatever metadata file is relevant to the active >>> configuration. >>> >>> This also means that conditions don't need to be added inside the >>> metadata >>> file for configurations in order to show files 'excluded' by being part >>> of >>> a non-active configuration. The code implementing discovery of >>> excluded >>> files is in the generate-metadata branch in my clone. >>> >>> >>> >>> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11323 >>> "At least Qt Creator does not need information on which conditions to >>> be met for a file to become part of the current build." >> [3] >> >>> >>> * I propose generating language-specific source lists, because CMake can >>> build files with compilers which do not match their file extension. >>> >>> * I propose generating language-specific compile properties in the >>> metadata >>> file if there a language specific variant groups. For example if the >>> compile options themselves are language-specific (the feature enabling >>> that >>> was merged to CMake master this week), then a property for each >>> language >>> is specified. Otherwise only a language-agnostic property is >>> generated. This >>> can vary per-configuration for a multi-config generator, so each >>> metadata >>> file for a multi-config generator could have different properties >>> present. >>> Consumers read the language specific property if it is present, and >>> read >>> the language agnostic version otherwise. >>> >>> * Generating metadata only (without generating buildsystem files) is not >>> currently in scope. This was requested several times, but it is not >>> clear why. >> [4] >> >>> >>> * How much information does tooling need about installation? Targets >>> can use different include directories and compile definitions in their >>> install locations compared to their build locations. If IDEs want to >>> provide some user interface related to the project files in their >>> install location, perhaps a separate solution based on cmExportFile* >>> is needed. For future investigation. >> [5] >> >> Hi, >> To be honest, I don't really understand why we're doing this here now, >> 7 months after the first e-mail with the proposal of the feature. I'm >> hoping we're doing this for transparency and, to be honest, all I want >> by now is this to be over. >> >> [1] About schema, you mean this, no? http://json-schema.org/examples.html >> I think it's fine to come up with a schema, can be useful to provide >> tests I guess? > > That looks great after a short glance, yes. > > It should be useful not only for unit tests, but for telling tools how to > parse the metadata files when multiple different versions of the content can > be generated by cmake. > >> I don't think it's important. >> I think JSON is the format to use, but then anything that's easily >> parseable works for me. JSON is, much more than XML even. > > OK, I'm happy with using json too. > >> [2] Ok. The KDevelop implementation was using it for being able to >> know what files are in scope. > > By 'in scope' you mean 'used by the primary CMakeLists.txt files via > include() or find_package()' or something like that? OK, let's see if that's > the best source of that data or if we should add something new internally in > cmake. By in scope I mean whether a variable or a target defined in such files. > > >> I'm still planning to do some cmake >> parsing for code-completion and it seemed like a way to provide the >> information. We can consider this part of the second iteration of the >> project though, as it wasn't very useful as it was anyway. >> >> [3] This is the biggest problem I see with this proposal. This has 2 >> problems: >> * We will have to set up a file system watcher to keep track of new >> cmake-metadata*.ext files popping up at random times. > > The 'ext' was just a placeholder while I wasn't sure about the data format > to generate. Let's call it cmake-metadata.json now. > > The Makefile and Ninja generators will only ever generate and keep > up-to-date a single 'cmake-metadata.json' without any -debug or -release > suffix, because those are 'single configuration generators'. Xcode and > Visual Studio will generate the configuration specific files, but will > always regenerate all of them. Ok. > >> * When the configs change, the file will remain there as cmake doesn't >> clean up stuff generated from previous builds. This will confuse the >> IDE since it will have available files that are not available anymore. > > I think the above explanation covers this. > >> [4] Because cmake is really slow and you often want to have the >> metadata file updated often, every time one of the cmake files in the >> project change. > > OK, maybe we can add something for that, but is it the generation stage that > is the slow part? How much time would we gain by doing this? Well, I'm unsure what's the best way to go about it. I understand that given the json file will be executed after all the processing of the sources it won't help much if we just skip the generation. Also maybe it's possible to optimize the configure process all together. > >> >> [5] In fact, installation information is more interesting for headers >> than targets, IMHO. > > Can you say why? To be able to use the headers that are being developed instead of the installed ones when developing 2 projects that are under development. Let's leave that for a later iteration. Aleix From mantis at public.kitware.com Sat Mar 14 12:13:04 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 14 Mar 2015 17:13:04 +0100 Subject: [cmake-developers] [CMake 0015447]: libpthreads not found on cmake >= 3.1 Message-ID: <15adc27f99216a1aba257b819f24099d@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15447 ====================================================================== Reported By: azrdev Assigned To: ====================================================================== Project: CMake Issue ID: 15447 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-14 17:13 CET Last Modified: 2015-03-14 17:13 CET ====================================================================== Summary: libpthreads not found on cmake >= 3.1 Description: Originally this popped up when trying to update the AUR tulip packet to 4.6.1 () The CMakeLists.txt for that software contains the line: FIND_PACKAGE(Threads) Which started to break after installing cmake 3.1 (or higher): Running cmake yields -- Looking for include file pthread.h -- Looking for include file pthread.h - found -- Looking for pthread_create -- Looking for pthread_create - not found -- Looking for pthread_create in pthreads -- Looking for pthread_create in pthreads - not found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Found Threads: TRUE CMake Error at CMakeLists.txt:111 (SET_TARGET_PROPERTIES): INTERFACE_LIBRARY targets may only have whitelisted properties. The property "INSTALL_RPATH" is not allowed. Call Stack (most recent call first): /usr/share/cmake-3.1/Modules/FindThreads.cmake:207 (add_library) CMakeLists.txt:234 (FIND_PACKAGE) CMakeError.txt contains the log for "Determining if the pthread_create exist" especially the line /usr/bin/ld: cannot find -lpthreads According to manual tests, that argument should read -lpthread (without the s). Please tell if you need any other information. The CMakeError.log is attached. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-14 17:13 azrdev New Issue 2015-03-14 17:13 azrdev File Added: CMakeError.log ====================================================================== From gjasny at googlemail.com Sat Mar 14 15:03:44 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Sat, 14 Mar 2015 20:03:44 +0100 Subject: [cmake-developers] [PATCH v8 0/5] Add XCTest Bundle Support Message-ID: <1426359829-33691-1-git-send-email-gjasny@googlemail.com> Hello, this is the eighth version of the XCTest patch. Besides the changes mentioned below I added some more input validation for the two xctest functions. On 27/02/15 16:26, Brad King wrote: > The XCTestUtilities module is feeling more like a find module > now that it finds XCTest components. Perhaps we should rename > it to FindXCTest and use find_package(XCTest) to use it. I changed it into a Find module and it looks much more polished now. > Is this kind of modification of the testee safe? Will projects > actually want their targets modified by adding tests for them? > Currently the settings will affect how the tested targets are > installed. I fully agree that modifying the testee is not something one would expect when adding a test for it. Therefore I reverted the rpath setting for Frameworks and replaced it with a DYLD environment variable when calling xctest. For the App Bundle I reverted your ENABLE_EXPORTS call and replaced it with Xcode specific settings for the XCODE generator and a linker flag for the Makefile generator. Once you ACK the series I will create a topic branch and follow the developer instructions. Thanks, Gregor Brad King (2): Tests: Compute Xcode version for any generator on OS X Help: Add notes for topic 'xcode-xctest' Gregor Jasny (3): OS X: Add handling for XCTest bundles OS X: Add FindXCTest module Tests: Add XCTest example to test Frameworks and Cocoa App Bundles Help/manual/cmake-modules.7.rst | 1 + Help/manual/cmake-properties.7.rst | 1 + Help/module/FindXCTest.rst | 1 + Help/prop_tgt/XCTEST.rst | 13 + Help/release/dev/xcode-xctest.rst | 6 + Modules/FindXCTest.cmake | 196 ++++++ Source/cmGlobalXCodeGenerator.cxx | 12 +- Source/cmTarget.cxx | 16 +- Source/cmTarget.h | 3 + Tests/CMakeLists.txt | 16 + Tests/XCTest/CMakeLists.txt | 57 ++ Tests/XCTest/CocoaExample/AppDelegate.h | 6 + Tests/XCTest/CocoaExample/AppDelegate.m | 18 + Tests/XCTest/CocoaExample/Info.plist | 30 + Tests/XCTest/CocoaExample/MainMenu.xib | 680 +++++++++++++++++++++ Tests/XCTest/CocoaExample/main.m | 5 + Tests/XCTest/CocoaExampleTests/CocoaExampleTests.m | 13 + Tests/XCTest/FrameworkExample/FrameworkExample.c | 6 + Tests/XCTest/FrameworkExample/FrameworkExample.h | 1 + Tests/XCTest/FrameworkExample/Info.plist | 28 + .../FrameworkExampleTests/FrameworkExampleTests.m | 16 + Tests/XCTest/FrameworkExampleTests/Info.plist | 24 + 22 files changed, 1146 insertions(+), 3 deletions(-) create mode 100644 Help/module/FindXCTest.rst create mode 100644 Help/prop_tgt/XCTEST.rst create mode 100644 Help/release/dev/xcode-xctest.rst create mode 100644 Modules/FindXCTest.cmake create mode 100644 Tests/XCTest/CMakeLists.txt create mode 100644 Tests/XCTest/CocoaExample/AppDelegate.h create mode 100644 Tests/XCTest/CocoaExample/AppDelegate.m create mode 100644 Tests/XCTest/CocoaExample/Info.plist create mode 100644 Tests/XCTest/CocoaExample/MainMenu.xib create mode 100644 Tests/XCTest/CocoaExample/main.m create mode 100644 Tests/XCTest/CocoaExampleTests/CocoaExampleTests.m create mode 100644 Tests/XCTest/FrameworkExample/FrameworkExample.c create mode 100644 Tests/XCTest/FrameworkExample/FrameworkExample.h create mode 100644 Tests/XCTest/FrameworkExample/Info.plist create mode 100644 Tests/XCTest/FrameworkExampleTests/FrameworkExampleTests.m create mode 100644 Tests/XCTest/FrameworkExampleTests/Info.plist -- 2.3.0 From gjasny at googlemail.com Sat Mar 14 15:03:45 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Sat, 14 Mar 2015 20:03:45 +0100 Subject: [cmake-developers] [PATCH v8 1/5] Tests: Compute Xcode version for any generator on OS X In-Reply-To: <1426359829-33691-1-git-send-email-gjasny@googlemail.com> References: <1426359829-33691-1-git-send-email-gjasny@googlemail.com> Message-ID: <1426359829-33691-2-git-send-email-gjasny@googlemail.com> From: Brad King Store the version in CMake_TEST_XCODE_VERSION for use by tests that work with any generator on OS X but may depend on the Xcode version providing the tools. --- Tests/CMakeLists.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt index 703c548..bcb1590 100644 --- a/Tests/CMakeLists.txt +++ b/Tests/CMakeLists.txt @@ -172,6 +172,7 @@ if(BUILD_TESTING) ON) mark_as_advanced(CTEST_TEST_CPACK) set(CTEST_TEST_OSX_ARCH 0) + set(CMake_TEST_XCODE_VERSION 0) if(APPLE) execute_process( COMMAND sw_vers -productVersion @@ -185,6 +186,17 @@ if(BUILD_TESTING) else() set(CTEST_TEST_OSX_ARCH 1) endif() + if(XCODE_VERSION) + set(CMake_TEST_XCODE_VERSION "${XCODE_VERSION}") + else() + execute_process( + COMMAND xcodebuild -version + OUTPUT_VARIABLE _version ERROR_VARIABLE _version + ) + if(_version MATCHES "^Xcode ([0-9]+(\\.[0-9]+)*)") + set(CMake_TEST_XCODE_VERSION "${CMAKE_MATCH_1}") + endif() + endif() endif() # Use 1500 or CTEST_TEST_TIMEOUT for long test timeout value, -- 2.3.0 From gjasny at googlemail.com Sat Mar 14 15:03:46 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Sat, 14 Mar 2015 20:03:46 +0100 Subject: [cmake-developers] [PATCH v8 2/5] OS X: Add handling for XCTest bundles In-Reply-To: <1426359829-33691-1-git-send-email-gjasny@googlemail.com> References: <1426359829-33691-1-git-send-email-gjasny@googlemail.com> Message-ID: <1426359829-33691-3-git-send-email-gjasny@googlemail.com> An XCTest bundle is a CFBundle with a special product-type and bundle extension. For more information about XCTest visit the Mac Developer library at: http://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/testing_with_xcode/ Signed-off-by: Gregor Jasny --- Help/manual/cmake-properties.7.rst | 1 + Help/prop_tgt/XCTEST.rst | 13 +++++++++++++ Source/cmGlobalXCodeGenerator.cxx | 12 ++++++++++-- Source/cmTarget.cxx | 16 +++++++++++++++- Source/cmTarget.h | 3 +++ 5 files changed, 42 insertions(+), 3 deletions(-) create mode 100644 Help/prop_tgt/XCTEST.rst diff --git a/Help/manual/cmake-properties.7.rst b/Help/manual/cmake-properties.7.rst index 19fdf23..1dff33e 100644 --- a/Help/manual/cmake-properties.7.rst +++ b/Help/manual/cmake-properties.7.rst @@ -243,6 +243,7 @@ Properties on Targets /prop_tgt/VS_WINRT_REFERENCES /prop_tgt/WIN32_EXECUTABLE /prop_tgt/XCODE_ATTRIBUTE_an-attribute + /prop_tgt/XCTEST Properties on Tests =================== diff --git a/Help/prop_tgt/XCTEST.rst b/Help/prop_tgt/XCTEST.rst new file mode 100644 index 0000000..f3ff474 --- /dev/null +++ b/Help/prop_tgt/XCTEST.rst @@ -0,0 +1,13 @@ +XCTEST +------ + +This target is a XCTest CFBundle on the Mac. + +This property will usually get set via the ``add_xctest`` macro in +:module:`FindXCTest` module. + +If a module library target has this property set to true it will be +built as a CFBundle when built on the Mac. It will have the directory +structure required for a CFBundle. + +This property depends on :prop_tgt:`BUNDLE` to be effective. diff --git a/Source/cmGlobalXCodeGenerator.cxx b/Source/cmGlobalXCodeGenerator.cxx index bd8a1f5..d340e72 100644 --- a/Source/cmGlobalXCodeGenerator.cxx +++ b/Source/cmGlobalXCodeGenerator.cxx @@ -804,6 +804,10 @@ GetSourcecodeValueFromFileExtension(const std::string& _ext, { sourcecode = "compiled.mach-o.objfile"; } + else if(ext == "xctest") + { + sourcecode = "wrapper.cfbundle"; + } else if(ext == "xib") { keepLastKnownFileType = true; @@ -2598,7 +2602,9 @@ const char* cmGlobalXCodeGenerator::GetTargetFileType(cmTarget& cmtarget) case cmTarget::STATIC_LIBRARY: return "archive.ar"; case cmTarget::MODULE_LIBRARY: - if (cmtarget.IsCFBundleOnApple()) + if (cmtarget.IsXCTestOnApple()) + return "wrapper.cfbundle"; + else if (cmtarget.IsCFBundleOnApple()) return "wrapper.plug-in"; else return ((this->XcodeVersion >= 22)? @@ -2622,7 +2628,9 @@ const char* cmGlobalXCodeGenerator::GetTargetProductType(cmTarget& cmtarget) case cmTarget::STATIC_LIBRARY: return "com.apple.product-type.library.static"; case cmTarget::MODULE_LIBRARY: - if (cmtarget.IsCFBundleOnApple()) + if (cmtarget.IsXCTestOnApple()) + return "com.apple.product-type.bundle.unit-test"; + else if (cmtarget.IsCFBundleOnApple()) return "com.apple.product-type.bundle"; else return ((this->XcodeVersion >= 22)? diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx index b70f60d..b3d1155 100644 --- a/Source/cmTarget.cxx +++ b/Source/cmTarget.cxx @@ -616,6 +616,13 @@ bool cmTarget::IsCFBundleOnApple() const } //---------------------------------------------------------------------------- +bool cmTarget::IsXCTestOnApple() const +{ + return (this->IsCFBundleOnApple() && + this->GetPropertyAsBool("XCTEST")); +} + +//---------------------------------------------------------------------------- bool cmTarget::IsBundleOnApple() const { return this->IsFrameworkOnApple() || this->IsAppBundleOnApple() || @@ -6791,7 +6798,14 @@ std::string cmTarget::GetCFBundleDirectory(const std::string& config, const char *ext = this->GetProperty("BUNDLE_EXTENSION"); if (!ext) { - ext = "bundle"; + if (this->IsXCTestOnApple()) + { + ext = "xctest"; + } + else + { + ext = "bundle"; + } } fpath += ext; fpath += "/Contents"; diff --git a/Source/cmTarget.h b/Source/cmTarget.h index 5170b31..a4ef977 100644 --- a/Source/cmTarget.h +++ b/Source/cmTarget.h @@ -527,6 +527,9 @@ public: /** Return whether this target is a CFBundle (plugin) on Apple. */ bool IsCFBundleOnApple() const; + /** Return whether this target is a XCTest on Apple. */ + bool IsXCTestOnApple() const; + /** Return whether this target is an executable Bundle on Apple. */ bool IsAppBundleOnApple() const; -- 2.3.0 From gjasny at googlemail.com Sat Mar 14 15:03:47 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Sat, 14 Mar 2015 20:03:47 +0100 Subject: [cmake-developers] [PATCH v8 3/5] OS X: Add FindXCTest module In-Reply-To: <1426359829-33691-1-git-send-email-gjasny@googlemail.com> References: <1426359829-33691-1-git-send-email-gjasny@googlemail.com> Message-ID: <1426359829-33691-4-git-send-email-gjasny@googlemail.com> Add a module to lookup XCTest Framework and xctest utility. It also provides APIs for creating 'xctest' targets. Signed-off-by: Gregor Jasny --- Help/manual/cmake-modules.7.rst | 1 + Help/module/FindXCTest.rst | 1 + Modules/FindXCTest.cmake | 196 ++++++++++++++++++++++++++++++++++++++++ 3 files changed, 198 insertions(+) create mode 100644 Help/module/FindXCTest.rst create mode 100644 Modules/FindXCTest.cmake diff --git a/Help/manual/cmake-modules.7.rst b/Help/manual/cmake-modules.7.rst index 2b26cc9..c9219d5 100644 --- a/Help/manual/cmake-modules.7.rst +++ b/Help/manual/cmake-modules.7.rst @@ -212,6 +212,7 @@ All Modules /module/FindWish /module/FindwxWidgets /module/FindwxWindows + /module/FindXCTest /module/FindXercesC /module/FindX11 /module/FindXMLRPC diff --git a/Help/module/FindXCTest.rst b/Help/module/FindXCTest.rst new file mode 100644 index 0000000..ff6273c --- /dev/null +++ b/Help/module/FindXCTest.rst @@ -0,0 +1 @@ +.. cmake-module:: ../../Modules/FindXCTest.cmake diff --git a/Modules/FindXCTest.cmake b/Modules/FindXCTest.cmake new file mode 100644 index 0000000..d7cd7bd --- /dev/null +++ b/Modules/FindXCTest.cmake @@ -0,0 +1,196 @@ +#[=======================================================================[.rst: +FindXCTest +---------- + +Functions to help creating and executing XCTest bundles. + +An XCTest bundle is a CFBundle with a special product-type +and bundle extension. For more information about XCTest visit +the Mac Developer library at: +http://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/testing_with_xcode/ + +Module Functions +^^^^^^^^^^^^^^^^ + +.. command:: xctest_add_bundle + + The ``xctest_add_bundle`` function creates a XCTest bundle named + which will test the target . Supported target types + for testee are Frameworks and App Bundles:: + + xctest_add_bundle( + # Name of the XCTest bundle + # Target name of the testee + ) + +.. command:: xctest_add_test + + The ``xctest_add_test`` function adds an XCTest bundle to the + project to be run by :manual:`ctest(1)`. The test will be named + and tests :: + + xctest_add_test( + # Test name + # Target name of XCTest bundle + ) + +Module Variables +^^^^^^^^^^^^^^^^ + +The following variables are set by including this module: + +.. variable:: XCTest_FOUND + + True if the XCTest Framework and executable were found. + +.. variable:: XCTest_EXECUTABLE + + The ``XCTEST_EXECUTABLE`` variable contains the path to the xctest + command line tool used to execute XCTest bundles. + +.. variable:: XCTest_INCLUDE_DIRS + + The directory containing the XCTest Framework headers. + +.. variable:: XCTest_LIBRARIES + + The location of the XCTest Framework. + +#]=======================================================================] + +#============================================================================= +# Copyright 2015 Gregor Jasny +# +# 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.) + +find_path(XCTest_INCLUDE_DIR + NAMES "XCTest/XCTest.h" + DOC "XCTest include directory") +mark_as_advanced(XCTest_INCLUDE_DIR) + +find_library(XCTest_LIBRARY + NAMES XCTest + DOC "XCTest Framework library") +mark_as_advanced(XCTest_LIBRARY) + +execute_process( + COMMAND xcrun --find xctest + OUTPUT_VARIABLE _xcrun_out OUTPUT_STRIP_TRAILING_WHITESPACE + ERROR_VARIABLE _xcrun_err) +if(_xcrun_out) + set(XCTest_EXECUTABLE "${_xcrun_out}" CACHE FILEPATH "XCTest executable") + mark_as_advanced(XCTest_EXECUTABLE) +endif() + +include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake) +find_package_handle_standard_args(XCTest + FOUND_VAR XCTest_FOUND + REQUIRED_VARS XCTest_LIBRARY XCTest_INCLUDE_DIR XCTest_EXECUTABLE) + +if(XCTest_FOUND) + set(XCTest_INCLUDE_DIRS "${XCTest_INCLUDE_DIR}") + set(XCTest_LIBRARIES "${XCTest_LIBRARY}") +endif(XCTest_FOUND) + + +function(xctest_add_bundle target testee) + if(NOT XCTest_FOUND) + message(FATAL_ERROR "XCTest is required to create a XCTest Bundle.") + endif(NOT XCTest_FOUND) + + if(NOT CMAKE_OSX_SYSROOT) + message(FATAL_ERROR "Adding XCTest bundles requires CMAKE_OSX_SYSROOT to be set.") + endif() + + add_library(${target} MODULE ${ARGN}) + + set_target_properties(${target} PROPERTIES + BUNDLE TRUE + XCTEST TRUE + XCTEST_TESTEE ${testee}) + + target_link_libraries(${target} PRIVATE "-framework Foundation") + target_link_libraries(${target} PRIVATE ${XCTest_LIBRARIES}) + target_include_directories(${target} PRIVATE ${XCTest_INCLUDE_DIRS}) + + # retrieve testee target type + if(NOT TARGET ${testee}) + message(FATAL_ERROR "${testee} is not a target.") + endif() + get_property(_testee_type TARGET ${testee} PROPERTY TYPE) + get_property(_testee_framework TARGET ${testee} PROPERTY FRAMEWORK) + get_property(_testee_macosx_bundle TARGET ${testee} PROPERTY MACOSX_BUNDLE) + + if(_testee_type STREQUAL "SHARED_LIBRARY" AND _testee_framework) + # testee is a Framework + target_link_libraries(${target} PRIVATE ${testee}) + + elseif(_testee_type STREQUAL "EXECUTABLE" AND _testee_macosx_bundle) + # testee is an App Bundle + add_dependencies(${target} ${testee}) + if(XCODE) + set_target_properties(${target} PROPERTIES + XCODE_ATTRIBUTE_BUNDLE_LOADER "$(TEST_HOST)" + XCODE_ATTRIBUTE_TEST_HOST "$") + else(XCODE) + target_link_libraries(${target} + PRIVATE "-bundle_loader $") + endif(XCODE) + + else() + message(FATAL_ERROR "Testee ${testee} is of unsupported type.") + endif() +endfunction(xctest_add_bundle) + + +function(xctest_add_test name bundle) + if(NOT XCTest_EXECUTABLE) + message(FATAL_ERROR "XCTest executable is required to register a test.") + endif() + + # check that bundle is a XCTest Bundle + + if(NOT TARGET ${bundle}) + message(FATAL_ERROR "${bundle} is not a target.") + endif(NOT TARGET ${bundle}) + + get_property(_test_type TARGET ${bundle} PROPERTY TYPE) + get_property(_test_bundle TARGET ${bundle} PROPERTY BUNDLE) + get_property(_test_xctest TARGET ${bundle} PROPERTY XCTEST) + + if(NOT _test_type STREQUAL "MODULE_LIBRARY" + OR NOT _test_xctest OR NOT _test_bundle) + message(FATAL_ERROR "Test ${bundle} is not an XCTest Bundle") + endif() + + # get and check testee properties + + get_property(_testee TARGET ${bundle} PROPERTY XCTEST_TESTEE) + if(NOT TARGET ${_testee}) + message(FATAL_ERROR "${_testee} is not a target.") + endif() + + get_property(_testee_type TARGET ${_testee} PROPERTY TYPE) + get_property(_testee_framework TARGET ${_testee} PROPERTY FRAMEWORK) + + # register test + + add_test( + NAME ${name} + COMMAND ${XCTest_EXECUTABLE} $/../..) + + # point loader to testee in case rpath is disabled + + if(_testee_type STREQUAL "SHARED_LIBRARY" AND _testee_framework) + set_property(TEST ${name} APPEND PROPERTY + ENVIRONMENT DYLD_FRAMEWORK_PATH=$/..) + endif() +endfunction(xctest_add_test) -- 2.3.0 From gjasny at googlemail.com Sat Mar 14 15:03:48 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Sat, 14 Mar 2015 20:03:48 +0100 Subject: [cmake-developers] [PATCH v8 4/5] Tests: Add XCTest example to test Frameworks and Cocoa App Bundles In-Reply-To: <1426359829-33691-1-git-send-email-gjasny@googlemail.com> References: <1426359829-33691-1-git-send-email-gjasny@googlemail.com> Message-ID: <1426359829-33691-5-git-send-email-gjasny@googlemail.com> Signed-off-by: Gregor Jasny --- Tests/CMakeLists.txt | 4 + Tests/XCTest/CMakeLists.txt | 57 ++ Tests/XCTest/CocoaExample/AppDelegate.h | 6 + Tests/XCTest/CocoaExample/AppDelegate.m | 18 + Tests/XCTest/CocoaExample/Info.plist | 30 + Tests/XCTest/CocoaExample/MainMenu.xib | 680 +++++++++++++++++++++ Tests/XCTest/CocoaExample/main.m | 5 + Tests/XCTest/CocoaExampleTests/CocoaExampleTests.m | 13 + Tests/XCTest/FrameworkExample/FrameworkExample.c | 6 + Tests/XCTest/FrameworkExample/FrameworkExample.h | 1 + Tests/XCTest/FrameworkExample/Info.plist | 28 + .../FrameworkExampleTests/FrameworkExampleTests.m | 16 + Tests/XCTest/FrameworkExampleTests/Info.plist | 24 + 13 files changed, 888 insertions(+) create mode 100644 Tests/XCTest/CMakeLists.txt create mode 100644 Tests/XCTest/CocoaExample/AppDelegate.h create mode 100644 Tests/XCTest/CocoaExample/AppDelegate.m create mode 100644 Tests/XCTest/CocoaExample/Info.plist create mode 100644 Tests/XCTest/CocoaExample/MainMenu.xib create mode 100644 Tests/XCTest/CocoaExample/main.m create mode 100644 Tests/XCTest/CocoaExampleTests/CocoaExampleTests.m create mode 100644 Tests/XCTest/FrameworkExample/FrameworkExample.c create mode 100644 Tests/XCTest/FrameworkExample/FrameworkExample.h create mode 100644 Tests/XCTest/FrameworkExample/Info.plist create mode 100644 Tests/XCTest/FrameworkExampleTests/FrameworkExampleTests.m create mode 100644 Tests/XCTest/FrameworkExampleTests/Info.plist diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt index bcb1590..e7cf220 100644 --- a/Tests/CMakeLists.txt +++ b/Tests/CMakeLists.txt @@ -1499,6 +1499,10 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P ${CMake_SOURCE_DIR}/Utilities/Release ) endif() + if(CMake_TEST_XCODE_VERSION AND NOT CMake_TEST_XCODE_VERSION VERSION_LESS 5) + ADD_TEST_MACRO(XCTest ${CMAKE_CTEST_COMMAND} -C $ -V) + endif() + add_test(linkorder1 ${CMAKE_CTEST_COMMAND} --build-and-test "${CMake_SOURCE_DIR}/Tests/LinkLineOrder" diff --git a/Tests/XCTest/CMakeLists.txt b/Tests/XCTest/CMakeLists.txt new file mode 100644 index 0000000..e866623 --- /dev/null +++ b/Tests/XCTest/CMakeLists.txt @@ -0,0 +1,57 @@ +cmake_minimum_required(VERSION 3.1) +project(XCTest) +enable_testing() + +find_package(XCTest REQUIRED) + +# Framework + +add_library(FrameworkExample SHARED + FrameworkExample/FrameworkExample.c + FrameworkExample/FrameworkExample.h + FrameworkExample/Info.plist) + +target_include_directories(FrameworkExample PUBLIC .) + +set_target_properties(FrameworkExample PROPERTIES + FRAMEWORK TRUE + VERSION "1.0.0" + SOVERSION "1.0.0" + FRAMEWORK_VERSION "A" + MACOSX_FRAMEWORK_INFO_PLIST ${CMAKE_CURRENT_SOURCE_DIR}/FrameworkExample/Info.plist + PUBLIC_HEADER FrameworkExample/FrameworkExample.h) + +# XCTest for Framework + +xctest_add_bundle(FrameworkExampleTests FrameworkExample + FrameworkExampleTests/FrameworkExampleTests.m + FrameworkExampleTests/Info.plist) + +set_target_properties(FrameworkExampleTests PROPERTIES + MACOSX_BUNDLE_INFO_PLIST ${CMAKE_CURRENT_SOURCE_DIR}/FrameworkExampleTests/Info.plist + ) + +xctest_add_test(XCTest.FrameworkExample FrameworkExampleTests) + +# Cocoa App Bundle + +add_executable(CocoaExample MACOSX_BUNDLE + CocoaExample/main.m + CocoaExample/AppDelegate.m + CocoaExample/AppDelegate.h + CocoaExample/MainMenu.xib +) + +target_link_libraries(CocoaExample PRIVATE "-framework Foundation") +target_link_libraries(CocoaExample PRIVATE "-framework AppKit") + +set_target_properties(CocoaExample PROPERTIES + MACOSX_BUNDLE_INFO_PLIST ${CMAKE_CURRENT_SOURCE_DIR}/CocoaExample/Info.plist + RESOURCE "CocoaExample/MainMenu.xib") + +# XCTest for Cocoa App Bundle + +xctest_add_bundle(CocoaExampleTests CocoaExample + CocoaExampleTests/CocoaExampleTests.m) + +xctest_add_test(XCTest.CocoaExample CocoaExampleTests) diff --git a/Tests/XCTest/CocoaExample/AppDelegate.h b/Tests/XCTest/CocoaExample/AppDelegate.h new file mode 100644 index 0000000..4bf4101 --- /dev/null +++ b/Tests/XCTest/CocoaExample/AppDelegate.h @@ -0,0 +1,6 @@ +#import + + at interface AppDelegate : NSObject + + + at end diff --git a/Tests/XCTest/CocoaExample/AppDelegate.m b/Tests/XCTest/CocoaExample/AppDelegate.m new file mode 100644 index 0000000..07af62f --- /dev/null +++ b/Tests/XCTest/CocoaExample/AppDelegate.m @@ -0,0 +1,18 @@ +#import "AppDelegate.h" + + at interface AppDelegate () + + at property (assign) IBOutlet NSWindow *window; + at end + + at implementation AppDelegate + +- (void)applicationDidFinishLaunching:(NSNotification *)aNotification { + // Insert code here to initialize your application +} + +- (void)applicationWillTerminate:(NSNotification *)aNotification { + // Insert code here to tear down your application +} + + at end diff --git a/Tests/XCTest/CocoaExample/Info.plist b/Tests/XCTest/CocoaExample/Info.plist new file mode 100644 index 0000000..5267c63 --- /dev/null +++ b/Tests/XCTest/CocoaExample/Info.plist @@ -0,0 +1,30 @@ + + + + + CFBundleDevelopmentRegion + en + CFBundleExecutable + CocoaExample + CFBundleIconFile + + CFBundleIdentifier + org.cmake.CocoaExample + CFBundleInfoDictionaryVersion + 6.0 + CFBundleName + CocoaExample + CFBundlePackageType + APPL + CFBundleShortVersionString + 1.0 + CFBundleSignature + ???? + CFBundleVersion + 1 + NSMainNibFile + MainMenu + NSPrincipalClass + NSApplication + + diff --git a/Tests/XCTest/CocoaExample/MainMenu.xib b/Tests/XCTest/CocoaExample/MainMenu.xib new file mode 100644 index 0000000..9498a0a --- /dev/null +++ b/Tests/XCTest/CocoaExample/MainMenu.xib @@ -0,0 +1,680 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Default + + + + + + + Left to Right + + + + + + + Right to Left + + + + + + + + + + + Default + + + + + + + Left to Right + + + + + + + Right to Left + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/Tests/XCTest/CocoaExample/main.m b/Tests/XCTest/CocoaExample/main.m new file mode 100644 index 0000000..8a6799b --- /dev/null +++ b/Tests/XCTest/CocoaExample/main.m @@ -0,0 +1,5 @@ +#import + +int main(int argc, const char * argv[]) { + return NSApplicationMain(argc, argv); +} diff --git a/Tests/XCTest/CocoaExampleTests/CocoaExampleTests.m b/Tests/XCTest/CocoaExampleTests/CocoaExampleTests.m new file mode 100644 index 0000000..70d61d6 --- /dev/null +++ b/Tests/XCTest/CocoaExampleTests/CocoaExampleTests.m @@ -0,0 +1,13 @@ +#import + + at interface CocoaExampleTests : XCTestCase + + at end + + at implementation CocoaExampleTests + +- (void)testExample { + XCTAssert(YES, @"Pass"); +} + + at end diff --git a/Tests/XCTest/FrameworkExample/FrameworkExample.c b/Tests/XCTest/FrameworkExample/FrameworkExample.c new file mode 100644 index 0000000..2da78da --- /dev/null +++ b/Tests/XCTest/FrameworkExample/FrameworkExample.c @@ -0,0 +1,6 @@ +#include "FrameworkExample.h" + +int FourtyTwo() +{ + return 42; +} diff --git a/Tests/XCTest/FrameworkExample/FrameworkExample.h b/Tests/XCTest/FrameworkExample/FrameworkExample.h new file mode 100644 index 0000000..2e0b499 --- /dev/null +++ b/Tests/XCTest/FrameworkExample/FrameworkExample.h @@ -0,0 +1 @@ +int FourtyTwo(); diff --git a/Tests/XCTest/FrameworkExample/Info.plist b/Tests/XCTest/FrameworkExample/Info.plist new file mode 100644 index 0000000..a22acea --- /dev/null +++ b/Tests/XCTest/FrameworkExample/Info.plist @@ -0,0 +1,28 @@ + + + + + CFBundleDevelopmentRegion + en + CFBundleExecutable + FrameworkExample + CFBundleIdentifier + org.cmake.FrameworkExample + CFBundleInfoDictionaryVersion + 6.0 + CFBundleName + FrameworkExample + CFBundlePackageType + FMWK + CFBundleShortVersionString + 1.0 + CFBundleSignature + ???? + CFBundleVersion + + NSHumanReadableCopyright + + NSPrincipalClass + + + diff --git a/Tests/XCTest/FrameworkExampleTests/FrameworkExampleTests.m b/Tests/XCTest/FrameworkExampleTests/FrameworkExampleTests.m new file mode 100644 index 0000000..7cba23e --- /dev/null +++ b/Tests/XCTest/FrameworkExampleTests/FrameworkExampleTests.m @@ -0,0 +1,16 @@ +#import + +#import "FrameworkExample/FrameworkExample.h" + + at interface FrameworkExampleTests : XCTestCase + + at end + + at implementation FrameworkExampleTests + +- (void)testFourtyTwo { + // This is an example of a functional test case. + XCTAssertEqual(42, FourtyTwo()); +} + + at end diff --git a/Tests/XCTest/FrameworkExampleTests/Info.plist b/Tests/XCTest/FrameworkExampleTests/Info.plist new file mode 100644 index 0000000..293921b --- /dev/null +++ b/Tests/XCTest/FrameworkExampleTests/Info.plist @@ -0,0 +1,24 @@ + + + + + CFBundleDevelopmentRegion + en + CFBundleExecutable + FrameworkExampleTests + CFBundleIdentifier + org.cmake.FrameworkExampleTests + CFBundleInfoDictionaryVersion + 6.0 + CFBundleName + FrameworkExampleTests + CFBundlePackageType + BNDL + CFBundleShortVersionString + 1.0 + CFBundleSignature + ???? + CFBundleVersion + 1 + + -- 2.3.0 From gjasny at googlemail.com Sat Mar 14 15:03:49 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Sat, 14 Mar 2015 20:03:49 +0100 Subject: [cmake-developers] [PATCH v8 5/5] Help: Add notes for topic 'xcode-xctest' In-Reply-To: <1426359829-33691-1-git-send-email-gjasny@googlemail.com> References: <1426359829-33691-1-git-send-email-gjasny@googlemail.com> Message-ID: <1426359829-33691-6-git-send-email-gjasny@googlemail.com> From: Brad King --- Help/release/dev/xcode-xctest.rst | 6 ++++++ 1 file changed, 6 insertions(+) create mode 100644 Help/release/dev/xcode-xctest.rst diff --git a/Help/release/dev/xcode-xctest.rst b/Help/release/dev/xcode-xctest.rst new file mode 100644 index 0000000..7a2f07b --- /dev/null +++ b/Help/release/dev/xcode-xctest.rst @@ -0,0 +1,6 @@ +xcode-xctest +------------ + +* On OS X, CMake learned to create XCTest bundles to test Frameworks + and App Bundles within Xcode. The :module:`FindXCTest` module + provides convenience functions to handle :prop_tgt:`XCTEST` bundles. -- 2.3.0 From neundorf at kde.org Sat Mar 14 15:27:55 2015 From: neundorf at kde.org (Alexander Neundorf) Date: Sat, 14 Mar 2015 20:27:55 +0100 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <5503F409.6010104@gmx.net> References: <5503F409.6010104@gmx.net> Message-ID: <1813051.SbvNgdKgsX@tuxedo.neundorf.net> On Saturday, March 14, 2015 09:40:41 Peter K?mmel wrote: > On 12.03.2015 16:24, Tobias Hunger wrote: > > A list of *all* headers used during the building of the target would > > be fine. There is no need to filter that list down in any way. > > > > CMake has that information: Without it cmake could not possibly know > > when a cpp file needs rebuilding. It would not be as successful a > > build system when it did not know that:-) > > Even cmake does not know all headers need for compilation, this is done > by the compiler providing the dependency files. the cmake dependency scanning does find all (and potentially some more) used headers, see depend.internal in the CMakeFiles/ tree. Alex From gjasny at googlemail.com Sat Mar 14 17:23:03 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Sat, 14 Mar 2015 22:23:03 +0100 Subject: [cmake-developers] [PATCH] Fix FindPackageHandleStandardArgs documentation Message-ID: <1426368184-56355-1-git-send-email-gjasny@googlemail.com> Hello, this is my first attempt to practice the topic workflow. I pushed the attached patch to the topic branch and await review before merging to next. http://www.cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/fix-FindPackageHandleStandardArgs-doc Thanks, Gregor Gregor Jasny (1): Fix documentation for FindPackageHandleStandardArgs Modules/FindPackageHandleStandardArgs.cmake | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.3.0 From gjasny at googlemail.com Sat Mar 14 17:23:04 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Sat, 14 Mar 2015 22:23:04 +0100 Subject: [cmake-developers] [PATCH] Fix documentation for FindPackageHandleStandardArgs In-Reply-To: <1426368184-56355-1-git-send-email-gjasny@googlemail.com> References: <1426368184-56355-1-git-send-email-gjasny@googlemail.com> Message-ID: <1426368184-56355-2-git-send-email-gjasny@googlemail.com> For mode 2 the first argument is not the literal NAME but the package name. Signed-off-by: Gregor Jasny --- Modules/FindPackageHandleStandardArgs.cmake | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Modules/FindPackageHandleStandardArgs.cmake b/Modules/FindPackageHandleStandardArgs.cmake index 2de1fb3..bcbd17d 100644 --- a/Modules/FindPackageHandleStandardArgs.cmake +++ b/Modules/FindPackageHandleStandardArgs.cmake @@ -33,7 +33,7 @@ # # :: # -# FIND_PACKAGE_HANDLE_STANDARD_ARGS(NAME +# FIND_PACKAGE_HANDLE_STANDARD_ARGS( # [FOUND_VAR ] # [REQUIRED_VARS ...] # [VERSION_VAR ] -- 2.3.0 From tobias.hunger at gmail.com Sun Mar 15 11:42:09 2015 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Sun, 15 Mar 2015 16:42:09 +0100 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <5503F409.6010104@gmx.net> References: <54F76572.9000206@kitware.com> <5503F409.6010104@gmx.net> Message-ID: Hi Peter, CMake does know all the headers or it could not decide which files need rebuilding. How would making cmake parse a file in the syntax of another build system help creator understand existing cmake projects? This is not about extending cmake language: It makes cmake generate another description of the project in a format that IDEs can use, in addition to the description stored in the Makefiles (or whichever other build tool). Best Regards, Tobias From nilsgladitz at gmail.com Sun Mar 15 13:00:25 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Sun, 15 Mar 2015 18:00:25 +0100 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: <54F76572.9000206@kitware.com> <5503F409.6010104@gmx.net> Message-ID: <5505BAA9.4040806@gmail.com> On 15.03.2015 16:42, Tobias Hunger wrote: > Hi Peter, > > CMake does know all the headers or it could not decide which files > need rebuilding. The build system that CMake generates knows the header dependencies and decides when which files need rebuilding. CMake itself doesn't know. How header dependencies are determined and where and how they are recorded is generator specific. Nils From syntheticpp at gmx.net Sun Mar 15 13:17:20 2015 From: syntheticpp at gmx.net (=?UTF-8?B?UGV0ZXIgS8O8bW1lbA==?=) Date: Sun, 15 Mar 2015 18:17:20 +0100 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: References: <54F76572.9000206@kitware.com> <5503F409.6010104@gmx.net> Message-ID: <5505BEA0.6070403@gmx.net> On 15.03.2015 16:42, Tobias Hunger wrote: > Hi Peter, > > CMake does know all the headers or it could not decide which files > need rebuilding. > > How would making cmake parse a file in the syntax of another build > system help creator understand existing cmake projects? The idea was that qtcreator then also could parse and change the CMakeLists.txt file (like it is done with qbs files, I assume). > > This is not about extending cmake language: It makes cmake generate > another description of the project in a format that IDEs can use, in > addition to the description stored in the Makefiles (or whichever > other build tool). > > Best Regards, > Tobias > From domen.vrankar at gmail.com Sun Mar 15 18:37:54 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Sun, 15 Mar 2015 23:37:54 +0100 Subject: [cmake-developers] file glob and glob recurse directory listing difference Message-ID: Hi all, I'm working on a patch to enable directory listing in file(GLOB_RECURSE...). Currently GLOB lists directories and GLOB_RECURSE doesn't. I was thinking about unifying the two by providing NO_DIRECTORY_LISTING option. Unfortunately this breaks back compatibility so I would need to use a policy. My question is may I use/define the next available policy number for that? Alternative would be to define LIST_DIRECTORIES for GLOB_RECURSE only and preserve back compatibility that way - maybe also define NO_DIRECTORY_LISTING for GLOB just for the sake of consistency. Thanks, Domen From rcdailey.lists at gmail.com Sun Mar 15 21:02:47 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Sun, 15 Mar 2015 20:02:47 -0500 Subject: [cmake-developers] .gitattributes updates Message-ID: Hey everyone, This isn't a huge change but I think it is important. I noticed that .gitattributes was not properly configured to utilize modern Git features: 1. "* text=auto" to specify automatic line ending handling for files that git detects as text files 2. Replace deprecated attribute specifications with newer versions 3. General cleanup and removal of redundant attributes One patch file is a line-ending conversion that does nothing more than replace CRLF with LF. This must be done since the goal is that all files are stored natively as LF in the actual repository. Line ending conversions are applied to the working copy as needed (e.g. LF -> CRLF on Windows for certain files, like VCPROJ) Note that this isn't simply a "cleanup" change. There were actually some things wrong with the current gitattributes: 1. Some files were not properly being handled by git 2. Git config settings on a per-machine basis affected the EOL normalization in the repository These changes will enforce consistency and ignore per-machine settings. Let me know if the changes look acceptable. I'm happy to answer any questions. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-automatic-EOL-handling-to-.gitattributes.patch Type: application/octet-stream Size: 2351 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Normalized-line-endings.patch Type: application/octet-stream Size: 17492 bytes Desc: not available URL: From Geoffrey.Viola at asirobots.com Mon Mar 16 02:03:45 2015 From: Geoffrey.Viola at asirobots.com (Geoffrey Viola) Date: Mon, 16 Mar 2015 06:03:45 +0000 Subject: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support In-Reply-To: <5501F487.10807@kitware.com> References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com> <54D129E3.60101@kitware.com> <54E365F4.3030104@kitware.com> <54E7542D.6050808@kitware.com> <54EB68C8.7030504@kitware.com> <54F0952B.5070809@kitware.com> <54F4781A.80708@kitware.com> <54FEF1C1.4030106@kitware.com> <5501F487.10807@kitware.com> Message-ID: > In Modules/Platform/GHS-MULTI-Initialize.cmake: > >> +#Setup consistent compiler executables >> +find_program(CMAKE_GENERATOR_CC ccarm PATHS ${GHS_COMP_ROOT}) >> +find_program(CMAKE_GENERATOR_CXX cxarm PATHS ${GHS_COMP_ROOT}) Removed >> +string(REGEX MATCH "(comp_)([0-9]+)" CMAKE_SYSTEM_VERSION >> +"${CMAKE_MAKE_PROGRAM}") string(REPLACE "comp_" "" >> +CMAKE_SYSTEM_VERSION "${CMAKE_SYSTEM_VERSION}") > >EnableLanguage should be able to set CMAKE_SYSTEM_VERSION too now that it has code to find the comp root. Done >> +mark_as_advanced(CMAKE_MAKE_PROGRAM) > >This should not be needed. Removed >> +include(Platform/WindowsPaths) > >This should move to Modules/Platform/GHS-MULTI.cmake Moved >In EnableLanguage: > >> + mf->AddDefinition("CMAKE_MAKE_PROGRAM", >> + std::string(ghsCompRootStart + >> + "gbuild.exe").c_str()); > >The VS and Xcode generators no longer put this in the cache. >Take a look at how the Xcode generator now does this with > > cmGlobalXCodeGenerator::FindMakeProgram > cmGlobalXCodeGenerator::GetXcodeBuildCommand > cmGlobalXCodeGenerator::FindXcodeBuildCommand > >and its call to SelectMakeProgram in GenerateBuildCommand: > > this->SelectMakeProgram(makeProgram, this->GetXcodeBuildCommand()) > >Together this all allows the generator to compute the proper build tool without exposing any settings to the user. Moved >> + mf->AddDefinition("CMAKE_C_COMPILER_ID", "GhsMultiArmC"); >[snip] >> + mf->AddDefinition("CMAKE_CXX_COMPILER_ID", "GhsMultiArmCXX"); > >Instead of "GhsMultiArm*" these should be just "GHS", to be consistent with "Modules/Compiler/GHS-DetermineCompiler.cmake". Renamed >Please also look at modifying the Help/ directory to document the new generator. You'll need at least to create/update: > > Help/manual/cmake-generators.7.rst > Help/generator/Green Hills MULTI.rst > Help/variable/CMAKE_MAKE_PROGRAM.rst > >where the change to the last one depends on the above updates. Added some documentation. I reran the experimental tests: https://open.cdash.org/viewTest.php?onlyfailed&buildid=3731770. I'm not quite sure why my FindModulesExecuteAll test fails. Seems like boost installation issue, but it isn't an issue in my nighlty test: https://open.cdash.org/testDetails.php?test=319857216&build=3731770. Geoffrey Viola SOFTWARE ENGINEER asirobots.com -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Thursday, March 12, 2015 2:18 PM To: Geoffrey Viola Cc: cmake-developers at cmake.org Subject: Re: FW: FW: [cmake-developers] Initial Attempt at Green Hill MULTI IDE Generator Support On 03/11/2015 01:39 PM, Geoffrey Viola wrote: > Attached is a patch with the recommended changes Thanks! The basic toolchain initialization is pretty close. Here are more comments. In Modules/Platform/GHS-MULTI-Initialize.cmake: > +#Setup consistent compiler executables > +find_program(CMAKE_GENERATOR_CC ccarm PATHS ${GHS_COMP_ROOT}) > +find_program(CMAKE_GENERATOR_CXX cxarm PATHS ${GHS_COMP_ROOT}) This should not be needed at all. The CMAKE_GENERATOR_* variables are just hints to the compiler detection logic. Since this generator hard-codes the compiler setting in C++ the logic that uses these variables is never executed anyway. > +string(REGEX MATCH "(comp_)([0-9]+)" CMAKE_SYSTEM_VERSION > +"${CMAKE_MAKE_PROGRAM}") string(REPLACE "comp_" "" > +CMAKE_SYSTEM_VERSION "${CMAKE_SYSTEM_VERSION}") EnableLanguage should be able to set CMAKE_SYSTEM_VERSION too now that it has code to find the comp root. > +mark_as_advanced(CMAKE_MAKE_PROGRAM) This should not be needed. > +include(Platform/WindowsPaths) This should move to Modules/Platform/GHS-MULTI.cmake In EnableLanguage: > + mf->AddDefinition("CMAKE_MAKE_PROGRAM", > + std::string(ghsCompRootStart + > + "gbuild.exe").c_str()); The VS and Xcode generators no longer put this in the cache. Take a look at how the Xcode generator now does this with cmGlobalXCodeGenerator::FindMakeProgram cmGlobalXCodeGenerator::GetXcodeBuildCommand cmGlobalXCodeGenerator::FindXcodeBuildCommand and its call to SelectMakeProgram in GenerateBuildCommand: this->SelectMakeProgram(makeProgram, this->GetXcodeBuildCommand()) Together this all allows the generator to compute the proper build tool without exposing any settings to the user. > + mf->AddDefinition("CMAKE_C_COMPILER_ID", "GhsMultiArmC"); [snip] > + mf->AddDefinition("CMAKE_CXX_COMPILER_ID", "GhsMultiArmCXX"); Instead of "GhsMultiArm*" these should be just "GHS", to be consistent with "Modules/Compiler/GHS-DetermineCompiler.cmake". ----------------------------------------------------------------- Please also look at modifying the Help/ directory to document the new generator. You'll need at least to create/update: Help/manual/cmake-generators.7.rst Help/generator/Green Hills MULTI.rst Help/variable/CMAKE_MAKE_PROGRAM.rst where the change to the last one depends on the above updates. Thanks, -Brad This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Added-some-support-for-a-Green-Hills-MULTI.patch Type: application/octet-stream Size: 68330 bytes Desc: 0001-Added-some-support-for-a-Green-Hills-MULTI.patch URL: From roman.wueger at gmx.at Mon Mar 16 03:05:09 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Mon, 16 Mar 2015 08:05:09 +0100 Subject: [cmake-developers] [CMake] Problems with WriteCompilerDetectionHeader and cxx_nullptr Message-ID: <79A8C11B-800E-46C2-B462-AA8156C79B41@gmx.at> Hi Brad, attached is an updated patch. Roman -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-WCDH-Fix-cxx_nullptr-for-compilers-which-doesn-t-sup 02.patch URL: -------------- next part -------------- From mantis at public.kitware.com Mon Mar 16 09:32:15 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 16 Mar 2015 14:32:15 +0100 Subject: [cmake-developers] [CMake 0015448]: find_path() after mark_as_advanced() Message-ID: <14db59d37a34721afc7ca7f9733c1f7c@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15448 ====================================================================== Reported By: nagger Assigned To: ====================================================================== Project: CMake Issue ID: 15448 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-16 14:32 CET Last Modified: 2015-03-16 14:32 CET ====================================================================== Summary: find_path() after mark_as_advanced() Description: It not clear to me if the following is a bug in CMake or just an invalid use: (I tested this for CMake 2.8.11, 3.0.1 and 3.2.1.) set(my_path "anyvalue") find_path(my_path NAMES CMakeLists.txt HINTS ${CMAKE_CURRENT_LIST_DIR}) mark_as_advanced(my_path) find_path(my_path NAMES CMakeLists.txt HINTS ${CMAKE_CURRENT_LIST_DIR}) message("my_path: '${my_path}'") # my_path is empty here! 1st FIND_PATH() uses only the non-cached variable and does not create the cache-variable * this is not described in the docs ** the docs should also describe when and how the cached-variable and the non-cached variable is read and written ** same goes for all find_*-commands MARK_AS_ADVANCED() for an undefined cache-variable creates the cache-var with and empty value and type 'UNDEFINED' * Is this a bug(?) * It could use the value of the non-cached variable (if there is one) * or it should not set the VALUE-property of the cached variable * or set the type to 'STRING' The 2nd FIND_PATH() does not use the non-cached variable as in the first call, but clears the variable without search for the path * For me this looks like a bug! Steps to Reproduce: See attached self-contained CMakeLists.txt with a lot of test cases (T1 .. T8) and its output at the end of the file. For me T1 and T2 is a bug, at least it should act as in T5 or in T7. And T9 also seems like a bug since the docs say: "[...] the search will not be repeated unless the variable is cleared" And T8 is inconsistent to the other tests: Its overwriting the cached value although the variable is set. Until now I thought that the cached value is always overwritten with the value of the variable. Is there any reason why it is not? ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-16 14:32 nagger New Issue ====================================================================== From Robert.Goulet at autodesk.com Mon Mar 16 10:28:08 2015 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Mon, 16 Mar 2015 14:28:08 +0000 Subject: [cmake-developers] Setting unexposed Visual Studio properties from CMake? Message-ID: Hi, Is there a way to set unexposed Visual Studio properties from CMake? In XCode generator, we have XCODE_ATTRIBUTE_. What about Visual Studio? The reason we need this is because we are trying to set project properties of the Nsight Tegra Android generator that are not exposed to CMake. Exposing every single Nsight Tegra build options to CMake is a big job, and perhaps a similar option like XCode would be beneficial to other generators as well. If it's not available, how difficult would it be to add this feature? Thanks! -Robert Goulet -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hunger at gmail.com Mon Mar 16 11:45:48 2015 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Mon, 16 Mar 2015 16:45:48 +0100 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <5505BEA0.6070403@gmx.net> References: <54F76572.9000206@kitware.com> <5503F409.6010104@gmx.net> <5505BEA0.6070403@gmx.net> Message-ID: On Sun, Mar 15, 2015 at 6:17 PM, Peter K?mmel wrote: > The idea was that qtcreator then also could parse and change the > CMakeLists.txt file (like it is done with qbs files, I assume). That would be a nice to have feature, yes, but I doubt that this will ever be an option with cmake. And I personally do not want to pile anything on top of cmake to enable this for a small subset of still-to-be-written projects. I would like to get to the point where you are able to build cmake projects, configure them and have creator open the correct CMakeLists.txt for you when you need to add/remove files to/from some target. It will need work in Creator to get there, and I really do not want that to end up relying on what I consider to be a implementation detail of cmake -- like the format of (probably even undocumented) files somewhere in the build directory that were meant for other consumers. This JSON file can be a step forward here: It is actually meant to be used by IDEs, it has a format straight forward to parse, it does not depend on the generator used, it will (hopefully;-) end up being documented, it provides versioning, etc. I see some potential there. Best Regards, Tobias From steveire at gmail.com Mon Mar 16 14:24:26 2015 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 16 Mar 2015 19:24:26 +0100 Subject: [cmake-developers] Extracting target metadata, IDE integration References: <54F76572.9000206@kitware.com> <5503F409.6010104@gmx.net> <5505BEA0.6070403@gmx.net> Message-ID: Tobias Hunger wrote: > This JSON file can be a step forward here: It is actually meant to be > used by IDEs, it has a format straight forward to parse, it does not > depend on the generator used, it will (hopefully;-) end up being > documented, it provides versioning, etc. I see some potential there. I asked for this thread to be discontinued. I provided a patch which has documentation. There is no 'hopefully' to it. You're simply responding to the wrong thread. Thanks, Steve. From mantis at public.kitware.com Mon Mar 16 14:47:25 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 16 Mar 2015 19:47:25 +0100 Subject: [cmake-developers] [CMake 0015449]: Add a TARGET_INFO generator expression Message-ID: <958da46d2680373710c7b26d0d2788bf@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15449 ====================================================================== Reported By: Stephen Kelly Assigned To: ====================================================================== Project: CMake Issue ID: 15449 Category: CMake Reproducibility: have not tried Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-16 19:47 CET Last Modified: 2015-03-16 19:47 CET ====================================================================== Summary: Add a TARGET_INFO generator expression Description: Add interface for generating information about various aspects of the build. Possibly add WITH expression for generating information about 'other' configs/platforms etc. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-16 19:47 Stephen Kelly New Issue 2015-03-16 19:47 Stephen Kelly File Added: 0001-Add-TARGET_INFO-genex.patch ====================================================================== From steveire at gmail.com Mon Mar 16 15:46:49 2015 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 16 Mar 2015 20:46:49 +0100 Subject: [cmake-developers] Generating buildsystem metadata from CMake References: Message-ID: Aleix Pol wrote: >> By 'in scope' you mean 'used by the primary CMakeLists.txt files via >> include() or find_package()' or something like that? OK, let's see if >> that's the best source of that data or if we should add something new >> internally in cmake. > By in scope I mean whether a variable or a target defined in such files. I see. >>> [4] Because cmake is really slow and you often want to have the >>> metadata file updated often, every time one of the cmake files in the >>> project change. >> >> OK, maybe we can add something for that, but is it the generation stage >> that is the slow part? How much time would we gain by doing this? > Well, I'm unsure what's the best way to go about it. I understand that > given the json file will be executed after all the processing of the > sources it won't help much if we just skip the generation. Also maybe > it's possible to optimize the configure process all together. Yes, if a 'metadata only' mode can be shown to make sense, it can be added in the future. Thanks, Steve. From steveire at gmail.com Mon Mar 16 15:54:06 2015 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 16 Mar 2015 20:54:06 +0100 Subject: [cmake-developers] Generating buildsystem metadata from CMake References: <5502F663.2050605@gmail.com> Message-ID: Nils Gladitz wrote: > On 03/11/2015 11:10 AM, Stephen Kelly wrote: >> I'm starting to gather requirements and make sure the feature is >> well designed to satisfy the needs we're already aware of, and fits with >> the features CMake currently has. > > Source file groups (as in defined by source_group()) and target folders > (as in the FOLDER target property) may be of interest to IDEs to layout > target and source file hierarchies. Indeed. I don't have enough experience with VS to comment much on this. I've added a commit containing some todos and added it there. Thanks, Steve. From mantis at public.kitware.com Mon Mar 16 16:27:34 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 16 Mar 2015 16:27:34 -0400 Subject: [cmake-developers] [CMake 0015450]: Install at build-time Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15450 ====================================================================== Reported By: Joel Lamotte Assigned To: ====================================================================== Project: CMake Issue ID: 15450 Category: CMake Reproducibility: N/A Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-16 16:27 EDT Last Modified: 2015-03-16 16:27 EDT ====================================================================== Summary: Install at build-time Description: Provide a way to trigger install of a target after each build (with a path relative to the build mode). See this discussion: http://cmake.3232098.n2.nabble.com/List-all-binaries-associated-with-a-target-td7590021.html >From Stephen Kelly: [quote] Klaim - Jo?l Lamotte wrote: > Actually 2 and 3 are the same, I just put the files in a specific place in > the > build directory so that it looks like installed, but I do this when the > binary is > built so that it's always up to date while debugging. > Now, I use post-build command (add_custom_command) to do this indeed > but I didn't find a way yet to trigger install() a specific binary on > post-build yet, > but I suppose I just missed it so far. There might be space for a first class feature in cmake for 'make something that looks like the install tree at build time'. Please file an issue to track it. [/quote] ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-16 16:27 Joel Lamotte New Issue ====================================================================== From raffi.enficiaud at mines-paris.org Mon Mar 16 17:58:10 2015 From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud) Date: Mon, 16 Mar 2015 22:58:10 +0100 Subject: [cmake-developers] Introduction and volunteering for the Matlab package In-Reply-To: <5501F061.2050401@kitware.com> References: <54D222A4.7090500@kitware.com> <2F7B25D2-7E72-44C1-B371-16F9399071BC@free.fr> <54DE0B41.5080000@kitware.com> <66AF3BFE-070C-4A57-BCBC-4184DB1EB387@free.fr> <54DE1A19.8050403@kitware.com> <54E49E02.5030105@kitware.com> <54E5F072.3090903@kitware.com> <06983E90-D75E-4335-8D02-1D40DF89B9C2@free.fr> <54EB694A.9030605@kitware.com> <7BCB5D1E-275E-43B2-B0FF-0ECEE0A78585@free.fr> <54EDCF04.2000909@kitware.com> <442BD016-E925-4186-9FBA-DA566C5C5886@free.fr> <54EF5D61.8010708@kitware.co m> <61974444-FEDF-4FE0-9FCE-2797CC7DE528@free.fr> <54EF82F9.4000305@kitware.com> <54FEF2E2.1000403@kitware.com> <5501F061.2050401@kitware.com> Message-ID: Le 12/03/15 21:00, Brad King a ?crit : > On 03/12/2015 12:35 PM, Raffi Enficiaud wrote: > > * Renamed one more MATLAB_USER_ROOT => Matlab_ROOT_DIR > * Do not call list(REMOVE_DUPLICATES/SORT/REVERSE) with no list Thanks! > > The commits are now: > > FindMatlab: Rewrite module and provide a usage API > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3c025a5f > > FindMatlab: Further revisions > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=842ab109 > > FindMatlab: Further revisions > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3743aa11 > > I will squash all this together once everything is done. > For now please base further work on commit 3743aa11. > We'll see how this does on the nightly testing! A test is failing on win32 but I to not think it is due to the FindMatlab: https://open.cdash.org/testDetails.php?test=319823202&build=3731585 What other changes are needed? Best, Raffi From raffi.enficiaud at mines-paris.org Tue Mar 17 05:52:20 2015 From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud) Date: Tue, 17 Mar 2015 10:52:20 +0100 Subject: [cmake-developers] Introduction and volunteering for the Matlab package In-Reply-To: <5501F061.2050401@kitware.com> References: <54D222A4.7090500@kitware.com> <2F7B25D2-7E72-44C1-B371-16F9399071BC@free.fr> <54DE0B41.5080000@kitware.com> <66AF3BFE-070C-4A57-BCBC-4184DB1EB387@free.fr> <54DE1A19.8050403@kitware.com> <54E49E02.5030105@kitware.com> <54E5F072.3090903@kitware.com> <06983E90-D75E-4335-8D02-1D40DF89B9C2@free.fr> <54EB694A.9030605@kitware.com> <7BCB5D1E-275E-43B2-B0FF-0ECEE0A78585@free.fr> <54EDCF04.2000909@kitware.com> <442BD016-E925-4186-9FBA-DA566C5C5886@free.fr> <54EF5D61.8010708@kitware.co m> <61974444-FEDF-4FE0-9FCE-2797CC7DE528@free.fr> <54EF82F9.4000305@kitware.com> <54FEF2E2.1000403@kitware.com> <5501F061.2050401@kitware.com> Message-ID: Le 12/03/15 21:00, Brad King a ?crit : > On 03/12/2015 12:35 PM, Raffi Enficiaud wrote: > > I will squash all this together once everything is done. > For now please base further work on commit 3743aa11. > We'll see how this does on the nightly testing! > Hi, I have a problem running the tests on win7. All the tests are passing, but at the end, I have the following: 17-Mar-2015 04:23:23 100% tests passed, 0 tests failed out of 21 17-Mar-2015 04:23:23 17-Mar-2015 04:23:23 Total Test time (real) = 21.84 sec 17-Mar-2015 04:23:23 Add file: D:/bamboo_build_dir/SW-CMAK-JOB1/dashboard/CMakeScripts/findmatlab_nightbuild.cmake 17-Mar-2015 04:23:23 Add file: D:/bamboo_build_dir/SW-CMAK-JOB1/dashboard/CMakeScripts/cmake_common.cmake 17-Mar-2015 04:23:23 Add file: D:/bamboo_build_dir/SW-CMAK-JOB1/dashboard/CMakeScripts/findmatlab_nightbuild.cmake 17-Mar-2015 04:23:23 Add file: D:/bamboo_build_dir/SW-CMAK-JOB1/dashboard/CMakeScripts/kwsys_common.cmake 17-Mar-2015 04:23:23 Submit files (using http) 17-Mar-2015 04:23:23 Using HTTP submit method 17-Mar-2015 04:23:23 Drop site:http://open.cdash.org/submit.php?project=KWSys 17-Mar-2015 04:23:40 Uploaded: D:/bamboo_build_dir/SW-CMAK-JOB1/dashboard/My Tests/KWSys-build/Testing/20150317-0100/Build.xml 17-Mar-2015 04:23:44 Uploaded: D:/bamboo_build_dir/SW-CMAK-JOB1/dashboard/My Tests/KWSys-build/Testing/20150317-0100/Configure.xml 17-Mar-2015 04:23:49 Uploaded: D:/bamboo_build_dir/SW-CMAK-JOB1/dashboard/My Tests/KWSys-build/Testing/20150317-0100/Notes.xml 17-Mar-2015 04:23:53 Uploaded: D:/bamboo_build_dir/SW-CMAK-JOB1/dashboard/My Tests/KWSys-build/Testing/20150317-0100/Test.xml 17-Mar-2015 04:23:56 Uploaded: D:/bamboo_build_dir/SW-CMAK-JOB1/dashboard/My Tests/KWSys-build/Testing/20150317-0100/Update.xml 17-Mar-2015 04:23:56 Submission successful 17-Mar-2015 04:23:57 Error in read script: D:/bamboo_build_dir/SW-CMAK-JOB1/dashboard/CMakeScripts/findmatlab_nightbuild.cmake 17-Mar-2015 04:23:57 Failing task since return code of [C:\Program Files (x86)\CMake 2.8\bin\ctest.exe -S findmatlab_nightbuild.cmake -V] was -1 while expected 0 The content of the findmatlab_nightbuild.cmake is set(CTEST_SITE "bambooagent.raffienficiaud") set(CTEST_BUILD_NAME "Win7x64-vs2013e-matlab2013b") set(CTEST_BUILD_CONFIGURATION Debug) set(CTEST_CMAKE_GENERATOR "Visual Studio 12 Win64") set(dashboard_cache "CMake_TEST_FindMatlab:BOOL=ON") include(${CTEST_SCRIPT_DIRECTORY}/cmake_common.cmake) and I am using ctest 2.8.12 to run -S findmatlab_nightbuild.cmake -V Any clue? Raffi From mantis at public.kitware.com Tue Mar 17 07:31:00 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 17 Mar 2015 07:31:00 -0400 Subject: [cmake-developers] [CMake 0015451]: Setting MAP_IMPORTED_CONFIG_ hides IMPORTED_LOCATION Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15451 ====================================================================== Reported By: Bjoern Thiel Assigned To: ====================================================================== Project: CMake Issue ID: 15451 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-17 07:30 EDT Last Modified: 2015-03-17 07:30 EDT ====================================================================== Summary: Setting MAP_IMPORTED_CONFIG_ hides IMPORTED_LOCATION Description: I thought IMPORTED_LOCATION is a fall back for IMPORTED_LOCATION_ and should be found in any case. But cmTarget::GetMappedConfig gives up too early: if(!mappedConfigs.empty() && !*loc && !*imp) { return false; } (line 5540) Example: set(CMAKE_MAP_IMPORTED_CONFIG_RELWITHDEBINFO RELEASE) and try to use Qt5::moc in the RelWithDebInfo configuration. Steps to Reproduce: See above. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-17 07:30 Bjoern Thiel New Issue ====================================================================== From jcmvbkbc at gmail.com Tue Mar 17 08:51:04 2015 From: jcmvbkbc at gmail.com (Max Filippov) Date: Tue, 17 Mar 2015 15:51:04 +0300 Subject: [cmake-developers] [PATCH] ABI.h.in: add support for Xtensa architecture Message-ID: <1426596664-9910-1-git-send-email-jcmvbkbc@gmail.com> Signed-off-by: Max Filippov --- Utilities/KWIML/ABI.h.in | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/Utilities/KWIML/ABI.h.in b/Utilities/KWIML/ABI.h.in index 21c9139..6300ada 100644 --- a/Utilities/KWIML/ABI.h.in +++ b/Utilities/KWIML/ABI.h.in @@ -432,6 +432,12 @@ suppression macro @KWIML at _ABI_NO_VERIFY was defined. # define @KWIML at _ABI_ENDIAN_ID @KWIML at _ABI_ENDIAN_ID_BIG # endif +/* Xtensa */ +#elif defined(__XTENSA_EB__) +# define @KWIML at _ABI_ENDIAN_ID @KWIML at _ABI_ENDIAN_ID_BIG +#elif defined(__XTENSA_EL__) +# define @KWIML at _ABI_ENDIAN_ID @KWIML at _ABI_ENDIAN_ID_LITTLE + /* Unknown CPU */ #elif !defined(@KWIML at _ABI_NO_ERROR_ENDIAN) # error "Byte order of target CPU unknown." -- 1.8.1.4 From brad.king at kitware.com Tue Mar 17 11:25:56 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 17 Mar 2015 11:25:56 -0400 Subject: [cmake-developers] Introduction and volunteering for the Matlab package In-Reply-To: References: <54D222A4.7090500@kitware.com> <2F7B25D2-7E72-44C1-B371-16F9399071BC@free.fr> <54DE0B41.5080000@kitware.com> <66AF3BFE-070C-4A57-BCBC-4184DB1EB387@free.fr> <54DE1A19.8050403@kitware.com> <54E49E02.5030105@kitware.com> <54E5F072.3090903@kitware.com> <06983E90-D75E-4335-8D02-1D40DF89B9C2@free.fr> <54EB694A.9030605@kitware.com> <7BCB5D1E-275E-43B2-B0FF-0ECEE0A78585@free.fr> <54EDCF04.2000909@kitware.com> <442BD016-E925-4186-9FBA-DA566C5C5886@free.fr> <54EF5D61.8010708@kitware.co m> <61974444-FEDF-4FE0-9FCE-2797CC7DE528@free.fr> <54EF82F9.4000305@kitware.com> <54FEF2E2.1000403@kitware.com> <5501F061.2050401@kitware.com> Message-ID: <55084784.2000107@kitware.com> On 03/16/2015 05:58 PM, Raffi Enficiaud wrote: > Le 12/03/15 21:00, Brad King a ?crit : >> I will squash all this together once everything is done. >> For now please base further work on commit 3743aa11. >> We'll see how this does on the nightly testing! > > A test is failing on win32 but I to not think it is due to the FindMatlab: That was a new test that failed on many machines its first day. It has now been resolved. > What other changes are needed? Nothing right now! I've squashed this all into one commit: FindMatlab: Rewrite module and provide a usage API http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=49c8dcf7 and merged to 'master' for inclusion in 3.3. Thanks for all your work on this and persistence with following up on feedback. This is a huge improvement over the previous FindMatlab module. -Brad From tobias.hunger at gmail.com Tue Mar 17 12:30:32 2015 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Tue, 17 Mar 2015 17:30:32 +0100 Subject: [cmake-developers] Generating buildsystem metadata from CMake In-Reply-To: References: Message-ID: Hi Stephen, sorry for being late to the party again:-) I am just reading your documentation. Some nits: * In the "Introduction" you say CMAKE_GENERATE_METADATA needs to be ON, in "Generating Metadata" it needs to be set to a version number. * In "Metadata Contents/Optional Properties" you propose to have several language specific properties. Would it make sense to group those together into one "language" property? * In "Target Properties/Conditional Properties", "backtrace": Which frame is the current one? The top one or the bottom one? I've seen both approaches in the wild:-) * In "Target Properties/Conditional Properties and optional properties": Would it make sense to have a list of target_files, each with a filepath and a type? That would be more similar to the targets which also are a list with name/type. Are these paths in the build or in the install location? * In "Target Properties/Conditional Optional Properties": Again, wouldn't a set of sources arrays with a list of filepaths and all the related meta information for this set of files be nicer? That way all the "language fallback properties" and "source file properties" would be in one place. Somewhat like this (going with JSON-ish syntax here for ease of writing): sources: [ { language: "C++", type: sources, defines: "FOO=1", include_paths: "/usr/include", files: [ "/full/path/a.cpp", "/full/path/b.cpp" ] }, { language: "C++", type: headers, files: [ "/full/path/a.h" ] }, { language: "C++", type: generated, files: [ "/full/path/config.h" ] }] This can express defines set for individual files, which I think you can have in CMake, can't you? I do not see how to express that within your proposal. The rest of my replies are inline: On Wed, Mar 11, 2015 at 11:10 AM, Stephen Kelly wrote: > I expect to require a few iterations to figure out what the metadata files > should contain in the end. Note that there are already some differences > between my design and Aleix's implementation, such as that my design > proposes one metadata file per config. There are also some things > missing like location, because it is not yet clear to me whether build > or install locations are needed etc. These configurations are only relevant to generators that can support e.g. having debug and release builds in the same build directory or did I misunderstand this? How are we supposed to handle a set of files for these configurations? How can we notice when one gets added and removed? Having everything in one file would probably be easier, as that is just one file what needs watching:-) Could we maybe just tag the targets with the configurations they apply to and maybe also add the same tag to the source file groups proposed above? > The content of the metadata file is determined by the build properties, and > is necessarily similar to the compile-related content created when > generating the actual buildsystem. It additionally contains information > about the output locations of build artifacts and information relating to > the cmake description itself. Output location of build artifacts: That is the location inside the build directory, isn't it? What about install locations? > Goals include: > > * Make it possible for IDEs to access the compile-related information for > autocompletion and code navigation etc purposes. > > * Remove the need for IDEs to parse generated Makefiles or Ninja files to > access compile-related information. The structure of those files is not > 'stable', while the content of the metadata file is stable. > http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/48412 > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11081 YES! > * Remove the need for users to create a new build directory and new build > in order to use or switch IDEs. QtCreator requires that > the C::B 'extra generator is used as it parses compile information from > that. Other 'extra generators' such as for eclipse, sublime, kate etc > also require fresh/new build directories, although the actual buildsystem > they create is identical (assuming using all Makefile based or > all Ninja based 'extra generators') That would indeed be a nice side-effect:-) > * Make it possible for editors/IDEs to allow specifying the configuration > at build-time, where the IDE has that feature, and where a multi-config > generator is available. That is, QtCreator provides user-interface for > choosing debug/release config to build. Currently it can't offer that > when using cmake, because it only allows the use of Makefile or Ninja > generators, in order to make use of the C::B file. QtCreator should be > able to use the Xcode or Visual Studio generators, generate the metadata > file(s), and invoke `cmake --build . --config ${CONFIG}` as > appropriate. Eclipse, Sublime and other editors have similar abilities > to invoke config-specific builds after generation. Yes again:-) > * Provide a list of 'build targets', which can be listed and invoked in > IDE/editor user interface. Build targets for all linked binaries > and utilties are provided. The tooling is expected to perform filtering > on the target types to show only executables and utilities for > execution, for example. OK. > * Provide a list of source files per target per type of source file, eg > object sources, header files, generated files, files excluded from the > active configuration/platform/compiler, non-compiled files. Nice. > * Make it more easy for an IDE to support actions such as 'remove file > from the project', which requires removing it from the CMakeLists.txt > at the appropriate place, and 'add new file/class to target', which > involves adding code to the CMakeLists.txt file at the appropriate > place. Most likely the easiest way to do the latter is using the > target_sources() command, and to support the former, the location of > the declaration of the target, and all target_sources() calls would > need to be recorded. Even that is not enough because of transitive > consumption of source files through the link interface, but that is > likely irrelevant. That would be the icing on the cake, but getting a full description of the project is what I care for at this point. > * Provide information about the entire build graph of link-dependencies > for visulization and dependency analysis > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/4042 Nice. > * Provide enough information about runtime link dependencies for IDEs to > be able to properly invoke targets with debuggers, profilers and other > tools. > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11011 Yes. > The CMAKE_EXPORT_COMPILE_COMMANDS variable already exists to generate > compile command lines, but that is a file whose format is defined by > Clang, not by CMake, and other tools in the Clang ecosystem also support > it. It is not extensible or versioned in the way that a CMake-defined > file format is, so I don't propose using it as a starting point. Fully agree with this:-) > * In the documentation and the test I didn't mention that the metadata file > is JSON. I'm not opposed to it, but I think there should be some kind of > schema defining how to read the metadata file. If we go with JSON > (instead of xml, say), then we'd have to define our own schema format, which > is not impossible. My proposal is to generate the schema beside the metadata > file instead of writing a metadata version into the metadata file > itself. Does > anyone feel strongly about the file being JSON? I just want to record the > reason for everything in this design phase - we don't have to spend a lot > of time on it. I do not care too much on the format, but I am strongly in favor of anything that I can conveniently parse with Qt. So XML and JSON are thus both fine with me:-) I would prefer JSON, simply because I find that way more human-readable. > * I didn't document the location or directory. I'm not clear on whether > it is supposed to be the build location, or the install location(s!), > or all of those. I see four options to place this file: * Source directory: Nah, let's not pollute the source dir more than necessary. * Build directory: Probably a good place as it contains per-build information if I understood this correctly. * Install directory: Probably not around by the time you start a build and I do not see any reason to have IDE support for installed files. * Some configuration directory: ~/.config/cmake/builds/whatever.config. That would make it simple to find all builds of a project, but will make it hard to keep the configuration in sync with the build directories (e.g. when somebody removes build directories). The only practical place seems the build directory to me. > * I don't generate 'dependencies' (actually the list of files which the > buildsystem re-generation depends on) as Aleix did, because there is no > well-defined usefulness for that list yet. How is the IDE supposed to know that it needs to re-run cmake then? If a file changes that may very well change the list of files that the IDE needs to display, so re-running cmake only at the next build is not going to work. > * I documented the 'name' for the targets, and the TARGET_FILE_NAME > etc information, and can push an implementation which generates them. > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12619 Great. > * If it is useful to preprocess/compile/assemble individual files from > IDEs, as made possible by the Makefiles and Ninja generators, we'll need > to design that. > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12429 That would be nice to have, but let's get the basics done first. At the same time being able to build only the src/ directory, etc. would be useful, too. > * Some more information from project() may be relevant, but it's not clear > yet. We will likely know more when we have decided the file format and > generated some 'interesting' metadata files. That is definitely needed! What is this file about(full path to top level CMakeLists.txt that was used to generate this build directory as well as the configuration that was used!) is essential to answer:-) I would love to have something like ccmake built into Qt Creator at some point, and having this information would spare me poking around CMakeCache.txt and whatnot:-) Creator also offers to import existing builds and with your stated goal of standardizing on this one file for several IDEs this import features becomes even more important. For that to work information on project this build directory is for as well as which Qt/compiler/whatnot was used in the project is essential for Creator to properly configure the code model and the rest of Creator. Having the full configuration available would also remove the need to have special flags in the "Metadata Contents" section for the compiler used. > * We might need backtraces for not only all add_library and add_executable > calls, but also all target_sources() calls. I do not see any obvious use for a full backtrace, but then it is probably interesting to have to generate the build system structure we display in the projects view in Qt Creator... Please keep it:-) Apropos project view: IIRC cmake allows to define lists of files to be displayed together in visual studio, doesn't it? Would it be possible to make this data available to other IDEs, too? > * We list the Generator used to configure the build. That way IDEs know > which build output parser to use. Good! > * I propose to generate one metadata file per configuration active in the > buildsystem. That means that the Makefile and Ninja generators would > generate only one file, and the multi-config generators would generate > multiple files. When changing the 'active configuration', IDEs would > then read whatever metadata file is relevant to the active configuration. How can I get the list of files that are relevant? Will there be one master file that lists all the available configurations and their configuration description file? > This also means that conditions don't need to be added inside the metadata > file for configurations in order to show files 'excluded' by being part of > a non-active configuration. The code implementing discovery of excluded > files is in the generate-metadata branch in my clone. > > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11323 > "At least Qt Creator does not need information on which conditions to > be met for a file to become part of the current build." OK. > * I propose generating language-specific source lists, because CMake can > build files with compilers which do not match their file extension. Makes a lot of sense, even though I am not too happy with the syntax. See the nits above. > * I propose generating language-specific compile properties in the metadata > file if there a language specific variant groups. For example if the > compile options themselves are language-specific (the feature enabling that > was merged to CMake master this week), then a property for each language > is specified. Otherwise only a language-agnostic property is generated. This > can vary per-configuration for a multi-config generator, so each metadata > file for a multi-config generator could have different properties present. > Consumers read the language specific property if it is present, and read > the language agnostic version otherwise. I do not fully get where you are going here. > * Generating metadata only (without generating buildsystem files) is not > currently in scope. This was requested several times, but it is not > clear why. Not sure... When opening a CMakeLists.txt, ideally I would ask the user for a build directory and a cmake generator to be used and run cmake once. Afterwards I would have a project description that I can generate a ccmake-like config UI from. If the user changes that I run cmake again and afterwards the project is fully set up and documented in the -- now updated -- project description file. Afterwards I will need to regenerate the configuration description each time something changed. That should be as fast as possible, as the data I display in the UI is stale at that point. If not generating the complete build-system makes this step faster, then I am all for that:-) OTOH, it probably does not matter too much if the description is created first and the build system is updated only afterwards in the background. Unrelated question: Can I query the available generators in a machine-readable format with user friendly names and their name from cmake somehow? > * How much information does tooling need about installation? Targets > can use different include directories and compile definitions in their > install locations compared to their build locations. If IDEs want to > provide some user interface related to the project files in their > install location, perhaps a separate solution based on cmExportFile* > is needed. For future investigation. Why is that necessary? My goal is to have solid support for stand-alone cmake-based projects in Creator. If such projects reference installed libraries I would expect that to be reflected in the compiler and linker flags. Why would that need special support for include directories and compile definitions? Creator needs to know where all files will end up on install since we might need to copy them to a remote machine (e.g. a phone, or a Linux box) to run/debug there. Installing everything with some temporary directory prefixed to all paths does work, though. We can then rsync the temporary directory to a device. But even then we will still need to know where the executables end up on the device to run/debug. Best Regards, Tobias PS: I hope there is not too much redundant stuff in here that is already discussed in the follow up mails I only skimmed over so far:-) From raffi.enficiaud at free.fr Tue Mar 17 12:45:14 2015 From: raffi.enficiaud at free.fr (Raffi Enficiaud) Date: Tue, 17 Mar 2015 17:45:14 +0100 Subject: [cmake-developers] Introduction and volunteering for the Matlab package In-Reply-To: <55084784.2000107@kitware.com> References: <54D222A4.7090500@kitware.com> <2F7B25D2-7E72-44C1-B371-16F9399071BC@free.fr> <54DE0B41.5080000@kitware.com> <66AF3BFE-070C-4A57-BCBC-4184DB1EB387@free.fr> <54DE1A19.8050403@kitware.com> <54E49E02.5030105@kitware.com> <54E5F072.3090903@kitware.com> <06983E90-D75E-4335-8D02-1D40DF89B9C2@free.fr> <54EB694A.9030605@kitware.com> <7BCB5D1E-275E-43B2-B0FF-0ECEE0A78585@free.fr> <54EDCF04.2000909@kitware.com> <442BD016-E925-4186-9FBA-DA566C5C5886@free.fr> <54EF5D61.8010708@kitware.co m> <61974444-FEDF-4FE0-9FCE-2797CC7DE528@free.fr> <54EF82F9.4000305@kitware.com> <54FEF2E2.1000403@kitware.com> <5501F061.2050401@kitware.com> <55084784. 2000107@kitware.com> Message-ID: <2D45C116-8E65-43EA-AC7C-D711B2740C0E@free.fr> > On 17 Mar 2015, at 16:25, Brad King wrote: > > Nothing right now! I've squashed this all into one commit: > > FindMatlab: Rewrite module and provide a usage API > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=49c8dcf7 > > and merged to 'master' for inclusion in 3.3. > > Thanks for all your work on this and persistence with following up > on feedback. This is a huge improvement over the previous FindMatlab > module. > > -Brad I am happy that it worked! I think everything in http://www.cmake.org/Bug/view.php?id=14641 was addressed. What should the "maintainer" usually do? Best, Raffi From brad.king at kitware.com Tue Mar 17 13:54:44 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 17 Mar 2015 13:54:44 -0400 Subject: [cmake-developers] [PATCH] Fix FindPackageHandleStandardArgs documentation In-Reply-To: <1426368184-56355-1-git-send-email-gjasny@googlemail.com> References: <1426368184-56355-1-git-send-email-gjasny@googlemail.com> Message-ID: <55086A64.7070900@kitware.com> On 03/14/2015 05:23 PM, Gregor Jasny wrote: > this is my first attempt to practice the topic workflow. > I pushed the attached patch to the topic branch and > await review before merging to next. The change looks good. Please change the commit message to start in the line FPHSA: Revise documented command signature We use the "FPHSA: " prefix for changes to that module. Then force-push the topic back to the stage and merge to 'next', please. Thanks, -Brad From brad.king at kitware.com Tue Mar 17 13:56:11 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 17 Mar 2015 13:56:11 -0400 Subject: [cmake-developers] file glob and glob recurse directory listing difference In-Reply-To: References: Message-ID: <55086ABB.60402@kitware.com> On 03/15/2015 06:37 PM, Domen Vrankar wrote: > Alternative would be to define LIST_DIRECTORIES for GLOB_RECURSE only > and preserve back compatibility that way - maybe also define > NO_DIRECTORY_LISTING for GLOB just for the sake of consistency. Let's just define both options for both commands so that it can always be explicitly specified. Thanks, -Brad From brad.king at kitware.com Tue Mar 17 14:10:54 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 17 Mar 2015 14:10:54 -0400 Subject: [cmake-developers] [CMake] Problems with WriteCompilerDetectionHeader and cxx_nullptr In-Reply-To: <79A8C11B-800E-46C2-B462-AA8156C79B41@gmx.at> References: <79A8C11B-800E-46C2-B462-AA8156C79B41@gmx.at> Message-ID: <55086E2E.9010106@kitware.com> On 03/16/2015 03:05 AM, Roman W?ger wrote: > attached is an updated patch. Applied, thanks: WCDH: Fix cxx_nullptr workaround for pre-C++11 compilers http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f9d09626 -Brad From brad.king at kitware.com Tue Mar 17 14:33:45 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 17 Mar 2015 14:33:45 -0400 Subject: [cmake-developers] [PATCH] ABI.h.in: add support for Xtensa architecture In-Reply-To: <1426596664-9910-1-git-send-email-jcmvbkbc@gmail.com> References: <1426596664-9910-1-git-send-email-jcmvbkbc@gmail.com> Message-ID: <55087389.2040205@kitware.com> On 03/17/2015 08:51 AM, Max Filippov wrote: > Signed-off-by: Max Filippov Thanks, applied: KWIML: Teach ABI.h about Xtensa architecture http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ded79a97 Merge branch 'upstream-kwiml' into update-kwiml http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=67940795 -Brad From brad.king at kitware.com Tue Mar 17 14:39:36 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 17 Mar 2015 14:39:36 -0400 Subject: [cmake-developers] Introduction and volunteering for the Matlab package In-Reply-To: <06A0238B-DC3F-401F-9F37-872AE7C07DFA@mines-paris.org> References: <54DE0B41.5080000@kitware.com> <66AF3BFE-070C-4A57-BCBC-4184DB1EB387@free.fr> <54DE1A19.8050403@kitware.com> <54E49E02.5030105@kitware.com> <54E5F072.3090903@kitware.com> <06983E90-D75E-4335-8D02-1D40DF89B9C2@free.fr> <54EB694A.9030605@kitware.com> <7BCB5D1E-275E-43B2-B0FF-0ECEE0A78585@free.fr> <54EDCF04.2000909@kitware.com> <442BD016-E925-4186-9FBA-DA566C5C5886@free.fr> <54EF5D61.8010708@kitware.co m> <61974444-FEDF-4FE0-9FCE-2797CC7DE528@free.fr> <54EF82F9.4000305@kitware.com> <54FEF2E2.1000403@kitware.com> <5501F061.2050401@kitware.com> <55084784. 2000107@kitware.com> <06A0238B-DC3F-401F-9F37-872AE7C07DFA@mines-paris.org> Message-ID: <550874E8.1080202@kitware.com> On 03/17/2015 12:28 PM, Raffi Enficiaud wrote: > I think everything in http://www.cmake.org/Bug/view.php?id=14641 was addressed. > What should the "maintainer" usually do? I've marked your Mantis account as a developer for CMake and assigned the issue to you. In this case since it's already resolved I went ahead and marked the issue as such already. Future issues with this module may be assigned to you. Thanks, -Brad From brad.king at kitware.com Tue Mar 17 14:43:55 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 17 Mar 2015 14:43:55 -0400 Subject: [cmake-developers] Setting unexposed Visual Studio properties from CMake? In-Reply-To: References: Message-ID: <550875EB.30508@kitware.com> On 03/16/2015 10:28 AM, Robert Goulet wrote: > Is there a way to set unexposed Visual Studio properties from CMake? No. Unlike Xcode the number of different places that VS properties go means there is no good equivalent to XCODE_ATTRIBUTE_ for VS (or any other generators AFAIK). > Exposing every single Nsight Tegra build options to CMake is a big job Nevertheless it is the cleanest path forward IMO. Many of them are likely properties corresponding to specific build flags. The way this works for MS tools is to use the reverse mappings builtin to CMake. See Source/cmVS12CLFlagTable.h for example. We currently have no flag table for Nsight Tegra as mentioned in one of the original commit messages: VS: Teach vcxproj generation about the Tegra-Android platform http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ef0fd4f0 -Brad From brad.king at kitware.com Tue Mar 17 15:04:57 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 17 Mar 2015 15:04:57 -0400 Subject: [cmake-developers] .gitattributes updates In-Reply-To: References: Message-ID: <55087AD9.3030900@kitware.com> On 03/15/2015 09:02 PM, Robert Dailey wrote: > I noticed that .gitattributes was not properly configured to utilize > modern Git features: Right, it was written back before Git had the 'text' and 'eol' attributes. Basically the strategy is: * Use '-crlf' for files on which we want no conversion and make sure the repo blobs have the right newlines. * Use 'crlf=input' for shell scripts to guarantee LF newlines. * Let core.autocrlf decide everything else. I personally prefer LF newlines on Windows, for example. I wouldn't mind updating to use the modern capabilities but some of our nightly testing machines may still have Git versions too old to support 'text' and 'eol' so I'm hesitant to change the above. I don't know when I'd have time to check them all. > 3. General cleanup and removal of redundant attributes Note that *.png is in .gitattributes because in some cases Git fails to detect that they are binary and still converts the newlines in the image header text. I'm not aware of anything else in the current .gitattributes that is not needed or is redundant. > 1. Some files were not properly being handled by git What files? Perhaps we can at least get those corrected. FYI, Utilities/cmbzip2/*.dsp are not used and could be deleted. > 2. Git config settings on a per-machine basis affected the EOL > normalization in the repository We have server-side repository checks to prevent CRLF newlines from appearing in files not marked as binary with -crlf. Still, this could be problematic for users working across platforms locally. Thanks, -Brad From brad.king at kitware.com Tue Mar 17 15:18:22 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 17 Mar 2015 15:18:22 -0400 Subject: [cmake-developers] [PATCH v8 0/5] Add XCTest Bundle Support In-Reply-To: <1426359829-33691-1-git-send-email-gjasny@googlemail.com> References: <1426359829-33691-1-git-send-email-gjasny@googlemail.com> Message-ID: <55087DFE.8050003@kitware.com> On 03/14/2015 03:03 PM, Gregor Jasny wrote: > I changed it into a Find module and it looks much more polished > now. Great. > I fully agree that modifying the testee is not something one would > expect when adding a test for it. Therefore I reverted the rpath > setting for Frameworks and replaced it with a DYLD environment > variable when calling xctest. For the App Bundle I reverted your > ENABLE_EXPORTS call and replaced it with Xcode specific settings > for the XCODE generator and a linker flag for the Makefile generator. Okay. > + target_link_libraries(${target} > + PRIVATE "-bundle_loader $") Please try using this in a CMake source/build tree each with spaces in the path. Quoting may need updating; perhaps: target_link_libraries(${target} PRIVATE -bundle_loader $) > Once you ACK the series I will create a topic branch and follow > the developer instructions. Please proceed. Thanks, -Brad From brad.king at kitware.com Tue Mar 17 15:41:17 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 17 Mar 2015 15:41:17 -0400 Subject: [cmake-developers] RFC: Helper macros for writing Find modules In-Reply-To: <4542775.7tyAsShsiA@kyoshi> References: <4542775.7tyAsShsiA@kyoshi> Message-ID: <5508835D.40705@kitware.com> On 03/13/2015 06:04 AM, Alex Merry wrote: > For the extra-cmake-modules package, I wrote some macros to help with writing > component-based Find modules, which are non-trivial to get right. > > The documentation for them can be found here: > http://api.kde.org/ecm/module/ECMFindModuleHelpers.html > > I've found them incredibly useful in writing classic Find modules, where you > just want to find a bunch of libraries and their associated headers, but you > also need to account for the dependencies between those libraries. Thanks. I've read through the file here: http://quickgit.kde.org/?p=extra-cmake-modules.git&a=blob&f=modules/ECMFindModuleHelpers.cmake&hb=v1.8.0 > # ecm_find_package_version_check() This one does not look relevant to CMake upstream. > # ecm_find_package_parse_components( > # RESULT_VAR > # KNOWN_COMPONENTS [ [...]] > # [SKIP_DEPENDENCY_HANDLING]) [snip] > # ecm_find_package_handle_library_components( > # COMPONENTS [ [...]] > # [SKIP_DEPENDENCY_HANDLING]) > # [SKIP_PKG_CONFIG]) These look like they take care of a lot of logic common to many find modules and could be useful upstream. They could also help make the find modules have a more consistent interface. I'd appreciate feedback on them from other upstream find module maintainers though. One comment is that they may be a little too all-encompassing and not very adaptable to slight variations from the standard cases. Perhaps that can be addressed with more options if needed. Also one could later factor some of the parts out into more granular helpers that could be used individually. If we upstream any of these I think we could create a CMakeFindModuleHelpers module that includes FindPackageHandleStandardArgs and also provides other helpers. That way individual modules would only have to include one other module to get the helpers. > The interface is a little unusual: you have to set up some information- > providing variables before calling the macros to describe the information > for each component. I think that is okay. The pre-set variables are more like tables of information AFAICT. FYI, see this change where I dropped a recommendation for find module authors that IIRC came from your ECM work: Help: Drop FeatureSummary example in cmake-developer.7 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8235effe I think it is a good convention to have, and I'm glad ECM has it, but would prefer it be established upstream only with a sweeping effort to cover many of the existing modules in a consistent way. > FindWayland.cmake (which I would also submit for inclusion to CMake). I haven't looked at FindWayland in detail yet, but is its design generic enough to be able to find varying Wayland implementations in the future? Should it be called FindWeston instead? Perhaps this is a discussion for a future thread after the above is resolved though. Thanks, -Brad From brad.king at kitware.com Tue Mar 17 15:56:18 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 17 Mar 2015 15:56:18 -0400 Subject: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support In-Reply-To: References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com> <54E365F4.3030104@kitware.com> <54E7542D.6050808@kitware.com> <54EB68C8.7030504@kitware.com> <54F0952B.5070809@kitware.com> <54F4781A.80708@kitware.com> <54FEF1C1.4030106@kitware.com> <5501F487.10807@kitware.com> Message-ID: <550886E2.1020708@kitware.com> On 03/16/2015 02:03 AM, Geoffrey Viola wrote: > Done Thanks for the updates. I just noticed that in some of the new C++ sources you copied the copyright block from other files but forgot to change the notice lines to refer to yourself or your employer. Certainly the current lines do not refer to the author of the content ;) > Added some documentation. Good start. Please adjust the section header underlines to match the length of the title text. Also, the new variable/GHS-MULTI document needs to be added to the toctree in 'Help/manual/cmake-variables.7.rst'. This time I actually tried building the sources. Some of the classes prefix their inline method definitions: cmGlobalGhsMultiGenerator::GetGhsBuildCommand This is not necessary when it is inside the class, and some compilers do not like it. Also the new lines you added to Source/cmake.cxx need to be made conditional on the platform. The CMakeLists.txt file already contains the proper platform conditions, so use of the new generator must match. > I'm not quite sure why my FindModulesExecuteAll test fails. > Seems like boost installation issue, but it isn't an issue > in my nighlty test Whether boost is found may depend on the environment, and your nightly test wipes out PATH. Thanks, -Brad From raffi.enficiaud at free.fr Tue Mar 17 17:23:19 2015 From: raffi.enficiaud at free.fr (Raffi Enficiaud) Date: Tue, 17 Mar 2015 22:23:19 +0100 Subject: [cmake-developers] Introduction and volunteering for the Matlab package In-Reply-To: <550874E8.1080202@kitware.com> References: <54DE0B41.5080000@kitware.com> <66AF3BFE-070C-4A57-BCBC-4184DB1EB387@free.fr> <54DE1A19.8050403@kitware.com> <54E49E02.5030105@kitware.com> <54E5F072.3090903@kitware.com> <06983E90-D75E-4335-8D02-1D40DF89B9C2@free.fr> <54EB694A.9030605@kitware.com> <7BCB5D1E-275E-43B2-B0FF-0ECEE0A78585@free.fr> <54EDCF04.2000909@kitware.com> <442BD016-E925-4186-9FBA-DA566C5C5886@free.fr> <54EF5D61.8010708@kitware.co m> <61974444-FEDF-4FE0-9FCE-2797CC7DE528@free.fr> <54EF82F9.4000305@kitware.com> <54FEF2E2.1000403@kitware.com> <5501F061.2050401@kitware.com> <55084784. 2000107@kitware.com> <06A0238B-DC3F-401F-9F37-872AE7C07DFA@mines-pari s.org> <550874E8.1080202@kitware.com> Message-ID: > On 17 Mar 2015, at 19:39, Brad King wrote: > > On 03/17/2015 12:28 PM, Raffi Enficiaud wrote: >> I think everything in http://www.cmake.org/Bug/view.php?id=14641 was addressed. >> What should the "maintainer" usually do? > > I've marked your Mantis account as a developer for CMake and assigned > the issue to you. In this case since it's already resolved I went ahead > and marked the issue as such already. Future issues with this module may > be assigned to you. > > Thanks, > -Brad > Very good, and many thanks for your support, Best, Raffi From ono at java.pl Tue Mar 17 17:50:58 2015 From: ono at java.pl (Adam Strzelecki) Date: Tue, 17 Mar 2015 22:50:58 +0100 Subject: [cmake-developers] Explicit custom command BYPRODUCTS In-Reply-To: References: <546A26AF.7080400@kitware.com> Message-ID: Guys, Does this BYPRODUCTS extension landed into 3.2? If yes, is there any new POLICY to tell CMake to stop generating implicit phony rules for Ninja as proposed in: http://permalink.gmane.org/gmane.comp.programming.tools.cmake.devel/11208 Reason I am asking, that Amine from ReactOS just pinged me on IRC asking about their unresolved Ninja crashing issue. Any idea how we can help them? -- Adam From mantis at public.kitware.com Tue Mar 17 20:19:39 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 17 Mar 2015 20:19:39 -0400 Subject: [cmake-developers] [CMake 0015454]: Ninja generator should not generate phony commands with cyclic dependency Message-ID: <56d19f43fd281edf5c248b542dc67f7e@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15454 ====================================================================== Reported By: Daniel Dunbar Assigned To: ====================================================================== Project: CMake Issue ID: 15454 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-17 20:19 EDT Last Modified: 2015-03-17 20:19 EDT ====================================================================== Summary: Ninja generator should not generate phony commands with cyclic dependency Description: The Ninja generator frequently will generate commands of the form: -- build testCCompiler.c: phony testCCompiler.c -- (taken from the build.ninja generated for the initial "-- Check for working C compiler using: Ninja" step). This command specifies a cyclic dependency, even though Ninja itself does not generally error on it: https://github.com/martine/ninja/issues/935 Steps to Reproduce: Here is a self contained example: -- $ cat CMakeLists.txt cmake_minimum_required(VERSION 3.0) add_custom_command(OUTPUT foo.tmp DEPENDS foo.c COMMAND true) add_custom_target(foo DEPENDS foo.tmp) $ cmake -GNinja . -- Configuring done -- Generating done -- Build files have been written to: /tmp/foo $ grep "foo.c:" build.ninja build foo.c: phony foo.c -- ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-17 20:19 Daniel Dunbar New Issue ====================================================================== From aklitzing at gmail.com Wed Mar 18 03:24:36 2015 From: aklitzing at gmail.com (A. Klitzing) Date: Wed, 18 Mar 2015 08:24:36 +0100 Subject: [cmake-developers] Support of codesign In-Reply-To: References: <1678645.2J7lYulytt@stryke> <2830805.x682EbQycE@stryke> Message-ID: Ping? :-) Am 11.03.2015 13:21 schrieb "A. Klitzing" : > Hi there! > > I added another improvement to the codesign feature. Sometimes it is > helpful to overwrite or pass additional parameters like "--timestamp=none" > to codesign. > But this shouldn't be the default for everyone. > > So I added the variable CPACK_BUNDLE_APPLE_CODESIGN_PARAMETER. > Hope you like it. > > Regards > Andr? > > > 2015-02-20 16:20 GMT+01:00 Clinton Stimpson : > >> On Friday, February 20, 2015 12:07:55 PM A. Klitzing wrote: >> > Hi Clint, >> > >> > I have another patch to tweak the error output a little bit. If codesign >> > fails it won't be possible to get the error message of codesign itself. >> > That is a little bit confusing because it just fails without an >> > understandable reason. >> > >> > This patch will print the output of codesign if it fails. >> > >> >> Thanks. >> >> >> >> Clint >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hunger at gmail.com Wed Mar 18 04:06:51 2015 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Wed, 18 Mar 2015 09:06:51 +0100 Subject: [cmake-developers] Generating buildsystem metadata from CMake In-Reply-To: References: Message-ID: On Wed, Mar 11, 2015 at 11:10 AM, Stephen Kelly wrote: > * Make it possible for editors/IDEs to allow specifying the configuration > at build-time, where the IDE has that feature, and where a multi-config > generator is available. That is, QtCreator provides user-interface for > choosing debug/release config to build. Currently it can't offer that > when using cmake, because it only allows the use of Makefile or Ninja > generators, in order to make use of the C::B file. QtCreator should be > able to use the Xcode or Visual Studio generators, generate the metadata > file(s), and invoke `cmake --build . --config ${CONFIG}` as > appropriate. Eclipse, Sublime and other editors have similar abilities > to invoke config-specific builds after generation. We can offer debug/release even with different build directories in Creator. Those are just labels on the build configuration that includes the build directory and the configuration to be set up in that build. For the other build systems it is completely safe to just nuke any build directory and creator will re-initialize it on the next build. That is unfortunately not the case with cmake at this time though: If you nuke a cmake build directory then creator will be completely lost about how to regenerate the configuration again. From dpolyanitsa at nvidia.com Wed Mar 18 07:39:02 2015 From: dpolyanitsa at nvidia.com (Dmitry Polyanitsa) Date: Wed, 18 Mar 2015 11:39:02 +0000 Subject: [cmake-developers] Setting unexposed Visual Studio properties from CMake? In-Reply-To: <550875EB.30508@kitware.com> References: <550875EB.30508@kitware.com> Message-ID: <2181c1ef36d04522bd568c7b2b279b9f@UKMAIL102.nvidia.com> We're definitely planning to do this, but it's a big action item and we're still prioritizing it. -Dmitry -----Original Message----- From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Brad King Sent: Tuesday, March 17, 2015 9:44 PM To: Robert Goulet Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] Setting unexposed Visual Studio properties from CMake? On 03/16/2015 10:28 AM, Robert Goulet wrote: > Is there a way to set unexposed Visual Studio properties from CMake? No. Unlike Xcode the number of different places that VS properties go means there is no good equivalent to XCODE_ATTRIBUTE_ for VS (or any other generators AFAIK). > Exposing every single Nsight Tegra build options to CMake is a big job Nevertheless it is the cleanest path forward IMO. Many of them are likely properties corresponding to specific build flags. The way this works for MS tools is to use the reverse mappings builtin to CMake. See Source/cmVS12CLFlagTable.h for example. We currently have no flag table for Nsight Tegra as mentioned in one of the original commit messages: VS: Teach vcxproj generation about the Tegra-Android platform http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ef0fd4f0 -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 ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- From gjasny at googlemail.com Wed Mar 18 10:41:29 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Wed, 18 Mar 2015 15:41:29 +0100 Subject: [cmake-developers] [PATCH v8 0/5] Add XCTest Bundle Support In-Reply-To: <55087DFE.8050003@kitware.com> References: <1426359829-33691-1-git-send-email-gjasny@googlemail.com> <55087DFE.8050003@kitware.com> Message-ID: <55098E99.8070502@googlemail.com> On 17/03/15 20:18, Brad King wrote: >> + target_link_libraries(${target} >> + PRIVATE "-bundle_loader $") > > Please try using this in a CMake source/build tree each with spaces > in the path. Quoting may need updating; perhaps: > > target_link_libraries(${target} > PRIVATE -bundle_loader $) You were right. These lines needed removal of surrounding ". >> Once you ACK the series I will create a topic branch and follow >> the developer instructions. > > Please proceed. Pushed to topic xcode-xctest. Please review and I'll merge to next. (Or you merge it to keep round-trips shorter). Thanks, Gregor From mantis at public.kitware.com Wed Mar 18 11:40:53 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 18 Mar 2015 11:40:53 -0400 Subject: [cmake-developers] [CMake 0015455]: Xcode 6.2 cannot be detected Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15455 ====================================================================== Reported By: qklxtlx Assigned To: ====================================================================== Project: CMake Issue ID: 15455 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-18 11:40 EDT Last Modified: 2015-03-18 11:40 EDT ====================================================================== Summary: Xcode 6.2 cannot be detected Description: After upgrading to Xcode 6.2 with corresponding command line tools, I cannot generate xcodeproj any more. Unix Makefile works correctly though. Steps to Reproduce: A simple CMakeLists.txt: project(HELLO) set(SRC_LIST main.c) add_executable(hello ${SRC_LIST}) This is the error log with `cmake -G "Xcode" .` ? /Users/anthony/Downloads/test >cmake -G "Xcode" . -- The C compiler identification is unknown -- The CXX compiler identification is unknown -- Check for working C compiler using: Xcode -- Check for working C compiler using: Xcode -- broken CMake Error at /usr/local/Cellar/cmake/3.2.1/share/cmake/Modules/CMakeTestCCompiler.cmake:61 (message): The C compiler "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" is not able to compile a simple test program. It fails with the following output: Change Dir: /Users/anthony/Downloads/test/CMakeFiles/CMakeTmp Run Build Command:"/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild" "-project" "CMAKE_TRY_COMPILE.xcodeproj" "build" "-target" "cmTryCompileExec1075155225" "-configuration" "Debug" === BUILD TARGET cmTryCompileExec1075155225 OF PROJECT CMAKE_TRY_COMPILE WITH CONFIGURATION Debug === Check dependencies Write auxiliary files /bin/mkdir -p /Users/anthony/Downloads/test/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTryCompileExec1075155225.build/Objects-normal/x86_64 write-file /Users/anthony/Downloads/test/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTryCompileExec1075155225.build/Objects-normal/x86_64/cmTryCompileExec1075155225.LinkFileList CompileC CMAKE_TRY_COMPILE.build/Debug/cmTryCompileExec1075155225.build/Objects-normal/x86_64/testCCompiler.o testCCompiler.c normal x86_64 c com.apple.compilers.llvm.clang.1_0.compiler cd /Users/anthony/Downloads/test/CMakeFiles/CMakeTmp export LANG=en_US.US-ASCII /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x c -arch x86_64 -fmessage-length=0 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit=0 -Wno-trigraphs -fpascal-strings -O0 -Wno-missing-field-initializers -Wno-missing-prototypes -Wno-return-type -Wno-missing-braces -Wparentheses -Wswitch -Wno-unused-function -Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wunused-value -Wno-empty-body -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-bool-conversion -Wno-enum-conversion -Wno-shorten-64-to-32 -Wpointer-sign -Wno-newline-eof -DCMAKE_INTDIR=\"Debug\" -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk -fasm-blocks -fstrict-aliasing -Wdeprecated-declarations -mmacosx-version-min=10.10 -Wno-sign-conversion -I/Users/anthony/Downloads/test/CMakeFiles/CMakeTmp/Debug/include -I/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include -I/Users/anthony/Downloads/test/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTryCompileExec1075155225.build/DerivedSources/x86_64 -I/Users/anthony/Downloads/test/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTryCompileExec1075155225.build/DerivedSources -Wmost -Wno-four-char-constants -Wno-unknown-pragmas -F/Users/anthony/Downloads/test/CMakeFiles/CMakeTmp/Debug -MMD -MT dependencies -MF /Users/anthony/Downloads/test/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTryCompileExec1075155225.build/Objects-normal/x86_64/testCCompiler.d --serialize-diagnostics /Users/anthony/Downloads/test/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTryCompileExec1075155225.build/Objects-normal/x86_64/testCCompiler.dia -c /Users/anthony/Downloads/test/CMakeFiles/CMakeTmp/testCCompiler.c -o /Users/anthony/Downloads/test/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTryCompileExec1075155225.build/Objects-normal/x86_64/testCCompiler.o Ld Debug/cmTryCompileExec1075155225 normal x86_64 cd /Users/anthony/Downloads/test/CMakeFiles/CMakeTmp export MACOSX_DEPLOYMENT_TARGET=10.10 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk -L/Users/anthony/Downloads/test/CMakeFiles/CMakeTmp/Debug -F/Users/anthony/Downloads/test/CMakeFiles/CMakeTmp/Debug -filelist /Users/anthony/Downloads/test/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTryCompileExec1075155225.build/Objects-normal/x86_64/cmTryCompileExec1075155225.LinkFileList -mmacosx-version-min=10.10 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -force_load /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/CoreService.framework/CoreService -Xlinker -dependency_info -Xlinker /Users/anthony/Downloads/test/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTryCompileExec1075155225.build/Objects-normal/x86_64/cmTryCompileExec1075155225_dependency_info.dat -o /Users/anthony/Downloads/test/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec1075155225 ld: warning: ObjC object file (/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/CoreService.framework/CoreService) was compiled for iOS Simulator, but linking for MacOSX ld: framework not found CoreImage for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) ** BUILD FAILED ** The following build commands failed: Ld Debug/cmTryCompileExec1075155225 normal x86_64 (1 failure) CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:1 (project) -- Configuring incomplete, errors occurred! See also "/Users/anthony/Downloads/test/CMakeFiles/CMakeOutput.log". See also "/Users/anthony/Downloads/test/CMakeFiles/CMakeError.log". ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-18 11:40 qklxtlx New Issue ====================================================================== From mantis at public.kitware.com Wed Mar 18 12:38:15 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 18 Mar 2015 12:38:15 -0400 Subject: [cmake-developers] [CMake 0015456]: Ninja manifests generated for CMake configuration steps should probably not have RERUN_CMAKE steps Message-ID: <5c30f2ad8eeebbc28a34ce800c918d03@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15456 ====================================================================== Reported By: Daniel Dunbar Assigned To: ====================================================================== Project: CMake Issue ID: 15456 Category: (No Category) Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-18 12:38 EDT Last Modified: 2015-03-18 12:38 EDT ====================================================================== Summary: Ninja manifests generated for CMake configuration steps should probably not have RERUN_CMAKE steps Description: The Ninja manifests that CMake generates as part of its initial configuration (e.g., checking if the C compiler works) include the commands to rerun the generator, even though it would never make sense for the generator to automatically be rerun by Ninja in such a context. This is wasteful of space/time in the manifest, but it also could be a serious problem if something ever causes Ninja to want to rerun the generator at that point. If it did, it could end up rerunning the same configuration checks (but under CMakeFiles/CMakeTmp), which would then trigger an infinite loop of configuration checks (in ever deepening CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/...). -- The reason why I noticed this problem is that I was looking at Ninja's behavior w.r.t. skipping rerunning of command when it is newer than the inputs. Ninja will currently skip running a command when the output has the same timestamp as the newest input. On OS X, this is not particularly safe, as the HFS filesystem has a 1s resolution on the mod times, and so it is very easy for the input to be "newer" than (modified after) the output and still not get rebuilt by Ninja. I was curious if changing Ninja to use a strict newer-than check would work. The way this relates to the aforementioned issue is that the RERUN_CMAKE command in the build.ninja files generated for the configuration checks depend on other .cmake files generated at the same time, and they are very likely to have the same timestamp on OS X. If Ninja did a more strict check here, it would cause it to rerun the generator as part of the configuration commands, and trigger an infinite loop... see steps to reproduce. It seems like it would be safer and more efficient to avoid generating the RERUN_CMAKE rules into these build.ninja files in the first place. Steps to Reproduce: There isn't a trivial way to see this problem, but if you build a custom version of Ninja that uses a stricter newer-than check for comparing outputs to inputs using the following patch (against 717619a260633ca0e7c9eb2366130fc06ebacfff): -- diff --git a/src/graph.cc b/src/graph.cc index 76c4e9a..4b45015 100644 --- a/src/graph.cc +++ b/src/graph.cc @@ -148,7 +148,7 @@ bool DependencyScan::RecomputeOutputDirty(Edge* edge, } // Dirty if the output is older than the input. - if (most_recent_input && output->mtime() < most_recent_input->mtime()) { + if (most_recent_input && output->mtime() <= most_recent_input->mtime()) { TimeStamp output_mtime = output->mtime(); // If this is a restat rule, we may have cleaned the output with a restat @@ -162,7 +162,7 @@ bool DependencyScan::RecomputeOutputDirty(Edge* edge, used_restat = true; } - if (output_mtime < most_recent_input->mtime()) { + if (output_mtime <= most_recent_input->mtime()) { EXPLAIN("%soutput %s older than most recent input %s " "(%d vs %d)", used_restat ? "restat of " : "", output->path().c_str(), -- then you can reproduce the problem trivially with an empty CMakeLists.txt: -- $ ls -la CMakeLists.txt -rw-r--r-- 1 ddunbar staff 35 Mar 18 09:34 CMakeLists.txt $ cmake -GNinja . -- The C compiler identification is AppleClang 7.0.0.7000009 -- The CXX compiler identification is AppleClang 7.0.0.7000009 -- Check for working C compiler using: Ninja C-c C-c $ find CMakeFiles | head -50 CMakeFiles CMakeFiles/3.2.1 CMakeFiles/3.2.1/CMakeCCompiler.cmake CMakeFiles/3.2.1/CMakeCXXCompiler.cmake CMakeFiles/3.2.1/CMakeSystem.cmake CMakeFiles/3.2.1/CompilerIdC CMakeFiles/3.2.1/CompilerIdC/CMakeCCompilerId.c CMakeFiles/3.2.1/CompilerIdC/a.out CMakeFiles/3.2.1/CompilerIdCXX CMakeFiles/3.2.1/CompilerIdCXX/CMakeCXXCompilerId.cpp CMakeFiles/3.2.1/CompilerIdCXX/a.out CMakeFiles/CMakeOutput.log CMakeFiles/CMakeTmp CMakeFiles/CMakeTmp/.ninja_deps CMakeFiles/CMakeTmp/.ninja_log CMakeFiles/CMakeTmp/CMakeCache.txt CMakeFiles/CMakeTmp/CMakeFiles CMakeFiles/CMakeTmp/CMakeFiles/3.2.1 CMakeFiles/CMakeTmp/CMakeFiles/3.2.1/CMakeCCompiler.cmake CMakeFiles/CMakeTmp/CMakeFiles/3.2.1/CMakeSystem.cmake CMakeFiles/CMakeTmp/CMakeFiles/3.2.1/CompilerIdC CMakeFiles/CMakeTmp/CMakeFiles/3.2.1/CompilerIdC/CMakeCCompilerId.c CMakeFiles/CMakeTmp/CMakeFiles/3.2.1/CompilerIdC/a.out CMakeFiles/CMakeTmp/CMakeFiles/CMakeOutput.log CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/.ninja_deps CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/.ninja_log CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeCache.txt CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles/3.2.1 CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles/3.2.1/CMakeCCompiler.cmake CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles/3.2.1/CMakeSystem.cmake CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles/3.2.1/CompilerIdC CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles/3.2.1/CompilerIdC/CMakeCCompilerId.c CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles/3.2.1/CompilerIdC/a.out CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles/CMakeOutput.log CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/.ninja_deps CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/.ninja_log CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeCache.txt CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles/3.2.1 CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles/3.2.1/CMakeCCompiler.cmake CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles/3.2.1/CMakeSystem.cmake CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles/3.2.1/CompilerIdC CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles/3.2.1/CompilerIdC/CMakeCCompilerId.c CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles/3.2.1/CompilerIdC/a.out CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles/CMakeOutput.log CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp/.ninja_deps $ -- ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-18 12:38 Daniel Dunbar New Issue ====================================================================== From brad.king at kitware.com Wed Mar 18 13:16:01 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 18 Mar 2015 13:16:01 -0400 Subject: [cmake-developers] Explicit custom command BYPRODUCTS In-Reply-To: References: <546A26AF.7080400@kitware.com> Message-ID: <5509B2D1.90303@kitware.com> On 03/17/2015 05:50 PM, Adam Strzelecki wrote: > Does this BYPRODUCTS extension landed into 3.2? Yes. > is there any new POLICY to tell CMake to stop generating > implicit phony rules for Ninja as proposed in: Not yet. For out-of-source builds the only place that the phony rules can show up is for custom command dependencies in the build tree that are not the OUTPUT of other custom commands. With 3.2 now that list can be cut further by listing BYPRODUCTS for those custom commands that produce them. IIUC the remaining issue is that for in-source builds all the custom command dependencies on source files now get phony rules. We need a policy to drop this behavior altogether and ask that projects explicitly specify their BYPRODUCTS. Correct? Thanks, -Brad From ono at java.pl Wed Mar 18 13:41:17 2015 From: ono at java.pl (Adam Strzelecki) Date: Wed, 18 Mar 2015 18:41:17 +0100 Subject: [cmake-developers] Explicit custom command BYPRODUCTS In-Reply-To: <5509B2D1.90303@kitware.com> References: <546A26AF.7080400@kitware.com> <5509B2D1.90303@kitware.com> Message-ID: > IIUC the remaining issue is that for in-source builds all the > custom command dependencies on source files now get phony > rules. We need a policy to drop this behavior altogether and > ask that projects explicitly specify their BYPRODUCTS. > Correct? Yes that is correct. And this is the case of ReactOS, they are perfectly sure they do not have any side-effect, they do not need these extra rules, yet there is no mechanism to avoid them. As a result Ninja crashes because it has simply too big build graph. -- Adam From mantis at public.kitware.com Wed Mar 18 14:37:50 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 18 Mar 2015 14:37:50 -0400 Subject: [cmake-developers] [CMake 0015457]: ninja generator relinks all executables after incremental build in LLVM due to extra .lib output file Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15457 ====================================================================== Reported By: Reid Kleckner Assigned To: ====================================================================== Project: CMake Issue ID: 15457 Category: (No Category) Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-18 14:37 EDT Last Modified: 2015-03-18 14:37 EDT ====================================================================== Summary: ninja generator relinks all executables after incremental build in LLVM due to extra .lib output file Description: Old versions of cmake would generate this ninja target: build bin\opt.exe: CXX_EXECUTABLE_LINKER ... Recent versions (3.2+) generate this target: build bin\opt.exe lib\opt.lib: CXX_EXECUTABLE_LINKER_RSP_FILE Since this is an executable, no .lib file should be generated, right? Why does the linker build rule even list the /implib flag? Maybe this is some functionality I'm unaware of, but so far as I can tell it is extraneous. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-18 14:37 Reid Kleckner New Issue ====================================================================== From alex.merry at kde.org Wed Mar 18 17:50:05 2015 From: alex.merry at kde.org (Alex Merry) Date: Wed, 18 Mar 2015 21:50:05 +0000 Subject: [cmake-developers] RFC: Helper macros for writing Find modules In-Reply-To: <5508835D.40705@kitware.com> References: <4542775.7tyAsShsiA@kyoshi> <5508835D.40705@kitware.com> Message-ID: <4223239.nbSvzUmUOe@kyoshi> On Tuesday 17 March 2015 15:41:17 Brad King wrote: > On 03/13/2015 06:04 AM, Alex Merry wrote: > > For the extra-cmake-modules package, I wrote some macros to help with > > writing component-based Find modules, which are non-trivial to get right. > > > > The documentation for them can be found here: > > http://api.kde.org/ecm/module/ECMFindModuleHelpers.html > > > > I've found them incredibly useful in writing classic Find modules, where > > you just want to find a bunch of libraries and their associated headers, > > but you also need to account for the dependencies between those > > libraries. > Thanks. I've read through the file here: > > http://quickgit.kde.org/?p=extra-cmake-modules.git&a=blob&f=modules/ECMFind > ModuleHelpers.cmake&hb=v1.8.0 > > # ecm_find_package_version_check() > > This one does not look relevant to CMake upstream. Yep, I can't imagine that being useful outside ECM. > > # ecm_find_package_parse_components( > > # RESULT_VAR > > # KNOWN_COMPONENTS [ [...]] > > # [SKIP_DEPENDENCY_HANDLING]) > > [snip] > > > # ecm_find_package_handle_library_components( > > # COMPONENTS [ [...]] > > # [SKIP_DEPENDENCY_HANDLING]) > > # [SKIP_PKG_CONFIG]) > > These look like they take care of a lot of logic common to many find > modules and could be useful upstream. They could also help make the > find modules have a more consistent interface. I'd appreciate feedback > on them from other upstream find module maintainers though. > > One comment is that they may be a little too all-encompassing and not > very adaptable to slight variations from the standard cases. Perhaps > that can be addressed with more options if needed. Also one could > later factor some of the parts out into more granular helpers that > could be used individually. I made some changes in a copy of this module for work that separated out the target creation, as well as adding debug/release support. I'll check about being allowed to release that work, but I doubt it'll be an issue. > If we upstream any of these I think we could create a CMakeFindModuleHelpers > module that includes FindPackageHandleStandardArgs and also provides other > helpers. That way individual modules would only have to include one other > module to get the helpers. That was pretty much what I was thinking of. Including FindPackageHandleStandardArgs seems sensible as well. > > The interface is a little unusual: you have to set up some information- > > providing variables before calling the macros to describe the information > > for each component. > > I think that is okay. The pre-set variables are more like tables > of information AFAICT. Yep, that's exactly what they are. > FYI, see this change where I dropped a recommendation for find > module authors that IIRC came from your ECM work: > > Help: Drop FeatureSummary example in cmake-developer.7 > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8235effe > > I think it is a good convention to have, and I'm glad ECM has it, > but would prefer it be established upstream only with a sweeping > effort to cover many of the existing modules in a consistent way. One issue I realised with this after the fact is that it works poorly with *Config.cmake files - if there is no find module, and the package is not found, the URL telling you how to get hold of it would be missing unless you add it at the find_package call site. > > FindWayland.cmake (which I would also submit for inclusion to CMake). > > I haven't looked at FindWayland in detail yet, but is its design generic > enough to be able to find varying Wayland implementations in the future? > Should it be called FindWeston instead? Perhaps this is a discussion > for a future thread after the above is resolved though. As far as I'm aware, the stuff that FindWayland finds is libraries designed for writing a wayland implementation - ie: it's the protocol layer. It was originally written partly to benefit KWin, which at least plans to be a Wayland implementation of its own. I may be wrong about that, though. Alex From mantis at public.kitware.com Wed Mar 18 18:32:34 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 18 Mar 2015 18:32:34 -0400 Subject: [cmake-developers] [CMake 0015458]: New Functionality to Restore Directory Attributes Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15458 ====================================================================== Reported By: Axl Assigned To: ====================================================================== Project: CMake Issue ID: 15458 Category: CMake Reproducibility: always Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-18 18:32 EDT Last Modified: 2015-03-18 18:32 EDT ====================================================================== Summary: New Functionality to Restore Directory Attributes Description: As documented in a feature request in http://www.cmake.org/Bug/view.php?id=14415 there is currently no functionality available to restore attributes such as "is marked as a system path" from directories, e.g., for calls to get_directory_property(INCLUDE_DIRECTORIES) Being able to read such information again would be beneficial, e.g., for modules such as FindCUDA that have to forward the include directories to a wrapped compiler or similar. Right now, that is not possible, causing very noisy output for warnings caused by header files - and users of these libraries have no chance to mute them accordingly. Steps to Reproduce: For an example, see the RFE in FindCUDA http://www.cmake.org/Bug/view.php?id=14415 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-18 18:32 Axl New Issue ====================================================================== From justin.borodinsky at gmail.com Wed Mar 18 21:46:15 2015 From: justin.borodinsky at gmail.com (Justin Borodinsky) Date: Wed, 18 Mar 2015 20:46:15 -0500 Subject: [cmake-developers] AutogenInfo.cmake With Read-Only Modules Message-ID: <550A2A67.3030600@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I ran into an issue when the Modules directory is read-only, I received a "Internal CMake error when trying to open file"... from cmQtAutoGenerators. ConfigureFile use the source file's permissions, but cmQtAutoGenerators::SetupAutoGenerateTarget requires write access. The attached patch is a quick work-around. - -- Thanks, Justin -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVCipnAAoJEJaK8jpvPrt2hYsP/izxGsO7aqicMv+w6sEGVwbq cvknvxMAluAeJytr31ENFdvPC8NpO3EC/OgnP7JXwTwYXtjzV0IHE4qOlPApcYo4 Id/Wh2ZS5KJsBB0lQhOXwG7XlAmIli49SaYYii6/zAnWnlu19Bf3Wsvt/zDlsH2D 7G5gm/8ToxX0UpBktOx8e3sLsTTHVkeqSCTEvDqTsM9OvAizX2waDmuCvLp2GDS5 rQfxxkl78199UVA7YuGDz0mo20OOaW5RqUmWnV+oOR9HN9LfnvzP/6sgJvmOW/I6 vk4PEHsTXvwPv17z+hSS85R9UlSTVj67Yyk5GfzQ8GAYsYecfLyoXOGocka9jQ1F +Oa9K5m8heKfmj5ldTn9qGCvrkFcffQqEtgcoyX0ELVaH9JcNFGEAN33JWMAuNA9 W1eyoO9Wzvd2i+S/TEpiLwsPtXXijTsBZeFfpD7+08LT0dvQ58XbT6PkJi/qOUGT +0zODeKhsj2NH5PR7MLUK6Efh5/beAXAiN9q/FyjeBPQhIGDx8g+G7OXmcgu3tLd GaVWx/GII3uqZoTMDKdg+KEKt7eBpQGgcrav5idNHldRhCWYG2zHfB8UnNOJvHr/ AkBpHRF7XRcYSHKHwTB0BLV7gBzVl1lX0+RXN3cpdEWJNatkeFvnS7A03UU3sLM1 NmV2qo+eZNjTeVR++dNJ =WVVL -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-ensure-write-access-to-AutogenInfo.cmake.patch Type: text/x-patch Size: 1374 bytes Desc: not available URL: From steveire at gmail.com Wed Mar 18 21:22:11 2015 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 19 Mar 2015 02:22:11 +0100 Subject: [cmake-developers] Generating buildsystem metadata from CMake References: Message-ID: Tobias Hunger wrote: > Hi Stephen, > > sorry for being late to the party again:-) > > I am just reading your documentation. Great, thanks for all this. Did you also read the unit test and generated file? I'm working on updating my branch based on all of the feedback in this thread so far. > > Some nits: > > * In the "Introduction" you say CMAKE_GENERATE_METADATA needs to be > ON, in "Generating Metadata" it needs to be set to a version number. Thanks, fixed locally. > * In "Target Properties/Conditional Properties", "backtrace": Which > frame is the current one? The top one or the bottom one? I've seen > both approaches in the wild:-) Documented as 'most recent first' locally. > * In "Target Properties/Conditional Properties and optional > properties": Would it make sense to have a list of target_files, each > with a filepath and a type? That would be more similar to the targets > which also are a list with name/type. What semantics would the 'type' have? I don't really understand what you propose here. > Are these paths in the build or in the install location? These paths are all absolute - they are most likely either in the source or build location. The user is free to specify any local file though of course. > * In "Metadata Contents/Optional Properties" you propose to have > several language specific properties. Would it make sense to group > those together into one "language" property? > * In "Target Properties/Conditional Optional Properties": Again, > wouldn't a set of sources arrays with a list of filepaths and all the > related meta information for this set of files be nicer? That way all > the "language fallback properties" and "source file properties" would > be in one place. > > Somewhat like this (going with JSON-ish syntax here for ease of > writing): > > sources: [ { > language: "C++", > type: sources, > defines: "FOO=1", > include_paths: "/usr/include", > files: [ "/full/path/a.cpp", "/full/path/b.cpp" ] > }, > { > language: "C++", > type: headers, > files: [ "/full/path/a.h" ] > }, > { > language: "C++", > type: generated, > files: [ "/full/path/config.h" ] > }] >> * I propose generating language-specific source lists, because CMake can >> build files with compilers which do not match their file extension. > > Makes a lot of sense, even though I am not too happy with the syntax. > See the nits above. Yes, there are clearly many options for how to organize this information. I'll see about gathering them and working what code using each different option would look like. > This can express defines set for individual files, which I think you > can have in CMake, can't you? Yep. > I do not see how to express that within your proposal. See the Tests/Metadata/cmake-metadata-Linux-GNU-4.9.json file I checked into the repo, which contains a sources property for specifying those source-specific properties. > The rest of my replies are inline: > > On Wed, Mar 11, 2015 at 11:10 AM, Stephen Kelly > wrote: >> I expect to require a few iterations to figure out what the metadata >> files >> should contain in the end. Note that there are already some differences >> between my design and Aleix's implementation, such as that my design >> proposes one metadata file per config. There are also some things >> missing like location, because it is not yet clear to me whether build >> or install locations are needed etc. > > These configurations are only relevant to generators that can support > e.g. having debug and release builds in the same build directory or > did I misunderstand this? Yes, your understanding is correct. > How are we supposed to handle a set of files for these configurations? Yes, that's how I see it working... > How can we notice when one gets added and removed? I'm not experienced enough with those generators to know. I'm not even certain whether it is possible to add to the list of configurations for those generators, or if the list is hardcoded. Something to look into or get information from someone else on this list if they know. I think in the worst case, you'd watch the CMakeCache.txt and read the CMAKE_CONFIGURATION_TYPES from there. I know you want to care about only one file, but maybe two is not so bad :), and there is potentially other stuff in the cache which might be useful, and which might not lend itself to the json metadata file. We'll have to see. > Having everything in one file would probably be easier, as that is > just one file what needs watching:-) Could we maybe just tag the > targets with the configurations they apply to and maybe also add the > same tag to the source file groups proposed above? That may be an option too. I wrote the solution with multiple files because we need to specify different 'object sources', 'other sources', 'header sources' and 'excluded sources' for each config, and only one config at a time is relevant. >> The content of the metadata file is determined by the build properties, >> and is necessarily similar to the compile-related content created when >> generating the actual buildsystem. It additionally contains information >> about the output locations of build artifacts and information relating to >> the cmake description itself. > > Output location of build artifacts: That is the location inside the > build directory, isn't it? What about install locations? I deliberately used a vague term 'output location', because it's not clear to me which locations we should generate in the metadata file (and why). >> * Make it more easy for an IDE to support actions such as 'remove file >> from the project', which requires removing it from the CMakeLists.txt >> at the appropriate place, and 'add new file/class to target', which >> involves adding code to the CMakeLists.txt file at the appropriate >> place. Most likely the easiest way to do the latter is using the >> target_sources() command, and to support the former, the location of >> the declaration of the target, and all target_sources() calls would >> need to be recorded. Even that is not enough because of transitive >> consumption of source files through the link interface, but that is >> likely irrelevant. > > That would be the icing on the cake, but getting a full description of > the project is what I care for at this point. Can you expand on what 'a full description of the project' means to you? Do you mean something different than 'how each object is compiled'? > I do not care too much on the format, but I am strongly in favor of > anything that I can conveniently parse with Qt. Yes, that needs to be a requirement, given the clients we're talking about at this point. > So XML and JSON are thus both fine with me:-) > > I would prefer JSON, simply because I find that way more human-readable. I think it's fine too. I've always been apprehensive about it because it seems uncommon for people to use a schema with it because it's 'easier' that way. But jsonschema seems to be everything we need. >> * I didn't document the location or directory. I'm not clear on whether >> it is supposed to be the build location, or the install location(s!), >> or all of those. > > I see four options to place this file: This is a misunderstanding. The 'location or directory' I referred to was 'the location or directory of the linked binary target'. The metadata file goes in the build directory. >> * I don't generate 'dependencies' (actually the list of files which the >> buildsystem re-generation depends on) as Aleix did, because there is no >> well-defined usefulness for that list yet. > > How is the IDE supposed to know that it needs to re-run cmake then? If > a file changes that may very well change the list of files that the > IDE needs to display, so re-running cmake only at the next build is > not going to work. Ok, I didn't realize that's the scenario we're talking about for that content. Are you saying that you would Set up a filesystem watcher for each of the (very many) files. If one of the files changes: Run `cmake .` in the build dir If the metadata file changes: Reload the data it contains Is it a problem if the value of 'very many' above is in the hundreds? >> * Some more information from project() may be relevant, but it's not >> clear >> yet. We will likely know more when we have decided the file format and >> generated some 'interesting' metadata files. > > That is definitely needed! What is this file about(full path to top > level CMakeLists.txt that was used to generate this build directory as > well as the configuration that was used!) is essential to answer:-) As it happens, the project() command doesn't really concern either of these pieces of information, but that's just implementation detail. > I would love to have something like ccmake built into Qt Creator at > some point, and having this information would spare me poking around > CMakeCache.txt and whatnot:-) If you mean you would like a fully-featured cache editor in Creator, then reading CMakeCache.txt is unavoidable, but you'd probably fork some of the Source/QtDialog code as a starting point. > For that to work information on project this build directory is for as > well as which Qt/compiler/whatnot was used in the project is essential > for Creator to properly configure the code model and the rest of > Creator. For CMake, there's nothing particularly special about Qt - we'd probably also have to provide information about which Boost etc, but actually that information is in the CMakeCache.txt. We might be better off creating a stable interface to reading that file somehow. Eg $ cmake -E read_cache Qt5Core_DIR Boost_ROOT KF5Archive_DIR ZLIB_LIBRARY { "Qt5Core_DIR": "/opt/qt5/...", "BOOST_ROOT": "/opt/boost/1.58/...", "KF5Archive_DIR": "/opt/kf5/karchive/...", "ZLIB_LIBRARY": "/opt/zlib/..." } As for 'when do I re-run it?' - the answer is whenever the CMakeCache.txt is changed. > Having the full configuration available would also remove the need to > have special flags in the "Metadata Contents" section for the compiler > used. I don't know what you mean. You mean '-g', '-O3' etc? Or are you referring to what I wrote about the pattern of the compile command line, and the order of where includes definitions and compile flags appear? > >> * We might need backtraces for not only all add_library and >> add_executable >> calls, but also all target_sources() calls. > > I do not see any obvious use for a full backtrace, but then it is > probably interesting to have to generate the build system structure we > display in the projects view in Qt Creator... In the unit test, I show that things like loop controls and functions/macros appear in the backtraces. Those don't seem useful to the idea you describe here. In fact they'd probably get in the way. > Please keep it:-) > > Apropos project view: IIRC cmake allows to define lists of files to be > displayed together in visual studio, doesn't it? Would it be possible > to make this data available to other IDEs, too? Yes, probably. I don't have any first hand experience with what people use that for. The command is source_group() I think. > >> * I propose to generate one metadata file per configuration active in the >> buildsystem. That means that the Makefile and Ninja generators would >> generate only one file, and the multi-config generators would generate >> multiple files. When changing the 'active configuration', IDEs would >> then read whatever metadata file is relevant to the active >> configuration. > > How can I get the list of files that are relevant? If I understand you correctly, the answer is the union of the source groups I defined in the file for a particular config (eg object sources, header sources, extra sources, excluded sources). All files (listed declaratively as in the unit test I wrote) appear in all config-specific metadata files, but might be specified in a different group (ie, usually either in 'object sources' or in 'excluded sources'). So, at least for the purpose of listing source files, there is no need for a master file. > Will there be one > master file that lists all the available configurations and their > configuration description file? I don't think there needs to be, unless you count reading the CMakeCache.txt CMAKE_CONFIGURATION_TYPES cache value as that... >> * I propose generating language-specific compile properties in the >> metadata >> file if there a language specific variant groups. For example if the >> compile options themselves are language-specific (the feature enabling >> that was merged to CMake master this week), then a property for each >> language >> is specified. Otherwise only a language-agnostic property is >> generated. This can vary per-configuration for a multi-config >> generator, so each metadata file for a multi-config generator could >> have different properties present. Consumers read the language specific >> property if it is present, and read the language agnostic version >> otherwise. > > I do not fully get where you are going here. If you are dealing with a cxx file and there is a "cxx_compile_options" property, then you read that and you're done. Otherwise, you read "compile_options". > >> * Generating metadata only (without generating buildsystem files) is not >> currently in scope. This was requested several times, but it is not >> clear why. > > Not sure... When opening a CMakeLists.txt, ideally I would ask the > user for a build directory and a cmake generator to be used and run > cmake once. Yes, so far this is possible, and doesn't carry a requirement to not generate an actual buildsystem... > Afterwards I would have a project description that I can generate a > ccmake-like config UI from. If the user changes that I run cmake again > and afterwards the project is fully set up and documented in the -- > now updated -- project description file. > > Afterwards I will need to regenerate the configuration description > each time something changed. That should be as fast as possible, as > the data I display in the UI is stale at that point. If not generating > the complete build-system makes this step faster, then I am all for > that:-) OTOH, it probably does not matter too much if the description > is created first and the build system is updated only afterwards in > the background. Yes, if speed is the concern, then we'll have to see what the gains are of not generating the buildsystem (probably much more significant on Windows actually). > Unrelated question: Can I query the available generators in a > machine-readable format with user friendly names and their name from > cmake somehow? Not yet. We can add that though with something like $ cmake -E list_generators { "generators": ["Unix Makefiles", "Ninja", "Xcode"] } etc. > >> * How much information does tooling need about installation? Targets >> can use different include directories and compile definitions in their >> install locations compared to their build locations. If IDEs want to >> provide some user interface related to the project files in their >> install location, perhaps a separate solution based on cmExportFile* >> is needed. For future investigation. > > Why is that necessary? I have no idea. The topic of installed location (of the targets being developed! Not of dependencies!) was raised in the other thread, but the actual requirements were not clear to me, so I added 'find out what is needed and why' to the todo list :). > My goal is to have solid support for stand-alone cmake-based projects > in Creator. If such projects reference installed libraries I would > expect that to be reflected in the compiler and linker flags. Yes, it is. > Why > would that need special support for include directories and compile > definitions? > > Creator needs to know where all files will end up on install since we > might need to copy them to a remote machine (e.g. a phone, or a Linux > box) to run/debug there. Installing everything with some temporary > directory prefixed to all paths does work, though. We can then rsync > the temporary directory to a device. But even then we will still need > to know where the executables end up on the device to run/debug. The CMAKE_STAGING_PREFIX is designed for this purpose. You would specify it when running cmake and copy the files from there. http://www.cmake.org/cmake/help/git-next/variable/CMAKE_STAGING_PREFIX.html http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/8363/focus=8629 It's basically the same as extprefix in the Qt configure script. > PS: I hope there is not too much redundant stuff in here that is > already discussed in the follow up mails I only skimmed over so far:-) It's all good thanks! Steve. From mantis at public.kitware.com Thu Mar 19 00:54:13 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 19 Mar 2015 00:54:13 -0400 Subject: [cmake-developers] [CMake 0015459]: autogen broken for ninja generator Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15459 ====================================================================== Reported By: Norbert Pfeiler Assigned To: ====================================================================== Project: CMake Issue ID: 15459 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-19 00:54 EDT Last Modified: 2015-03-19 00:54 EDT ====================================================================== Summary: autogen broken for ninja generator Description: Using automoc and autorcc, cmake_autogen is only triggered when the resources change, leaving new or changed header files unprocessed. Ironically (at least on linux) the target is now ?cmake_automoc? and not ?cmake_autogen? anymore. Additionally on Windows all resources get assigned to ?ident*? variables whose lines end with CRCRCRLF. Ninja complains: ?carriage returns are not allowed, use newlines? The first 4 ident variables also only specify the source directory and no file Steps to Reproduce: use automoc and autorcc with the ninja generator on windows: can?t build in the first place due to ninja complaining on linux or after fixing the newlines on windows: build ? remove a generated moc file ? build again ? fail ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-19 00:54 Norbert PfeilerNew Issue ====================================================================== From tgamblin at llnl.gov Thu Mar 19 02:53:40 2015 From: tgamblin at llnl.gov (Todd Gamblin) Date: Wed, 18 Mar 2015 23:53:40 -0700 Subject: [cmake-developers] BlueGene/Q Platform files Message-ID: Hi all, I've had some BG/Q platform flies kicking around LLNL for a while now, but I had been putting off sending them back to Kitware. The ParaView folks finally got around to working with our BG/Q machines, and my guilt for not contributing them back for so long recently caught up with me. I just pushed a topic branch for BG/Q support: $ git push stage HEAD Counting objects: 43, done. Delta compression using up to 16 threads. Compressing objects: 100% (19/19), done. Writing objects: 100% (19/19), 4.24 KiB | 0 bytes/s, done. Total 19 (delta 16), reused 0 (delta 0) To git at cmake.org:stage/cmake.git * [new branch] HEAD -> blugeneq-platform-files These are based on the BG/P platform files, but they're revised to account for BG/Q's directory structure. Let me know if I can merge this topic to next. Also, Thanks to David DeMarle of Kitware for testing these for me. Thanks! -Todd -------------- next part -------------- An HTML attachment was scrubbed... URL: From Geoffrey.Viola at asirobots.com Thu Mar 19 09:57:11 2015 From: Geoffrey.Viola at asirobots.com (Geoffrey Viola) Date: Thu, 19 Mar 2015 13:57:11 +0000 Subject: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support In-Reply-To: <550886E2.1020708@kitware.com> References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com> <54E365F4.3030104@kitware.com> <54E7542D.6050808@kitware.com> <54EB68C8.7030504@kitware.com> <54F0952B.5070809@kitware.com> <54F4781A.80708@kitware.com> <54FEF1C1.4030106@kitware.com> <5501F487.10807@kitware.com> <550886E2.1020708@kitware.com> Message-ID: > I just noticed that in some of the new C++ sources you copied the copyright block from other files but forgot to change the notice lines to refer to yourself or your employer. Certainly the current lines do not refer to the author of the content ;) Sorry about that. I updated them. > Good start. Please adjust the section header underlines to match the length of the title text. Formatted > Also, the new variable/GHS-MULTI document needs to be added to the toctree in 'Help/manual/cmake-variables.7.rst'. Added > This time I actually tried building the sources. Some of the classes prefix their inline method definitions: > > cmGlobalGhsMultiGenerator::GetGhsBuildCommand > > This is not necessary when it is inside the class, and some compilers do not like it. Fixed. That was a copy and paste error. It probably didn't compile in GCC. > Also the new lines you added to Source/cmake.cxx need to be made conditional on the platform. The CMakeLists.txt file already contains the proper platform conditions, so use of the new generator must match. I moved it under #if defined(_WIN32) && !defined(__CYGWIN__) # if !defined(CMAKE_BOOT_MINGW) >> I'm not quite sure why my FindModulesExecuteAll test fails. >> Seems like boost installation issue, but it isn't an issue in my >> nighlty test > >Whether boost is found may depend on the environment, and your nightly test wipes out PATH. It turns out that I upgraded boost without clearing the test's cache. My experimental test does not do a clean build because I'm trying to make it faster. Here's a link to the results: https://open.cdash.org/buildSummary.php?buildid=3735698. Geoffrey Viola SOFTWARE ENGINEER asirobots.com -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Tuesday, March 17, 2015 1:56 PM To: Geoffrey Viola Cc: cmake-developers at cmake.org Subject: Re: FW: FW: [cmake-developers] Initial Attempt at Green Hill MULTI IDE Generator Support On 03/16/2015 02:03 AM, Geoffrey Viola wrote: > Done Thanks for the updates. I just noticed that in some of the new C++ sources you copied the copyright block from other files but forgot to change the notice lines to refer to yourself or your employer. Certainly the current lines do not refer to the author of the content ;) > Added some documentation. Good start. Please adjust the section header underlines to match the length of the title text. Also, the new variable/GHS-MULTI document needs to be added to the toctree in 'Help/manual/cmake-variables.7.rst'. This time I actually tried building the sources. Some of the classes prefix their inline method definitions: cmGlobalGhsMultiGenerator::GetGhsBuildCommand This is not necessary when it is inside the class, and some compilers do not like it. Also the new lines you added to Source/cmake.cxx need to be made conditional on the platform. The CMakeLists.txt file already contains the proper platform conditions, so use of the new generator must match. > I'm not quite sure why my FindModulesExecuteAll test fails. > Seems like boost installation issue, but it isn't an issue in my > nighlty test Whether boost is found may depend on the environment, and your nightly test wipes out PATH. Thanks, -Brad This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Added-some-support-for-a-Green-Hills-MULTI.patch Type: application/octet-stream Size: 68058 bytes Desc: 0001-Added-some-support-for-a-Green-Hills-MULTI.patch URL: From tobias.hunger at gmail.com Thu Mar 19 10:26:07 2015 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Thu, 19 Mar 2015 15:26:07 +0100 Subject: [cmake-developers] Generating buildsystem metadata from CMake In-Reply-To: References: Message-ID: Hi Stephen, On Thu, Mar 19, 2015 at 2:22 AM, Stephen Kelly wrote: >> * In "Target Properties/Conditional Properties and optional >> properties": Would it make sense to have a list of target_files, each >> with a filepath and a type? That would be more similar to the targets >> which also are a list with name/type. > > What semantics would the 'type' have? I don't really understand what you > propose here. See the examples with the sources below: >> sources: [ { >> language: "C++", >> type: sources, >> defines: "FOO=1", >> include_paths: "/usr/include", >> files: [ "/full/path/a.cpp", "/full/path/b.cpp" ] >> }, >> { >> language: "C++", >> type: headers, >> files: [ "/full/path/a.h" ] >> }, >> { >> language: "C++", >> type: generated, >> files: [ "/full/path/config.h" ] >> }] The type is used to distinguish between the different kinds of files. Your proposal uses different keys for all the different kinds of files, my is to use the same key for all sources and distinguish between them by giving a type. >> These configurations are only relevant to generators that can support >> e.g. having debug and release builds in the same build directory or >> did I misunderstand this? > > Yes, your understanding is correct. > >> How are we supposed to handle a set of files for these configurations? > > Yes, that's how I see it working... > >> How can we notice when one gets added and removed? > > I'm not experienced enough with those generators to know. I'm not even > certain whether it is possible to add to the list of configurations for > those generators, or if the list is hardcoded. > > Something to look into or get information from someone else on this list if > they know. > > I think in the worst case, you'd watch the CMakeCache.txt and read the > CMAKE_CONFIGURATION_TYPES from there. I know you want to care about only one > file, but maybe two is not so bad :), and there is potentially other stuff > in the cache which might be useful, and which might not lend itself to the > json metadata file. We'll have to see. So we are back to parsing random files in internal formats again:-) Could you add have a "configuration list" key in the top level of each file that lists all available configurations (including itself)? That might be the lowest overhead solution that does not require parsing extra files that I can think of right now. I definitely will not hardcode cmake generator-A has configurations X and Y while generator-A supports configurations X, Z and D into the cmake plugin. I do prefer not to support configurations at all to doing that. >>> * Make it more easy for an IDE to support actions such as 'remove file >>> from the project', which requires removing it from the CMakeLists.txt >>> at the appropriate place, and 'add new file/class to target', which >>> involves adding code to the CMakeLists.txt file at the appropriate >>> place. Most likely the easiest way to do the latter is using the >>> target_sources() command, and to support the former, the location of >>> the declaration of the target, and all target_sources() calls would >>> need to be recorded. Even that is not enough because of transitive >>> consumption of source files through the link interface, but that is >>> likely irrelevant. >> >> That would be the icing on the cake, but getting a full description of >> the project is what I care for at this point. > > Can you expand on what 'a full description of the project' means to you? Do > you mean something different than 'how each object is compiled'? When you open a project in Creator we offer to "import existing builds" (at least for qmake-based projects, none of the other build systems supports this yet). That is very convenient when you blew away the .user file we put into the sources directory with all the information on how you built stuff where. What we do there is to check the default project build location for folders that contain a build of the current sources. To do so we need to know which code was built in that directory and which kit (think set of compiler, Qt, some other settings) were used to in the built in that directory. We also need to figure out the exact configuration (parameters passed to the "configure" step of the build system) that was built there. Since this is a feature our qmake users love I would also like to make that possible with cmake. It would be great if I could get most answers from the json file. >>> * I don't generate 'dependencies' (actually the list of files which the >>> buildsystem re-generation depends on) as Aleix did, because there is no >>> well-defined usefulness for that list yet. >> >> How is the IDE supposed to know that it needs to re-run cmake then? If >> a file changes that may very well change the list of files that the >> IDE needs to display, so re-running cmake only at the next build is >> not going to work. > > Ok, I didn't realize that's the scenario we're talking about for that > content. Are you saying that you would > > Set up a filesystem watcher for each of the (very many) files. > If one of the files changes: > Run `cmake .` in the build dir > If the metadata file changes: > Reload the data it contains Yes, that's the scenario. > Is it a problem if the value of 'very many' above is in the hundreds? I would probably trim down the list to those actually in the project or build directories, but I would prefer having too much information than too little:-) In addition I will probably have a "Run cmake" option in the menu to force the metadata to regenerate. >> I would love to have something like ccmake built into Qt Creator at >> some point, and having this information would spare me poking around >> CMakeCache.txt and whatnot:-) > > If you mean you would like a fully-featured cache editor in Creator, then > reading CMakeCache.txt is unavoidable, but you'd probably fork some of the > Source/QtDialog code as a starting point. Is CMakeCache.txt considered to be a implementation detail of cmake, or is it expected that external applications will parse it? >> For that to work information on project this build directory is for as >> well as which Qt/compiler/whatnot was used in the project is essential >> for Creator to properly configure the code model and the rest of >> Creator. > > For CMake, there's nothing particularly special about Qt - we'd probably > also have to provide information about which Boost etc, but actually that > information is in the CMakeCache.txt. We might be better off creating a > stable interface to reading that file somehow. Eg > > $ cmake -E read_cache Qt5Core_DIR Boost_ROOT KF5Archive_DIR ZLIB_LIBRARY > { > "Qt5Core_DIR": "/opt/qt5/...", > "BOOST_ROOT": "/opt/boost/1.58/...", > "KF5Archive_DIR": "/opt/kf5/karchive/...", > "ZLIB_LIBRARY": "/opt/zlib/..." > } Yes, that would be nice, but once you add "cmake -E list_cache" you could just as well just add the whole config into the json file and let its users worry whether or not to actually read the section. >> Having the full configuration available would also remove the need to >> have special flags in the "Metadata Contents" section for the compiler >> used. > > I don't know what you mean. You mean '-g', '-O3' etc? Or are you referring > to what I wrote about the pattern of the compile command line, and the order > of where includes definitions and compile flags appear? You documented a couple of keys in the top level that deal with the compiler (See "Metadata Contents/Optional Properties", e.g. "_compiler"). I will need more information than just the compiler used: The Qt version used is obviously important to us, as are all settings related to cross-compilation. We have a couple of specialized Qt Creator versions floating around that are specialized for certain environments and those usually also need access to special flags of the build system. Basically I need access to the complete configuration. With the current proposal I will need to get that information from CMakeCache.txt (if I understood that right). If that is intended, then I do not see the need to copy the compiler settings into the json file. A quick google search did not turn up whether this file is considered a implementation detail of cmake or whether it is meant to be consumed by e.g. IDEs. Ideally I would get away with just the json file (which would require copying all the configuration into it), but if I am required to parse CMakeCache.txt anyway, then I do not see the need to copy settings that are readily available there. >> I do not see any obvious use for a full backtrace, but then it is >> probably interesting to have to generate the build system structure we >> display in the projects view in Qt Creator... > > In the unit test, I show that things like loop controls and functions/macros > appear in the backtraces. Those don't seem useful to the idea you describe > here. In fact they'd probably get in the way. Well, I am mostly interested in the tree of CMakeLists.txt files and I think I can re-generate that from the backtrace:-) The "Projects" view in Qt Creator is meant to visualize the structure of the build system to allow the user to edit that. Currently I would use the backtraces to generate that view. If dependency information (the list of all files included by cmake into the build system) became available that is what I would use instead. >> Apropos project view: IIRC cmake allows to define lists of files to be >> displayed together in visual studio, doesn't it? Would it be possible >> to make this data available to other IDEs, too? > > Yes, probably. I don't have any first hand experience with what people use > that for. The command is source_group() I think. Maybe we could have a tree of "source objects" in the targets stead of a list? Something along this line: sources: { language: "C++", defines: "FOO=1", sources: [ { type: "sources", name: "Critical source files", include_paths: "/some/path", files: [ "/full/path/a.cpp", "/full/path/b.cpp" ] }, { type: headers, files: [ "/full/path/a.h" ] }, { type: generated, files: [ "/full/path/config.h" ] }, { type: "sources", name: "Tests", include_paths: "/some/path", files: [ "/full/path/a.cpp", "/full/path/b.cpp", "/full/path/test.cpp" ] } ] } where the "name" keys are taken from the source_group? >>> * I propose generating language-specific compile properties in the >>> metadata >>> file if there a language specific variant groups. For example if the >>> compile options themselves are language-specific (the feature enabling >>> that was merged to CMake master this week), then a property for each >>> language >>> is specified. Otherwise only a language-agnostic property is >>> generated. This can vary per-configuration for a multi-config >>> generator, so each metadata file for a multi-config generator could >>> have different properties present. Consumers read the language specific >>> property if it is present, and read the language agnostic version >>> otherwise. >> >> I do not fully get where you are going here. > > If you are dealing with a cxx file and there is a "cxx_compile_options" > property, then you read that and you're done. Otherwise, you read > "compile_options". I agree with Anton: This will required all IDEs to duplicate the logic for mapping a file to a type 'X' and then get the settings for 'X_compile_options' and fall back to 'compile_options' if that is unset. Can't we go for a syntax where the files and everything that applies to them are grouped so that there is no need to reimplement the logic found in cmake (with added bugs:-)? >>> * Generating metadata only (without generating buildsystem files) is not >>> currently in scope. This was requested several times, but it is not >>> clear why. >> >> Not sure... When opening a CMakeLists.txt, ideally I would ask the >> user for a build directory and a cmake generator to be used and run >> cmake once. > > Yes, so far this is possible, and doesn't carry a requirement to not > generate an actual buildsystem... I agree with Anton that it would be nice not to have to ask for a build directory and generator first thing. Many users just want to browse some project and an IDE should support that use case as well as possible. Nagging those users about a build directory or generator is not the best user experience. >> Afterwards I would have a project description that I can generate a >> ccmake-like config UI from. If the user changes that I run cmake again >> and afterwards the project is fully set up and documented in the -- >> now updated -- project description file. >> >> Afterwards I will need to regenerate the configuration description >> each time something changed. That should be as fast as possible, as >> the data I display in the UI is stale at that point. If not generating >> the complete build-system makes this step faster, then I am all for >> that:-) OTOH, it probably does not matter too much if the description >> is created first and the build system is updated only afterwards in >> the background. > > Yes, if speed is the concern, then we'll have to see what the gains are of > not generating the buildsystem (probably much more significant on Windows > actually). > >> Unrelated question: Can I query the available generators in a >> machine-readable format with user friendly names and their name from >> cmake somehow? > > Not yet. We can add that though with something like > > $ cmake -E list_generators > { > "generators": ["Unix Makefiles", "Ninja", "Xcode"] > } > > etc. That would be *really* nice to have once this metadata file is in place:-) >> Creator needs to know where all files will end up on install since we >> might need to copy them to a remote machine (e.g. a phone, or a Linux >> box) to run/debug there. Installing everything with some temporary >> directory prefixed to all paths does work, though. We can then rsync >> the temporary directory to a device. But even then we will still need >> to know where the executables end up on the device to run/debug. > > The CMAKE_STAGING_PREFIX is designed for this purpose. You would specify it > when running cmake and copy the files from there. > > http://www.cmake.org/cmake/help/git-next/variable/CMAKE_STAGING_PREFIX.html > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/8363/focus=8629 > > It's basically the same as extprefix in the Qt configure script. I am aware of that:-) Creator would still need to know where the files went that the user wants to run/debug though. So at least for the binaries a way to map them from the build to the install location is needed for our use-case. Best Regards, Tobias From tobias.hunger at gmail.com Thu Mar 19 10:54:33 2015 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Thu, 19 Mar 2015 15:54:33 +0100 Subject: [cmake-developers] Generating buildsystem metadata from CMake In-Reply-To: References: Message-ID: Hi Anton, you raised some good points, all of which I agree with:-) On Thu, Mar 19, 2015 at 10:18 AM, Anton Makeev wrote: > * If it is useful to preprocess/compile/assemble individual files from > IDEs, as made possible by the Makefiles and Ninja generators, we'll need > to design that. > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12429 > > > This is definitely useful, but I?m not sure what kind of information needed > here, > as I see it, since we already know the files in the project, we can tell > make/ninja to simply compile it. You asked me to use "cmake --build", so ideally that would be "cmake --build . /full/file/path" and ideally it would work with all generators without magic in the IDE:-) Since I assume that not all build systems will allow to build individual files, you might want to add a flag "can_build_individual_files" or similar to the metadata that a generator can use to flag the IDE on whether the generated build system can build individual files or not. Then the IDE can hide that option if it is not applicable. > * Some more information from project() may be relevant, but it's not clear > yet. We will likely know more when we have decided the file format and > generated some 'interesting' metadata files. > > > Project name, list of the configurations are most needed ones. > We also use CMAKE__SOURCEFILE_EXTENSIONS to determine if a given file > is potentially source file or not. I would also love to see subprojects:-) CMake allows for them, doesn't it? Will you still need CMAKE__SOURCEFILE_EXTENSIONS when you can get access to the list of sources as above where each group of files is flagged with the language, etc.? > As a side note, it seems more natural to me to have one json file with one > or several configurations listed, providing that there is also shared > project info that should be in that files. > something like that: > > project: ProjectName > configurations: { > { > name: Debug > targets: {...} > }, > { > name: Release > targets: {...} > } > ... > } I'd actually prefer having a "configurations" key with the list of the configurations an object applies to. That can be optional if the object is relevant to all configurations (default in single-configuration generators;-). This key would then need to be applicable to targets as well as the group of source files. So that would be something like this: { project: "TestProject", targets: [ { name: "Debug only", configurations: [ "Debug" ], type: "EXECUTABLE", sources: [ ... ] }, { name: "Release only", configurations: [ "Release" ], type: "EXECUTABLE", sources: [ ... ] }, { name: "Run Tests", sources: sources: { language: "C++", defines: "FOO=1", sources: [ { type: "sources", name: "Critical source files", configurations: [ "Debug" ], include_paths: "/some/path", files: [ "/full/path/a.cpp", "/full/path/b.cpp" ] }, { type: headers, files: [ "/full/path/a.h" ] }, { type: generated, files: [ "/full/path/config.h" ] }, { type: "sources", name: "Tests", include_paths: "/some/path", files: [ "/full/path/a.cpp", "/full/path/b.cpp", "/full/path/test.cpp" ] } ] } } That would most likely avoid quite a bit of duplication in the file(s). > This also means that conditions don't need to be added inside the metadata > file for configurations in order to show files 'excluded' by being part of > a non-active configuration. The code implementing discovery of excluded > files is in the generate-metadata branch in my clone. Yeap, that would be a convenient property for me, too. > * Generating metadata only (without generating buildsystem files) is not > currently in scope. This was requested several times, but it is not > clear why. > > > It?s simply to be able to get this the information as quickly as possible. > I?m not sure which part is most slow, but, say, InsightToolKit 4.5 > (http://www.itk.org/Wiki/ITK/Source), generates in couple of minutes. The > regeneration, even when nothing was changes, a few dozens of seconds. > > Plus, we?d prefer being able to open the project without any questions to > user, e.g. not asking, which generator he/she prefers. If we generate using > ?wrong? default generator we?ll need to regenerate everything again when > user decides to change it. > > Another benefit of skipping actual generation is possibly better error > recoverability. > That is, some generators may fail here and there if the project is > incorrectly configured (e.g. source files are missing). Skipping the > generation phase will (probably) help getting the project metadata even in > that case. > > But anyway, it seems a little outside of the scope of the discussion. Very good points that I fully agree with. > * How much information does tooling need about installation? Targets > can use different include directories and compile definitions in their > install locations compared to their build locations. If IDEs want to > provide some user interface related to the project files in their > install location, perhaps a separate solution based on cmExportFile* > is needed. For future investigation. > > > > An additional though: here only the 'project information' aspect is > discussed; though, to be fully machine-frienly, cmake should be able to also > generate parseable output (error reports etc), provide the progress, etc. > So, just to mull over, probably the discussed design should consider such > future direction. Yes, that would be great, but I do not see how cmake can do that: It delegates the actual build to external tools. So in the end during a build we will always have to deal with whatever output the generated buildsystem throws at us:-/ This again somewhat limits the usefulness of allowing the user to pick whichever generator they want: Some will just loose some or all the build issues. Best Regards, Tobias From mantis at public.kitware.com Thu Mar 19 11:02:36 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 19 Mar 2015 11:02:36 -0400 Subject: [cmake-developers] [CMake 0015460]: PGI Fortran compiler does not recognise -fPIE Message-ID: <731e7aa0e1aeddf49e199781d68f4cd8@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15460 ====================================================================== Reported By: Tiago Quintino Assigned To: ====================================================================== Project: CMake Issue ID: 15460 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-19 11:02 EDT Last Modified: 2015-03-19 11:02 EDT ====================================================================== Summary: PGI Fortran compiler does not recognise -fPIE Description: By selecting POSITION_INDEPENDENT_CODE the PGI compiler settings add automatically the flag -fPIE. This flag does not exist for PGI Fortran Compiler. I have checked this with pgf77, pgf90 and pgfortran. The only workaround I found is to set the flag: -DCMAKE_Fortran_FLAGS="-noswitcherror" This turns off the check for flag validity in the compiler, but obviously is not a long-term solution, since now any test to compiler flags will pass irrespectively if the flag is recognised or not. The solution I think is changing Modules/Platform/Linux-PGI.cmake to: set(CMAKE_${lang}_COMPILE_OPTIONS_PIE "") Note that the flag -fPIE also does not exist for PGI C and C++ compilers. Steps to Reproduce: Build the attached CMakeLists.txt project with cmake -DCMAKE_Fortran_COMPILER=pgf90 .. Additional Information: I am using CMake 3.1.2 and PGI Fortran 14.4. The man page of compiler does not reference this flag whatsoever. This is the output I get: -- The C compiler identification is GNU 4.8.1 -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- The Fortran compiler identification is PGI -- Check for working Fortran compiler: /usr/local/apps/pgi/14.4/bin/pgf90 -- Check for working Fortran compiler: /usr/local/apps/pgi/14.4/bin/pgf90 -- broken CMake Error at /usr/local/apps/cmake/3.1.2/share/cmake-3.1/Modules/CMakeTestFortranCompiler.cmake:54 (message): The Fortran compiler "/usr/local/apps/pgi/14.4/bin/pgf90" is not able to compile a simple test program. It fails with the following output: Change Dir: /home/ma/matq/git/cmake-test/pgi-pie/build/CMakeFiles/CMakeTmp Run Build Command:"/usr/bin/gmake" "cmTryCompileExec951442437/fast" gmake: Warning: File `Makefile' has modification time 1.9 s in the future /usr/bin/gmake -f CMakeFiles/cmTryCompileExec951442437.dir/build.make CMakeFiles/cmTryCompileExec951442437.dir/build gmake[1]: Entering directory `/home/ma/matq/git/cmake-test/pgi-pie/build/CMakeFiles/CMakeTmp' gmake[1]: Warning: File `CMakeFiles/cmTryCompileExec951442437.dir/flags.make' has modification time 1.9 s in the future /usr/local/apps/cmake/3.1.2/bin/cmake -E cmake_progress_report /home/ma/matq/git/cmake-test/pgi-pie/build/CMakeFiles/CMakeTmp/CMakeFiles 1 Building Fortran object CMakeFiles/cmTryCompileExec951442437.dir/testFortranCompiler.f.o /usr/local/apps/pgi/14.4/bin/pgf90 -Mpreprocess -Kieee -fPIE -c /home/ma/matq/git/cmake-test/pgi-pie/build/CMakeFiles/CMakeTmp/testFortranCompiler.f -o CMakeFiles/cmTryCompileExec951442437.dir/testFortranCompiler.f.o pgf90-Error-Unknown switch: -fPIE gmake[1]: *** [CMakeFiles/cmTryCompileExec951442437.dir/testFortranCompiler.f.o] Error 1 gmake[1]: Leaving directory `/home/ma/matq/git/cmake-test/pgi-pie/build/CMakeFiles/CMakeTmp' gmake: *** [cmTryCompileExec951442437/fast] Error 2 CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:7 (enable_language) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-19 11:02 Tiago Quintino New Issue 2015-03-19 11:02 Tiago Quintino File Added: CMakeLists.txt ====================================================================== From Anton.Makeev at jetbrains.com Thu Mar 19 11:06:03 2015 From: Anton.Makeev at jetbrains.com (Anton Makeev) Date: Thu, 19 Mar 2015 16:06:03 +0100 Subject: [cmake-developers] Generating buildsystem metadata from CMake In-Reply-To: References: Message-ID: Hi Stephen, everyone. First of all, many thanks for pushing this forward and spending your time to prepare the proposal. My comments are inline. > Goals include: > > * Make it possible for IDEs to access the compile-related information for > autocompletion and code navigation etc purposes. > > * Remove the need for IDEs to parse generated Makefiles or Ninja files to > access compile-related information. The structure of those files is not > 'stable', while the content of the metadata file is stable. > http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/48412 > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11081 > > * Remove the need for users to create a new build directory and new build > in order to use or switch IDEs. QtCreator requires that > the C::B 'extra generator is used as it parses compile information from > that. Other 'extra generators' such as for eclipse, sublime, kate etc > also require fresh/new build directories, although the actual buildsystem > they create is identical (assuming using all Makefile based or > all Ninja based 'extra generators') > > * Make it possible to write a plugin for the editors/IDEs such as sublime > which consumes the metadata file and invokes the build using whatever > buildsystem the user already has a build directory for, instead of > writing an 'extra generator' and maintaining it in the cmake repo. > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9004 > > * Make it possible for editors/IDEs to allow specifying the configuration > at build-time, where the IDE has that feature, and where a multi-config > generator is available. That is, QtCreator provides user-interface for > choosing debug/release config to build. Currently it can't offer that > when using cmake, because it only allows the use of Makefile or Ninja > generators, in order to make use of the C::B file. QtCreator should be > able to use the Xcode or Visual Studio generators, generate the metadata > file(s), and invoke `cmake --build . --config ${CONFIG}` as > appropriate. Eclipse, Sublime and other editors have similar abilities > to invoke config-specific builds after generation. > > * Provide a list of 'build targets', which can be listed and invoked in > IDE/editor user interface. Build targets for all linked binaries > and utilties are provided. The tooling is expected to perform filtering > on the target types to show only executables and utilities for > execution, for example. > > * Provide a list of source files per target per type of source file, eg > object sources, header files, generated files, files excluded from the > active configuration/platform/compiler, non-compiled files. Agree with Tobias here (if I understood correctly): cmake-metadata-generation page suggests that there should be the following property: sources: the list of sources with specific extra build properties specified. Each object in this property has properties described in Source File Properties . This list seems to be more logical as a property of a target: this way we could easily handle per-file-per-target settings (not sure if it??s currently supported), and make it easier for IDE to handle this information. But I?m not sure about the details so may be wrong here. The other thing that seems troubling to me is that since file, target, language compiler options are split into different parts of metadata, the IDE need to know exactly how to assemble them back into the compiler?s command line (e.g. what flags go first file?s or language?s), duplicating CMake's logic that may be different from version to version and from compiler to compiler. The exact command line is needed to get the actual and precise defines, include search paths etc. from the compiler. > * Make it more easy for an IDE to support actions such as 'remove file > from the project', which requires removing it from the CMakeLists.txt > at the appropriate place, and 'add new file/class to target', which > involves adding code to the CMakeLists.txt file at the appropriate > place. Most likely the easiest way to do the latter is using the > target_sources() command, and to support the former, the location of > the declaration of the target, and all target_sources() calls would > need to be recorded. Even that is not enough because of transitive > consumption of source files through the link interface, but that is > likely irrelevant. This would be really helpful indeed, currently, we have to introspect CMakeLists.txt files in order to find the most probably place where new files should be placed (works only in basic cases now). And being able to do so correctly is also crucial for refactoring (e.g. extract class). > * Provide information about the entire build graph of link-dependencies > for visulization and dependency analysis > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/4042 > > * Provide enough information about runtime link dependencies for IDEs to > be able to properly invoke targets with debuggers, profilers and other > tools. > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11011 > > > The CMAKE_EXPORT_COMPILE_COMMANDS variable already exists to generate > compile command lines, but that is a file whose format is defined by > Clang, not by CMake, and other tools in the Clang ecosystem also support > it. It is not extensible or versioned in the way that a CMake-defined > file format is, so I don't propose using it as a starting point. > > Notes: > > * I deliberately didn't push an implementation to my repo, so that this > discussion can focus on the design of the feature and contents of the > file first. > > * In the documentation and the test I didn't mention that the metadata file > is JSON. I'm not opposed to it, but I think there should be some kind of > schema defining how to read the metadata file. If we go with JSON > (instead of xml, say), then we'd have to define our own schema format, which > is not impossible. My proposal is to generate the schema beside the metadata > file instead of writing a metadata version into the metadata file > itself. Does > anyone feel strongly about the file being JSON? I just want to record the > reason for everything in this design phase - we don't have to spend a lot > of time on it. > > * I didn't document the location or directory. I'm not clear on whether > it is supposed to be the build location, or the install location(s!), > or all of those. It would be useful, though, to have a location of generated files for each target: in case metadata misses some information (and I think it won?t cover every possible need anytime soon), IDE will be able to get if from generated makefiles. > * I don't generate 'dependencies' (actually the list of files which the > buildsystem re-generation depends on) as Aleix did, because there is no > well-defined usefulness for that list yet. As Tobias pointed, we at least need to know what files are the part of CMake project, that is, the list of all CMakeLists.txt and *.cmake files, used for generation (ideally, including missing ones, since in that case IDE could be able to tell when missing file is created and refresh the project) > * I documented the 'name' for the targets, and the TARGET_FILE_NAME > etc information, and can push an implementation which generates them. > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12619 > > * If it is useful to preprocess/compile/assemble individual files from > IDEs, as made possible by the Makefiles and Ninja generators, we'll need > to design that. > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12429 This is definitely useful, but I?m not sure what kind of information needed here, as I see it, since we already know the files in the project, we can tell make/ninja to simply compile it. > * Some more information from project() may be relevant, but it's not clear > yet. We will likely know more when we have decided the file format and > generated some 'interesting' metadata files. Project name, list of the configurations are most needed ones. We also use CMAKE__SOURCEFILE_EXTENSIONS to determine if a given file is potentially source file or not. > * We might need backtraces for not only all add_library and add_executable > calls, but also all target_sources() calls. > > * We list the Generator used to configure the build. That way IDEs know > which build output parser to use. > > * I propose to generate one metadata file per configuration active in the > buildsystem. That means that the Makefile and Ninja generators would > generate only one file, and the multi-config generators would generate > multiple files. When changing the 'active configuration', IDEs would > then read whatever metadata file is relevant to the active configuration. This has already been discussed but I give our usage scenario: in CLion we retrieve the list of all build types (aka configurations, Debug, Release etc) and then generate project using Makefiles generator for each of them. This is necessary because of several reasons: 1) To be able to correctly build language model, we need to know, when a file is used in several configurations, which means, it's compiler settings and macros are different. E.g. some branches of code may not be available in Debug or Release and we give user an option to quickly switch between them in the editor. 2) Though, the case is rare, the list of the targets may be different in configurations, and we want to show all the targets (with an options to change configuration during build time). There is also another issue with Makefiles/Ninja generator: if CMAKE_BUILD_TYPE is not specified, an unnamed configuration is generated, that is neither Debug nor Release. And we don?t know in advance what configurations are available, since the list of them may be redefined. I don?t know if it?s possible at all, but it would be great if we could have info for all configurations generated in one go (not only for multi-config, but for single-config generators as well like Ninja and Makefiles). As a side note, it seems more natural to me to have one json file with one or several configurations listed, providing that there is also shared project info that should be in that files. something like that: project: ProjectName configurations: { { name: Debug targets: {...} }, { name: Release targets: {...} } ... } > This also means that conditions don't need to be added inside the metadata > file for configurations in order to show files 'excluded' by being part of > a non-active configuration. The code implementing discovery of excluded > files is in the generate-metadata branch in my clone. > > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11323 > "At least Qt Creator does not need information on which conditions to > be met for a file to become part of the current build." > > * I propose generating language-specific source lists, because CMake can > build files with compilers which do not match their file extension. > > * I propose generating language-specific compile properties in the metadata > file if there a language specific variant groups. For example if the > compile options themselves are language-specific (the feature enabling that > was merged to CMake master this week), then a property for each language > is specified. Otherwise only a language-agnostic property is generated. This > can vary per-configuration for a multi-config generator, so each metadata > file for a multi-config generator could have different properties present. > Consumers read the language specific property if it is present, and read > the language agnostic version otherwise. > > * Generating metadata only (without generating buildsystem files) is not > currently in scope. This was requested several times, but it is not > clear why. It?s simply to be able to get this the information as quickly as possible. I?m not sure which part is most slow, but, say, InsightToolKit 4.5 (http://www.itk.org/Wiki/ITK/Source ), generates in couple of minutes. The regeneration, even when nothing was changes, a few dozens of seconds. Plus, we?d prefer being able to open the project without any questions to user, e.g. not asking, which generator he/she prefers. If we generate using ?wrong? default generator we?ll need to regenerate everything again when user decides to change it. Another benefit of skipping actual generation is possibly better error recoverability. That is, some generators may fail here and there if the project is incorrectly configured (e.g. source files are missing). Skipping the generation phase will (probably) help getting the project metadata even in that case. But anyway, it seems a little outside of the scope of the discussion. > * How much information does tooling need about installation? Targets > can use different include directories and compile definitions in their > install locations compared to their build locations. If IDEs want to > provide some user interface related to the project files in their > install location, perhaps a separate solution based on cmExportFile* > is needed. For future investigation. An additional though: here only the 'project information' aspect is discussed; though, to be fully machine-frienly, cmake should be able to also generate parseable output (error reports etc), provide the progress, etc. So, just to mull over, probably the discussed design should consider such future direction. Regards, Anton Makeev JetBrains http://www.jetbrains.com "Develop with pleasure!" -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2856 bytes Desc: not available URL: From clinton at elemtech.com Thu Mar 19 17:53:56 2015 From: clinton at elemtech.com (Clinton Stimpson) Date: Thu, 19 Mar 2015 15:53:56 -0600 Subject: [cmake-developers] Support of codesign In-Reply-To: References: Message-ID: <4180285.C3Tb588k3b@stryke> Thanks for providing the patch. http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=2c50db26 Clint On Wednesday, March 18, 2015 08:24:36 AM A. Klitzing wrote: > Ping? :-) > > Am 11.03.2015 13:21 schrieb "A. Klitzing" : > > Hi there! > > > > I added another improvement to the codesign feature. Sometimes it is > > helpful to overwrite or pass additional parameters like "--timestamp=none" > > to codesign. > > But this shouldn't be the default for everyone. > > > > So I added the variable CPACK_BUNDLE_APPLE_CODESIGN_PARAMETER. > > Hope you like it. > > > > Regards > > > > Andr? > > > > 2015-02-20 16:20 GMT+01:00 Clinton Stimpson : > >> On Friday, February 20, 2015 12:07:55 PM A. Klitzing wrote: > >> > Hi Clint, > >> > > >> > I have another patch to tweak the error output a little bit. If > >> > codesign > >> > fails it won't be possible to get the error message of codesign itself. > >> > That is a little bit confusing because it just fails without an > >> > understandable reason. > >> > > >> > This patch will print the output of codesign if it fails. > >> > >> Thanks. > >> > >> > >> > >> Clint From steven.vancoillie at teokem.lu.se Fri Mar 20 04:23:13 2015 From: steven.vancoillie at teokem.lu.se (Steven Vancoillie) Date: Fri, 20 Mar 2015 09:23:13 +0100 Subject: [cmake-developers] patch that adds -KPIC flag to SunPro Fortran compiler Message-ID: <20150320082313.GB17545@lenovo> Hi, I ran into a problem with SunPro Fortran compiler not being able to create a shared library since the -KPIC flag was missing. The patch that is attached fixes this. I didn't add a -KPIE as that doesn't exist for SunPro. Looking at other compiler configurations, it seems it might be better to have a SunPro.cmake module that combines flags that are independent of the language? greetings, Steven -- Steven Vancoillie Theoretical Chemistry Lund University P.O.B 124 S-221 00 Lund Sweden -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-position-independent-code-flag-for-SunPro-Fortra.patch Type: text/x-diff Size: 900 bytes Desc: 0001-Add-position-independent-code-flag-for-SunPro-Fortra.patch URL: From brad.king at kitware.com Fri Mar 20 10:19:23 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 20 Mar 2015 10:19:23 -0400 Subject: [cmake-developers] BlueGene/Q Platform files In-Reply-To: References: Message-ID: <550C2C6B.5040107@kitware.com> On 03/19/2015 02:53 AM, Todd Gamblin wrote: > Let me know if I can merge this topic to next. Yes, please. Thanks, -Brad From brad.king at kitware.com Fri Mar 20 10:38:08 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 20 Mar 2015 10:38:08 -0400 Subject: [cmake-developers] AutogenInfo.cmake With Read-Only Modules In-Reply-To: <550A2A67.3030600@gmail.com> References: <550A2A67.3030600@gmail.com> Message-ID: <550C30D0.1090502@kitware.com> On 03/18/2015 09:46 PM, Justin Borodinsky wrote: > ConfigureFile use the source file's permissions, but > cmQtAutoGenerators::SetupAutoGenerateTarget requires write access. Great! That resolves this issue: http://www.cmake.org/Bug/view.php?id=15416 Applied: QtAutogen: Ensure write access to AutogenInfo.cmake (#15416) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=610464c1 Thanks, -Brad From brad.king at kitware.com Fri Mar 20 13:08:18 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 20 Mar 2015 13:08:18 -0400 Subject: [cmake-developers] patch that adds -KPIC flag to SunPro Fortran compiler In-Reply-To: <20150320082313.GB17545@lenovo> References: <20150320082313.GB17545@lenovo> Message-ID: <550C5402.8090604@kitware.com> On 03/20/2015 04:23 AM, Steven Vancoillie wrote: > I ran into a problem with SunPro Fortran compiler not being able to > create a shared library since the -KPIC flag was missing. The patch > that is attached fixes this. I didn't add a -KPIE as that doesn't > exist for SunPro. Applied, thanks: SunPro: Add position independent code flag for Fortran compiler http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3556fb1b > Looking at other compiler configurations, it seems it might be better > to have a SunPro.cmake module that combines flags that are independent > of the language? Yes. This refactoring has simply not been done for this compiler. If you want to work on it, please note that such a module is not loaded automatically and must be included by the per-language modules. This pattern is visible in several other compiler modules. Thanks, -Brad From brad.king at kitware.com Fri Mar 20 13:13:07 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 20 Mar 2015 13:13:07 -0400 Subject: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation In-Reply-To: References: <20150302010209.GC17534@bronto-burt.dev.benboeckel.net> <5BB62C37-0B76-4CA9-9529-3E3FCB5D151E@java.pl> <54F762D3.8080608@kitware.com> Message-ID: <550C5523.8040501@kitware.com> On 03/13/2015 08:44 AM, Daniel Pfeifer wrote: > I pushed some work to https://github.com/purpleKarrot/CMake/commits/pch Thanks for working on this. I'm hoping others will respond because I have little experience with PCH. > target_precompile_headers(bar INTERFACE bar.h) [snip] > This command is used to set a list of headers "to precompile". This would say that any target that links to 'bar' would get 'bar.h' as a source file to be precompiled for that target's settings. This makes some sense for producing the precompiled header, but what decides what precompiled header is *used* by each source file? IIUC a given compiler call may specify at most one precompiled header to use because it is actually more like a partially compiled translation unit to be continued by each source consuming it. Thanks, -Brad From brad.king at kitware.com Fri Mar 20 13:30:53 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 20 Mar 2015 13:30:53 -0400 Subject: [cmake-developers] RFC: Helper macros for writing Find modules In-Reply-To: <4223239.nbSvzUmUOe@kyoshi> References: <4542775.7tyAsShsiA@kyoshi> <5508835D.40705@kitware.com> <4223239.nbSvzUmUOe@kyoshi> Message-ID: <550C594D.6060508@kitware.com> On 03/18/2015 05:50 PM, Alex Merry wrote: > I made some changes in a copy of this module for work that separated out the > target creation, as well as adding debug/release support. I'll check about > being allowed to release that work, but I doubt it'll be an issue. Great. Will you be able to test this by factoring it into ECM proper? One attractive feature of this particular work is that ECM is well tested and widely used, so the modules can come with some maturity. >> Help: Drop FeatureSummary example in cmake-developer.7 >> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8235effe > > One issue I realised with this after the fact is that it works poorly with > *Config.cmake files - if there is no find module, and the package is not found, > the URL telling you how to get hold of it would be missing unless you add it > at the find_package call site. That's a good point. When FeatureSummary was first introduced I always envisioned it being used in project code near the find_package call sites but not underneath them in the call stack. The goal of the *Config file approach to find_package is to have no information about the package hard-coded in CMake, because doing so is not scalable to every package in the world. Thanks, -Brad From brad.king at kitware.com Fri Mar 20 13:32:04 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 20 Mar 2015 13:32:04 -0400 Subject: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support In-Reply-To: References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com> <54E7542D.6050808@kitware.com> <54EB68C8.7030504@kitware.com> <54F0952B.5070809@kitware.com> <54F4781A.80708@kitware.com> <54FEF1C1.4030106@kitware.com> <5501F487.10807@kitware.com> <550886E2.1020708@kitware.com> Message-ID: <550C5994.8020802@kitware.com> On 03/19/2015 09:57 AM, Geoffrey Viola wrote: > Fixed. Great, thanks. I'll take another look at the updated patch next week. -Brad From amine.khaldi at reactos.org Fri Mar 20 13:35:06 2015 From: amine.khaldi at reactos.org (Amine Khaldi) Date: Fri, 20 Mar 2015 18:35:06 +0100 Subject: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation In-Reply-To: <550C5523.8040501@kitware.com> References: <20150302010209.GC17534@bronto-burt.dev.benboeckel.net> <5BB62C37-0B76-4CA9-9529-3E3FCB5D151E@java.pl> <54F762D3.8080608@kitware.com> <550C5523.8040501@kitware.com> Message-ID: <550C5A4A.7080406@reactos.org> Two requests please: * The option to use existing headers instead of autogenerated ones. * Implementing PCH support without additional targets. ReactOS already has like 1000+ targets, and we currently use PCH on almost all of them, so imagine if this official implementation doubles our targets number. Regards, Amine. From ono at java.pl Fri Mar 20 14:30:17 2015 From: ono at java.pl (Adam Strzelecki) Date: Fri, 20 Mar 2015 19:30:17 +0100 Subject: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation In-Reply-To: <550C5A4A.7080406@reactos.org> References: <20150302010209.GC17534@bronto-burt.dev.benboeckel.net> <5BB62C37-0B76-4CA9-9529-3E3FCB5D151E@java.pl> <54F762D3.8080608@kitware.com> <550C5523.8040501@kitware.com> <550C5A4A.7080406@reactos.org> Message-ID: <6705D488-437B-4CDE-8143-B183A22676EC@java.pl> > * The option to use existing headers instead of autogenerated ones. My solution (which is about PCH support to existing CMake version) does not auto generate any headers. > * Implementing PCH support without additional targets. ReactOS already has like 1000+ targets, and we currently use PCH on almost all of them, so imagine if this official implementation doubles our targets number. My solution needs to generate additional target indeed for one pre-generated header, so if all your 1000+ targets will share same precompiled header (given the compiler flags don't change) then you will have just one (single) additional target. If CMake will support PCH natively I don't see any reason it will need extra target, yet obviously there will be extra (Ninja) compiler rule for PCH. -- Adam From amine.khaldi at reactos.org Fri Mar 20 14:51:02 2015 From: amine.khaldi at reactos.org (Amine Khaldi) Date: Fri, 20 Mar 2015 19:51:02 +0100 Subject: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation In-Reply-To: <6705D488-437B-4CDE-8143-B183A22676EC@java.pl> References: <20150302010209.GC17534@bronto-burt.dev.benboeckel.net> <5BB62C37-0B76-4CA9-9529-3E3FCB5D151E@java.pl> <54F762D3.8080608@kitware.com> <550C5523.8040501@kitware.com> <550C5A4A.7080406@reactos.org> <6705D488-437B-4CDE-8143-B183A22676EC@java.pl> Message-ID: <550C6C16.1010805@reactos.org> > My solution needs to generate additional target indeed for one pre-generated header, so if all your 1000+ targets will share same precompiled header (given the compiler flags don't change) then you will have just one (single) additional target. It's very rare (not to mention risky) to be able to share a PCH with more than one target, because each target can have its own set of defines/flags and header inclusions, so we'd really end up with additional 1000+ targets. BTW, please note that the most recent test is still https://github.com/nanoant/CMakePCHCompiler/issues/1#issuecomment-77003296 > If CMake will support PCH natively I don't see any reason it will need extra target, yet obviously there will be extra (Ninja) compiler rule for PCH. That's far better than extra targets. From ewmailing at gmail.com Fri Mar 20 15:06:59 2015 From: ewmailing at gmail.com (Eric Wing) Date: Fri, 20 Mar 2015 12:06:59 -0700 Subject: [cmake-developers] Support of codesign In-Reply-To: <4180285.C3Tb588k3b@stryke> References: <4180285.C3Tb588k3b@stryke> Message-ID: Sorry, I'm also very late on this thread, but there was a suggestion that codesigning should be in CMake instead of CPack. I agree and also say it needs to be integrated as part of the build process when specified. Here's a real world workflow. I use JavaScriptCore in my Mac application which allows me to run various bits of JavaScript inside my main application, as you would with other embedded scripting languages like Lua. Safari has a feature that lets you attach the Safari built-in debugger to other applications JavaScriptCore contexts if you set the entitlement com.apple.security.get-task-allow. In order to set the entitlement, you must codesign. And I want to emphasize, this is a standard development workflow, not a release workflow which means this is the common case. The workflow should be: - Edit code in your app - Hit the Xcode run button to recompile and run/test. CMake's current workflow doesn't work this way and it is annoying. There are other things on Mac that require codesigning, such as if you use sandboxing (some APIs behave differently under sandboxing so testing under non-sandboxing has risks), or if you use certain Apple services like iCloud, In-App-Purchases, and Game Center. An additional note, any 3rd party libraries/frameworks embedded in the app also must be codesigned. I currently employed my own workarounds for both using a lot of post_build/custom_command instructions. However my solution is still a little clumsy with switching between different codesign keys (Developer ID vs Mac App Store vs none). It would be nicer if you could pick it in Xcode directly instead of having to regenerate CMake everytime. Additionally, resigning all the 3rd party frameworks every single time is kind of slow (my algorithm is kind of stupid), but there are additional complications when you change the key to sign with which is partly why my algorithm ended up playing stupid. Thanks, Eric From mantis at public.kitware.com Fri Mar 20 15:37:46 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 20 Mar 2015 15:37:46 -0400 Subject: [cmake-developers] [CMake 0015461]: Ninja generator does not honor COMMENT for TARGET POST_BUILD commands Message-ID: <30723bbef1707ee2b4b9698a89574959@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15461 ====================================================================== Reported By: Chris Green Assigned To: ====================================================================== Project: CMake Issue ID: 15461 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-20 15:37 EDT Last Modified: 2015-03-20 15:37 EDT ====================================================================== Summary: Ninja generator does not honor COMMENT for TARGET POST_BUILD commands Description: Upon adding a TARGET POST_BUILD command to make an alias link for a built library, the Ninja system does not print my defined COMMENT. Steps to Reproduce: Define a custom command as a POST_BUILD command to (e.g.) a library target, and define a COMMENT. Run CMake -GNinja. Run ninja > log.txt 2>&1 Fail to see your COMMENT in log.txt. Additional Information: The COMMENT is printed as expected with the UNIX Makefile generator in CMake 3.2.1. The actual command we used: function(cet_lib_alias LIB_TARGET) foreach(alias ${ARGN}) add_custom_command(TARGET ${LIB_TARGET} POST_BUILD COMMAND ln -sf $ ${CMAKE_SHARED_LIBRARY_PREFIX}${alias}${CMAKE_SHARED_LIBRARY_SUFFIX} COMMENT "Generate / refresh courtesy link ${CMAKE_SHARED_LIBRARY_PREFIX}${alias}${CMAKE_SHARED_LIBRARY_SUFFIX} -> $" VERBATIM WORKING_DIRECTORY ${LIBRARY_OUTPUT_PATH}) endforeach() endfunction() ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-20 15:37 Chris Green New Issue ====================================================================== From daniel at pfeifer-mail.de Fri Mar 20 15:40:28 2015 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Fri, 20 Mar 2015 20:40:28 +0100 Subject: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation In-Reply-To: <550C5523.8040501@kitware.com> References: <20150302010209.GC17534@bronto-burt.dev.benboeckel.net> <5BB62C37-0B76-4CA9-9529-3E3FCB5D151E@java.pl> <54F762D3.8080608@kitware.com> <550C5523.8040501@kitware.com> Message-ID: On Fri, Mar 20, 2015 at 6:13 PM, Brad King wrote: > On 03/13/2015 08:44 AM, Daniel Pfeifer wrote: >> I pushed some work to https://github.com/purpleKarrot/CMake/commits/pch > > Thanks for working on this. I'm hoping others will respond because > I have little experience with PCH. > >> target_precompile_headers(bar INTERFACE bar.h) > [snip] >> This command is used to set a list of headers "to precompile". > > This would say that any target that links to 'bar' would get 'bar.h' as > a source file to be precompiled for that target's settings. This makes > some sense for producing the precompiled header, but what decides what > precompiled header is *used* by each source file? IIUC a given compiler > call may specify at most one precompiled header to use because it is > actually more like a partially compiled translation unit to be continued > by each source consuming it. There is be one header per target that is precompiled and used to compile all source files of that target. This header is generated by CMake. It simply #includes all files that are requested to be precompiled. In the example above, each target that links to 'bar' will have a precompiled header that contains the line '#include ' among others. cheers, Daniel From daniel at pfeifer-mail.de Fri Mar 20 15:56:36 2015 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Fri, 20 Mar 2015 20:56:36 +0100 Subject: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation In-Reply-To: <550C5A4A.7080406@reactos.org> References: <20150302010209.GC17534@bronto-burt.dev.benboeckel.net> <5BB62C37-0B76-4CA9-9529-3E3FCB5D151E@java.pl> <54F762D3.8080608@kitware.com> <550C5523.8040501@kitware.com> <550C5A4A.7080406@reactos.org> Message-ID: On Fri, Mar 20, 2015 at 6:35 PM, Amine Khaldi wrote: > Two requests please: > > * The option to use existing headers instead of autogenerated ones. That is an implementation detail. It should not make a difference whether the precompiled header is used through your existing header or through an autogenerated header that forward includes your existing header. This forward inclusion is important at least for GCC: The compiler searches for a .gch file in the same directory as the header file. Since we do not want this .gch file to be generated in the source directory for out-of-source builds, we need to put the header file into the build directory. Did I misunderstand your request and you meant "use an existing *precompiled* header", ie. provide a .pch or .gch file? My approach currently does not support that. Please let me know if that is what you meant. > * Implementing PCH support without additional targets. ReactOS already has like 1000+ targets, and we currently use PCH on almost all of them, so imagine if this official implementation doubles our targets number. I completely agree. One request that I can add: * It shall be visible in the IDE's settings that precompiled headers are used. Cheers, Daniel From amine.khaldi at reactos.org Fri Mar 20 16:08:33 2015 From: amine.khaldi at reactos.org (Amine Khaldi) Date: Fri, 20 Mar 2015 21:08:33 +0100 Subject: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation In-Reply-To: References: <20150302010209.GC17534@bronto-burt.dev.benboeckel.net> <5BB62C37-0B76-4CA9-9529-3E3FCB5D151E@java.pl> <54F762D3.8080608@kitware.com> <550C5523.8040501@kitware.com> <550C5A4A.7080406@reactos.org> Message-ID: <550C7E41.9@reactos.org> > That is an implementation detail. It should not make a difference > whether the precompiled header is used through your existing header or > through an autogenerated header that forward includes your existing > header. This forward inclusion is important at least for GCC: The > compiler searches for a .gch file in the same directory as the header > file. Since we do not want this .gch file to be generated in the > source directory for out-of-source builds, we need to put the header > file into the build directory. > > Did I misunderstand your request and you meant "use an existing > *precompiled* header", ie. provide a .pch or .gch file? > My approach currently does not support that. Please let me know if > that is what you meant. Right now Peter K?mmel's solution works perfectly for us, with GCC, thanks to the object location property. A similar concept can easily solve this implementation detail without the need for a CMake generated header. We really hope we will have the option of not having these headers in the binary folder. By existing precompiled header I mean: https://git.reactos.org/?p=reactos.git;a=blob;f=reactos/base/applications/calc/CMakeLists.txt;h=85332bd76ea9f1e6cbcfee7d09929a3460083f50;hb=HEAD#l23 As you can see, calc.h is a header perfectly suitable for PCH creation. All our targets (that use PCH) have headers like that. Here's the GCC bit BTW: https://git.reactos.org/?p=reactos.git;a=blob;f=reactos/cmake/gcc.cmake;h=25c451ccd2979efeddd721784c12fed68b1ed604;hb=HEAD#l395 > One request that I can add: > > * It shall be visible in the IDE's settings that precompiled headers are used. Sounds good. We already have that for VS so far (the VS flags mappings in CMake show you PCH use in the VS projects' properties) and we don't use any other IDEs so I can't speak of the rest. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Sat Mar 21 04:17:08 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 21 Mar 2015 09:17:08 +0100 Subject: [cmake-developers] [CMake 0015462]: Provide a machine readable way to determine the available generators Message-ID: <97b8c4141425e709d6296e6bb02e9fd4@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15462 ====================================================================== Reported By: Stephen Kelly Assigned To: ====================================================================== Project: CMake Issue ID: 15462 Category: CMake Reproducibility: have not tried Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-21 09:17 CET Last Modified: 2015-03-21 09:17 CET ====================================================================== Summary: Provide a machine readable way to determine the available generators Description: As per http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12658/focus=12750 Providing some easily parsed way of determining the available generators for IDEs would be useful. Eg: $ cmake -E list_generators { "generators": [ { "name": "Unix Makefiles", "multiconfig": false, "recursive": true, "extraGenerators": ["Sublime", "CodeBlocks"] }, { "name": "Ninja", "multiconfig": false, "recursive": false, "extraGenerators": ["Sublime", "CodeBlocks"] }, { "name": "Xcode" "multiconfig": true, ... } ... ] } ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-21 09:17 Stephen Kelly New Issue ====================================================================== From steveire at gmail.com Sat Mar 21 04:18:53 2015 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 21 Mar 2015 09:18:53 +0100 Subject: [cmake-developers] Generating buildsystem metadata from CMake References: Message-ID: Tobias Hunger wrote: >>> sources: [ { >>> language: "C++", >>> type: sources, >>> defines: "FOO=1", >>> include_paths: "/usr/include", >>> files: [ "/full/path/a.cpp", "/full/path/b.cpp" ] >>> }, >>> { >>> language: "C++", >>> type: headers, >>> files: [ "/full/path/a.h" ] >>> }, >>> { >>> language: "C++", >>> type: generated, >>> files: [ "/full/path/config.h" ] >>> }] > > The type is used to distinguish between the different kinds of files. > Your proposal uses different keys for all the different kinds of > files, my is to use the same key for all sources and distinguish > between them by giving a type. Ok, I understand the proposal. >> I think in the worst case, you'd watch the CMakeCache.txt and read the >> CMAKE_CONFIGURATION_TYPES from there. I know you want to care about only >> one file, but maybe two is not so bad :), and there is potentially other >> stuff in the cache which might be useful, and which might not lend itself >> to the json metadata file. We'll have to see. > > So we are back to parsing random files in internal formats again:-) Well, or getting the information you need into the metadata.json or make cmake output it with a special command, as I suggested below. > Could you add have a "configuration list" key in the top level of each > file that lists all available configurations (including itself)? That > might be the lowest overhead solution that does not require parsing > extra files that I can think of right now. For Ninja and Makefile generators, CMake does not necessarily know 'all' of the configurations. It only knows what the user specified as the CMAKE_BUILD_TYPE. I could have a CMakeLists.txt with a condition like: if (CMAKE_BUILD_TYPE STREQUAL Coverage) # Foo endif() and I could document to users/developers that they use it for coverage. CMake would not treat the above any differently to any other condition on any other variable. CMake can probably list its own built-in configurations, like Debug/Release/RelWithDebInfo/MinSizeRel, but that's not a generic solution. If you want though we can do that. > I definitely will not hardcode cmake generator-A has configurations X > and Y while generator-A supports configurations X, Z and D into the > cmake plugin. I do prefer not to support configurations at all to > doing that. I think your position is reasonable. It is likely that you should consider Makefile and Ninja generators to be single-configuration, and we provide a way to give you the CMAKE_CONFIGURATION_TYPES for the multi-config generators. > What we do there is to check the default project build location for > folders that contain a build of the current sources. > > To do so we need to know which code was built in that directory I get this: The JSON file in the build dir would contain the path to the source and that part of the problem is solved, right? > and > which kit (think set of compiler, Qt, some other settings) were used > to in the built in that directory. Is this hypothetical? Currently I can add a compiler location and a Qt location in QtCreator, and I can create a kit and give it a name and partcular compiler and Qt. However, the information I configure there and the kit that I choose is not passed to cmake when creator invokes that, right? CMake will do its own determination of the compiler to use, and will find Qt on its own, right? Unless the user manually sets those as arguments in the 'Run CMake' dialog page. My point is that you have to pass CMake this information before it can pass it back to you :). I might be looking at an old creator which doesn't have a relevant feature here though? Or are you thinking of scenarios such as 'the user creates a build outside of Creator and then tries to open it in creator'. Given that 'a kit' is something internal to Creator, there is no way CMake could tell you the kit in that scenario. Is that obvious or am I missing something? I think the best thing you can do there is find out which compiler was used, and what the value of Qt5Core_DIR is, and map that to things you know about available kits to find the match if there is one. In other words, this again collapses to 'we need a way to read cache values'. > We also need to figure out the > exact configuration (parameters passed to the "configure" step of the > build system) that was built there. My first question is 'Why?'. Running 'cmake .' in the build dir re-uses the options which were passed to it before. Aside from that, particular arguments can be retrieved from the cache. It seems that some stable interface to the cache is needed anyway. At most, this is just another reason to add a stable interface to it, right? > Since this is a feature our qmake users love I would also like to make > that possible with cmake. It would be great if I could get most > answers from the json file. I see. How do you determine which kit to use if you are imported an externally generated qmake build? Do you use heuristics like I described above? >> Set up a filesystem watcher for each of the (very many) files. >> If one of the files changes: >> Run `cmake .` in the build dir >> If the metadata file changes: >> Reload the data it contains > > Yes, that's the scenario. In the 'one of the files changes' scenario, how do you imagine the change happened? Something the user did, either in creator, or a git checkout, or anything else? >> Is it a problem if the value of 'very many' above is in the hundreds? > > I would probably trim down the list to those actually in the project > or build directories, but I would prefer having too much information > than too little:-) I don't see any reason to watch anything in the build dir. It is 'owned' by cmake and the user has no business messing with any files there. Additionally, any messing around they do there would immediately be overwritten by Creator running in the background. It seems that the relevant locations are 'within the source tree' and 'some external site of cmake files', such as the cmake installation itself, or cmake helper files shipped by a 'platform' like KDE. What do you think? Are changes to files outside of the source tree relevant at all? Is the 'you update your system cmake' scenario important enough that Creator should immediately update the content it shows without user interaction? FWIW I think the IDE should not do this 'regeneration in the background' for me when I edit files outside of the IDE. If I have Creator open in the background and then I go to the console and edit some files (possibly outside of the source dir of the project which is open in Creator), and save multiple times over a few seconds, I don't want Creator to be constantly re- running cmake for me. Or I'm doing a 'rebase -i' or anything else which is not for Creator to worry about. I also wonder how cmake would react if I edited those files and I ran 'cmake .' myself, and Creator did the same thing at the same time. I don't know that cmake currently defends against that. I only want the IDE to re-generate when I'm actually working in the IDE. If I edit any file and hit Ctrl+B, the IDE runs 'cmake --build .' and cmake regenerates if needed at that point. It's 'ok' if the project tree is technically 'stale' after I edit a file and before I hit Ctrl+B. It's 'ok' in the sense that the alternative is 'worse' as far as my opinion goes. You also have the option of running 'cmake .' any time any file is saved in the IDE, if that improves the experience, but I strongly believe you shouldn't be watching the files for outside changes and re-generating in response. That's not to say we won't 'give you the rope'. But before we would do that, cmake would have to be defensive against concurrent runs in the same build dir. > In addition I will probably have a "Run cmake" option in the menu to > force the metadata to regenerate. Yes, that's already there in the 'build' menu anyway. >>> I would love to have something like ccmake built into Qt Creator at >>> some point, and having this information would spare me poking around >>> CMakeCache.txt and whatnot:-) >> >> If you mean you would like a fully-featured cache editor in Creator, then >> reading CMakeCache.txt is unavoidable, but you'd probably fork some of >> the Source/QtDialog code as a starting point. > > Is CMakeCache.txt considered to be a implementation detail of cmake, > or is it expected that external applications will parse it? As far as I know the file is an implementation detail. So, I guess if we add some stable interface for reading it, you wouldn't really have to read the CMakeCache.txt file directly and could 'write' it by invoking cmake with -D arguments. >> $ cmake -E read_cache Qt5Core_DIR Boost_ROOT KF5Archive_DIR ZLIB_LIBRARY >> { >> "Qt5Core_DIR": "/opt/qt5/...", >> "BOOST_ROOT": "/opt/boost/1.58/...", >> "KF5Archive_DIR": "/opt/kf5/karchive/...", >> "ZLIB_LIBRARY": "/opt/zlib/..." >> } > > Yes, that would be nice, but once you add "cmake -E list_cache" you > could just as well just add the whole config into the json file and > let its users worry whether or not to actually read the section. When you wrote 'config' you meant 'cache key value pairs' or simply 'cache'. The key difference is that my proposal is only requested values, so is minimal. As you suggest, we could write all of the cache data into the generated cmake-metadata.json file. Alternatively, we could design the interface such that you specify not only what version of the metadata you want, but also which cache values $ cmake . -DCMAKE_GENERATE_METADATA=3.3 -DCMAKE_METADATA_CACHE="Foo;Bar" to generate a cache section in the metadata file with the 'Foo' and 'Bar' key-value pairs. Is there any particular reason you want "everything" instead of specifying what you want? You don't know how to understand 'everything'. Is it just because of the idea you wrote above about a cache editor within Creator? Why not just run cmake-gui as an external process? Note also that nothing in the cache tells you the path to qmake for Qt 5 or anything like that. The Qt5Core_DIR is a path to `qt_installation/lib/cmake/Qt5Core`. Depending on how Qt was built, qmake may or may not be in `../../bin`. I don't know if that's relevant to Creator. At any rate, the content of the Qt5Core_DIR variable is what identifies Qt to CMake. qmake does not identify Qt 5 for CMake. However, if you run `qmake -query QT_INSTALL_LIBS` for each of your available Qts, you can map to the right one easily enough. >>> Having the full configuration available would also remove the need to >>> have special flags in the "Metadata Contents" section for the compiler >>> used. >> >> I don't know what you mean. You mean '-g', '-O3' etc? Or are you >> referring to what I wrote about the pattern of the compile command line, >> and the order of where includes definitions and compile flags appear? > > You documented a couple of keys in the top level that deal with the > compiler (See "Metadata Contents/Optional Properties", e.g. > "_compiler"). > > I will need more information than just the compiler used: The Qt > version used is obviously important to us, as are all settings > related to cross-compilation. By 'important to us', do you mean 'we provide interface allowing the user to edit the values, and we pass those values to CMake on behalf of the user'? Is that currently the case? If it is not currently the case, does the fact that the metadata file does not currently exist somehow block that? If so, how? That feature seems completely orthogonal to the metadata file to me. It could be added to Creator at any time if it is not there already. > Ideally I would get away with just the json file (which would require > copying all the configuration into it), but if I am required to parse > CMakeCache.txt anyway, then I do not see the need to copy settings > that are readily available there. Right. > Well, I am mostly interested in the tree of CMakeLists.txt files and I > think I can re-generate that from the backtrace:-) Right. > Maybe we could have a tree of "source objects" in the targets stead of a > list? Maybe. I think it makes sense to leave behind discussion of the exact format and structure of the json file. It feels like we need to take a step back and gather more requirements. >> Yes, so far this is possible, and doesn't carry a requirement to not >> generate an actual buildsystem... > > I agree with Anton that it would be nice not to have to ask for a > build directory and generator first thing. Adding a way to make cmake dump the metadata to stdout would be possible, but it wouldn't help... > Many users just want to > browse some project and an IDE should support that use case as well as > possible. Nagging those users about a build directory or generator is > not the best user experience. ... CMake needs a directory to run in. It needs to generate files to compile to test the compiler features, determine the platform etc. The content of the project depends on the outcome of those configure-time tests. You need to give cmake a temp directory in this scenario *anyway*. A temp directory from your OS is fine, and you can read the metadata file from there. This doesn't change the scope or requirements afaics. >> $ cmake -E list_generators >> { >> "generators": ["Unix Makefiles", "Ninja", "Xcode"] >> } >> >> etc. > > That would be *really* nice to have once this metadata file is in place:-) It is also orthogonal to the metadata of the build itself and can be designed separately. I filed http://public.kitware.com/Bug/view.php?id=15462 if you want to engage in the design or implementation of that. >>> Creator needs to know where all files will end up on install since we >>> might need to copy them to a remote machine (e.g. a phone, or a Linux >>> box) to run/debug there. Installing everything with some temporary >>> directory prefixed to all paths does work, though. We can then rsync >>> the temporary directory to a device. But even then we will still need >>> to know where the executables end up on the device to run/debug. >> >> The CMAKE_STAGING_PREFIX is designed for this purpose. You would specify >> it when running cmake and copy the files from there. >> >> http://www.cmake.org/cmake/help/git-next/variable/CMAKE_STAGING_PREFIX.html >> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/8363/focus=8629 >> >> It's basically the same as extprefix in the Qt configure script. > > I am aware of that:-) > > Creator would still need to know where the files went that the user > wants to run/debug though. So at least for the binaries a way to map > them from the build to the install location is needed for our > use-case. Ok. So, requirements gathered in this email: * Being able to read cache values is of primary importance * * Open question whether values should be 'on demand' or 'always all' * Knowing which CMake files in the source directory need to be watched for changes is very important. * Knowing which CMake files outside of the source directory need to be watched for changes is very important. Major open question: How do we handle configs. Let's get to that next. Thanks, Steve. From mantis at public.kitware.com Sat Mar 21 04:38:28 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 21 Mar 2015 09:38:28 +0100 Subject: [cmake-developers] [CMake 0015463]: Provide a way to generate machine readable output during CMake generation Message-ID: <522bee2cd45dbabff040a75c2a6ae80e@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15463 ====================================================================== Reported By: Stephen Kelly Assigned To: ====================================================================== Project: CMake Issue ID: 15463 Category: (No Category) Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-21 09:38 CET Last Modified: 2015-03-21 09:38 CET ====================================================================== Summary: Provide a way to generate machine readable output during CMake generation Description: As in: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12658/focus=12753 cmake could accept a command line argument to generate output in a different way which is more easy for tools to parse. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-21 09:38 Stephen Kelly New Issue ====================================================================== From gjasny at googlemail.com Sat Mar 21 04:41:06 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Sat, 21 Mar 2015 09:41:06 +0100 Subject: [cmake-developers] CMake and intersphinx Message-ID: <550D2EA2.4040008@googlemail.com> Hello, I wanted to start documenting our in-company CMake modules. Often I'd like to refer to some basic CMake commands. As far as I understand the intersphinx extension [1] should be able to provide that. To reference remote projects these need to provide a objects.inv mapping file. But thee mapping files were excluded from install by this commit: http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=0c3cf36b3a1388bb9c3a718350c80eae0a41119d Would you consider re-adding these files? Or should 3rd parties host their own documentation sets somewhere? Thanks, Gregor [1] http://sphinx-doc.org/latest/ext/intersphinx.html From steveire at gmail.com Sat Mar 21 04:41:22 2015 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 21 Mar 2015 09:41:22 +0100 Subject: [cmake-developers] Generating buildsystem metadata from CMake References: Message-ID: Anton Makeev wrote: > The other thing that seems troubling to me is that since file, target, > language compiler options are split into different parts of metadata, the > IDE need to know exactly how to assemble them back into the compiler?s > command line (e.g. what flags go first file?s or language?s), duplicating > CMake's logic that may be different from version to version and from > compiler to compiler. The exact command line is needed to get the actual > and precise defines, include search paths etc. from the compiler. Yes. I previously proposed the _compile_command to contain information about how to built it: http://www.steveire.com/cmake-future/manual/cmake-metadata-generation.7.html#optional-properties However, I think it might be better to generate something similar to what is currently generated in compile-commands.json into cmake-metadata.json. That is, we would generate (in some context) "include_directories" : ["/foo", "/opt"] "compile_definitions" : ["DEF=\"Foo\"", "OTHER_DEF=1"] "compile_command": "-c -DDEF=\"Foo\" -DOTHER_DEF=1 -I/foo -I/opt" So, "compile_command" contains approximately what you can currently get from compile-commands.json. The other properties contain things which are specifically known to be include directories or compile definitions, as javascript arrays. These properties are obviously redundant information, so I wonder if they should be generated at all? Is the compile command I wrote above easy to parse? Or is it sufficiently difficult to parse that this redundant information should be provided? I have no idea if such "compile_command" can be generated for VS or Xcode, or if constructing such compile commands is done internally by those tools. So, this may not be a portable solution anyway. > This would be really helpful indeed, currently, we have to introspect > CMakeLists.txt files in order to find the most probably place where new > files should be placed (works only in basic cases now). And being able to > do so correctly is also crucial for refactoring (e.g. extract class). Given the backtrace, you can navigate up the scope from the most recent frame to get out of any functions, macros or loops. You can then add a target_sources() line directly after that. That algorithm will work for every case (not just basic cases) as far as I can tell and is available with CMake 3.1. >> * I didn't document the location or directory. I'm not clear on whether >> it is supposed to be the build location, or the install location(s!), >> or all of those. > > It would be useful, though, to have a location of generated files for each > target: in case metadata misses some information (and I think it won?t > cover every possible need anytime soon), IDE will be able to get if from > generated makefiles. Yes, we can at least provide the build location in an obvious way. We can discuss install locations eventually. >> * I don't generate 'dependencies' (actually the list of files which the >> buildsystem re-generation depends on) as Aleix did, because there is no >> well-defined usefulness for that list yet. > > As Tobias pointed, we at least need to know what files are the part of > CMake project, that is, the list of all CMakeLists.txt and *.cmake files, > used for generation (ideally, including missing ones, since in that case > IDE could be able to tell when missing file is created and refresh the > project) As I wrote to Tobias, I'm apprehensive about this, and it would require other work to make cmake parallel safe first. I think if the IDE does not have focus it should not be running 'cmake .' on my behalf. I think if the IDE newly gets focus you can maybe run 'cmake .' at *that* point (after the user is done with their rebase or whatever). That doesn't require giving you a list of files to watch. Maybe I'm missing something though. >> * Some more information from project() may be relevant, but it's not >> clear >> yet. We will likely know more when we have decided the file format and >> generated some 'interesting' metadata files. > > Project name, list of the configurations are most needed ones. > We also use CMAKE__SOURCEFILE_EXTENSIONS to determine if a given > file is potentially source file or not. As CMake already knows which files are 'object sources', the metadata will provide that. Also, the extensions is not enough. See the unit test I created and in particular the compiled_as_cxx.c file. > This has already been discussed but I give our usage scenario: > > in CLion we retrieve the list of all build types (aka configurations, > Debug, Release etc) >From where do you currently retrieve this list? I guess you look at all cache keys named CMAKE_.*_FLAGS_(.*) and list the matches? and list the matches? > and then generate project using Makefiles generator > for each of them. This is necessary because of several reasons: 1) To be > able to correctly build language model, we need to know, when a file is > used in several configurations, which means, it's compiler settings and > macros are different. > E.g. some branches of code may not be available in Debug or Release > and we give user an option to quickly switch between them in the > editor. This seems similar to what Tobias talked about. > I don?t know if it?s possible at all, but it would be great if we could > have info for all configurations generated in one go (not only for > multi-config, but for single-config generators as well like Ninja and > Makefiles). I can think of two ways to make that possible: 1) Create new mulit-config generators, or add options for the existing ones. 2) Add a generic multi-configuration mode to cmake: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10873/focus=10912 http://public.kitware.com/Bug/view.php?id=14539 I consider both out of scope for this thread though. > As a side note, it seems more natural to me to have one json file with one > or several configurations listed, providing that there is also shared > project info that should be in that files. something like that: I'm going to post a separate mail about this. I think 'how to handle' the most pressing point we need to design for here. We can't make further progress until that part is designed. >> * Generating metadata only (without generating buildsystem files) is not >> currently in scope. This was requested several times, but it is not >> clear why. > > It?s simply to be able to get this the information as quickly as possible. > I?m not sure which part is most slow, but, say, InsightToolKit 4.5 > (http://www.itk.org/Wiki/ITK/Source ), > generates in couple of minutes. CMake has a 'configure' step followed by a 'generate step'. Your count of minutes must be the sum of both. The information determined during those steps is exactly what the metadata file should contain. Avoiding all of it would leave you with no metadata. > The regeneration, even when nothing was > changes, a few dozens of seconds. This cost is mostly the 'generation step', as everything from the 'configure step' was cached and available for re-generation. > Plus, we?d prefer being able to open the project without any questions to > user, e.g. not asking, which generator he/she prefers. If we generate > using ?wrong? default generator we?ll need to regenerate everything again > when user decides to change it. It seems like you can use a throwaway temp directory until the user chooses a generator. I am sympathetic to the idea of 'not breaking the users flow', but I don't currently have any idea how to avoid it. Everything does indeed have to be re-generated if the generator is changed, and cmake currently issues an error if you use a different -G option than was originally used in a build dir. If you really want to change that behavior, I suggest a separate bug report to track the idea. As I said I am sympathetic to the idea, but I don't see a way. If you file a bug, maybe Brad will have an idea or can say it's fundamentally out of scope. > Another benefit of skipping actual generation is possibly better error > recoverability. That is, some generators may fail here and there if the > project is incorrectly configured (e.g. source files are missing). > Skipping the generation phase will (probably) help getting the project > metadata even in that case. I don't think that's the case. The 'generate step' is the point where the metadata is generated, and that step begins strictly after the 'configure step' ends. The scenario you describe is errors during the 'configure step'. That means no metadata for you. If this is possible to change, it's out of scope of this current design work. I'd suggest a separate bug report. > But anyway, it seems a little outside of the scope of the discussion. Yep :). >> * How much information does tooling need about installation? Targets >> can use different include directories and compile definitions in their >> install locations compared to their build locations. If IDEs want to >> provide some user interface related to the project files in their >> install location, perhaps a separate solution based on cmExportFile* >> is needed. For future investigation. > > > An additional though: here only the 'project information' aspect is > discussed; though, to be fully machine-frienly, cmake should be able to > also generate parseable output (error reports etc), provide the progress, > etc. So, just to mull over, probably the discussed design should consider > such future direction. Ok. It is also orthogonal to the metadata of the build itself and can be designed separately. I filed http://public.kitware.com/Bug/view.php?id=15463 if you want to engage in the design or implementation of that. Thanks, Steve. From mantis at public.kitware.com Sat Mar 21 04:46:28 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 21 Mar 2015 04:46:28 -0400 Subject: [cmake-developers] [CMake 0015464]: target_include_directories(tgt SYSTEM PUBLIC foo) adds include path with -I instead of -isystem Message-ID: <669d79981890b2b105eb2d95cfc21f2c@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15464 ====================================================================== Reported By: socantre Assigned To: ====================================================================== Project: CMake Issue ID: 15464 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-21 04:46 EDT Last Modified: 2015-03-21 04:46 EDT ====================================================================== Summary: target_include_directories(tgt SYSTEM PUBLIC foo) adds include path with -I instead of -isystem Description: With the ninja generator and AppleClang on OS X the include flag -I is used instead of -isystem when include directories are added to specific targets A global include_directories(SYSTEM headers) uses the correct -isystem flag Steps to Reproduce: mkdir tmp && cd tmp touch main.cpp cat << EOF > CMakeLists.txt cmake_minimum_required(VERSION 3.2) project(test) add_executable(main main.cpp) target_include_directories(main SYSTEM PUBLIC include) EOF mkdir build && cd build cmake -G Ninja .. grep build.ninja -e "-I../include" Additional Information: -- The C compiler identification is AppleClang 6.0.0.6000057 -- The CXX compiler identification is AppleClang 6.0.0.6000057 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-21 04:46 socantre New Issue ====================================================================== From mantis at public.kitware.com Sat Mar 21 05:03:21 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 21 Mar 2015 10:03:21 +0100 Subject: [cmake-developers] [CMake 0015465]: Provide a way to build individual files through cmake Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15465 ====================================================================== Reported By: Stephen Kelly Assigned To: ====================================================================== Project: CMake Issue ID: 15465 Category: (No Category) Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-21 10:03 CET Last Modified: 2015-03-21 10:03 CET ====================================================================== Summary: Provide a way to build individual files through cmake Description: CMake has the `--build` command line option providing an abstraction of 'run the build in the specified directory' action. Particular configurations and targets to build can be specified with other options. A new abstraction could be added for 'build the object for sourcefile f'. The Makefiles generator already generates targets for each object in each directory. Those targets are not available from the 'top level' of the build dir. grantlee/make_build$ cmake .. -G "Unix Makefiles" grantlee/make_build$ make -C templates/lib engine.cpp.o Ninja has native support for 'building the output of a source file' using '^'. grantlee/ninja_build$ cmake .. -G Ninja grantlee/ninja_build$ ninja ../templates/lib/engine.cpp^ grantlee/ninja_build$ cmake --build . --target ../templates/lib/engine.cpp^ Ninja seems to build more dependencies of the object file though too (it runs moc via automoc for example, but make seems not to). It is unknown whether the IDE generators have a way to build an individual file. As the syntax is different for different tools, it could be useful for cmake to provide a unified abstraction. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-21 10:03 Stephen Kelly New Issue ====================================================================== From steveire at gmail.com Sat Mar 21 05:12:33 2015 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 21 Mar 2015 10:12:33 +0100 Subject: [cmake-developers] Generating buildsystem metadata from CMake References: Message-ID: Tobias Hunger wrote: > Hi Anton, > > you raised some good points, all of which I agree with:-) > > On Thu, Mar 19, 2015 at 10:18 AM, Anton Makeev > wrote: >> * If it is useful to preprocess/compile/assemble individual files from >> IDEs, as made possible by the Makefiles and Ninja generators, we'll need >> to design that. >> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12429 >> >> >> This is definitely useful, but I?m not sure what kind of information >> needed here, >> as I see it, since we already know the files in the project, we can tell >> make/ninja to simply compile it. > > You asked me to use "cmake --build", so ideally that would be "cmake > --build . /full/file/path" and ideally it would work with all > generators without magic in the IDE:-) It is also orthogonal to the metadata of the build itself and can be designed separately. I filed http://public.kitware.com/Bug/view.php?id=15465 if you want to engage in the design or implementation of that. > > Since I assume that not all build systems will allow to build > individual files, you might want to add a flag > "can_build_individual_files" or similar to the metadata that a > generator can use to flag the IDE on whether the generated build > system can build individual files or not. Then the IDE can hide that > option if it is not applicable. Yes. If it's not possible for xcodebuild/VS, then such a property can be added. Noted in http://public.kitware.com/Bug/view.php?id=15462 > I would also love to see subprojects:-) CMake allows for them, doesn't it? I don't know what 'subprojects' means to you. >> An additional though: here only the 'project information' aspect is >> discussed; though, to be fully machine-frienly, cmake should be able to >> also generate parseable output (error reports etc), provide the progress, >> etc. So, just to mull over, probably the discussed design should consider >> such future direction. > > Yes, that would be great, but I do not see how cmake can do that: It > delegates the actual build to external tools. Anton is talking about output of cmake itself afaik. > So in the end during a build we will always have to deal with whatever > output the generated buildsystem throws at us:-/ This again somewhat > limits the usefulness of allowing the user to pick whichever generator > they want: Some will just loose some or all the build issues. Only allow the user to choose a generator for whose make_program you have a parser for. Thanks, Steve. From steveire at gmail.com Sat Mar 21 05:14:58 2015 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 21 Mar 2015 10:14:58 +0100 Subject: [cmake-developers] Generating buildsystem metadata from CMake References: Message-ID: Tobias Hunger wrote: > On Wed, Mar 11, 2015 at 11:10 AM, Stephen Kelly > wrote: >> * Make it possible for editors/IDEs to allow specifying the configuration >> at build-time, where the IDE has that feature, and where a multi-config >> generator is available. That is, QtCreator provides user-interface for >> choosing debug/release config to build. Currently it can't offer that >> when using cmake, because it only allows the use of Makefile or Ninja >> generators, in order to make use of the C::B file. QtCreator should be >> able to use the Xcode or Visual Studio generators, generate the >> metadata file(s), and invoke `cmake --build . --config ${CONFIG}` as >> appropriate. Eclipse, Sublime and other editors have similar abilities >> to invoke config-specific builds after generation. > > We can offer debug/release even with different build directories in > Creator. Those are just labels on the build configuration that > includes the build directory and the configuration to be set up in > that build. Interesting. Is that already the case in Creator? > For the other build systems it is completely safe to just nuke any > build directory and creator will re-initialize it on the next build. > That is unfortunately not the case with cmake at this time though: If > you nuke a cmake build directory then creator will be completely lost > about how to regenerate the configuration again. Ah, is this why you asked before for the command line options passed to cmake before? Why is it safe with other buildsystems but not cmake to nuke the build dir? Thanks, Steve. From steveire at gmail.com Sat Mar 21 05:56:24 2015 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 21 Mar 2015 10:56:24 +0100 Subject: [cmake-developers] How to handle configurations (Was: Generating buildsystem metadata from CMake) References: Message-ID: This seems to be to be a design point which we are blocked on. There are many different ideas floating around. I think we need to talk about what would be generated for actual CMakeLists files, and how tools would parse the result. I suggest starting with the Tests/Metadata/CMakeLists.txt file in my clone. I think we need to see both json files and prototype parsers in some mainstream language or framework (Qt5,Python etc) in order to see whether a particular proposal is viable. For my proposal there is already a generated json file checked in as an example, and a python class for extracting the information. The requirements for the metadata file include 1) Make it easy to get relevant information without extra computation/logic. 2) Be as DRY as possible. 3) Design something that is possible for cmake to generate. The first two requirements are obviously in direct conflict. The third will I'm sure be a limitation compared to what you desire. If some part of what you propose is impossible, we'll either have to design a way to make it possible, or accept that it is impossible and update the proposal. Hopefully this will converge on a design which provides both what is needed and what is possible. Implementing it will be easy then. Tobias Hunger wrote: >Anton Makeev wrote: >> As a side note, it seems more natural to me to have one json file with >> one or several configurations listed, providing that there is also shared >> project info that should be in that files. >> something like that: >> >> project: ProjectName >> configurations: { >> { >> name: Debug >> targets: {...} >> }, >> { >> name: Release >> targets: {...} >> } >> ... >> } If we do this, then we have N repetitions of exactly the same data, or almost exactly the same data. It could be a lot of data. Is that a problem? For machine reading it is probably not a problem. All the repetition does make it harder for human reading though of course. I also don't know at what point does it become slower for the IDE to have to parse ~4-6N times the amount of data. If the configuration is a 'mode' and only one configuration is active at a time, you're not using the other stuff anyway. If you want all the data for all configurations (even inactive ones) for some reason, then the repetition probably doesn't matter at all. Even with my proposal of separate files, you would want to load all the files anyway. Is that the case? So, the design question I have is: * Is lots of repetition ok in the metadata file? The answer will be re-used in many other places. For example, if I have a CMakeLists like add_executable(main file1.cpp ... fileM.cpp ) target_include_directories(main ...) target_compile_definitions(main ...) then we could either write the definitions and includes once (associated with the target), or we could repeat them all M times (once for each file). That could be lots and lots of repetition, repeated N times, once for each configuration. I personally prefer minimising the repetition, as I did in the unit test I pushed to my clone. I have the feeling you guys have not looked at the unit test I pushed to my clone. Please go ahead and do that if not. Also, when proposing json formats, please imagine how your proposal would represent the data in Tests/Metadata/CMakeLists.txt. Anton, in your proposal, given that realistically Makefile and Ninja generators are not going to become aware of multiple configurations before this feature reaches master, what should they generate? project: ProjectName configurations: { { name: WHAT_WAS_IN_CMAKE_BUILD_TYPE targets: {...} } or project: ProjectName targets: {...} or project: ProjectName configuration: WHAT_WAS_IN_CMAKE_BUILD_TYPE targets: {...} ? > I'd actually prefer having a "configurations" key with the list of the > configurations an object applies to. > > That can be optional if the object is relevant to all configurations > (default in single-configuration generators;-). > > This key would then need to be applicable to targets as well as the > group of source files. > > So that would be something like this: Could you post what would be generated by your proposed structure for the unit test file in my branch? > That would most likely avoid quite a bit of duplication in the file(s). How does the design goal of 'avoid duplication' weigh against the design goal of 'don't make me combine multiple properties together to get relevant information (eg target defines and additional source defines)', in general? We can either go for one extreme or the other, but I don't think it makes sense to go for something in between. That would be the worst of both worlds. So, for the proposals which are on the table, please either use the Metadata/CMakeLists.txt file in my clone, or post an alternative together with the json which you propose we should generate for it, and a prototype or pseudo-implementation of a parser for that json. Thanks, Steve. From alex.merry at kde.org Sat Mar 21 07:06:36 2015 From: alex.merry at kde.org (Alex Merry) Date: Sat, 21 Mar 2015 11:06:36 +0000 Subject: [cmake-developers] CMake and intersphinx In-Reply-To: <550D2EA2.4040008@googlemail.com> References: <550D2EA2.4040008@googlemail.com> Message-ID: <2037760.ImaFPdq0eZ@kyoshi> On Saturday 21 March 2015 09:41:06 Gregor Jasny wrote: > Hello, > > I wanted to start documenting our in-company CMake modules. Often I'd > like to refer to some basic CMake commands. As far as I understand the > intersphinx extension [1] should be able to provide that. To reference > remote projects these need to provide a objects.inv mapping file. > > But thee mapping files were excluded from install by this commit: > http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=0c3cf36b3a1388bb9c3a71835 > 0c80eae0a41119d > > Would you consider re-adding these files? Or should 3rd parties host > their own documentation sets somewhere? > > Thanks, > Gregor > > [1] http://sphinx-doc.org/latest/ext/intersphinx.html This would also be useful for the extra-cmake-modules project. Alex From mantis at public.kitware.com Sat Mar 21 07:33:14 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 21 Mar 2015 07:33:14 -0400 Subject: [cmake-developers] [CMake 0015466]: ninja does not use requested linker Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15466 ====================================================================== Reported By: Benjamin Schindler Assigned To: ====================================================================== Project: CMake Issue ID: 15466 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-21 07:33 EDT Last Modified: 2015-03-21 07:33 EDT ====================================================================== Summary: ninja does not use requested linker Description: In a project, I set CMAKE_LINKER to /usr/bin/ld.gold. Yet, when I build my project, the link step uses /usr/bin/c++ to link the project. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-21 07:33 Benjamin SchindlerNew Issue ====================================================================== From mantis at public.kitware.com Sat Mar 21 22:04:35 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 21 Mar 2015 22:04:35 -0400 Subject: [cmake-developers] [CMake 0015467]: add_custom_target ALL option regression Message-ID: <32b57977fec1dbdca78249618a42bbd7@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15467 ====================================================================== Reported By: Zhihao Yuan Assigned To: ====================================================================== Project: CMake Issue ID: 15467 Category: CMake Reproducibility: always Severity: minor Priority: high Status: new ====================================================================== Date Submitted: 2015-03-21 22:04 EDT Last Modified: 2015-03-21 22:04 EDT ====================================================================== Summary: add_custom_target ALL option regression Description: It seems that the ALL option is not making the target to run before other targets after cmake 3.1. The cmake file is here: https://github.com/lichray/nvi2/blob/master/build/CMakeLists.txt#L49 I'm generating header files with add_custom_commend and using add_custom_target to run those commands. Steps to Reproduce: See https://github.com/lichray/nvi2/issues/29 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-21 22:04 Zhihao Yuan New Issue ====================================================================== From gjasny at googlemail.com Sun Mar 22 07:16:45 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Sun, 22 Mar 2015 12:16:45 +0100 Subject: [cmake-developers] CMake and intersphinx In-Reply-To: <2037760.ImaFPdq0eZ@kyoshi> References: <550D2EA2.4040008@googlemail.com> <2037760.ImaFPdq0eZ@kyoshi> Message-ID: <550EA49D.6040709@googlemail.com> On 21/03/15 12:06, Alex Merry wrote: > On Saturday 21 March 2015 09:41:06 Gregor Jasny wrote: >> I wanted to start documenting our in-company CMake modules. Often I'd >> like to refer to some basic CMake commands. As far as I understand the >> intersphinx extension [1] should be able to provide that. To reference >> remote projects these need to provide a objects.inv mapping file. > This would also be useful for the extra-cmake-modules project. I pushed a topic branch to stage and await ACK for merging to next: http://www.cmake.org/gitweb?p=stage/cmake.git;a=commit;h=840f5b89a456b6f68a9b75c7a0a0bfc3fa37e643 From tobias.hunger at gmail.com Sun Mar 22 15:45:28 2015 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Sun, 22 Mar 2015 20:45:28 +0100 Subject: [cmake-developers] Generating buildsystem metadata from CMake In-Reply-To: References: Message-ID: Hi Stephen, On Sat, Mar 21, 2015 at 9:18 AM, Stephen Kelly wrote: >> Could you add have a "configuration list" key in the top level of each >> file that lists all available configurations (including itself)? That >> might be the lowest overhead solution that does not require parsing >> extra files that I can think of right now. > > For Ninja and Makefile generators, CMake does not necessarily know 'all' of > the configurations. It only knows what the user specified as the > CMAKE_BUILD_TYPE. I could have a CMakeLists.txt with a condition like: > > if (CMAKE_BUILD_TYPE STREQUAL Coverage) > # Foo > endif() > > and I could document to users/developers that they use it for coverage. > > CMake would not treat the above any differently to any other condition on > any other variable. CMake can probably list its own built-in configurations, > like Debug/Release/RelWithDebInfo/MinSizeRel, but that's not a generic > solution. If you want though we can do that. I understand and expect that. >> I definitely will not hardcode cmake generator-A has configurations X >> and Y while generator-A supports configurations X, Z and D into the >> cmake plugin. I do prefer not to support configurations at all to >> doing that. > > I think your position is reasonable. It is likely that you should consider > Makefile and Ninja generators to be single-configuration, and we provide a > way to give you the CMAKE_CONFIGURATION_TYPES for the multi-config > generators. I think that is fine. >> What we do there is to check the default project build location for >> folders that contain a build of the current sources. >> >> To do so we need to know which code was built in that directory > > I get this: The JSON file in the build dir would contain the path to the > source and that part of the problem is solved, right? Yes, that would already be a step into the right direction. >> and >> which kit (think set of compiler, Qt, some other settings) were used >> to in the built in that directory. > > Is this hypothetical? Currently I can add a compiler location and a Qt > location in QtCreator, and I can create a kit and give it a name and > partcular compiler and Qt. However, the information I configure there and > the kit that I choose is not passed to cmake when creator invokes that, > right? CMake will do its own determination of the compiler to use, and will > find Qt on its own, right? Unless the user manually sets those as arguments > in the 'Run CMake' dialog page. We do that for qmake projects at this time. Nothing listed here is needed to get the level of cmake support we have in Creator right *now*: That works fine already after all. I want something better:-) So I bring up all the things I can think of to get cmake to the same level that we currently have for qmake. > My point is that you have to pass CMake this information before it can pass > it back to you :). I might be looking at an old creator which doesn't have a > relevant feature here though? No, we do *nothing* to help with configuring a cmake project. That is far from ideal, you are right there. > Or are you thinking of scenarios such as 'the user creates a build outside > of Creator and then tries to open it in creator'. Given that 'a kit' is > something internal to Creator, there is no way CMake could tell you the kit > in that scenario. Is that obvious or am I missing something? I think the > best thing you can do there is find out which compiler was used, and what > the value of Qt5Core_DIR is, and map that to things you know about available > kits to find the match if there is one. Yes, that is the same we do for qmake projects. In fact we just create a new kit for configurations we had not seen before. > In other words, this again collapses to 'we need a way to read cache > values'. Yeap. >> We also need to figure out the >> exact configuration (parameters passed to the "configure" step of the >> build system) that was built there. > > My first question is 'Why?'. Running 'cmake .' in the build dir re-uses the > options which were passed to it before. In qmake it is perfectly save to do "rm -rf builddir" and then hit "Build" in Creator. I would love to have the same for cmake projects. > Aside from that, particular arguments can be retrieved from the cache. It > seems that some stable interface to the cache is needed anyway. At most, > this is just another reason to add a stable interface to it, right? Yeap, that would be fine. >> Since this is a feature our qmake users love I would also like to make >> that possible with cmake. It would be great if I could get most >> answers from the json file. > > I see. How do you determine which kit to use if you are imported an > externally generated qmake build? Do you use heuristics like I described > above? We exctract as much data as we can from the qmake build (Qt version, compiler, etc.) and then try to find an existing kit with those characteristics. If none is found we set up a new kit with all the settings. >>> Set up a filesystem watcher for each of the (very many) files. >>> If one of the files changes: >>> Run `cmake .` in the build dir >>> If the metadata file changes: >>> Reload the data it contains >> >> Yes, that's the scenario. > > In the 'one of the files changes' scenario, how do you imagine the change > happened? Something the user did, either in creator, or a git checkout, or > anything else? All of them:-) Git and other VCSes regularly touch the build system on updates. We have users editing them in Creator, while others use some other means. So I'll go with "all of the above":-) >>> Is it a problem if the value of 'very many' above is in the hundreds? >> >> I would probably trim down the list to those actually in the project >> or build directories, but I would prefer having too much information >> than too little:-) > > I don't see any reason to watch anything in the build dir. It is 'owned' by > cmake and the user has no business messing with any files there. > Additionally, any messing around they do there would immediately be > overwritten by Creator running in the background. True. So watching the files in the source dir should be enough. > It seems that the relevant locations are 'within the source tree' and 'some > external site of cmake files', such as the cmake installation itself, or > cmake helper files shipped by a 'platform' like KDE. > > What do you think? Are changes to files outside of the source tree relevant > at all? Is the 'you update your system cmake' scenario important enough that > Creator should immediately update the content it shows without user > interaction? I think the files in the cmake files in the source dir are what I will end up watching. I do need to offer a way to force cmake to regenerate everything anyway, so that is fine for the few cases where somebody updates cmake or globally installed cmake files. > FWIW I think the IDE should not do this 'regeneration in the background' for > me when I edit files outside of the IDE. If I have Creator open in the > background and then I go to the console and edit some files (possibly > outside of the source dir of the project which is open in Creator), and save > multiple times over a few seconds, I don't want Creator to be constantly re- > running cmake for me. Or I'm doing a 'rebase -i' or anything else which is > not for Creator to worry about. I also wonder how cmake would react if I > edited those files and I ran 'cmake .' myself, and Creator did the same > thing at the same time. I don't know that cmake currently defends against > that. > > I only want the IDE to re-generate when I'm actually working in the IDE. If > I edit any file and hit Ctrl+B, the IDE runs 'cmake --build .' and cmake > regenerates if needed at that point. It's 'ok' if the project tree is > technically 'stale' after I edit a file and before I hit Ctrl+B. It's 'ok' > in the sense that the alternative is 'worse' as far as my opinion goes. You > also have the option of running 'cmake .' any time any file is saved in the > IDE, if that improves the experience, but I strongly believe you shouldn't > be watching the files for outside changes and re-generating in response. That might be ok for you, but we do get a lot of bug reports whenever we have the project tree not update directly. So it is *not* ok for a large number of users, particularly those that come from a proprietary IDE that comes with a built-in build system. We do *not* update creator while it is not in use. When the window gets focus again we go "Things have changed outside Creator, do you want to update?". > That's not to say we won't 'give you the rope'. But before we would do that, > cmake would have to be defensive against concurrent runs in the same build > dir. A simple lock file should suffice. I would be surprised if that was not there already, but I never checked. >>>> I would love to have something like ccmake built into Qt Creator at >>>> some point, and having this information would spare me poking around >>>> CMakeCache.txt and whatnot:-) >>> >>> If you mean you would like a fully-featured cache editor in Creator, then >>> reading CMakeCache.txt is unavoidable, but you'd probably fork some of >>> the Source/QtDialog code as a starting point. >> >> Is CMakeCache.txt considered to be a implementation detail of cmake, >> or is it expected that external applications will parse it? > > As far as I know the file is an implementation detail. So, I guess if we add > some stable interface for reading it, you wouldn't really have to read the > CMakeCache.txt file directly and could 'write' it by invoking cmake with -D > arguments. > >>> $ cmake -E read_cache Qt5Core_DIR Boost_ROOT KF5Archive_DIR ZLIB_LIBRARY >>> { >>> "Qt5Core_DIR": "/opt/qt5/...", >>> "BOOST_ROOT": "/opt/boost/1.58/...", >>> "KF5Archive_DIR": "/opt/kf5/karchive/...", >>> "ZLIB_LIBRARY": "/opt/zlib/..." >>> } >> >> Yes, that would be nice, but once you add "cmake -E list_cache" you >> could just as well just add the whole config into the json file and >> let its users worry whether or not to actually read the section. > > When you wrote 'config' you meant 'cache key value pairs' or simply 'cache'. > > The key difference is that my proposal is only requested values, so is > minimal. Yes. But then you need to add "cmake -E list_cache" that lists all values. Or how can I find out which values are there in a project? Maybe also "cmake -E check_cache KEY" to check whether a key exists, etc. And "cmake -E query_cache KEY" to get the type and advanced flag for the KEY. In the end it is probably easier to either put all that stuff into the json file or to declare CMakeCache.txt to be a stable read-only file for the configuration. > As you suggest, we could write all of the cache data into the generated > cmake-metadata.json file. Alternatively, we could design the interface such > that you specify not only what version of the metadata you want, but also > which cache values > > $ cmake . -DCMAKE_GENERATE_METADATA=3.3 -DCMAKE_METADATA_CACHE="Foo;Bar" > > to generate a cache section in the metadata file with the 'Foo' and 'Bar' > key-value pairs. > > Is there any particular reason you want "everything" instead of specifying > what you want? Mostly because I want to be able to rm -rf "builddir" and still be able to build:-) > You don't know how to understand 'everything'. Is it just > because of the idea you wrote above about a cache editor within Creator? ... and because of a cache editor. > Why not just run cmake-gui as an external process? My hope is to get good cmake support into creator, not to add a more fancy set of clutches:-) That is one more thing that needs configuring, it is ugly to have yet another window pop up and I can not embed that where I want the information to be visible. > Note also that nothing in the cache tells you the path to qmake for Qt 5 or > anything like that. The Qt5Core_DIR is a path to > `qt_installation/lib/cmake/Qt5Core`. Depending on how Qt was built, qmake > may or may not be in `../../bin`. I don't know if that's relevant to > Creator. At any rate, the content of the Qt5Core_DIR variable is what > identifies Qt to CMake. qmake does not identify Qt 5 for CMake. However, if > you run `qmake -query QT_INSTALL_LIBS` for each of your available Qts, you > can map to the right one easily enough. Thanks for the tip! It is appreciated. >>>> Having the full configuration available would also remove the need to >>>> have special flags in the "Metadata Contents" section for the compiler >>>> used. >>> >>> I don't know what you mean. You mean '-g', '-O3' etc? Or are you >>> referring to what I wrote about the pattern of the compile command line, >>> and the order of where includes definitions and compile flags appear? >> >> You documented a couple of keys in the top level that deal with the >> compiler (See "Metadata Contents/Optional Properties", e.g. >> "_compiler"). >> >> I will need more information than just the compiler used: The Qt >> version used is obviously important to us, as are all settings >> related to cross-compilation. > > By 'important to us', do you mean 'we provide interface allowing the user to > edit the values, and we pass those values to CMake on behalf of the user'? > Is that currently the case? If it is not currently the case, does the fact > that the metadata file does not currently exist somehow block that? If so, > how? That feature seems completely orthogonal to the metadata file to me. It > could be added to Creator at any time if it is not there already. We do not do that *yet*: Currently the configuration inside Qt Creator and that of cmake are two entirely separate beasts, and that is a huge part of why I consider our cmake support to be in dire need of improvement. We need to feed information into cmake when we first set up a build directory and we need to retrieve that information back from cmake when we read make use of a build directory. I would really appreciate getting all possible information from CMake mostly since I doubt you can decide what each and every IDE will need that wants to integrate cmake. We need the Qt version used for the code model as well as for the help system. CLion will most likely not be so concerned about that piece of information but will need something else instead. Please do not try to second-guess which information might be relevant to any IDE, that is bound to fail. >>> Yes, so far this is possible, and doesn't carry a requirement to not >>> generate an actual buildsystem... >> >> I agree with Anton that it would be nice not to have to ask for a >> build directory and generator first thing. > > Adding a way to make cmake dump the metadata to stdout would be possible, > but it wouldn't help... Why not? We could set a temporary build dir and you give us the data you can. We have people that want to look into projects and moan when we ask them to configure a build dir since they do not understand why they need that: They want to browse the code only. We do need the information from the build system to set up the code model correctly and thus need to put them through that -- from their point useless -- setup. >> Many users just want to >> browse some project and an IDE should support that use case as well as >> possible. Nagging those users about a build directory or generator is >> not the best user experience. > > ... CMake needs a directory to run in. It needs to generate files to compile > to test the compiler features, determine the platform etc. The content of > the project depends on the outcome of those configure-time tests. You need > to give cmake a temp directory in this scenario *anyway*. A temp directory > from your OS is fine, and you can read the metadata file from there. > > This doesn't change the scope or requirements afaics. > >>> $ cmake -E list_generators >>> { >>> "generators": ["Unix Makefiles", "Ninja", "Xcode"] >>> } >>> >>> etc. >> >> That would be *really* nice to have once this metadata file is in place:-) > > It is also orthogonal to the metadata of the build itself and can be > designed separately. I agree. > I filed > > http://public.kitware.com/Bug/view.php?id=15462 > > if you want to engage in the design or implementation of that. Thanks. Bookmarked:-) > So, requirements gathered in this email: > > * Being able to read cache values is of primary importance > * * Open question whether values should be 'on demand' or 'always all' I vote for "always all". That should be simpler. > * Knowing which CMake files in the source directory need to be watched for > changes is very important. Yes. > * Knowing which CMake files outside of the source directory need to be > watched for changes is very important. I'd say that is just important. From tobias.hunger at gmail.com Sun Mar 22 16:02:16 2015 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Sun, 22 Mar 2015 21:02:16 +0100 Subject: [cmake-developers] Generating buildsystem metadata from CMake In-Reply-To: References: Message-ID: On Sat, Mar 21, 2015 at 9:41 AM, Stephen Kelly wrote: > Anton Makeev wrote: > >> The other thing that seems troubling to me is that since file, target, >> language compiler options are split into different parts of metadata, the >> IDE need to know exactly how to assemble them back into the compiler?s >> command line (e.g. what flags go first file?s or language?s), duplicating >> CMake's logic that may be different from version to version and from >> compiler to compiler. The exact command line is needed to get the actual >> and precise defines, include search paths etc. from the compiler. > > Yes. I previously proposed the _compile_command to contain information > about how to built it: > > http://www.steveire.com/cmake-future/manual/cmake-metadata-generation.7.html#optional-properties > > However, I think it might be better to generate something similar to what is > currently generated in compile-commands.json into cmake-metadata.json. That > is, we would generate (in some context) > > "include_directories" : ["/foo", "/opt"] > "compile_definitions" : ["DEF=\"Foo\"", "OTHER_DEF=1"] > "compile_command": "-c -DDEF=\"Foo\" -DOTHER_DEF=1 -I/foo -I/opt" > > So, "compile_command" contains approximately what you can currently get from > compile-commands.json. > > The other properties contain things which are specifically known to be > include directories or compile definitions, as javascript arrays. These > properties are obviously redundant information, so I wonder if they should > be generated at all? Is the compile command I wrote above easy to parse? Or > is it sufficiently difficult to parse that this redundant information should > be provided? How about include_directories, compile_definitions and compile_flags? So something along the lines of: "include_directories" : ["/foo", "/opt"] "compile_definitions" : ["DEF=\"Foo\"", "OTHER_DEF=1"] "compile_flags": [ "-c" ] Parsing things is always error prone. Is that -D for definitions or /D? The compiler flags are definitely needed though. They are used to e.g. decide which dialect of a language are used. This would keep parsing simple and will also provide all the information we need. "linker_flags" might also be interesting... Best Regards, Tobias From tobias.hunger at gmail.com Sun Mar 22 17:26:14 2015 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Sun, 22 Mar 2015 22:26:14 +0100 Subject: [cmake-developers] How to handle configurations (Was: Generating buildsystem metadata from CMake) In-Reply-To: References: Message-ID: Hi Stephen, On Sat, Mar 21, 2015 at 10:56 AM, Stephen Kelly wrote: > So, the design question I have is: > > * Is lots of repetition ok in the metadata file? If it can not be avoided, then so be it. > The answer will be re-used in many other places. For example, if I have a > CMakeLists like > > add_executable(main > file1.cpp > ... > fileM.cpp > ) > target_include_directories(main ...) > target_compile_definitions(main ...) > > then we could either write the definitions and includes once (associated > with the target), or we could repeat them all M times (once for each file). > That could be lots and lots of repetition, repeated N times, once for each > configuration. ... or define a group of files, put all the files into that group and add the other relevant flags. If there is a file that needs something different, then just add that as a separate group. In the normal case where all files have the same flags applied the overhead should be close to the minimum. And it still allows for having different settings for different groups of files without the IDE needing to combine settings. E.g. if main.cpp defined "TEST=1", while the main-target defined "TEST=2", which one will win? Please do not require all IDEs to implement logic found in cmake. There will always be corner cases where this will fail, leading to a broken code model in the IDE. > I personally prefer minimising the repetition, as I did in the unit test I > pushed to my clone. I have the feeling you guys have not looked at the unit > test I pushed to my clone. Please go ahead and do that if not. Also, when > proposing json formats, please imagine how your proposal would represent the > data in Tests/Metadata/CMakeLists.txt. I am not sure I understand cmake well enough to do that correctly:-/ But I'll give it a try. >> I'd actually prefer having a "configurations" key with the list of the >> configurations an object applies to. >> >> That can be optional if the object is relevant to all configurations >> (default in single-configuration generators;-). >> >> This key would then need to be applicable to targets as well as the >> group of source files. >> >> So that would be something like this: > > Could you post what would be generated by your proposed structure for the > unit test file in my branch? > >> That would most likely avoid quite a bit of duplication in the file(s). > > How does the design goal of 'avoid duplication' weigh against the design > goal of 'don't make me combine multiple properties together to get relevant > information (eg target defines and additional source defines)', in general? > > We can either go for one extreme or the other, but I don't think it makes > sense to go for something in between. That would be the worst of both > worlds. > > So, for the proposals which are on the table, please either use the > Metadata/CMakeLists.txt file in my clone, or post an alternative together > with the json which you propose we should generate for it, and a prototype > or pseudo-implementation of a parser for that json. Attached you find something that is close to what I want. I moved the sections in your version of that file around a bit in a text editor, so this might not be valid json:-) This does not really cover the conditions though, as those were not in your file either. Note how the main.cpp is handled differently from your proposal. i do not see configurations as much of a problem in such a setup: Just add them as tags to each group of files (and each target). That way the configurations can be handled just as the other differentiators (language, type) in the file groups/targets. That should reduce the duplication, still be pretty readable and should be reasonably simple to parse. Best Regards, Tobias -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake-metadata-Linux-GNU-4.9.json Type: application/json Size: 22878 bytes Desc: not available URL: From tgamblin at llnl.gov Mon Mar 23 01:20:28 2015 From: tgamblin at llnl.gov (Todd Gamblin) Date: Sun, 22 Mar 2015 22:20:28 -0700 Subject: [cmake-developers] BlueGene/Q Platform files In-Reply-To: <550C2C6B.5040107@kitware.com> References: <550C2C6B.5040107@kitware.com> Message-ID: Done! Thanks. On 3/20/15, 7:19 AM, "Brad King" wrote: >On 03/19/2015 02:53 AM, Todd Gamblin wrote: >> Let me know if I can merge this topic to next. > >Yes, please. > >Thanks, >-Brad > From steven.vancoillie at teokem.lu.se Mon Mar 23 04:37:28 2015 From: steven.vancoillie at teokem.lu.se (Steven Vancoillie) Date: Mon, 23 Mar 2015 09:37:28 +0100 Subject: [cmake-developers] patch that adds -KPIC flag to SunPro Fortran compiler In-Reply-To: <550C5402.8090604@kitware.com> References: <20150320082313.GB17545@lenovo> <550C5402.8090604@kitware.com> Message-ID: <20150323083728.GA4146@lenovo> On Mar 20 [13:08], Brad King wrote: > On 03/20/2015 04:23 AM, Steven Vancoillie wrote: > > Looking at other compiler configurations, it seems it might be better > > to have a SunPro.cmake module that combines flags that are independent > > of the language? > > Yes. This refactoring has simply not been done for this compiler. > If you want to work on it, please note that such a module is not > loaded automatically and must be included by the per-language > modules. This pattern is visible in several other compiler modules. I've included a candidate patch for this refactoring. I also noticed the follow variables are set for C, CSS, and ASM: set(CMAKE_${type}_LINK_STATIC_${lang}_FLAGS "-Bstatic") set(CMAKE_${type}_LINK_DYNAMIC_${lang}_FLAGS "-Bdynamic") I could add these for Fortran as well and move it also to the macro in SunPro.cmake. However, since this only seems to be there for SunPro, I wondered if these are used at all? These options are just passed to ld, so they are not sun-specific. grtz Steven -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Combine-SunPro-compiler-flags-for-multiple-languages.patch Type: text/x-diff Size: 8171 bytes Desc: 0001-Combine-SunPro-compiler-flags-for-multiple-languages.patch URL: From brad.king at kitware.com Mon Mar 23 09:32:59 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 23 Mar 2015 09:32:59 -0400 Subject: [cmake-developers] CMake and intersphinx In-Reply-To: <550EA49D.6040709@googlemail.com> References: <550D2EA2.4040008@googlemail.com> <2037760.ImaFPdq0eZ@kyoshi> <550EA49D.6040709@googlemail.com> Message-ID: <5510160B.6090409@kitware.com> On 03/22/2015 07:16 AM, Gregor Jasny wrote: > On 21/03/15 12:06, Alex Merry wrote: >> On Saturday 21 March 2015 09:41:06 Gregor Jasny wrote: >>> I wanted to start documenting our in-company CMake modules. Often I'd >>> like to refer to some basic CMake commands. As far as I understand the >>> intersphinx extension [1] should be able to provide that. To reference >>> remote projects these need to provide a objects.inv mapping file. > >> This would also be useful for the extra-cmake-modules project. > > I pushed a topic branch to stage and await ACK for merging to next: > http://www.cmake.org/gitweb?p=stage/cmake.git;a=commit;h=840f5b89a456b6f68a9b75c7a0a0bfc3fa37e643 Thanks. Yes, please merge that to 'next'. FYI, we do publish that file with the online documentation: http://www.cmake.org/cmake/help/v3.2/objects.inv http://www.cmake.org/cmake/help/v3.1/objects.inv http://www.cmake.org/cmake/help/v3.0/objects.inv so other documentation can cross-reference to docs at those URLs. -Brad From brad.king at kitware.com Mon Mar 23 09:49:13 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 23 Mar 2015 09:49:13 -0400 Subject: [cmake-developers] Explicit custom command BYPRODUCTS In-Reply-To: References: <546A26AF.7080400@kitware.com> <5509B2D1.90303@kitware.com> Message-ID: <551019D9.7080806@kitware.com> On 03/18/2015 01:41 PM, Adam Strzelecki wrote: >> IIUC the remaining issue is that for in-source builds all the >> custom command dependencies on source files now get phony >> rules. We need a policy to drop this behavior altogether and >> ask that projects explicitly specify their BYPRODUCTS. >> Correct? > > Yes that is correct. I've added the policy: Ninja: Add policy to require explicit custom command byproducts http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bd9c7f9b -Brad From brad.king at kitware.com Mon Mar 23 10:02:11 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 23 Mar 2015 10:02:11 -0400 Subject: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support In-Reply-To: References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com> <54E7542D.6050808@kitware.com> <54EB68C8.7030504@kitware.com> <54F0952B.5070809@kitware.com> <54F4781A.80708@kitware.com> <54FEF1C1.4030106@kitware.com> <5501F487.10807@kitware.com> <550886E2.1020708@kitware.com> Message-ID: <55101CE3.9000603@kitware.com> On 03/19/2015 09:57 AM, Geoffrey Viola wrote: > I moved it under > #if defined(_WIN32) && !defined(__CYGWIN__) > # if !defined(CMAKE_BOOT_MINGW) The #include line needs to be moved similarly. I made that fix and a few whitespace fixes. I've attached a patch with those revisions. I noticed while making those fixes that you're using auto_ptr inside a map value. The auto_ptr is documented as not suitable for use in containers in general. For TargetFolderBuildStreams you could just use a normal pointer and then cleanup in the generator destructor using cmDeleteAll. Thanks, -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Added-some-support-for-a-Green-Hills-MULTI.patch Type: text/x-diff Size: 68236 bytes Desc: not available URL: From brad.king at kitware.com Mon Mar 23 10:33:29 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 23 Mar 2015 10:33:29 -0400 Subject: [cmake-developers] patch that adds -KPIC flag to SunPro Fortran compiler In-Reply-To: <20150323083728.GA4146@lenovo> References: <20150320082313.GB17545@lenovo> <550C5402.8090604@kitware.com> <20150323083728.GA4146@lenovo> Message-ID: <55102439.1010604@kitware.com> On 03/23/2015 04:37 AM, Steven Vancoillie wrote: > I've included a candidate patch for this refactoring. Thanks. I split out the -KPIE removal: SunPro: Drop non-existent -KPIE flag http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=209c142f Please rebase the revisions below on that. > I also noticed the follow variables are set for C, CXX, and ASM: > > set(CMAKE_${type}_LINK_STATIC_${lang}_FLAGS "-Bstatic") > set(CMAKE_${type}_LINK_DYNAMIC_${lang}_FLAGS "-Bdynamic") > > I could add these for Fortran as well and move it also to the > macro in SunPro.cmake. However, since this only seems to be there > for SunPro, I wondered if these are used at all? These options are > just passed to ld, so they are not sun-specific. They are set for other compilers over in the Modules/Platform directory. We should preserve them as-is. This patch should be pure refactoring and make no functional changes. The current patch does not account for differences in the flags for each language: * The _VERBOSE_FLAG is -v for most languages and -# for ASM. * The _CREATE_PREPROCESSED_SOURCE rule for Fortran uses -F instead of -E. Please revise the patch accordingly and check that the values set after refactoring match those from before. It is okay for flags that are not shared by all languages to be set as they are now or overridden after the macro call. Thanks, -Brad From mantis at public.kitware.com Mon Mar 23 11:28:44 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 23 Mar 2015 11:28:44 -0400 Subject: [cmake-developers] [CMake 0015468]: Generated Xcode project contains source groups for ALL_BUILD and ZERO_CHECK targets Message-ID: <965c6e589c3dc4340472bbcf1eb589b3@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15468 ====================================================================== Reported By: Abigail Bunyan Assigned To: ====================================================================== Project: CMake Issue ID: 15468 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-23 11:28 EDT Last Modified: 2015-03-23 11:28 EDT ====================================================================== Summary: Generated Xcode project contains source groups for ALL_BUILD and ZERO_CHECK targets Description: When using the Xcode generator, each file in a target is placed under a target-specific source group. (If a file has a custom source group specified, then that group will be created as a subgroup of the target's.) However, ALL_BUILD and ZERO_CHECK also generate their own source groups. This is not intended behavior: cmGlobalXCodeGenerator::CreateGroups (at cmGlobalXCodeGenerator.cxx:3018) has a comment specifying that these should be skipped, and code that is supposed to skip them. These erroneous source groups contain CMakeLists.txt, and an empty subgroup called "CMake Rules". ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-23 11:28 Abigail Bunyan New Issue ====================================================================== From mantis at public.kitware.com Mon Mar 23 11:46:43 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 23 Mar 2015 11:46:43 -0400 Subject: [cmake-developers] [CMake 0015469]: Xcode projects misuses targets for ALL_BUILD; it should use a scheme instead Message-ID: <3b698602baf4928b32788591e3316e57@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15469 ====================================================================== Reported By: Abigail Bunyan Assigned To: ====================================================================== Project: CMake Issue ID: 15469 Category: CMake Reproducibility: N/A Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-23 11:46 EDT Last Modified: 2015-03-23 11:46 EDT ====================================================================== Summary: Xcode projects misuses targets for ALL_BUILD; it should use a scheme instead Description: When generating an Xcode project from a CMakeLists.txt with one target, the resultant project contains three targets: the user's target, ALL_BUILD, and ZERO_CHECK. It then makes all targets depend on ZERO_CHECK, and makes ALL_BUILD depend on all other targets. However, the Xcode documentation specifies "Projects can contain one or more targets, each of which produces one product." - so ALL_BUILD is not the intended use of targets. CMake should instead create an Xcode scheme, which depends on all of the user's Xcode targets. Additional Information: Debatably, ZERO_CHECK shouldn't be a target - and ZERO_CHECK's only build phase should instead be a build phase present in every other target. However, you could argue that it does produce a product (ie. the Xcode project itself). ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-23 11:46 Abigail Bunyan New Issue ====================================================================== From brad.king at kitware.com Mon Mar 23 12:53:24 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 23 Mar 2015 12:53:24 -0400 Subject: [cmake-developers] CMake 3.3 feature freeze on 2015-06-01 Message-ID: <55104504.2040506@kitware.com> Hi Folks, The feature freeze in 'master' for CMake 3.3 will be on June 1, 2015. I will announce a freeze in 'next' sometime in the preceding week so that we can get any remaining dashboard trouble cleaned up. Please schedule any planned topics accordingly. Any major or disruptive changes should be completed a few weeks prior to the freeze or delayed until after 'next' re-opens. Thanks, -Brad From mantis at public.kitware.com Mon Mar 23 13:12:11 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 23 Mar 2015 13:12:11 -0400 Subject: [cmake-developers] [CMake 0015470]: Clarify behavior for relative paths in custom command DEPENDS Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15470 ====================================================================== Reported By: Brad King Assigned To: ====================================================================== Project: CMake Issue ID: 15470 Category: (No Category) Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-23 13:12 EDT Last Modified: 2015-03-23 13:12 EDT ====================================================================== Summary: Clarify behavior for relative paths in custom command DEPENDS Description: The add_custom_command and add_custom_target commands provide DEPENDS options. Our own projects always use absolute paths with these DEPENDS option. We've never clearly defined how relative paths are treated, but the implementation has been modified a few times assuming that we always get either target names or absolute paths. For example: add_custom_command: Normalize OUTPUT and DEPENDS paths. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c4af46b4 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-23 13:12 Brad King New Issue ====================================================================== From mantis at public.kitware.com Mon Mar 23 13:21:07 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 23 Mar 2015 13:21:07 -0400 Subject: [cmake-developers] [CMake 0015471]: Subversion_WC_INFO shall report current branch commit Message-ID: <1fb08e25d9f731a74bbd4002f0fd797c@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15471 ====================================================================== Reported By: Julien Finet Assigned To: ====================================================================== Project: CMake Issue ID: 15471 Category: Modules Reproducibility: sometimes Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-23 13:21 EDT Last Modified: 2015-03-23 13:21 EDT ====================================================================== Summary: Subversion_WC_INFO shall report current branch commit Description: Sometimes svn info gives only the last revision of the entire repository. It would be more useful to know the revision of the current branch. To do so, add -r BASE Steps to Reproduce: $ svn info mydir Path: . URL: https://github.com/username/myproject/branches/mybranch Repository Root: https://github.com/username/myproject Revision: 56700 Node Kind: directory Schedule: normal $ svn info -r BASE mydir Path: cax_ext-6.2.0 URL: https://github.com/username/myproject/branches/mybranch Repository Root: https://github.com/username/myproject Repository UUID: fa2db1fb-064d-a4d9-c6c8-ce57b7db7bff Revision: 56700 Node Kind: directory Last Changed Author: dave.demarle Last Changed Rev: 56658 Last Changed Date: 2015-02-16 19:30:42 +0100 (Mon, 16 Feb 2015) Additional Information: Use -r BASE with svn info: with svn info -r BASE ${dir} ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-23 13:21 Julien Finet New Issue ====================================================================== From neundorf at kde.org Mon Mar 23 16:15:53 2015 From: neundorf at kde.org (Alexander Neundorf) Date: Mon, 23 Mar 2015 21:15:53 +0100 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <5505BAA9.4040806@gmail.com> References: <5505BAA9.4040806@gmail.com> Message-ID: <79302279.FOPXxSrPnD@tuxedo.neundorf.net> On Sunday, March 15, 2015 18:00:25 Nils Gladitz wrote: > On 15.03.2015 16:42, Tobias Hunger wrote: > > Hi Peter, > > > > CMake does know all the headers or it could not decide which files > > need rebuilding. > > The build system that CMake generates knows the header dependencies and > decides when which files need rebuilding. > CMake itself doesn't know. How header dependencies are determined and > where and how they are recorded is generator specific. I have spent enough time on this code, so: for the makefile-generators, the header dependencies are generated by cmake (not at cmake time, but at build time), which results in the depend.make file. Alex From nilsgladitz at gmail.com Mon Mar 23 16:55:54 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 23 Mar 2015 21:55:54 +0100 Subject: [cmake-developers] Extracting target metadata, IDE integration In-Reply-To: <79302279.FOPXxSrPnD@tuxedo.neundorf.net> References: <5505BAA9.4040806@gmail.com> <79302279.FOPXxSrPnD@tuxedo.neundorf.net> Message-ID: <55107DDA.70904@gmail.com> On 23.03.2015 21:15, Alexander Neundorf wrote: > On Sunday, March 15, 2015 18:00:25 Nils Gladitz wrote: >> The build system that CMake generates knows the header dependencies and >> decides when which files need rebuilding. >> CMake itself doesn't know. How header dependencies are determined and >> where and how they are recorded is generator specific. > I have spent enough time on this code, so: > > for the makefile-generators, the header dependencies are generated by cmake > (not at cmake time, but at build time), which results in the depend.make file. > > > Alex > So both how the dependencies are determined and where they are recorded is a generator specific implementation detail. This does not make it suitable for general consumption. Nils From mark.j.abraham at gmail.com Mon Mar 23 19:40:25 2015 From: mark.j.abraham at gmail.com (Mark Abraham) Date: Tue, 24 Mar 2015 00:40:25 +0100 Subject: [cmake-developers] BlueGene/Q Platform files In-Reply-To: References: <550C2C6B.5040107@kitware.com> Message-ID: Hi, Looks good. We have bundled similar content in GROMACS for a while. Can I add one for bgclang? Mark On 23/03/2015 6:21 am, "Todd Gamblin" wrote: > Done! Thanks. > > On 3/20/15, 7:19 AM, "Brad King" wrote: > > >On 03/19/2015 02:53 AM, Todd Gamblin wrote: > >> Let me know if I can merge this topic to next. > > > >Yes, please. > > > >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 steveire at gmail.com Mon Mar 23 19:44:14 2015 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 24 Mar 2015 00:44:14 +0100 Subject: [cmake-developers] Generating buildsystem metadata from CMake References: Message-ID: Tobias Hunger wrote: >>> and >>> which kit (think set of compiler, Qt, some other settings) were used >>> to in the built in that directory. >> >> Is this hypothetical? Currently I can add a compiler location and a Qt >> location in QtCreator, and I can create a kit and give it a name and >> partcular compiler and Qt. However, the information I configure there and >> the kit that I choose is not passed to cmake when creator invokes that, >> right? CMake will do its own determination of the compiler to use, and >> will find Qt on its own, right? Unless the user manually sets those as >> arguments in the 'Run CMake' dialog page. > > We do that for qmake projects at this time. > > Nothing listed here is needed to get the level of cmake support we > have in Creator right *now*: That works fine already after all. I want > something better:-) So I bring up all the things I can think of to get > cmake to the same level that we currently have for qmake. Right, I see. >> Or are you thinking of scenarios such as 'the user creates a build >> outside of Creator and then tries to open it in creator'. Given that 'a >> kit' is something internal to Creator, there is no way CMake could tell >> you the kit in that scenario. Is that obvious or am I missing something? >> I think the best thing you can do there is find out which compiler was >> used, and what the value of Qt5Core_DIR is, and map that to things you >> know about available kits to find the match if there is one. > > Yes, that is the same we do for qmake projects. In fact we just create > a new kit for configurations we had not seen before. Right. In the case that Creator imports a cmake build dir for a project which uses Qt 5, and which is not already configured in Creator, you would need the path to qmake for the Qt used by it, because that is what Creator uses as the key for a particular Qt (or that used to be the case). By the way, just as another tip, in that case the reliable way to get the corresponding qmake would be to get the Qt5Core_DIR from the cache in the just-found build dir (via the json or whatever), and write a file to a temp dir with the content: cmake_minimum_required(VERSION 2.8) project(find_qmake NONE) find_package(Qt5Core REQUIRED) get_target_property(loc Qt5::qmake LOCATION) message("QMAKE_LOCATION: \"${loc}\"") and then run cmake on it and parse the result: stephen at hal:/tmp/cmake/build$ cmake .. \ -DQt5Core_DIR=/usr/lib/x86_64-linux-gnu/cmake/Qt5Core/ QMAKE_LOCATION: "/usr/lib/x86_64-linux-gnu/qt5/bin/qmake" -- Configuring done -- Generating done -- Build files have been written to: /tmp/cmake/build stephen at hal:/tmp/cmake/build$ cmake .. \ -DQt5Core_DIR=/opt/qt/binary/Qt5.2.1/5.2.1/gcc_64/lib/cmake/Qt5Core QMAKE_LOCATION: "/opt/qt/binary/Qt5.2.1/5.2.1/gcc_64/bin/qmake" -- Configuring done -- Generating done -- Build files have been written to: /tmp/cmake/build >> I only want the IDE to re-generate when I'm actually working in the IDE. >> If I edit any file and hit Ctrl+B, the IDE runs 'cmake --build .' and >> cmake regenerates if needed at that point. It's 'ok' if the project tree >> is technically 'stale' after I edit a file and before I hit Ctrl+B. It's >> 'ok' in the sense that the alternative is 'worse' as far as my opinion >> goes. You also have the option of running 'cmake .' any time any file is >> saved in the IDE, if that improves the experience, but I strongly believe >> you shouldn't be watching the files for outside changes and re-generating >> in response. > > That might be ok for you, but we do get a lot of bug reports whenever > we have the project tree not update directly. 'Update directly' means 'I save a file in the IDE and the target treeview updates', right? Quoting myself above: "running 'cmake .' any time any file is saved in the IDE". > So it is *not* ok for a > large number of users, particularly those that come from a proprietary > IDE that comes with a built-in build system. For my curiosity, what scenario are you talking about which is not covered by triggering regeneration on 'saving in the IDE' and 'newly getting focus'? > We do *not* update creator while it is not in use. Fantastic! > When the window > gets focus again we go "Things have changed outside Creator, do you > want to update?". Great. >> That's not to say we won't 'give you the rope'. But before we would do >> that, cmake would have to be defensive against concurrent runs in the >> same build dir. > > A simple lock file should suffice. I would be surprised if that was > not there already, but I never checked. Yes, I think you're right. I haven't checked yet either, but either way it is necessary. >> The key difference is that my proposal is only requested values, so is >> minimal. > > Yes. But then you need to add "cmake -E list_cache" that lists all > values. Or how can I find out which values are there in a project? Indeed. > In the end it is probably easier to either put all that stuff into the > json file or to declare CMakeCache.txt to be a stable read-only file > for the configuration. Indeed. >> As you suggest, we could write all of the cache data into the generated >> cmake-metadata.json file. Alternatively, we could design the interface >> such that you specify not only what version of the metadata you want, but >> also which cache values >> >> $ cmake . -DCMAKE_GENERATE_METADATA=3.3 -DCMAKE_METADATA_CACHE="Foo;Bar" >> >> to generate a cache section in the metadata file with the 'Foo' and 'Bar' >> key-value pairs. >> >> Is there any particular reason you want "everything" instead of >> specifying what you want? > > Mostly because I want to be able to rm -rf "builddir" and still be > able to build:-) Are we talking about this scenario: 1. I build a project with "Unix Makefiles" generator on the command line. 2. I open the project in Creator - creator reads and caches all values in the cache, and I do some work in creator. 3. I decide I want to use the Ninja generator instead. I go an rm -rf on the command line. 4. I alt-tab back to creator and it immediately re-populates the build dir I just cleared by invoking `cmake . -D$KEY=$VALUE` for every single cache entry (therefore ensuring that it stays using "Unix Makefiles"). 5. I look at my build dir that I thought I just cleared and wonder what is going on. ? If the build dir gets rm -rf'd, then you should probably treat that in the same way as the 'I want to open a project and don't ask me for a build dir' scenario discussed below which requires a temp directory. > I would really appreciate getting all possible information from CMake > mostly since I doubt you can decide what each and every IDE will need > that wants to integrate cmake. Right. > Please do not try to second-guess which information might be relevant > to any IDE, that is bound to fail. I'm trying to find out what is really needed so that we can define stable interfaces that don't paint cmake into a corner for future refactorings. >> Adding a way to make cmake dump the metadata to stdout would be possible, >> but it wouldn't help... > > Why not? We could set a temporary build dir and you give us the data you > can. If you set a temporary build dir, then read the metadata from there. No need for stdout reading. Just read the file as normal. > We have people that want to look into projects and moan when we ask > them to configure a build dir since they do not understand why they > need that: They want to browse the code only. Then choose a temp dir in the background as both of us suggested :). Quoting myself below: >> ... CMake needs a directory to run in. It needs to generate files to >> compile to test the compiler features, determine the platform etc. The >> content of the project depends on the outcome of those configure-time >> tests. You need to give cmake a temp directory in this scenario *anyway*. >> A temp directory from your OS is fine, and you can read the metadata file >> from there. > We do need the information from the build system to set up the code > model correctly and thus need to put them through that -- from their > point useless -- setup. Well, you can delay the 'useless setup', but eventually you'll have to ask them for a build dir, right? Thanks, Steve. From steveire at gmail.com Mon Mar 23 19:54:06 2015 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 24 Mar 2015 00:54:06 +0100 Subject: [cmake-developers] Generating buildsystem metadata from CMake References: Message-ID: Tobias Hunger wrote: > > How about include_directories, compile_definitions and compile_flags? > > So something along the lines of: > > "include_directories" : ["/foo", "/opt"] > "compile_definitions" : ["DEF=\"Foo\"", "OTHER_DEF=1"] > "compile_flags": [ "-c" ] Quoting Anton: Anton Makeev wrote: > The other thing that seems troubling to me is that since file, target, > language compiler options are split into different parts of metadata, the > IDE need to know exactly how to assemble them back into the compiler?s > command line (e.g. what flags go first file?s or language?s), duplicating > CMake's logic that may be different from version to version and from > compiler to compiler. The exact command line is needed to get the actual > and precise defines, include search paths etc. from the compiler. Maybe he can chime in with more. I don't really know why the entire command line is needed instead of separate "include_directories" and "compile_definitions" arrays as you and I suggested. Perhaps because that would not include -fPIC for example, which causes __PIC__ to be defined. Another item of note is that CMake does not know the compile flags as a sequential container of individual flags currently, but it knows them as a string (that's also why it appears as a string in my generated json currently). > Parsing things is always error prone. Is that -D for definitions or /D? As we can define the format, we could always generate -D and define that as the answer to your question. Anyway, let's see if Anton can explain more about the need for the exact command line and whether my suggestion of duplicating the "include_directories" and "compile_definitions" is fine. > The compiler flags are definitely needed though. They are used to e.g. > decide which dialect of a language are used. > > This would keep parsing simple and will also provide all the > information we need. > > "linker_flags" might also be interesting... Yes, something like this is also in the goals for this design. Thanks, Steve. From mantis at public.kitware.com Mon Mar 23 20:15:25 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 24 Mar 2015 01:15:25 +0100 Subject: [cmake-developers] [CMake 0015472]: CMake does not deduplicate defines which have the same name but different value Message-ID: <0f4a63a0f1fe1401f2a0f37f834fd18c@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15472 ====================================================================== Reported By: Stephen Kelly Assigned To: ====================================================================== Project: CMake Issue ID: 15472 Category: (No Category) Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-24 01:15 CET Last Modified: 2015-03-24 01:15 CET ====================================================================== Summary: CMake does not deduplicate defines which have the same name but different value Description: cmake_minimum_required(VERSION 2.8) project(cmaketest) add_executable(mn main.cpp) target_compile_definitions(mn PRIVATE TESTD=1 TESTD=3) set_source_files_properties(main.cpp PROPERTIES COMPILE_DEFINITIONS TESTD=5) CMake currently passes all of the defines, and the compiler (gcc at least) warns about redefinition. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-24 01:15 Stephen Kelly New Issue ====================================================================== From steveire at gmail.com Mon Mar 23 20:28:37 2015 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 24 Mar 2015 01:28:37 +0100 Subject: [cmake-developers] How to handle configurations (Was: Generating buildsystem metadata from CMake) References: Message-ID: Tobias Hunger wrote: > Hi Stephen, > > On Sat, Mar 21, 2015 at 10:56 AM, Stephen Kelly > wrote: >> So, the design question I have is: >> >> * Is lots of repetition ok in the metadata file? > > If it can not be avoided, then so be it. It can be avoided at the cost of computation. I thought that was more clear in my mail. >> The answer will be re-used in many other places. For example, if I have a >> CMakeLists like >> >> add_executable(main >> file1.cpp >> ... >> fileM.cpp >> ) >> target_include_directories(main ...) >> target_compile_definitions(main ...) >> >> then we could either write the definitions and includes once (associated >> with the target), or we could repeat them all M times (once for each >> file). That could be lots and lots of repetition, repeated N times, once >> for each configuration. > > ... or define a group of files, put all the files into that group and > add the other relevant flags. > > If there is a file that needs something different, then just add that > as a separate group. This still just pushes a computation requirement to you the consumer of the file. The reason I'm asking about duplication versus computation is because of what you wrote: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12658/focus=12750 Tobias Hunger wrote: > Can't we go for a syntax where the files and everything that applies > to them are grouped so that there is no need to reimplement the logic > found in cmake (with added bugs:-)? If the concern that computation means bugs is the primary concern then we should duplicate a lot of information. Also, the outcome of how we should generate compile flags could have an influence on what we duplicate. Anton will hopefully respond. I don't believe we'll have a huge problem with bugs processing the json. It will have a schema and documentation telling you how to consume it. If it is consumed in multiple steps (eg with processing of your 'source group' idea etc), then I think that's fine. We simply document how it's done. It's no different to any other data format in that sense. A spec is needed to implement the logic of parsing json too, and there are many json parsers out there. I'm sure some have hard-to-reach bugs, but all software has hard-to- reach bugs. > In the normal case where all files have the same flags applied the > overhead should be close to the minimum. And it still allows for > having different settings for different groups of files without the > IDE needing to combine settings. E.g. if main.cpp defined "TEST=1", > while the main-target defined "TEST=2", which one will win? I guess this relates to why Anton wants the actual command line. That's undefined behavior. I guess it could be made defined. I filed http://public.kitware.com/Bug/view.php?id=15472 > Please do not require all IDEs to implement logic found in cmake. > There will always be corner cases where this will fail, leading to a > broken code model in the IDE. I agree we don't want to require implementing logic found in CMake. I do think we should be allowed to require 'implementing well defined and specified logic', as you do too judging by your source groups idea. > Attached you find something that is close to what I want. I moved the > sections in your version of that file around a bit in a text editor, > so this might not be valid json:-). Thanks for this. Actually I guess the generated file for that test is too big to do sensible comparisons. I basically want to see a proposal which is more complete than many different ideas of snippets and lots of '...', and I want to see how a consumer would process the file. Maybe we should start with a simpler CMake file. > This does not really cover the > conditions though, as those were not in your file either. The conditions are handled in my file. Files which do not match the condition all go into the 'excluded files' group. I implemented it that way because of this quote from you: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11323 > > I wonder how those kinds of conditions would need to be represented in > > the ProjectTargets.json file. > > This is actually a bit too detailed for my needs:-) > > I want to know which files are part of the project and which are part > of the current build. > > At least Qt Creator does not need information on which conditions to > be met for a file to become part of the current build. The 'object sources' are files which will be compiled. The 'excluded' sources will not be compiled, but they are 'part of the project' as you seemed to describe above before. Also, note that in my json file, there is not a generic 'files' property because cmake has more information than just 'files' - it has information about which compiler is used for the files to compile objects, which files are not going to be compiled at all etc. My design gives you that information, but a 'files' array discards it. > i do not see configurations as much of a problem in such a setup: Just > add them as tags to each group of files (and each target). That way > the configurations can be handled just as the other differentiators > (language, type) in the file groups/targets. That should reduce the > duplication, still be pretty readable and should be reasonably simple > to parse. The configuration is not like other differentiators. That's the topic of other mails. Thanks, Steve. From steven.vancoillie at teokem.lu.se Tue Mar 24 04:38:10 2015 From: steven.vancoillie at teokem.lu.se (Steven Vancoillie) Date: Tue, 24 Mar 2015 09:38:10 +0100 Subject: [cmake-developers] patch that adds -KPIC flag to SunPro Fortran compiler In-Reply-To: <55102439.1010604@kitware.com> References: <20150320082313.GB17545@lenovo> <550C5402.8090604@kitware.com> <20150323083728.GA4146@lenovo> <55102439.1010604@kitware.com> Message-ID: <20150324083810.GA977@lenovo> On Mar 23 [10:33], Brad King wrote: > On 03/23/2015 04:37 AM, Steven Vancoillie wrote: > Thanks. I split out the -KPIE removal: > > SunPro: Drop non-existent -KPIE flag > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=209c142f > > Please rebase the revisions below on that. > > The current patch does not account for differences in the > flags for each language: > > * The _VERBOSE_FLAG is -v for most languages and -# for ASM. The verbose flags for SunPro compilers are documented as: Sun C compiler: -# (-v enables stricter semantic checks) Sun CXX compiler: -# (-v turns on -verbose=diags, seems similar) Sun ASM compiler: none (-v/-# are not recognized) Sun Fortran compiler: -v (-# works too) Since the current verbose flags are thus not correct, I've left this alone in this patch, as it should be pure refactoring. Maybe they can go in a separate patch? > * The _CREATE_PREPROCESSED_SOURCE rule for Fortran uses -F > instead of -E. The _CREATE_PREPROCESSED_SOURCE rule for Fortran is now overwritten again in the Fortran-specific file to use the -F option. > Please revise the patch accordingly and check that the values > set after refactoring match those from before. It is okay for > flags that are not shared by all languages to be set as they > are now or overridden after the macro call. I've attached the new patch. This does not strictly follow your rule, as now there will be a CMAKE_ASM_COMPILE_OPTIONS_PIC variable set because of the macro (before this was not set). Should I unset it again in the ASM-specific file? Steven -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Refactor-SunPro-per-language-options-into-single-mac.patch Type: text/x-diff Size: 7793 bytes Desc: 0001-Refactor-SunPro-per-language-options-into-single-mac.patch URL: From steven.vancoillie at teokem.lu.se Tue Mar 24 05:08:35 2015 From: steven.vancoillie at teokem.lu.se (Steven Vancoillie) Date: Tue, 24 Mar 2015 10:08:35 +0100 Subject: [cmake-developers] Fortran support for Ninja generator Message-ID: <20150324090834.GB977@lenovo> Dear all, we have a large Fortran project which we build with cmake and I'm interested in making the ninja generator work with Fortran. I found a few short discussions of this on the mailing list, but since then nothing has happened. One mention was to use the -M* flags supported by gfortran, just as with gcc. However, when I tried this approach I found out that the -M* flag for gfortran seems buggy, it doesn't output the correct format (e.g. the target given with -MT flag is just added instead of overwriting the default target). So, my ninja build failed saying the depfile format was wrong. Alternatively someone proposed to have ninja use cmake-generated dependencies. From what I can tell from the ninja documentation, would this mean that the cmake executable needs to generate the depfile instead of the compiler? I'm willing to work on this, but so far my experience with the cmake source code is very rudimentary. If someone can point me in the right direction, or provide some input to get started, this would be greatly appreciated. Steven From nilsgladitz at gmail.com Tue Mar 24 05:46:34 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 24 Mar 2015 10:46:34 +0100 Subject: [cmake-developers] Fortran support for Ninja generator In-Reply-To: <20150324090834.GB977@lenovo> References: <20150324090834.GB977@lenovo> Message-ID: <5511327A.6040700@gmail.com> On 03/24/2015 10:08 AM, Steven Vancoillie wrote: > Dear all, > > we have a large Fortran project which we build with cmake and I'm > interested in making the ninja generator work with Fortran. I found a > few short discussions of this on the mailing list, but since then > nothing has happened. > > One mention was to use the -M* flags supported by gfortran, just as > with gcc. However, when I tried this approach I found out that the -M* > flag for gfortran seems buggy, it doesn't output the correct format > (e.g. the target given with -MT flag is just added instead of > overwriting the default target). So, my ninja build failed saying the > depfile format was wrong. > > Alternatively someone proposed to have ninja use cmake-generated > dependencies. From what I can tell from the ninja documentation, would > this mean that the cmake executable needs to generate the depfile > instead of the compiler? > > I'm willing to work on this, but so far my experience with the cmake > source code is very rudimentary. If someone can point me in the right > direction, or provide some input to get started, this would be greatly > appreciated. I am not very familiar with fortran myself but there was this discussion on the ninja mailing list that implied that this might also require changes to ninja itself: https://groups.google.com/d/msg/ninja-build/b1-AF3pRJuE/NkPDsO0C2IUJ Nils From ono at java.pl Tue Mar 24 08:10:04 2015 From: ono at java.pl (Adam Strzelecki) Date: Tue, 24 Mar 2015 13:10:04 +0100 Subject: [cmake-developers] Explicit custom command BYPRODUCTS In-Reply-To: <551019D9.7080806@kitware.com> References: <546A26AF.7080400@kitware.com> <5509B2D1.90303@kitware.com> <551019D9.7080806@kitware.com> Message-ID: <43D8E73B-FB4D-4023-B07F-54AA2F1D12C8@java.pl> Awesome! Thanks for sorting that out. Hope it will now serve well for Amine. Would it be default for projects targeting min 3.3? -- Adam > Wiadomo?? napisana przez Brad King w dniu 23 mar 2015, o godz. 14:49: > > On 03/18/2015 01:41 PM, Adam Strzelecki wrote: >>> IIUC the remaining issue is that for in-source builds all the >>> custom command dependencies on source files now get phony >>> rules. We need a policy to drop this behavior altogether and >>> ask that projects explicitly specify their BYPRODUCTS. >>> Correct? >> >> Yes that is correct. > > I've added the policy: > > Ninja: Add policy to require explicit custom command byproducts > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bd9c7f9b > > -Brad > From brad.king at kitware.com Tue Mar 24 08:52:45 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 24 Mar 2015 08:52:45 -0400 Subject: [cmake-developers] patch that adds -KPIC flag to SunPro Fortran compiler In-Reply-To: <20150324083810.GA977@lenovo> References: <20150320082313.GB17545@lenovo> <550C5402.8090604@kitware.com> <20150323083728.GA4146@lenovo> <55102439.1010604@kitware.com> <20150324083810.GA977@lenovo> Message-ID: <55115E1D.909@kitware.com> On 03/24/2015 04:38 AM, Steven Vancoillie wrote: > On Mar 23 [10:33], Brad King wrote: >> * The _VERBOSE_FLAG is -v for most languages and -# for ASM. > > The verbose flags for SunPro compilers are documented as: > Sun C compiler: -# (-v enables stricter semantic checks) > Sun CXX compiler: -# (-v turns on -verbose=diags, seems similar) > Sun ASM compiler: none (-v/-# are not recognized) > Sun Fortran compiler: -v (-# works too) > Since the current verbose flags are thus not correct, I've left > this alone in this patch, as it should be pure refactoring. Maybe > they can go in a separate patch? Okay. The purpose of this flag for CMake is to be able to see the ld invocation that the compiler front-end produces. This is used while enabling a language to collect the implicit linker search paths and libraries that the compiler front-end uses. We can change the flags from their current setting as long as this works. Look at CMakeFiles/*/CMake*Compiler.cmake for the detection results and in CMakeFiles/CMakeOutput.log for a log of the extraction process. Please first create a patch to fix all the flags with corresponding explanations and documentation references. Then a second patch can do the refactoring and consolidation of duplicate flags. > The _CREATE_PREPROCESSED_SOURCE rule for Fortran is now overwritten > again in the Fortran-specific file to use the -F option. Good. > I've attached the new patch. This does not strictly follow your > rule, as now there will be a CMAKE_ASM_COMPILE_OPTIONS_PIC variable > set because of the macro (before this was not set). Should I unset it > again in the ASM-specific file? Yes. If there is no verbose flag for ASM either then that should be unset too. Thanks, -Brad From brad.king at kitware.com Tue Mar 24 08:57:20 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 24 Mar 2015 08:57:20 -0400 Subject: [cmake-developers] Explicit custom command BYPRODUCTS In-Reply-To: <43D8E73B-FB4D-4023-B07F-54AA2F1D12C8@java.pl> References: <546A26AF.7080400@kitware.com> <5509B2D1.90303@kitware.com> <551019D9.7080806@kitware.com> <43D8E73B-FB4D-4023-B07F-54AA2F1D12C8@java.pl> Message-ID: <55115F30.60509@kitware.com> On 03/24/2015 08:10 AM, Adam Strzelecki wrote: > Awesome! Thanks for sorting that out. Hope it will now serve well for Amine. > Would it be default for projects targeting min 3.3? Yes. That is how policies work. The need to be aware of them goes away over time as projects update their min req version of CMake. -Brad From Geoffrey.Viola at asirobots.com Tue Mar 24 09:14:35 2015 From: Geoffrey.Viola at asirobots.com (Geoffrey Viola) Date: Tue, 24 Mar 2015 13:14:35 +0000 Subject: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support In-Reply-To: <55101CE3.9000603@kitware.com> References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com> <54E7542D.6050808@kitware.com> <54EB68C8.7030504@kitware.com> <54F0952B.5070809@kitware.com> <54F4781A.80708@kitware.com> <54FEF1C1.4030106@kitware.com> <5501F487.10807@kitware.com> <550886E2.1020708@kitware.com> <55101CE3.9000603@kitware.com> Message-ID: > The #include line needs to be moved similarly. I made that fix and a few whitespace fixes. I've attached a patch with those revisions. Thanks. > I noticed while making those fixes that you're using auto_ptr inside a map value. The auto_ptr is documented as not suitable for use in containers in general. For TargetFolderBuildStreams you could just use a normal pointer and then cleanup in the generator destructor using cmDeleteAll. Good catch. I made the switch. Attached is a new patch. Here's the test: https://open.cdash.org/buildSummary.php?buildid=3741919. Geoffrey Viola SOFTWARE ENGINEER asirobots.com This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Added-some-support-for-a-Green-Hills-MULTI.patch Type: application/octet-stream Size: 62546 bytes Desc: 0001-Added-some-support-for-a-Green-Hills-MULTI.patch URL: From bill.hoffman at kitware.com Tue Mar 24 11:00:09 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 24 Mar 2015 11:00:09 -0400 Subject: [cmake-developers] Fortran support for Ninja generator In-Reply-To: <5511327A.6040700@gmail.com> References: <20150324090834.GB977@lenovo> <5511327A.6040700@gmail.com> Message-ID: <55117BF9.6050306@kitware.com> On 3/24/2015 5:46 AM, Nils Gladitz wrote: > > I am not very familiar with fortran myself but there was this discussion > on the ninja mailing list that implied that this might also require > changes to ninja itself: > > https://groups.google.com/d/msg/ninja-build/b1-AF3pRJuE/NkPDsO0C2IUJ Yes, the problem is that to build fortran 95 you have to parse the fortran first and figure out what order to build it, and then do the build. ninja is setup to load the depend tree once when it starts. It would have to be modified to be able to load the depend information dynamically. -Bill From brad.king at kitware.com Tue Mar 24 11:21:40 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 24 Mar 2015 11:21:40 -0400 Subject: [cmake-developers] Fortran support for Ninja generator In-Reply-To: <5511327A.6040700@gmail.com> References: <20150324090834.GB977@lenovo> <5511327A.6040700@gmail.com> Message-ID: <55118104.8000005@kitware.com> On 03/24/2015 05:46 AM, Nils Gladitz wrote: >> One mention was to use the -M* flags supported by gfortran, just as >> with gcc. However, when I tried this approach I found out that the -M* >> flag for gfortran seems buggy, it doesn't output the correct format >> (e.g. the target given with -MT flag is just added instead of >> overwriting the default target). So, my ninja build failed saying the >> depfile format was wrong. Yes, gfortran seems to produce rules with multiple outputs and ninja expects there to be only one output. It looks like gfortran lists the module.mod files produced by a translation unit as outputs and those consumed by a translation unit as dependencies. This is valuable information for ordering compilations, but we need to figure out the right way to get ninja to use the information. In particular, we need to get the information before a rule runs. >> Alternatively someone proposed to have ninja use cmake-generated >> dependencies. > > I am not very familiar with fortran myself but there was this discussion > on the ninja mailing list that implied that this might also require > changes to ninja itself: > > https://groups.google.com/d/msg/ninja-build/b1-AF3pRJuE/NkPDsO0C2IUJ That discussion concludes assuming that CMake scans source files while generating the build files to generate the ordering dependencies. It does not. There could be generated source files or header files that are needed to get the ordering right. In the Makefile generator we have a step to scan dependencies for a target after all its dependencies are finished and its custom commands have executed. This ensures generated files are available. Then CMake puts the dependency scanning results in a place used by the actual compile and link rules. There is absolutely no way to do this without some kind of change to ninja because its build plan graph must be updated dynamically to add Fortran module dependencies as they are discovered. AFAIK the only place ninja has for dynamically updating the build plan is the restat=1 option. IIUC the depfile information is loaded only at the beginning of the build. The "deps=gcc" option causes it to read a depfile immediately after a rule produces it, but I'm not sure whether it only transfers the information to the .ninja_deps file or updates its build graph on the fly. In all of these cases the build plan updates affecting a rule only occur *after* it runs. We cannot pre-generate a depfile because there is not enough information to do so until during the build. I've been thinking about some ideas on how build.ninja rules could express the dynamic scanning and update we need. Rather than posting them now, perhaps the design process would benefit from any independently developed ideas you may have. Thanks, -Brad From brad.king at kitware.com Tue Mar 24 11:54:49 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 24 Mar 2015 11:54:49 -0400 Subject: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support In-Reply-To: References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com> <54EB68C8.7030504@kitware.com> <54F0952B.5070809@kitware.com> <54F4781A.80708@kitware.com> <54FEF1C1.4030106@kitware.com> <5501F487.10807@kitware.com> <550886E2.1020708@kitware.com> <55101CE3.9000603@kitware.com> Message-ID: <551188C9.9070104@kitware.com> On 03/24/2015 09:14 AM, Geoffrey Viola wrote: > Attached is a new patch. Thanks. I've applied it and merged to 'next' for testing. I added some more commits to tweak a few things too: Add a 'Green Hills MULTI' generator http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1128a5f7 Help: Revise CMAKE_MAKE_PROGRAM documentation for GHS http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=590e0eb5 GHS: Wrap long lines in source http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ad69c815 GHS: Fix global generator constructor http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3fbaa372 GHS: Cleanup file streams as soon as we are done with them http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=52a7d6a8 GHS: Drop unused method argument http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed1ee3d4 I will squash all those in once you've okay-ed them and we've finished the topic with clean nightly testing. Meanwhile, please continue work based on commit ed1ee3d4 and send patches against that. In particular, please convert the C++ coding style as follows: * Use "this->" on all member accesses inside methods. * Place "{" on its own line indented with the content inside the block. This is the style used in the rest of CMake so it will be more consistent to maintain that way. Thanks, -Brad From brad.king at kitware.com Tue Mar 24 14:00:28 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 24 Mar 2015 14:00:28 -0400 Subject: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support In-Reply-To: <551188C9.9070104@kitware.com> References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com> <54EB68C8.7030504@kitware.com> <54F0952B.5070809@kitware.com> <54F4781A.80708@kitware.com> <54FEF1C1.4030106@kitware.com> <5501F487.10807@kitware.com> <550886E2.1020708@kitware.com> <55101CE3.9000603@kitware.com> <551188C9.9070104@kitware.com> Message-ID: <5511A63C.2000806@kitware.com> On 03/24/2015 11:54 AM, Brad King wrote: > I added some more commits to tweak a few things too: And a few more to fix our continuous testing results: GHS: Do not use C++11 enum name scope http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a4427fa9 GHS: Use !foo.empty() instead of foo.size() > 0 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=54828b82 GHS: Do not use string::back() that is missing on VS 7.1 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dbc9f8c6 > I will squash all those in once you've okay-ed them and we've finished > the topic with clean nightly testing. > > Meanwhile, please continue work based on commit ed1ee3d4 and send > patches against that. In particular, please convert the C++ coding > style as follows: > > * Use "this->" on all member accesses inside methods. > * Place "{" on its own line indented with the content inside the > block. > > This is the style used in the rest of CMake so it will be more > consistent to maintain that way. Please do this based on commit dbc9f8c6 instead. Also, several of the places that test for and add a trailing slash could be ported to use ConvertToUnixSlashes instead. That always removes trailing slashes and would also fix any backslashes specified by project code in property values. Thanks, -Brad From konstantin at podsvirov.pro Wed Mar 25 01:49:09 2015 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Wed, 25 Mar 2015 08:49:09 +0300 Subject: [cmake-developers] Qt, QtIFW, CMake and CPackIFW In-Reply-To: References: Message-ID: <2913711427262549@web18g.yandex.ru> Hello, Rizzen! 24.03.2015, 21:54, "Rizzen Yazston" : > Hi Konstantin, > > I hope you are the correct person I am contacting regarding the CPackIFW. After plenty of searching I came across an email post wanting to promote the usage of CPackIFW. You have come to the right place. I am the Creator of CPack IFW generator, which allows you to create installers for CMake projects using QtIFW tools. I want to congratulate you! You are the first person who contacted me personally and expressed a desire to use this generator packages. > I fairly new to Qt and to using CMake. Not being very good with CMake at this stage, I found the example given on the CPackIFW vague web page. That is how to use CPackIFW and CPack within Cmake to automate working with QtIFW. CPack IFW generator is a new module in CMake (added in version 3.1). The generator was tested on QtIFW tools version 1.5.0 (Linux and Windows. For MacOS not tested) that you can find on the download page of Qt: http://download.qt.io/official_releases/qt-installer-framework/1.5.0 > I looking for a more complete more detailed example of CMakeList files using these components. Also the example making use of directory hierarchy structure instead of the flat QMake system used, that is separate bin, build, src, include, rpc, ui, lang (translations) and data (application data files that can't be included in binary). Documentation specific to CPack IFW generator variables and functions (macros) is on the official website: http://www.cmake.org/cmake/help/v3.1/module/CPackIFW.html CPack IFW generator is the tip of the iceberg CMake :-) despite the fact that the generator is still young, he can solve your tasks. > I hoping you have a more complete example that I can look at for setting up my build and packing process for multi platform support. Unfortunately there are no detailed examples and tutorials for creating installer using CPack IFW generator. But I too want such materials have appeared in the documentation CMake and Qt. I think it will be useful for pracital the module description CPackComponent: http://www.cmake.org/cmake/help/v3.1/module/CPackComponent.html As well as the documentation for the install command: http://www.cmake.org/cmake/help/v3.1/command/install.html In the CMake documentation but there is no place to create guidelines and examples. The Qt documentation is a description of the work with CMake: http://doc.qt.io/qt-5/cmake-manual.html I was contacted by the developers of Qt and they welcomed the opportunity to add information about working with CPack IFW generator in their documentation. Go back to your task. Suggest to read the documentation provided in the above links. Let's assume that you've already read. CPack generator according to IFW-default. You can specify CPACK_GENERATOR "IFW". Or set the advanced option CPACK_BINARY_IFW to "ON" (AND the rest off :-) ). You need to use the option COMPONENT along with the install command. Use different name (comp_id) component for different parts of the installed project. Next, set CPACK_XXX variables describing the project. Then enable the modules: include(CPack) include(CPackIFW) You can use groups for gruppirovki components: cpack_add_component_group(group_id ...) Then add for each component CPack configuration: cpack_add_component(comp_id ... GROUP group_id) You can then configure specific IFW generator options: cpack_ifw_configure_component(comp_id ...) cpack_ifw_configure_component_group(group_id ...) That's all! :-) Now your project should appear in the target "package" - it creates the installer. You can also create online installers, but more on that later if you need it. We assume that the first guide CPack IFW generator is out! Dear, Rizzen! If you still have questions, feel free to email me - let's deal! Good luck in the development of modern tools :-) -- Regards, Konstantin Podsvirov (Sorry for my English) From dcrayford at gmail.com Wed Mar 25 05:46:19 2015 From: dcrayford at gmail.com (David Crayford) Date: Wed, 25 Mar 2015 17:46:19 +0800 Subject: [cmake-developers] Has CMake been ported to z/OS Message-ID: <551283EB.6090502@gmail.com> Hello list, Has anybody ported CMake to z/OS? And if so are they willing to share it? From steven.vancoillie at teokem.lu.se Wed Mar 25 09:37:00 2015 From: steven.vancoillie at teokem.lu.se (Steven Vancoillie) Date: Wed, 25 Mar 2015 14:37:00 +0100 Subject: [cmake-developers] Fortran support for Ninja generator In-Reply-To: <55118104.8000005@kitware.com> References: <20150324090834.GB977@lenovo> <5511327A.6040700@gmail.com> <55118104.8000005@kitware.com> Message-ID: <20150325133700.GE922@lenovo> On Mar 24 [11:21], Brad King wrote: > On 03/24/2015 05:46 AM, Nils Gladitz wrote: > > I am not very familiar with fortran myself but there was this discussion > > on the ninja mailing list that implied that this might also require > > changes to ninja itself: > > > > https://groups.google.com/d/msg/ninja-build/b1-AF3pRJuE/NkPDsO0C2IUJ > > That discussion concludes assuming that CMake scans source files > while generating the build files to generate the ordering dependencies. > It does not. There could be generated source files or header files > that are needed to get the ordering right. In the Makefile generator > we have a step to scan dependencies for a target after all its > dependencies are finished and its custom commands have executed. > This ensures generated files are available. Then CMake puts the > dependency scanning results in a place used by the actual compile > and link rules. > > [snip] > > I've been thinking about some ideas on how build.ninja rules > could express the dynamic scanning and update we need. Rather > than posting them now, perhaps the design process would benefit > from any independently developed ideas you may have. >From what I understood from the conclusion of the discussion is indeed that it would require cmake to generate dependency files at build time. In a test setup, I have the following: build CMakeFiles/testninja.dir/prog.o.d: Fortran_DEPENDS_SCAN ../prog.f90 build CMakeFiles/testninja.dir/prog.o: Fortran_COMPILER ../prog.f90 | CMakeFiles/testninja.dir/prog.o.d DEP_FILE = CMakeFiles/testninja.dir/prog.o.d FLAGS = -cpp -I../ OBJECT_DIR = CMakeFiles/testninja.dir OBJECT_FILE_DIR = CMakeFiles/testninja.dir build ... build ... I skipped all the other files, but the pattern is the same. Then, there are these rules: rule Fortran_DEPENDS_SCAN command = f90deps $in $out description = Write Fortran dependencies to $out rule Fortran_COMPILER depfile = $DEP_FILE deps = gcc command = /usr/bin/f95 $DEFINES $FLAGS -c $in -o $out description = Building Fortran object $out In this case, a script 'f90deps' does the dependencies on the fly. Note that the Fortran_COMPILER rule is now missing any -MMD/-MT stuff. So, to do a similar thing with cmake, one would need to expose the cmake Fortran dependency scanner so that it can be invoked as e.g.: rule Fortran_DEPENDS_SCAN command = cmake scan_dependencies $in $out description = Write Fortran dependencies to $out but I don't know if turning the cmake executable into a build-time dependency scanner is feasible and/or acceptable. Steven From Geoffrey.Viola at asirobots.com Wed Mar 25 09:47:10 2015 From: Geoffrey.Viola at asirobots.com (Geoffrey Viola) Date: Wed, 25 Mar 2015 13:47:10 +0000 Subject: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support In-Reply-To: <5511A63C.2000806@kitware.com> References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com> <54EB68C8.7030504@kitware.com> <54F0952B.5070809@kitware.com> <54F4781A.80708@kitware.com> <54FEF1C1.4030106@kitware.com> <5501F487.10807@kitware.com> <550886E2.1020708@kitware.com> <55101CE3.9000603@kitware.com> <551188C9.9070104@kitware.com> <5511A63C.2000806@kitware.com> Message-ID: >> I added some more commits to tweak a few things too: > >And a few more to fix our continuous testing results: > >GHS: Do not use C++11 enum name scope >http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a4427fa9 > >GHS: Use !foo.empty() instead of foo.size() > 0 >http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=54828b82 > > GHS: Do not use string::back() that is missing on VS 7.1 > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dbc9f8c6 Thanks. That's good to know. > Please do this based on commit dbc9f8c6 instead. The attached patches should be based on that commit and then made sequentially. >>> * Place "{" on its own line indented with the content inside the Made the changes in patch 1. I used the attached clang format file. >> > * Use "this->" on all member accesses inside methods. Made the changes in patch 2. > Also, several of the places that test for and add a trailing slash could be ported to use ConvertToUnixSlashes instead. That always removes trailing slashes and would also fix any backslashes specified by project code in property values. Made the changes in patch 3. The total changes were tested: https://open.cdash.org/buildSummary.php?buildid=3743400. I'll test it on my internal projects. Geoffrey Viola SOFTWARE ENGINEER asirobots.com This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-cleaned-up-trailing-slash-logic.patch Type: application/octet-stream Size: 2731 bytes Desc: 0003-cleaned-up-trailing-slash-logic.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-broke-lines-after-curly-brace-in-GHS-CPP-files.patch Type: application/octet-stream Size: 48768 bytes Desc: 0001-broke-lines-after-curly-brace-in-GHS-CPP-files.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-added-this-to-member-accesses-in-GHS-CPP-files.patch Type: application/octet-stream Size: 27815 bytes Desc: 0002-added-this-to-member-accesses-in-GHS-CPP-files.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: _clang-format Type: application/octet-stream Size: 340 bytes Desc: _clang-format URL: From brad.king at kitware.com Wed Mar 25 10:49:25 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 25 Mar 2015 10:49:25 -0400 Subject: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support In-Reply-To: References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com> <54F0952B.5070809@kitware.com> <54F4781A.80708@kitware.com> <54FEF1C1.4030106@kitware.com> <5501F487.10807@kitware.com> <550886E2.1020708@kitware.com> <55101CE3.9000603@kitware.com> <551188C9.9070104@kitware.com> <5511A63C.2000806@kitware.com> Message-ID: <5512CAF5.2030908@kitware.com> On 03/25/2015 09:47 AM, Geoffrey Viola wrote: > The attached patches should be based on that commit and then made sequentially. Thanks. In the meantime I had made one more fix that should address test failures from last night's testing: GHS: Fix selection of make program 'gbuild' http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=128cad7e I rebased your patches on that and updated the indentation using my editor mode. I've squashed it all into: GHS: Further revisions http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=89bcd1a0 If you have further work, please base it on that. Since all these fixup commits will be squashed away before merging to 'master' their commit messages were not written for long term future reference. Once this is all clean on nightly testing I will squash it all into one commit that initially adds the generator. We need to construct a commit message for that commit. The first line can be just Add a 'Green Hills MULTI' generator Please provide some text (prose) to summarize the new generator. In particular, please provide a link to the GHS product page so we know exactly what IDE the generator supports. Thanks, -Brad From Geoffrey.Viola at asirobots.com Wed Mar 25 11:15:19 2015 From: Geoffrey.Viola at asirobots.com (Geoffrey Viola) Date: Wed, 25 Mar 2015 15:15:19 +0000 Subject: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support In-Reply-To: <5512CAF5.2030908@kitware.com> References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com> <54F0952B.5070809@kitware.com> <54F4781A.80708@kitware.com> <54FEF1C1.4030106@kitware.com> <5501F487.10807@kitware.com> <550886E2.1020708@kitware.com> <55101CE3.9000603@kitware.com> <551188C9.9070104@kitware.com> <5511A63C.2000806@kitware.com> <5512CAF5.2030908@kitware.com> Message-ID: > We need to construct a commit message for that commit. The first line can be just > > Add a 'Green Hills MULTI' generator > > Please provide some text (prose) to summarize the new generator. > In particular, please provide a link to the GHS product page so we know exactly what IDE the generator supports. Add a 'Green Hills MULTI' generator Green Hills MULTI is an IDE for embedded real-time systems. The IDE's product page can be found here: http://www.ghs.com/products/MULTI_IDE.html. It supports cross compiling on ARM, Intel x86, and other architectures with various operating systems. The IDE exists on Linux and Windows host systems, but CMake will only generate the project files on Windows host systems. Geoffrey Viola SOFTWARE ENGINEER asirobots.com This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. From brad.king at kitware.com Wed Mar 25 11:39:47 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 25 Mar 2015 11:39:47 -0400 Subject: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support In-Reply-To: References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com> <54F4781A.80708@kitware.com> <54FEF1C1.4030106@kitware.com> <5501F487.10807@kitware.com> <550886E2.1020708@kitware.com> <55101CE3.9000603@kitware.com> <551188C9.9070104@kitware.com> <5511A63C.2000806@kitware.com> <5512CAF5.2030908@kitware.com> Message-ID: <5512D6C3.7090000@kitware.com> On 03/25/2015 11:15 AM, Geoffrey Viola wrote: >> Please provide some text (prose) to summarize the new generator. > > Green Hills MULTI is an IDE for embedded real-time systems. Thanks. I've squashed the topic so far down into: Add a 'Green Hills MULTI' generator on Windows http://cmake.org/gitweb?p=cmake.git;a=commit;h=8f547be5 We can still add more fixup commits as needed for nightly testing. Please base further work, if any, on that commit for now. Thanks, -Brad From mantis at public.kitware.com Wed Mar 25 13:18:45 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 25 Mar 2015 13:18:45 -0400 Subject: [cmake-developers] [CMake 0015474]: The "Unix Makefiles" generator should use .DELETE_ON_ERROR Message-ID: <094e61b52298d1aa3eaa925addd362ef@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15474 ====================================================================== Reported By: Andrey Vihrov Assigned To: ====================================================================== Project: CMake Issue ID: 15474 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-25 13:18 EDT Last Modified: 2015-03-25 13:18 EDT ====================================================================== Summary: The "Unix Makefiles" generator should use .DELETE_ON_ERROR Description: The .DELETE_ON_ERROR special target in GNU Make ensures that if a command fails, then its corresponding target will be deleted. For example, if a linker OOMs halfway writing the final executable, then without .DELETE_ON_ERROR Make will consider that the (corrupted) executable has been built and refuse to rebuild it. See also https://www.gnu.org/software/make/manual/html_node/Special-Targets.html#index-_002eDELETE_005fON_005fERROR and https://www.gnu.org/software/make/manual/html_node/Errors.html#index-deletion-of-target-files (last paragraph). Steps to Reproduce: * Use the "Unix Makefiles" generator with a sample CMake project * Verify that the generated Makefiles do not contain .DELETE_ON_ERROR ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-25 13:18 Andrey Vihrov New Issue ====================================================================== From brad.king at kitware.com Wed Mar 25 13:23:02 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 25 Mar 2015 13:23:02 -0400 Subject: [cmake-developers] Has CMake been ported to z/OS In-Reply-To: <551283EB.6090502@gmail.com> References: <551283EB.6090502@gmail.com> Message-ID: <5512EEF6.6030008@kitware.com> On 03/25/2015 05:46 AM, David Crayford wrote: > Has anybody ported CMake to z/OS? I'm not aware of any such work. The only knowledge of z/OS of which I recall was added here: Teach compiler id about VisualAge -> XL rebranding http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=115ecc57 It simply distinguishes the zOS compiler from XL and VisualAge compilers because both define __IBMC__ or __IBMCPP__. However, no platform or compiler information modules are available for zOS. I'm not familiar with z/OS other than in that it exists. Porting to be hosted on there may be quite a bit of work if it is not POSIX-like. (A VMS port was done in the past but has not been maintained.) If cross compilers are available to build for z/OS from another OS maybe that would be simpler. -Brad From neundorf at kde.org Wed Mar 25 17:12:14 2015 From: neundorf at kde.org (Alexander Neundorf) Date: Wed, 25 Mar 2015 22:12:14 +0100 Subject: [cmake-developers] Fortran support for Ninja generator In-Reply-To: <20150325133700.GE922@lenovo> References: <20150324090834.GB977@lenovo> <55118104.8000005@kitware.com> <20150325133700.GE922@lenovo> Message-ID: <1816523.OBNj1KdstS@tuxedo.neundorf.net> On Wednesday, March 25, 2015 14:37:00 Steven Vancoillie wrote: > On Mar 24 [11:21], Brad King wrote: > > On 03/24/2015 05:46 AM, Nils Gladitz wrote: > > > I am not very familiar with fortran myself but there was this discussion > > > on the ninja mailing list that implied that this might also require > > > changes to ninja itself: > > > > > > https://groups.google.com/d/msg/ninja-build/b1-AF3pRJuE/NkPDsO0C2IUJ > > > > That discussion concludes assuming that CMake scans source files > > while generating the build files to generate the ordering dependencies. > > It does not. There could be generated source files or header files > > that are needed to get the ordering right. In the Makefile generator > > we have a step to scan dependencies for a target after all its > > dependencies are finished and its custom commands have executed. > > This ensures generated files are available. Then CMake puts the > > dependency scanning results in a place used by the actual compile > > and link rules. > > > > [snip] > > > > I've been thinking about some ideas on how build.ninja rules > > could express the dynamic scanning and update we need. Rather > > than posting them now, perhaps the design process would benefit > > from any independently developed ideas you may have. > > From what I understood from the conclusion of the discussion is indeed > that it would require cmake to generate dependency files at build > time. In a test setup, I have the following: > > build CMakeFiles/testninja.dir/prog.o.d: Fortran_DEPENDS_SCAN ../prog.f90 > build CMakeFiles/testninja.dir/prog.o: Fortran_COMPILER ../prog.f90 | > CMakeFiles/testninja.dir/prog.o.d DEP_FILE = > CMakeFiles/testninja.dir/prog.o.d > FLAGS = -cpp -I../ > OBJECT_DIR = CMakeFiles/testninja.dir > OBJECT_FILE_DIR = CMakeFiles/testninja.dir > build ... > build ... > > I skipped all the other files, but the pattern is the same. > Then, there are these rules: > > rule Fortran_DEPENDS_SCAN > command = f90deps $in $out > description = Write Fortran dependencies to $out > > rule Fortran_COMPILER > depfile = $DEP_FILE > deps = gcc > command = /usr/bin/f95 $DEFINES $FLAGS -c $in -o $out > description = Building Fortran object $out > > In this case, a script 'f90deps' does the dependencies on the fly. > Note that the Fortran_COMPILER rule is now missing any -MMD/-MT stuff. > > So, to do a similar thing with cmake, one would need to expose the > cmake Fortran dependency scanner so that it can be invoked as e.g.: > > rule Fortran_DEPENDS_SCAN > command = cmake scan_dependencies $in $out > description = Write Fortran dependencies to $out > > but I don't know if turning the cmake executable into a build-time > dependency scanner is feasible and/or acceptable. as Brad wrote, this is already the case for the makefile generator, so I guess in general this should be Ok. Alex From mantis at public.kitware.com Wed Mar 25 20:29:17 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 25 Mar 2015 17:29:17 -0700 Subject: [cmake-developers] [CMake 0015475]: Fails to build against external Expat 2.1.0 with Visual Studio 2013 Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15475 ====================================================================== Reported By: Daniel Schepler Assigned To: ====================================================================== Project: CMake Issue ID: 15475 Category: CPack Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-25 17:29 PDT Last Modified: 2015-03-25 17:29 PDT ====================================================================== Summary: Fails to build against external Expat 2.1.0 with Visual Studio 2013 Description: When I try to build CMake 3.2.1 using external Expat 2.1.0 (and also external ZLib 1.2.8) using Visual Studio 2013 (Express Edition), I get this error: C:\tools\cygwin\home\dschepler\scalable-dev\scalable-3p\scalable-3p-cmake\Source \CPack\WiX\cmWIXPatchParser.cxx(135) : error C2664: 'XML_Size XML_GetCurrentLine Number(XML_Parser)' : cannot convert argument 1 from 'void *' to 'XML_Parser' Conversion from 'void*' to pointer to non-'void' requires an explicit ca st C:\tools\cygwin\home\dschepler\scalable-dev\scalable-3p\scalable-3p-cmake\Source \CPack\WiX\cmWIXPatchParser.cxx(136) : error C2664: 'XML_Size XML_GetCurrentColu mnNumber(XML_Parser)' : cannot convert argument 1 from 'void *' to 'XML_Parser' Conversion from 'void*' to pointer to non-'void' requires an explicit ca st C:\tools\cygwin\home\dschepler\scalable-dev\scalable-3p\scalable-3p-cmake\Source \CPack\WiX\cmWIXPatchParser.cxx(137) : error C2660: 'cmWIXPatchParser::ReportErr or' : function does not take 2 arguments NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~1.0\VC\bin\X86_AM~1\cl.exe' : ret urn code '0x2' Stop. NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0 \VC\BIN\nmake.exe"' : return code '0x2' Stop. NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0 \VC\BIN\nmake.exe"' : return code '0x2' Stop. Steps to Reproduce: The command line I used to configure the build was: cmake -G"NMake Makefiles" -DCMAKE_BUILD_TYPE:STRING=Release -DCMAKE_INSTALL_PREFIX:PATH=C:\tools\cygwin\home\dschepler\scalable-dev\scalable-3p\scalable-3p-cmake\image -DCMAKE_USE_SYSTEM_EXPAT:BOOL=ON -DCMAKE_USE_SYSTEM_ZLIB:BOOL=ON -DBUILD_QtDialog:BOOL=ON .. Then running nmake in the build directory gave the error. And incidentally, it found Expat and ZLib through paths included in the CMAKE_PREFIX_PATH environment variable; while as usual, Qt 4 was found through qmake being on PATH. Additional Information: With the attached patch, I was able to complete the build, and the install image looked good. I don't know if this is the best solution, or whether it might be better to change cmXMLParser to have "XML_Parser Parser;" instead of "void* Parser;". ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-25 17:29 Daniel ScheplerNew Issue 2015-03-25 17:29 Daniel ScheplerFile Added: fix-build-against-expat-2.1.0.diff ====================================================================== From mantis at public.kitware.com Thu Mar 26 05:30:22 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 26 Mar 2015 05:30:22 -0400 Subject: [cmake-developers] [CMake 0015476]: WiX packages not created with files that contain special characters. Message-ID: <45905e4e5b5c058b07e0ba42a9ecfb9b@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15476 ====================================================================== Reported By: Richard Ulrich Assigned To: ====================================================================== Project: CMake Issue ID: 15476 Category: CPack Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-26 05:30 EDT Last Modified: 2015-03-26 05:30 EDT ====================================================================== Summary: WiX packages not created with files that contain special characters. Description: After upgrading to cmake 3.2.1, WiX packages can no longer be created that contain files with special characters in their name. Steps to Reproduce: Use the attached minimal project, and try to generate a WiX installer. Additional Information: error LGHT0103 : The system cannot find the file '... .txt' If I open files.wxs, instead of the special chars, it displays garbage characters. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-26 05:30 Richard Ulrich New Issue 2015-03-26 05:30 Richard Ulrich File Added: wix_utf8.zip ====================================================================== From mantis at public.kitware.com Thu Mar 26 06:11:22 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 26 Mar 2015 06:11:22 -0400 Subject: [cmake-developers] [CMake 0015477]: FindMFC.cmake warning due to POLICY CMP0054 Message-ID: <5f2c001ba7615719d24f8154a80d97f9@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15477 ====================================================================== Reported By: j.kreuzberger Assigned To: ====================================================================== Project: CMake Issue ID: 15477 Category: Modules Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-26 06:11 EDT Last Modified: 2015-03-26 06:11 EDT ====================================================================== Summary: FindMFC.cmake warning due to POLICY CMP0054 Description: cmake_required_version is 3.0.0 during migration to 3.2.1 the POLICY CMP0054 gives a warning in FindMFC.cmake line 39 Question is if i set the policy to "NEW", does this affect the FindMFC.cmake behaviour on FindMFC? Steps to Reproduce: cmake configure step Additional Information: Cannot clearly check the behaviour for FindMFC.cmake cause i am on a linux machine and currently have no environment with cmake 3.2, mfc installed and visual studio professional ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-26 06:11 j.kreuzberger New Issue ====================================================================== From brad.king at kitware.com Thu Mar 26 08:53:25 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 26 Mar 2015 08:53:25 -0400 Subject: [cmake-developers] Fortran support for Ninja generator In-Reply-To: <1816523.OBNj1KdstS@tuxedo.neundorf.net> References: <20150324090834.GB977@lenovo> <55118104.8000005@kitware.com> <20150325133700.GE922@lenovo> <1816523.OBNj1KdstS@tuxedo.neundorf.net> Message-ID: <55140145.4050508@kitware.com> On 03/25/2015 05:12 PM, Alexander Neundorf wrote: >> rule Fortran_DEPENDS_SCAN >> command = f90deps $in $out >> description = Write Fortran dependencies to $out >> >> rule Fortran_COMPILER >> depfile = $DEP_FILE >> deps = gcc >> command = /usr/bin/f95 $DEFINES $FLAGS -c $in -o $out >> description = Building Fortran object $out Thanks. I have a similar structure in mind. I think it will end up being a bit more complicated because the dependencies have to be scanned and loaded on the fly. Currently Ninja loads all depfiles up front and dependencies generated from scanning are only considered on the next invocation. We will need build-time incremental addition of dependencies and even new build nodes to represent the module files that sit between providers and consumers. I'm working on a write-up of the whole thing to present to Ninja folks. Once it's drafted I'll post it here for discussion. >> So, to do a similar thing with cmake, one would need to expose the >> cmake Fortran dependency scanner so that it can be invoked as e.g.: >> >> rule Fortran_DEPENDS_SCAN >> command = cmake scan_dependencies $in $out >> description = Write Fortran dependencies to $out >> >> but I don't know if turning the cmake executable into a build-time >> dependency scanner is feasible and/or acceptable. > > as Brad wrote, this is already the case for the makefile generator, > so I guess in general this should be Ok. Yes, the Makefile generator already uses an undocumented cmake command line tool to scan dependencies during the build. -Brad From brad.king at kitware.com Thu Mar 26 09:13:37 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 26 Mar 2015 09:13:37 -0400 Subject: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support In-Reply-To: <5512D6C3.7090000@kitware.com> References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com> <54F4781A.80708@kitware.com> <54FEF1C1.4030106@kitware.com> <5501F487.10807@kitware.com> <550886E2.1020708@kitware.com> <55101CE3.9000603@kitware.com> <551188C9.9070104@kitware.com> <5511A63C.2000806@kitware.com> <5512CAF5.2030908@kitware.com> <5512D6C3.7090000@kitware.com> Message-ID: <55140601.7070804@kitware.com> On 03/25/2015 11:39 AM, Brad King wrote: > http://cmake.org/gitweb?p=cmake.git;a=commit;h=8f547be5 > > We can still add more fixup commits as needed for nightly testing. > Please base further work, if any, on that commit for now. Two GHS tests still fail: https://open.cdash.org/viewTest.php?onlyfailed&buildid=3744753 with output like: Run Clean Command:"gbuild" "-clean" The system cannot find the file specified Generator: execution of make clean failed. The FindGhsBuildCommand method currently just searches the PATH for "gbuild". Shouldn't it be able to locate gbuild through similar means to finding GHS_COMP_ROOT? Thanks, -Brad From Geoffrey.Viola at asirobots.com Thu Mar 26 13:50:33 2015 From: Geoffrey.Viola at asirobots.com (Geoffrey Viola) Date: Thu, 26 Mar 2015 17:50:33 +0000 Subject: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support In-Reply-To: <55140601.7070804@kitware.com> References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com> <54F4781A.80708@kitware.com> <54FEF1C1.4030106@kitware.com> <5501F487.10807@kitware.com> <550886E2.1020708@kitware.com> <55101CE3.9000603@kitware.com> <551188C9.9070104@kitware.com> <5511A63C.2000806@kitware.com> <5512CAF5.2030908@kitware.com> <5512D6C3.7090000@kitware.com> <55140601.7070804@kitware.com> Message-ID: > The FindGhsBuildCommand method currently just searches the PATH for "gbuild". Shouldn't it be able to locate gbuild through similar means to finding GHS_COMP_ROOT? Yeah, it looks like the GetGhsBuildCommand in cmGlobalGhsMultiGenerator.cxx on ln. 105 just runs FindProgram to locate gbuild. The tests are passing on my machine without gbuild in my path: https://open.cdash.org/buildSummary.php?buildid=3745149. Do you have Green Hills MULTI installed? If so which version is installed? Geoffrey Viola SOFTWARE ENGINEER asirobots.com -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Thursday, March 26, 2015 7:14 AM To: Geoffrey Viola Cc: cmake-developers at cmake.org Subject: Re: FW: FW: [cmake-developers] Initial Attempt at Green Hill MULTI IDE Generator Support On 03/25/2015 11:39 AM, Brad King wrote: > http://cmake.org/gitweb?p=cmake.git;a=commit;h=8f547be5 > > We can still add more fixup commits as needed for nightly testing. > Please base further work, if any, on that commit for now. Two GHS tests still fail: https://open.cdash.org/viewTest.php?onlyfailed&buildid=3744753 with output like: Run Clean Command:"gbuild" "-clean" The system cannot find the file specified Generator: execution of make clean failed. The FindGhsBuildCommand method currently just searches the PATH for "gbuild". Shouldn't it be able to locate gbuild through similar means to finding GHS_COMP_ROOT? Thanks, -Brad This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. From brad.king at kitware.com Thu Mar 26 14:50:28 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 26 Mar 2015 14:50:28 -0400 Subject: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support In-Reply-To: References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com> <54FEF1C1.4030106@kitware.com> <5501F487.10807@kitware.com> <550886E2.1020708@kitware.com> <55101CE3.9000603@kitware.com> <551188C9.9070104@kitware.com> <5511A63C.2000806@kitware.com> <5512CAF5.2030908@kitware.com> <5512D6C3.7090000@kitware.com> <55140601.7070804@kitware.com> Message-ID: <551454F4.6060304@kitware.com> On 03/26/2015 01:50 PM, Geoffrey Viola wrote: > Do you have Green Hills MULTI installed? If so which version is installed? No. The failures I'm linking are on /your/ nightly build. Remember that does set(ENV{PATH} "c:\\Windows\\system32;c:\\Windows") so nothing is in the path. The purpose of FindGhsBuildCommand is to use any knowledge possible to find gbuild. The equivalent method in the VS generators uses the registry to find msbuild for example. Thanks, -Brad From mantis at public.kitware.com Thu Mar 26 15:25:20 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 26 Mar 2015 15:25:20 -0400 Subject: [cmake-developers] [CMake 0015478]: As of CMake 3.1 Properties cannot be set to "" Message-ID: <0099006e1e07ebf276e538dbf569edc0@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15478 ====================================================================== Reported By: Walter Gray Assigned To: ====================================================================== Project: CMake Issue ID: 15478 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-26 15:25 EDT Last Modified: 2015-03-26 15:25 EDT ====================================================================== Summary: As of CMake 3.1 Properties cannot be set to "" Description: As of CMake 3.0.2, it was completely legal to set a target property to "". This was in fact a very helpful feature for me in some cases since it meant that if I knew I'd set a property to a list (even an empty one), when I read it back later and passed it into a foreach I didn't have to also use an if to check if it existed. This functionality was broken in 3.1, and there is neither a policy setting about it, nor any documentation I can find that indicates this was an intended change. Steps to Reproduce: Run the following cmake script. In CMake <= 3.0.2, prop1 will be an empty string. In CMake >= 3.1, it will be prop1-NOTFOUND cmake_minimum_required(VERSION 3.0) cmake_policy(VERSION 3.0.2) project(cmaketestproject) add_executable(testexe test.cpp) set(emptylist "") set_target_properties(testexe PROPERTIES INTERFACE_PROP_1 "${emptylist}" INTERFACE_PROP_2 "thing") get_target_property(prop1 testexe INTERFACE_PROP_1) get_target_property(prop2 testexe INTERFACE_PROP_2) get_target_property(prop3 testexe INTERFACE_PROP_3) message(prop1=${prop1}) message(prop2=${prop2}) message(prop3=${prop3}) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-26 15:25 Walter Gray New Issue ====================================================================== From mantis at public.kitware.com Thu Mar 26 16:05:35 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 26 Mar 2015 16:05:35 -0400 Subject: [cmake-developers] [CMake 0015479]: Support depfiles from add_custom_command Message-ID: <2daffa05149504a6afa6792fbd3d29a7@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15479 ====================================================================== Reported By: Ben Boeckel Assigned To: ====================================================================== Project: CMake Issue ID: 15479 Category: CMake Reproducibility: have not tried Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-26 16:05 EDT Last Modified: 2015-03-26 16:05 EDT ====================================================================== Summary: Support depfiles from add_custom_command Description: It would be nice to be able to have custom commands be able to generate their own depfiles for Make and Ninja. Probably a DEPFILE argument to `add_custom_command`. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-26 16:05 Ben Boeckel New Issue ====================================================================== From felix.schwitzer at gmx.at Thu Mar 26 17:16:42 2015 From: felix.schwitzer at gmx.at (felix schwitzer) Date: Thu, 26 Mar 2015 21:16:42 +0000 (UTC) Subject: [cmake-developers] UseSWIG warns about CMP0057 Message-ID: I have a library and use the "UseSWIG"-module to generate bindings for different scripting languages from an interface file (ltt.i in the example below). To get the bindings for more than one language, my CMakeLists.txt looks somehow like add_library(ltt ) include(UseSWIG) foreach(_lang "ruby" "python") if(_lang STREQUAL "ruby") set(_modulename "rltt") else() set(_modulename "pltt") endif() swig_add_module(${_modulename} ${_lang} ltt.i) swig_link_libraries(${_modulename} ltt) endif() Running this with cmake built from master (version 3.2.20150326-g5d1d99) now gives the warning about Policy CMP0057 is not set: Disallow multiple MAIN_DEPENDENCY specifications Is this a bug in UseSWIG or is my use case invalid? If the latter, who can I workaround it? The warning comes from UseSWIG in line 193; the interface file is added as a MAIN_DEPENDENCY to the swig-generated wrapper file, and because of the loop, it is added twice, to the lttPYTHON_warp.cxx and lttRUBY_warp.cxx, the two swig-generated files. Fixing this would be simple by adding the interface file as a normal dependency to the wrapper-files, the only drawback is backward compatibility. regards Felix From brad.king at kitware.com Fri Mar 27 08:34:42 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 27 Mar 2015 08:34:42 -0400 Subject: [cmake-developers] UseSWIG warns about CMP0057 In-Reply-To: References: Message-ID: <55154E62.109@kitware.com> On 03/26/2015 05:16 PM, felix schwitzer wrote: > Is this a bug in UseSWIG or is my use case invalid? It's a bug exposed by the policy warning. We never supported repeated use of MAIN_DEPENDENCY, it just wasn't diagnosed before CMP0057. > The warning comes from UseSWIG in line 193; the interface file is added as > a MAIN_DEPENDENCY to the swig-generated wrapper file, and because of the loop, > it is added twice, to the lttPYTHON_warp.cxx and lttRUBY_warp.cxx, > the two swig-generated files. > > Fixing this would be simple by adding the interface file as a normal dependency > to the wrapper-files, the only drawback is backward compatibility. Yes, it should be fixed to just use DEPENDS instead of MAIN_DEPENDENCY, at least if there are multiple languages to be generated. There is no compatibility issue because MAIN_DEPENDENCY only affects the presentation of source files in IDE projects. Otherwise it is the same as DEPENDS. This is likely why repeated MAIN_DEPENDENCY didn't get noticed before. I'm not set up to test UseSWIG on a real project like you. Would you please look at making and testing the change locally and then send a patch? Thanks, -Brad From brad.king at kitware.com Fri Mar 27 15:20:58 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 27 Mar 2015 15:20:58 -0400 Subject: [cmake-developers] Fortran support for Ninja generator In-Reply-To: <55140145.4050508@kitware.com> References: <20150324090834.GB977@lenovo> <55118104.8000005@kitware.com> <20150325133700.GE922@lenovo> <1816523.OBNj1KdstS@tuxedo.neundorf.net> <55140145.4050508@kitware.com> Message-ID: <5515AD9A.5060608@kitware.com> On 03/26/2015 08:53 AM, Brad King wrote: > I'm working on a write-up of the whole thing to present to Ninja > folks. Once it's drafted I'll post it here for discussion. I've drafted the attached document in Markdown to make it easy to paste into a Github issue or comment for discussion with Ninja upstream. Review on our side should be about whether the proposal is sufficient to satisfy our needs rather than about specific syntax and such. Thanks, -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: ninja-and-fortran.md Type: text/x-markdown Size: 7812 bytes Desc: not available URL: From mantis at public.kitware.com Fri Mar 27 17:07:31 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 27 Mar 2015 17:07:31 -0400 Subject: [cmake-developers] [CMake 0015480]: UseSWIG.cmake warns about CMP0057 Message-ID: <160930814340ad40545cfd00df1676f8@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15480 ====================================================================== Reported By: Felix Schwitzer Assigned To: ====================================================================== Project: CMake Issue ID: 15480 Category: CMake Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-27 17:07 EDT Last Modified: 2015-03-27 17:07 EDT ====================================================================== Summary: UseSWIG.cmake warns about CMP0057 Description: When calling swig_add_module (from module UseSWIG) with the same interface file for different scripting languages, cmake emits a warning about CMP0057 as swig_add_module adds the interface file as MAIN_DEPENDENCY to the generated wrapper file. This happens with an actual cmake from master (7910cb7); see http://article.gmane.org/gmane.comp.programming.tools.cmake.devel/12835 I added a minimal example to reproduce and a patch Steps to Reproduce: unpack the attached example tst.tgz and change into the directory tst, then mkdir build && cd build && cmake .. Without patching cmake fails as CMP0057 is set to new. With the patch the command runs fine. On a system with swig, ruby-dev and python-dev installed, compilation should run fine and also the dependencies are kept right: make -> runs swig and compiles the wrappers touch ../ltt.i && make -> runs swig again and compiles the wrappers ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-27 17:07 Felix SchwitzerNew Issue 2015-03-27 17:07 Felix SchwitzerFile Added: tst.tgz ====================================================================== From felix.schwitzer at gmx.at Fri Mar 27 17:24:09 2015 From: felix.schwitzer at gmx.at (felix schwitzer) Date: Fri, 27 Mar 2015 21:24:09 +0000 (UTC) Subject: [cmake-developers] UseSWIG warns about CMP0057 References: <55154E62.109@kitware.com> Message-ID: Brad King writes: > > Yes, it should be fixed to just use DEPENDS instead of MAIN_DEPENDENCY, > at least if there are multiple languages to be generated. There is no > compatibility issue because MAIN_DEPENDENCY only affects the presentation > of source files in IDE projects. Otherwise it is the same as DEPENDS. > This is likely why repeated MAIN_DEPENDENCY didn't get noticed before. > > I'm not set up to test UseSWIG on a real project like you. Would you > please look at making and testing the change locally and then send > a patch? I filed a bug report (http://public.kitware.com/Bug/view.php?id=15480) with an example and a patch attached. On my linux-system it worked fine. Thanks Felix From michael.tanner at new.ox.ac.uk Sat Mar 28 21:34:55 2015 From: michael.tanner at new.ox.ac.uk (Michael Tanner) Date: Sun, 29 Mar 2015 01:34:55 +0000 Subject: [cmake-developers] Patch: FindCUDA.cmake -Wall Warnings Message-ID: When 'Wall' flag is set, FindCUDA.cmake generates literally thousands of warnings from NVIDIA?s header files (primarily -Wunused-function warnings). This patch (below email signature) removes those warnings by using the CMAKE_INCLUDE_SYSTEM_FLAG_C flag to treat NVIDIA?s include files as system headers. -- Michael Tanner From 725d0d7d078bf6a150560a5aa4e1d11fe6691ec9 Mon Sep 17 00:00:00 2001 From: Michael Tanner Date: Sun, 29 Mar 2015 00:55:34 +0000 Subject: [PATCH] Fixes FindCUDA.cmake to prevent system warnings Previously, the NVIDIA header/implementaiton files would generate literally thousands of warnings to comopile even the simpleste of CUDA projects with "-Wall". --- Modules/FindCUDA.cmake | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Modules/FindCUDA.cmake b/Modules/FindCUDA.cmake index 81e1cad..c79ff35 100644 --- a/Modules/FindCUDA.cmake +++ b/Modules/FindCUDA.cmake @@ -1097,7 +1097,8 @@ macro(CUDA_WRAP_SRCS cuda_target format generated_files) endif() # Initialize our list of includes with the user ones followed by the CUDA system ones. - set(CUDA_NVCC_INCLUDE_ARGS ${CUDA_NVCC_INCLUDE_ARGS_USER} "-I${CUDA_INCLUDE_DIRS}") + string(STRIP ${CMAKE_INCLUDE_SYSTEM_FLAG_C} CMAKE_INCLUDE_SYSTEM_FLAG_C_STRIPPED) + set(CUDA_NVCC_INCLUDE_ARGS ${CUDA_NVCC_INCLUDE_ARGS_USER} ${CMAKE_INCLUDE_SYSTEM_FLAG_C_STRIPPED} ${CUDA_INCLUDE_DIRS}) # Get the include directories for this directory and use them for our nvcc command. # Remove duplicate entries which may be present since include_directories # in CMake >= 2.8.8 does not remove them. -- 2.1.0 From steveire at gmail.com Sun Mar 29 12:08:11 2015 From: steveire at gmail.com (Stephen Kelly) Date: Sun, 29 Mar 2015 18:08:11 +0200 Subject: [cmake-developers] Generating buildsystem metadata from CMake References: Message-ID: Stephen Kelly wrote: > I expect to require a few iterations to figure out what the metadata files > should contain in the end. Just FYI, I have not forgotten about this and am working on an expanded design to cover the reported needs. Thanks, Steve. From matt.mccormick at kitware.com Sun Mar 29 21:32:40 2015 From: matt.mccormick at kitware.com (Matt McCormick) Date: Sun, 29 Mar 2015 21:32:40 -0400 Subject: [cmake-developers] A CMAKE_EMULATOR variable In-Reply-To: <54F86D63.8040709@kitware.com> References: <54F73A15.7070306@kitware.com> <54F86D63.8040709@kitware.com> Message-ID: Hi Brad, On Thu, Mar 5, 2015 at 9:51 AM, Brad King wrote: > On 03/04/2015 08:15 PM, Matt McCormick wrote: >> On Wed, Mar 4, 2015 at 12:00 PM, Brad King wrote: >>> I do not think a global setting like this makes sense. We cannot >>> unconditionally add the cross-compiling target launcher in front of >>> all tests. Some tests may be running host tools. See below. >> >> This set of patches does not globally and unconditionally add a >> launcher in front of all tests. It uses build system knowledge to add >> the emulator commands in front of target executables only. > > Good, but it may take more work. I see the key logic here: > >> cmTarget* target = mf->FindTargetToUse(exe); >> if(target && target->GetType() == cmTarget::EXECUTABLE) >> { >> // Use the target file on disk. >> exe = target->GetFullPath(config); >> + >> + // Prepend with the emulator when cross compiling if required. > > This if() condition is not sufficient to know that the executable > is for the target architecture. The cmTarget could be IMPORTED, in > which case we don't know whether it references a host tool or one > built for the target architecture. Some kind of target property > may be needed to say "use the emulator to run me" more explicitly. > Once we have such a property, then it might as well refer to the > tool to be used, e.g. > > add_executable(myexe ...) > set_property(TARGET myexe PROPERTY CROSSCOMPILING_EMULATOR ${emulator}) > >> The point about the overloaded meaning of "targets" is a good one. I >> think the best name is then CMAKE_CROSSCOMPILING_EMULATOR. > > Sounds good. This variable could be used to initialize the above > property on target creation (see SetPropertyDefault calls). In > try_run we simply need to pass the value into the inner project > and its executable will pick it up too. That sounds cool. I have implemented it in the emulator-property branch [1]. The variable name that defines the default for the CROSSCOMPILING_EMULATOR property is CMAKE_CROSSCOMPILING_EMULATOR. Thanks, Matt [1] http://www.cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/emulator-property From Geoffrey.Viola at asirobots.com Mon Mar 30 00:49:17 2015 From: Geoffrey.Viola at asirobots.com (Geoffrey Viola) Date: Mon, 30 Mar 2015 04:49:17 +0000 Subject: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support In-Reply-To: <551454F4.6060304@kitware.com> References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com> <54FEF1C1.4030106@kitware.com> <5501F487.10807@kitware.com> <550886E2.1020708@kitware.com> <55101CE3.9000603@kitware.com> <551188C9.9070104@kitware.com> <5511A63C.2000806@kitware.com> <5512CAF5.2030908@kitware.com> <5512D6C3.7090000@kitware.com> <55140601.7070804@kitware.com> <551454F4.6060304@kitware.com> Message-ID: > The failures I'm linking are on /your/ nightly build. Remember that does > > set(ENV{PATH} "c:\\Windows\\system32;c:\\Windows") > > so nothing is in the path. The purpose of FindGhsBuildCommand is to use any knowledge possible to find gbuild. The equivalent method in the VS generators uses the registry to find msbuild for example. I think the problem was related to old cache values, since gbuild is not in the path. Both the experimental and nightly test suites limit the path the same way. The experimental test does not build cleanly. Here's a link to the tests passing: https://open.cdash.org/buildSummary.php?buildid=3749371. > Shouldn't it be able to locate gbuild through similar means to finding GHS_COMP_ROOT? Yeah, cmGlobalGhsMultiGenerator::FindMakeProgram uses the definition, "GHS_COMP_ROOT," to find gbuild. There's also support for the rest of the standard CMAKE_BUILD_TYPE values. These are RELWITHDEBINFO and MINSIZEREL. Geoffrey Viola SOFTWARE ENGINEER asirobots.com This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fixed-tests-by-finding-make-program-when-cleaning.patch Type: application/octet-stream Size: 5186 bytes Desc: 0001-Fixed-tests-by-finding-make-program-when-cleaning.patch URL: From brad.king at kitware.com Mon Mar 30 09:56:05 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 30 Mar 2015 09:56:05 -0400 Subject: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support In-Reply-To: References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com> <5501F487.10807@kitware.com> <550886E2.1020708@kitware.com> <55101CE3.9000603@kitware.com> <551188C9.9070104@kitware.com> <5511A63C.2000806@kitware.com> <5512CAF5.2030908@kitware.com> <5512D6C3.7090000@kitware.com> <55140601.7070804@kitware.com> <551454F4.6060304@kitware.com> Message-ID: <551955F5.2010307@kitware.com> On 03/30/2015 12:49 AM, Geoffrey Viola wrote: > cmGlobalGhsMultiGenerator::FindMakeProgram uses the definition, > "GHS_COMP_ROOT," to find gbuild. Thanks. However, I don't think that approach will work. At the point where GenerateBuildCommand is called in the case that is failing, EnableLanguage has never been run because it is not a real configuration. One giveaway of this problem is this hunk: > - this->SelectMakeProgram(makeProgram, this->GetGhsBuildCommand()) > - ); > + this->SelectMakeProgram(makeProgram, this->GhsBuildCommand) > + ); which I presume had to be done because no "mf" is available. However, at this point in the code nothing will have populated the GhsBuildCommand member. That's why it needs the call. Instead, please look at using GetCompRoot in FindGhsBuildCommand. > also support for the rest of the standard CMAKE_BUILD_TYPE values For all other generators and toolchains, the place we put the config-specific flags is in the CMAKE__FLAGS_ cache entries. These values are typically initialized in the Modules/Compiler/-.cmake modules. In this case, I think it would be: Modules/Compiler/GHS-C.cmake Modules/Compiler/GHS-CXX.cmake modules. See Modules/Compiler/Intel-*.cmake for an example. Then make sure the generator reads the flag values for the current configuration and uses them. Thanks, -Brad From brad.king at kitware.com Mon Mar 30 10:05:20 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 30 Mar 2015 10:05:20 -0400 Subject: [cmake-developers] Patch: FindCUDA.cmake -Wall Warnings In-Reply-To: References: Message-ID: <55195820.5080400@kitware.com> On 03/28/2015 09:34 PM, Michael Tanner wrote: > using the CMAKE_INCLUDE_SYSTEM_FLAG_C flag to treat NVIDIA's > include files as system headers. Good idea. > - set(CUDA_NVCC_INCLUDE_ARGS ${CUDA_NVCC_INCLUDE_ARGS_USER} "-I${CUDA_INCLUDE_DIRS}") > + string(STRIP ${CMAKE_INCLUDE_SYSTEM_FLAG_C} CMAKE_INCLUDE_SYSTEM_FLAG_C_STRIPPED) > + set(CUDA_NVCC_INCLUDE_ARGS ${CUDA_NVCC_INCLUDE_ARGS_USER} ${CMAKE_INCLUDE_SYSTEM_FLAG_C_STRIPPED} ${CUDA_INCLUDE_DIRS}) I don't think CMAKE_INCLUDE_SYSTEM_FLAG_C is the proper flag: - It may not be set if C is not enabled - It may not be set if the current compiler has no such flag - It specifies a flag for the current "real" compiler, not for nvcc Does nvcc support -isystem on all platforms such that we could just hard-code using the flag? Thanks, -Brad From robert.maynard at kitware.com Mon Mar 30 10:31:41 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 30 Mar 2015 10:31:41 -0400 Subject: [cmake-developers] Patch: FindCUDA.cmake -Wall Warnings In-Reply-To: <55195820.5080400@kitware.com> References: <55195820.5080400@kitware.com> Message-ID: I know in the past setting all of NVidia's headers to be system includes would actually break compilation of complex projects such as Thrust. The reason for this was that in the past you would get the following error: "error: kernel launches from templates are not allowed in system files" On Mon, Mar 30, 2015 at 10:05 AM, Brad King wrote: > On 03/28/2015 09:34 PM, Michael Tanner wrote: > > using the CMAKE_INCLUDE_SYSTEM_FLAG_C flag to treat NVIDIA's > > include files as system headers. > > Good idea. > > > - set(CUDA_NVCC_INCLUDE_ARGS ${CUDA_NVCC_INCLUDE_ARGS_USER} > "-I${CUDA_INCLUDE_DIRS}") > > + string(STRIP ${CMAKE_INCLUDE_SYSTEM_FLAG_C} > CMAKE_INCLUDE_SYSTEM_FLAG_C_STRIPPED) > > + set(CUDA_NVCC_INCLUDE_ARGS ${CUDA_NVCC_INCLUDE_ARGS_USER} > ${CMAKE_INCLUDE_SYSTEM_FLAG_C_STRIPPED} ${CUDA_INCLUDE_DIRS}) > > I don't think CMAKE_INCLUDE_SYSTEM_FLAG_C is the proper flag: > > - It may not be set if C is not enabled > - It may not be set if the current compiler has no such flag > - It specifies a flag for the current "real" compiler, not for nvcc > > Does nvcc support -isystem on all platforms such that we could > just hard-code using the flag? > > Thanks, > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Mar 30 11:15:13 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 30 Mar 2015 11:15:13 -0400 Subject: [cmake-developers] A CMAKE_EMULATOR variable In-Reply-To: References: <54F73A15.7070306@kitware.com> <54F86D63.8040709@kitware.com> Message-ID: <55196881.3020007@kitware.com> On 03/29/2015 09:32 PM, Matt McCormick wrote: > That sounds cool. I have implemented it in the emulator-property branch [1]. > > The variable name that defines the default for the > CROSSCOMPILING_EMULATOR property is CMAKE_CROSSCOMPILING_EMULATOR. Thanks. That looks pretty good, but needs some tweaking: In each place that you ExpandListArgument to get the emulator command and arguments and write them out before an executable name, you need to be sure to make the proper call to escape each argument. In each case the code just below your hunk does this for the test arguments. The Tests/RunCMake/pseudo_emulator.cxx tool must be able to compile with any of the compilers we test, not just those that host the build of CMake. It will be more portable to use a .c file with and printf. Also, please make it print out each argument in quotes so one could match expected output in the future. > +RunCMake_TEST:STRING=AddTest Why is this needed in InitialCache.cmake? Thanks, -Brad From Anton.Makeev at jetbrains.com Mon Mar 30 12:51:22 2015 From: Anton.Makeev at jetbrains.com (Anton Makeev) Date: Mon, 30 Mar 2015 18:51:22 +0200 Subject: [cmake-developers] Generating buildsystem metadata from CMake In-Reply-To: References: Message-ID: <16D006E0-B286-4689-99CE-80476181DD92@jetbrains.com> > On 21 Mar 2015, at 09:41, Stephen Kelly wrote: > > Anton Makeev wrote: > >> The other thing that seems troubling to me is that since file, target, >> language compiler options are split into different parts of metadata, the >> IDE need to know exactly how to assemble them back into the compiler?s >> command line (e.g. what flags go first file?s or language?s), duplicating >> CMake's logic that may be different from version to version and from >> compiler to compiler. The exact command line is needed to get the actual >> and precise defines, include search paths etc. from the compiler. > > Yes. I previously proposed the _compile_command to contain information > about how to built it: > > http://www.steveire.com/cmake-future/manual/cmake-metadata-generation.7.html#optional-properties Thanks for pointing, I missed the purpose of that property. If we are after a compact form, this should work, I guess. > However, I think it might be better to generate something similar to what is > currently generated in compile-commands.json into cmake-metadata.json. That > is, we would generate (in some context) > > "include_directories" : ["/foo", "/opt"] > "compile_definitions" : ["DEF=\"Foo\"", "OTHER_DEF=1"] > "compile_command": "-c -DDEF=\"Foo\" -DOTHER_DEF=1 -I/foo -I/opt" > > So, "compile_command" contains approximately what you can currently get from > compile-commands.json. > > The other properties contain things which are specifically known to be > include directories or compile definitions, as javascript arrays. These > properties are obviously redundant information, so I wonder if they should > be generated at all? Is the compile command I wrote above easy to parse? Or > is it sufficiently difficult to parse that this redundant information should > be provided? Agree, I don?t see any point in having this redundant info. I?d better not have it to avoid confusion: the include_directories lists is incomplete (it doesn?t contain compiler-defined search paths) and should not be used for any purpose. >> This would be really helpful indeed, currently, we have to introspect >> CMakeLists.txt files in order to find the most probably place where new >> files should be placed (works only in basic cases now). And being able to >> do so correctly is also crucial for refactoring (e.g. extract class). > > Given the backtrace, you can navigate up the scope from the most recent > frame to get out of any functions, macros or loops. You can then add a > target_sources() line directly after that. > > That algorithm will work for every case (not just basic cases) as far as I > can tell and is available with CMake 3.1. OK, it?s definitely better than nothing, so we can start with the target backtraces. >>> * I didn't document the location or directory. I'm not clear on whether >>> it is supposed to be the build location, or the install location(s!), >>> or all of those. >> >> It would be useful, though, to have a location of generated files for each >> target: in case metadata misses some information (and I think it won?t >> cover every possible need anytime soon), IDE will be able to get if from >> generated makefiles. > > Yes, we can at least provide the build location in an obvious way. We can > discuss install locations eventually. OK >>> * I don't generate 'dependencies' (actually the list of files which the >>> buildsystem re-generation depends on) as Aleix did, because there is no >>> well-defined usefulness for that list yet. >> >> As Tobias pointed, we at least need to know what files are the part of >> CMake project, that is, the list of all CMakeLists.txt and *.cmake files, >> used for generation (ideally, including missing ones, since in that case >> IDE could be able to tell when missing file is created and refresh the >> project) > > As I wrote to Tobias, I'm apprehensive about this, and it would require > other work to make cmake parallel safe first. > > I think if the IDE does not have focus it should not be running 'cmake .' on > my behalf. I think if the IDE newly gets focus you can maybe run 'cmake .' > at *that* point (after the user is done with their rebase or whatever). That > doesn't require giving you a list of files to watch. Maybe I'm missing > something though. Agree, the IDE should not do any automatic stuff, when user doesn?t expect it. Though, the use-case here is quite different: Consider a project that have 'add_directory(missing_dir)? in one of the CMakeLists files. If IDE were aware that missing_dir/CMakeLists.txt is a required file, it might then automatically trigger update, when the user creates this file inside the IDE (not externally). Or it may even have a quick-fix ?Create missing CMakeList.txt?. Also, files updated and created during VCS (called from the IDE) should be automatically recognized, of course. >>> * Some more information from project() may be relevant, but it's not >>> clear >>> yet. We will likely know more when we have decided the file format and >>> generated some 'interesting' metadata files. >> >> Project name, list of the configurations are most needed ones. >> We also use CMAKE__SOURCEFILE_EXTENSIONS to determine if a given >> file is potentially source file or not. > > As CMake already knows which files are 'object sources', the metadata will > provide that. Also, the extensions is not enough. See the unit test I > created and in particular the compiled_as_cxx.c file. For the existing files we indeed have all the necessary info in the proposed format. Though, it?s about newly-created files: when a user creates a new file ?foo.zxy', IDE should decide, wether to add it (or suggest to) to a target or not. The list of source files extensions is what may help here. >> This has already been discussed but I give our usage scenario: >> >> in CLion we retrieve the list of all build types (aka configurations, >> Debug, Release etc) > > From where do you currently retrieve this list? I guess you look at all > cache keys named > > CMAKE_.*_FLAGS_(.*) > > and list the matches? > and list the matches? It comes from CMAKE_CONFIGURATION_TYPES, if project defined such a variable. With default of Debug/Release/RelWithDebInfo/MinSizeRel >> and then generate project using Makefiles generator >> for each of them. This is necessary because of several reasons: 1) To be >> able to correctly build language model, we need to know, when a file is >> used in several configurations, which means, it's compiler settings and >> macros are different. >> E.g. some branches of code may not be available in Debug or Release >> and we give user an option to quickly switch between them in the >> editor. > > This seems similar to what Tobias talked about. > >> I don?t know if it?s possible at all, but it would be great if we could >> have info for all configurations generated in one go (not only for >> multi-config, but for single-config generators as well like Ninja and >> Makefiles). > > I can think of two ways to make that possible: > > 1) Create new mulit-config generators, or add options for the existing ones. > 2) Add a generic multi-configuration mode to cmake: > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10873/focus=10912 > http://public.kitware.com/Bug/view.php?id=14539 > > I consider both out of scope for this thread though. Agree, and thanks for opening the discussion. >>> * Generating metadata only (without generating buildsystem files) is not >>> currently in scope. This was requested several times, but it is not >>> clear why. >> >> It?s simply to be able to get this the information as quickly as possible. >> I?m not sure which part is most slow, but, say, InsightToolKit 4.5 >> (http://www.itk.org/Wiki/ITK/Source ), >> generates in couple of minutes. > > CMake has a 'configure' step followed by a 'generate step'. Your count of > minutes must be the sum of both. The information determined during those > steps is exactly what the metadata file should contain. Avoiding all of it > would leave you with no metadata. I see, you?re most likely right. Anyway, optimization is out of scope, I just wanted to clarify why this could be desirable. >> The regeneration, even when nothing was >> changes, a few dozens of seconds. > > This cost is mostly the 'generation step', as everything from the 'configure > step' was cached and available for re-generation. > >> Plus, we?d prefer being able to open the project without any questions to >> user, e.g. not asking, which generator he/she prefers. If we generate >> using ?wrong? default generator we?ll need to regenerate everything again >> when user decides to change it. > > It seems like you can use a throwaway temp directory until the user chooses > a generator. I am sympathetic to the idea of 'not breaking the users flow', > but I don't currently have any idea how to avoid it. > > Everything does indeed have to be re-generated if the generator is changed, > and cmake currently issues an error if you use a different -G option than > was originally used in a build dir. If you really want to change that > behavior, I suggest a separate bug report to track the idea. As I said I am > sympathetic to the idea, but I don't see a way. If you file a bug, maybe > Brad will have an idea or can say it's fundamentally out of scope. > >> Another benefit of skipping actual generation is possibly better error >> recoverability. That is, some generators may fail here and there if the >> project is incorrectly configured (e.g. source files are missing). >> Skipping the generation phase will (probably) help getting the project >> metadata even in that case. > > I don't think that's the case. The 'generate step' is the point where the > metadata is generated, and that step begins strictly after the 'configure > step' ends. The scenario you describe is errors during the 'configure step'. > That means no metadata for you. > > If this is possible to change, it's out of scope of this current design > work. I'd suggest a separate bug report. OK, let?s put aside this part for now. > >> But anyway, it seems a little outside of the scope of the discussion. > > Yep :). > > Thanks, > > Steve. > Regards, Anton Makeev JetBrains http://www.jetbrains.com "Develop with pleasure!" -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2856 bytes Desc: not available URL: From Anton.Makeev at jetbrains.com Mon Mar 30 13:04:10 2015 From: Anton.Makeev at jetbrains.com (Anton Makeev) Date: Mon, 30 Mar 2015 19:04:10 +0200 Subject: [cmake-developers] Generating buildsystem metadata from CMake In-Reply-To: References: Message-ID: <8C743887-8366-4A9E-A433-637F726746CB@jetbrains.com> > On 24 Mar 2015, at 00:54, Stephen Kelly wrote: > > Tobias Hunger wrote: >> >> How about include_directories, compile_definitions and compile_flags? >> >> So something along the lines of: >> >> "include_directories" : ["/foo", "/opt"] >> "compile_definitions" : ["DEF=\"Foo\"", "OTHER_DEF=1"] >> "compile_flags": [ "-c" ] > > Quoting Anton: > > Anton Makeev wrote: >> The other thing that seems troubling to me is that since file, target, >> language compiler options are split into different parts of metadata, the >> IDE need to know exactly how to assemble them back into the compiler?s >> command line (e.g. what flags go first file?s or language?s), duplicating >> CMake's logic that may be different from version to version and from >> compiler to compiler. The exact command line is needed to get the actual >> and precise defines, include search paths etc. from the compiler. > > Maybe he can chime in with more. I don't really know why the entire command > line is needed instead of separate "include_directories" and > "compile_definitions" arrays as you and I suggested. Perhaps because that > would not include -fPIC for example, which causes __PIC__ to be defined. > > Another item of note is that CMake does not know the compile flags as a > sequential container of individual flags currently, but it knows them as a > string (that's also why it appears as a string in my generated json > currently). The problem with the following format: --- "include_directories" : ["/foo", "/opt"] "compile_definitions" : ["DEF=\"Foo\"", "OTHER_DEF=1"] "compile_flags": [ "-c" ] ? Is that it?s incomplete and cannot be used directly: * include directories list misses compiler-defined search paths * quote include directories are not distinguishable * compiler definition do not include compiler-defined(built-in) definitions etc. That is, to have the complete list of include directories and compiler definitions, the IDE will have to call the compiler anyways. And here is where it will need the actual compiler?s command line. Should we had the full list of include directories (split into groups like: <>, quote, and frameworks) and the list of all compiler defines, we would not need the compiler command-line at all. (It?s actually not completely true, since we?ll need to call the compiler with the correct command-line to get some more info like specific compiler features, but I guess CMake could do it instead of the IDE). Though I don?t this it?s a way to go for CMake generation, since the compiler should be called for every unique command-line flags and undoubtedly make generation way longer. That?s why I think it?s up to the IDE to (lazily) call the compiler when this information is necessary. Does it make sense or maybe I?m missing something? >> Parsing things is always error prone. Is that -D for definitions or /D? > > As we can define the format, we could always generate -D and define that as > the answer to your question. > > Anyway, let's see if Anton can explain more about the need for the exact > command line and whether my suggestion of duplicating the > "include_directories" and "compile_definitions" is fine. > >> The compiler flags are definitely needed though. They are used to e.g. >> decide which dialect of a language are used. >> >> This would keep parsing simple and will also provide all the >> information we need. >> >> "linker_flags" might also be interesting... > > Yes, something like this is also in the goals for this design. > > Thanks, > > Steve. Anton Makeev JetBrains http://www.jetbrains.com "Develop with pleasure!" -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2856 bytes Desc: not available URL: From brad.king at kitware.com Mon Mar 30 14:26:55 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 30 Mar 2015 14:26:55 -0400 Subject: [cmake-developers] Fortran support for Ninja generator In-Reply-To: <5515AD9A.5060608@kitware.com> References: <20150324090834.GB977@lenovo> <55118104.8000005@kitware.com> <20150325133700.GE922@lenovo> <1816523.OBNj1KdstS@tuxedo.neundorf.net> <55140145.4050508@kitware.com> <5515AD9A.5060608@kitware.com> Message-ID: <5519956F.9040405@kitware.com> On 03/27/2015 03:20 PM, Brad King wrote: > I've drafted the attached document in Markdown to make it easy to paste > into a Github issue or comment for discussion with Ninja upstream. > > Review on our side should be about whether the proposal is sufficient I've updated the "Automatic Module Dependencies" to split the `scan` tool execution out into its own step. The depgen file needs to be an output of a rule so it can be regenerated if it is deleted. -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: ninja-and-fortran.md Type: text/x-markdown Size: 8189 bytes Desc: not available URL: From neundorf at kde.org Mon Mar 30 15:21:42 2015 From: neundorf at kde.org (Alexander Neundorf) Date: Mon, 30 Mar 2015 21:21:42 +0200 Subject: [cmake-developers] Generating buildsystem metadata from CMake In-Reply-To: <8C743887-8366-4A9E-A433-637F726746CB@jetbrains.com> References: <8C743887-8366-4A9E-A433-637F726746CB@jetbrains.com> Message-ID: <1494746.jQc7OTaO4E@tuxedo.neundorf.net> On Monday, March 30, 2015 19:04:10 Anton Makeev wrote: > > On 24 Mar 2015, at 00:54, Stephen Kelly wrote: > > > > Tobias Hunger wrote: > >> How about include_directories, compile_definitions and compile_flags? > >> > >> So something along the lines of: > >> > >> "include_directories" : ["/foo", "/opt"] > >> "compile_definitions" : ["DEF=\"Foo\"", "OTHER_DEF=1"] > >> "compile_flags": [ "-c" ] > > > > Quoting Anton: > > > > Anton Makeev wrote: > >> The other thing that seems troubling to me is that since file, target, > >> language compiler options are split into different parts of metadata, the > >> IDE need to know exactly how to assemble them back into the compiler?s > >> command line (e.g. what flags go first file?s or language?s), duplicating > >> CMake's logic that may be different from version to version and from > >> compiler to compiler. The exact command line is needed to get the actual > >> and precise defines, include search paths etc. from the compiler. > > > > Maybe he can chime in with more. I don't really know why the entire > > command > > line is needed instead of separate "include_directories" and > > "compile_definitions" arrays as you and I suggested. Perhaps because that > > would not include -fPIC for example, which causes __PIC__ to be defined. > > > > Another item of note is that CMake does not know the compile flags as a > > sequential container of individual flags currently, but it knows them as a > > string (that's also why it appears as a string in my generated json > > currently). > > The problem with the following format: > --- > "include_directories" : ["/foo", "/opt"] > "compile_definitions" : ["DEF=\"Foo\"", "OTHER_DEF=1"] > "compile_flags": [ "-c" ] > ? > Is that it?s incomplete and cannot be used directly: > * include directories list misses compiler-defined search paths > * quote include directories are not distinguishable > * compiler definition do not include compiler-defined(built-in) definitions > etc. Code for detecting the built-in include dirs and definitions is in CMakeExtraGeneratorDetermineCompilerMacrosAndIncludeDirs.cmake. This is used currently by CMakeFindCodeBlocks.cmake and CMakeFindEclipseCDT4.cmake, i.e. the respective extra-generators, and the information is generated into the eclipse/codeblocks project files. This could be used here too. I don't really understand your second point. Can you elaborate ? Alex P.S. Actually I still fail to understand why this generic json generator will be implemented differently then the other extra-generators. Those could also be changed to be variable-activated, instead of generator-activated, if this is preferred. Without checking the code, I don't think there is a technical reason not to do this. From Anton.Makeev at jetbrains.com Mon Mar 30 16:19:24 2015 From: Anton.Makeev at jetbrains.com (Anton Makeev) Date: Mon, 30 Mar 2015 22:19:24 +0200 Subject: [cmake-developers] Generating buildsystem metadata from CMake In-Reply-To: <1494746.jQc7OTaO4E@tuxedo.neundorf.net> References: <8C743887-8366-4A9E-A433-637F726746CB@jetbrains.com> <1494746.jQc7OTaO4E@tuxedo.neundorf.net> Message-ID: <6555910E-91AC-4C17-98A8-AF8AB29E862C@jetbrains.com> > On 30 Mar 2015, at 21:21, Alexander Neundorf wrote: > > On Monday, March 30, 2015 19:04:10 Anton Makeev wrote: >>> On 24 Mar 2015, at 00:54, Stephen Kelly wrote: >>> >>> Tobias Hunger wrote: >>>> How about include_directories, compile_definitions and compile_flags? >>>> >>>> So something along the lines of: >>>> >>>> "include_directories" : ["/foo", "/opt"] >>>> "compile_definitions" : ["DEF=\"Foo\"", "OTHER_DEF=1"] >>>> "compile_flags": [ "-c" ] >>> >>> Quoting Anton: >>> >>> Anton Makeev wrote: >>>> The other thing that seems troubling to me is that since file, target, >>>> language compiler options are split into different parts of metadata, the >>>> IDE need to know exactly how to assemble them back into the compiler?s >>>> command line (e.g. what flags go first file?s or language?s), duplicating >>>> CMake's logic that may be different from version to version and from >>>> compiler to compiler. The exact command line is needed to get the actual >>>> and precise defines, include search paths etc. from the compiler. >>> >>> Maybe he can chime in with more. I don't really know why the entire >>> command >>> line is needed instead of separate "include_directories" and >>> "compile_definitions" arrays as you and I suggested. Perhaps because that >>> would not include -fPIC for example, which causes __PIC__ to be defined. >>> >>> Another item of note is that CMake does not know the compile flags as a >>> sequential container of individual flags currently, but it knows them as a >>> string (that's also why it appears as a string in my generated json >>> currently). >> >> The problem with the following format: >> --- >> "include_directories" : ["/foo", "/opt"] >> "compile_definitions" : ["DEF=\"Foo\"", "OTHER_DEF=1"] >> "compile_flags": [ "-c" ] >> ? >> Is that it?s incomplete and cannot be used directly: >> * include directories list misses compiler-defined search paths >> * quote include directories are not distinguishable >> * compiler definition do not include compiler-defined(built-in) definitions >> etc. > > > Code for detecting the built-in include dirs and definitions is in > CMakeExtraGeneratorDetermineCompilerMacrosAndIncludeDirs.cmake. This is used > currently by CMakeFindCodeBlocks.cmake and CMakeFindEclipseCDT4.cmake, i.e. > the respective extra-generators, and the information is generated into the > eclipse/codeblocks project files. > This could be used here too. > > I don't really understand your second point. Can you elaborate ? Sure, 'some compilers? distinguish between ?include? and search paths, gcc has -iquote and -I- parameters to specify ?include? search path: https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html Distinguishing them is necessary to correctly resolve headers inside the IDE. Additionally, there is frameworks search paths (os OS X), and it?s very important to differentiate them as well. Here is clang? list just for the reference: --- #include "..." search starts here: #include <...> search starts here: /Applications/Dev/Xcode-6.2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0/include /Applications/Dev/Xcode-6.2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include /usr/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) --- Cheers, Anton Makeev JetBrains http://www.jetbrains.com "Develop with pleasure!" -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2856 bytes Desc: not available URL: From mantis at public.kitware.com Mon Mar 30 16:34:57 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 30 Mar 2015 16:34:57 -0400 Subject: [cmake-developers] [CMake 0015482]: CUDA - Support Static Linked Binaries. Message-ID: <2e93b48954cfa0f0487ecea68f91a1de@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15482 ====================================================================== Reported By: Curtis Mahieu Assigned To: ====================================================================== Project: CMake Issue ID: 15482 Category: CMake Reproducibility: have not tried Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-30 16:34 EDT Last Modified: 2015-03-30 16:34 EDT ====================================================================== Summary: CUDA - Support Static Linked Binaries. Description: currently FindCUDA searches for "cudart" and other CUDA equivalent libraries. These find the dynamic versions of the files, as they are named libcudart.so libcudart.dylib.... etc. It seems to be impossible to compile with the static files named "libcudart_static.a" ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-30 16:34 Curtis Mahieu New Issue ====================================================================== From tobias.hunger at gmail.com Mon Mar 30 19:20:15 2015 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Tue, 31 Mar 2015 01:20:15 +0200 Subject: [cmake-developers] Generating buildsystem metadata from CMake In-Reply-To: <8C743887-8366-4A9E-A433-637F726746CB@jetbrains.com> References: <8C743887-8366-4A9E-A433-637F726746CB@jetbrains.com> Message-ID: On Mon, Mar 30, 2015 at 7:04 PM, Anton Makeev wrote: >> Another item of note is that CMake does not know the compile flags as a >> sequential container of individual flags currently, but it knows them as a >> string (that's also why it appears as a string in my generated json >> currently). > > The problem with the following format: > --- > "include_directories" : ["/foo", "/opt"] > "compile_definitions" : ["DEF=\"Foo\"", "OTHER_DEF=1"] > "compile_flags": [ "-c" ] > ? > Is that it?s incomplete and cannot be used directly: > * include directories list misses compiler-defined search paths > * quote include directories are not distinguishable > * compiler definition do not include compiler-defined(built-in) definitions > etc. > > That is, to have the complete list of include directories and compiler definitions, the IDE will have to call the compiler anyways. > And here is where it will need the actual compiler?s command line. Oh, yes, we do need the path to the compiler to be run, too. I think we can combine the include_directories, compile definitions and flags ourselves though when that is needed for us to run the compiler. I do not see the need to have the full command line that would be run for each and every file, which is how I read "full compiler command line". > Should we had the full list of include directories (split into groups like: <>, quote, and frameworks) and the list of all compiler defines, we would not need the compiler command-line at all. We need the compiler binary anyway:-) Best Regards, Tobias From mantis at public.kitware.com Tue Mar 31 09:40:44 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 31 Mar 2015 09:40:44 -0400 Subject: [cmake-developers] [CMake 0015483]: CMAKE_MAKE_PROGRAM not managed correctly with CMake/CPack Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15483 ====================================================================== Reported By: marc.chevrier Assigned To: ====================================================================== Project: CMake Issue ID: 15483 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-31 09:40 EDT Last Modified: 2015-03-31 09:40 EDT ====================================================================== Summary: CMAKE_MAKE_PROGRAM not managed correctly with CMake/CPack Description: CMAKE_MAKE_PROGRAM is not propagated from CMake to CPack so preventing correct behavior if CMAKE_MAKE_PROGRAM refers to a program not the PATH This problem does not occur with all generators but is perfectly reproductible with "NMake Makefiles JOM" Steps to Reproduce: * jom.exe directory MUST NOT in PATH environment variable * generation step: cmake -G "NMake Makefiles JOM" -DCMAKE_MAKE_PROGRAM= * launch compilation: cmake --build . --target package Result: jom 1.0.14 - empower your cores Run CPack packaging tool... CPack: Create package using TGZ CPack: Install projects CPack: - Run preinstall target for: CMAKE_CPACK_BUG CPack Error: Problem running install command: "jom" "preinstall" Please check D:/tests/cmake/build/_CPack_Packages/win64/TGZ/PreinstallOutput.log for errors CPack Error: Error when generating package: CMAKE_CPACK_BUG jom: D:\tests\cmake\build\Makefile [package] Error 1 Additional Information: attached is the CMakeLists.txt used to show problem. I try to add to CPackConfig.cmake to set variable CPACK_CMAKE_MAKE_PROGRAM with correct value but problem is not solved. Correct behavior expected : CMake/CPack must managed correctly and automatically variable CMAKE_MAKE_PROGRAM. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-31 09:40 marc.chevrier New Issue 2015-03-31 09:40 marc.chevrier File Added: CMakeLists.txt ====================================================================== From ahovda at openit.com Tue Mar 31 09:42:14 2015 From: ahovda at openit.com (=?UTF-8?B?w4VkbmUgSG92ZGE=?=) Date: Tue, 31 Mar 2015 15:42:14 +0200 Subject: [cmake-developers] Patch: cmjsoncpp - missing isfinite on AIX 5.1 and HP-UX 11.23 Message-ID: Hi Applying the attached patch fixes compilation with GCC on AIX 5.1 and HP-UX for me. ?dne -------------- next part -------------- From 4ab1acefaf065d0b647b0530ffcabc51ea177a5d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C3=85dne=20Hovda?= Date: Mon, 30 Mar 2015 21:32:25 +0200 Subject: [PATCH] Use finite() for AIX and HP-UX in case we have no isfinite() --- Utilities/cmjsoncpp/src/lib_json/json_writer.cpp | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/Utilities/cmjsoncpp/src/lib_json/json_writer.cpp b/Utilities/cmjsoncpp/src/lib_json/json_writer.cpp index 7f8e6f1..82e1319 100644 --- a/Utilities/cmjsoncpp/src/lib_json/json_writer.cpp +++ b/Utilities/cmjsoncpp/src/lib_json/json_writer.cpp @@ -27,6 +27,11 @@ # define isfinite finite #endif +// AIX / HP-UX +#if ( defined(_AIX) || defined(__hpux) ) && !defined(isfinite) +# define isfinite finite +#endif + // Ancient glibc #if defined(__GLIBC__) && __GLIBC__ == 2 && __GLIBC_MINOR__ < 2 # if !defined(isfinite) -- 2.0.0 From brad.king at kitware.com Tue Mar 31 10:13:54 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 31 Mar 2015 10:13:54 -0400 Subject: [cmake-developers] Patch: cmjsoncpp - missing isfinite on AIX 5.1 and HP-UX 11.23 In-Reply-To: References: Message-ID: <551AABA2.4060501@kitware.com> On 03/31/2015 09:42 AM, ?dne Hovda wrote: > Applying the attached patch fixes compilation with GCC on AIX 5.1 and > HP-UX for me. Thanks. What compiler versions are you using? What architectures? Would you be able to run nightly testing? Instructions are here: http://www.cmake.org/Wiki/CMake/Git/Dashboard Currently we have nightly testing for: * AIX 7.1 with GNU 4.8.1 compiler * AIX 7.1 with XL 12.1.0 compiler * HP-UX B.11.23 ia64 with HP 6.25.0 compiler * HP-UX B.11.31 ia64 with HP 6.25.0 compiler and they all build cleanly without this patch. Can you add some kind of version or architecture preprocessor test? Or, do we know if the "defined(isfinite)" condition will be true on the above systems? Thanks, -Brad From mantis at public.kitware.com Tue Mar 31 12:07:57 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 31 Mar 2015 12:07:57 -0400 Subject: [cmake-developers] [CMake 0015485]: CFBundleExecutable path in a bundle should not be a relative path into bundle Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15485 ====================================================================== Reported By: Daniel Dunbar Assigned To: ====================================================================== Project: CMake Issue ID: 15485 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-31 12:07 EDT Last Modified: 2015-03-31 12:07 EDT ====================================================================== Summary: CFBundleExecutable path in a bundle should not be a relative path into bundle Description: The CFBundleExecutable path inside of a CMake generated bundle is a relative path including the bundle name itself. This is not correct, it should simply be the name of the bundle binary that is inside the MacOS directory: In this example: -- $ cat CMakeLists.txt cmake_minimum_required(VERSION 3.2) add_library(Bar MODULE Bar.c) set_target_properties(Bar PROPERTIES BUNDLE true) $ touch Bar.c $ cmake -G Ninja . ... $ ninja [1/2] Building C object CMakeFiles/Bar.dir/Bar.c.o [2/2] Linking C CFBundle shared module Bar.bundle/Contents/MacOS/Bar $ defaults read $(pwd)/Bar.bundle/Contents/Info.plist CFBundleExecutable Bar.bundle/Contents/MacOS/Bar $ -- the last line should just print "Bar". You can verify this is not what the platform expects by trying to load the bundle from somewhere else: -- $ cat load.m #import int main(int argc, char **argv) { @autoreleasepool { NSBundle *bundle = [NSBundle bundleWithPath:[[NSString alloc] initWithUTF8String:argv[1]]]; [bundle load]; } return 0; } $ clang load.m -o load -framework Foundation && ./load Bar.bundle 2015-03-31 09:07:24.778 load[95727:5952049] Cannot find executable for CFBundle 0x7fc292d13ac0 (not loaded) -- whereas this will load fine if the CFBundleExecutable key is just "Bar". ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-31 12:07 Daniel Dunbar New Issue ====================================================================== From Geoffrey.Viola at asirobots.com Tue Mar 31 12:43:44 2015 From: Geoffrey.Viola at asirobots.com (Geoffrey Viola) Date: Tue, 31 Mar 2015 16:43:44 +0000 Subject: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support In-Reply-To: <551955F5.2010307@kitware.com> References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com> <5501F487.10807@kitware.com> <550886E2.1020708@kitware.com> <55101CE3.9000603@kitware.com> <551188C9.9070104@kitware.com> <5511A63C.2000806@kitware.com> <5512CAF5.2030908@kitware.com> <5512D6C3.7090000@kitware.com> <55140601.7070804@kitware.com> <551454F4.6060304@kitware.com> <551955F5.2010307@kitware.com> Message-ID: > Instead, please look at using GetCompRoot in FindGhsBuildCommand. Thanks for the tip. That was an easy fix. Attached is the new patch. It passed the tests: https://open.cdash.org/buildSummary.php?buildid=3751365. I think the issue where the tests seemed to have passed was that my test script CTEST_SOURCE_DIRECTORY and CTEST_BINARY_DIRECTORY were set to an old git checkout. >> also support for the rest of the standard CMAKE_BUILD_TYPE values > > For all other generators and toolchains, the place we put the config-specific flags is in the CMAKE__FLAGS_ cache entries. These values are typically initialized in the > > Modules/Compiler/-.cmake > > modules. In this case, I think it would be: > > Modules/Compiler/GHS-C.cmake > Modules/Compiler/GHS-CXX.cmake > > modules. See Modules/Compiler/Intel-*.cmake for an example. > Then make sure the generator reads the flag values for the current configuration and uses them. I added the files in the patch and noted them being read, but I haven't figured out the best way to extract the flags. In the Modules/Compiler/Intel-C.cmake file CMAKE_C_CREATE_PREPROCESSED_SOURCE and CMAKE_C_CREATE_ASSEMBLY_SOURCE are set, but I wasn't sure what they did so I deleted them. Geoffrey Viola SOFTWARE ENGINEER asirobots.com -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Monday, March 30, 2015 7:56 AM To: Geoffrey Viola Cc: cmake-developers at cmake.org Subject: Re: FW: FW: [cmake-developers] Initial Attempt at Green Hill MULTI IDE Generator Support On 03/30/2015 12:49 AM, Geoffrey Viola wrote: > cmGlobalGhsMultiGenerator::FindMakeProgram uses the definition, > "GHS_COMP_ROOT," to find gbuild. Thanks. However, I don't think that approach will work. At the point where GenerateBuildCommand is called in the case that is failing, EnableLanguage has never been run because it is not a real configuration. One giveaway of this problem is this hunk: > - this->SelectMakeProgram(makeProgram, this->GetGhsBuildCommand()) > - ); > + this->SelectMakeProgram(makeProgram, this->GhsBuildCommand) ); which I presume had to be done because no "mf" is available. However, at this point in the code nothing will have populated the GhsBuildCommand member. That's why it needs the call. Instead, please look at using GetCompRoot in FindGhsBuildCommand. > also support for the rest of the standard CMAKE_BUILD_TYPE values For all other generators and toolchains, the place we put the config-specific flags is in the CMAKE__FLAGS_ cache entries. These values are typically initialized in the Modules/Compiler/-.cmake modules. In this case, I think it would be: Modules/Compiler/GHS-C.cmake Modules/Compiler/GHS-CXX.cmake modules. See Modules/Compiler/Intel-*.cmake for an example. Then make sure the generator reads the flag values for the current configuration and uses them. Thanks, -Brad This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fixed-tests-by-finding-make-program-when-cleaning.patch Type: application/octet-stream Size: 5886 bytes Desc: 0001-Fixed-tests-by-finding-make-program-when-cleaning.patch URL: From brad.king at kitware.com Tue Mar 31 13:16:25 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 31 Mar 2015 13:16:25 -0400 Subject: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support In-Reply-To: References: <0543633b28c7431f93808182fc1e26e1@CO1PR07MB208.namprd07.prod.outlook.com> <550886E2.1020708@kitware.com> <55101CE3.9000603@kitware.com> <551188C9.9070104@kitware.com> <5511A63C.2000806@kitware.com> <5512CAF5.2030908@kitware.com> <5512D6C3.7090000@kitware.com> <55140601.7070804@kitware.com> <551454F4.6060304@kitware.com> <551955F5.2010307@kitware.com> Message-ID: <551AD669.2080905@kitware.com> On 03/31/2015 12:43 PM, Geoffrey Viola wrote: >> Instead, please look at using GetCompRoot in FindGhsBuildCommand. > > Thanks for the tip. That was an easy fix. Attached is the new patch. I've added that to the topic: GHS: Fix tests by finding make program when cleaning http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=79fe11f1 >> modules. See Modules/Compiler/Intel-*.cmake for an example. >> Then make sure the generator reads the flag values for the current >> configuration and uses them. > > I added the files in the patch and noted them being read, but > I haven't figured out the best way to extract the flags. I've added that part to the topic: GHS: Initialize CMAKE__FLAGS[_] http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ff7ecb92 I left out the hard-coded flag updates to the generator because it should be replaced by using these flag variables anyway. The language/config flag cache entries and all the other places that CMake supports adding flags are all collected together by the generators. See cmVisualStudio10TargetGenerator::ComputeClOptions cmMakefileTargetGenerator::GetFlags cmMakefileTargetGenerator::GetDefines cmNinjaTargetGenerator::ComputeDefines cmNinjaTargetGenerator::ComputeFlagsForObject for some examples. This generator needs to do that too. > In the Modules/Compiler/Intel-C.cmake file CMAKE_C_CREATE_PREPROCESSED_SOURCE > and CMAKE_C_CREATE_ASSEMBLY_SOURCE are set, but I wasn't sure what they did > so I deleted them. Correct. Thanks, -Brad From mantis at public.kitware.com Tue Mar 31 13:28:52 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 31 Mar 2015 13:28:52 -0400 Subject: [cmake-developers] [CMake 0015486]: CPackRPM - Move Component handling into .spec file Message-ID: <7f6fc0bab217ae48970b4ddad8dff483@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15486 ====================================================================== Reported By: Curtis Mahieu Assigned To: ====================================================================== Project: CMake Issue ID: 15486 Category: CPack Reproducibility: have not tried Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-31 13:28 EDT Last Modified: 2015-03-31 13:28 EDT ====================================================================== Summary: CPackRPM - Move Component handling into .spec file Description: I think it would make sense to move the Component logic into the spec file itself and let rpmbuild take care of the naming. if there was only one spec file generated for the entire build when Compnonents are enabled then the spec could look like this: BuildRoot: @CPACK_RPM_DIRECTORY@/@CPACK_PACKAGE_FILE_NAME@@CPACK_RPM_PACKAGE_COMPONENT_PART_PATH@ Summary: @CPACK_RPM_PACKAGE_SUMMARY@ Name: @CPACK_RPM_PACKAGE_NAME@@CPACK_RPM_PACKAGE_COMPONENT_PART_NAME@ Version: @CPACK_RPM_PACKAGE_VERSION@ Release: @CPACK_RPM_PACKAGE_RELEASE@ License: @CPACK_RPM_PACKAGE_LICENSE@ Group: @CPACK_RPM_PACKAGE_GROUP@ Vendor: @CPACK_RPM_PACKAGE_VENDOR@ ........ %description @CPACK_RPM_PACKAGE_DESCRIPTION@ ...... %package Summary: Group: %files %defattr(-,root,root,-) @CPACK_RPM_INSTALL_FILES@ %files %defattr(-, root, root, -) .... Then if the logic to specify file names could be set by a user adding a "%define _rpmfilename". Gathering all the final files could wait for all the RPM's to be generated and then scan the output folder and add them all to the final files list in the c++ code replacing this: // add the generated package to package file names list packageFileNames.push_back(packageFileName); ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-31 13:28 Curtis Mahieu New Issue ====================================================================== From brad.king at kitware.com Tue Mar 31 14:57:30 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 31 Mar 2015 14:57:30 -0400 Subject: [cmake-developers] Patch: cmjsoncpp - missing isfinite on AIX 5.1 and HP-UX 11.23 In-Reply-To: <551AABA2.4060501@kitware.com> References: <551AABA2.4060501@kitware.com> Message-ID: <551AEE1A.40607@kitware.com> On 03/31/2015 10:13 AM, Brad King wrote: > do we know if the "defined(isfinite)" condition will be true > on the above systems? We've confirmed that it is true for the newer AIX versions, so we can use the "!defined(isfinite)" check as a way to define it only on the older systems. I've revised your patch slightly and merged to 'next' for testing: jsoncpp: Provide 'isfinite' implementation on older AIX and HP-UX http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7b1cdb00 Thanks, -Brad From steveire at gmail.com Tue Mar 31 18:17:23 2015 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 01 Apr 2015 00:17:23 +0200 Subject: [cmake-developers] Generating buildsystem metadata from CMake References: <16D006E0-B286-4689-99CE-80476181DD92@jetbrains.com> Message-ID: Anton Makeev wrote: > Agree, the IDE should not do any automatic stuff, when user doesn?t expect > it. Though, the use-case here is quite different: > Consider a project that have 'add_directory(missing_dir)? in one of the > CMakeLists files. If IDE were aware that missing_dir/CMakeLists.txt is a > required file, it might then automatically trigger update, when the user > creates this file inside the IDE (not externally). Or it may even have a > quick-fix ?Create missing CMakeList.txt?. Interesting. Thanks for that description. >>> Project name, list of the configurations are most needed ones. >>> We also use CMAKE__SOURCEFILE_EXTENSIONS to determine if a given >>> file is potentially source file or not. >> >> As CMake already knows which files are 'object sources', the metadata >> will provide that. Also, the extensions is not enough. See the >> unit test I created and in particular the compiled_as_cxx.c file. > > For the existing files we indeed have all the necessary info in the > proposed format. Though, it?s about newly-created files: when a user > creates a new file ?foo.zxy', IDE should decide, > wether to add it (or suggest to) to a target or not. The list of source > files extensions is what may help here. I see. > It comes from CMAKE_CONFIGURATION_TYPES, if project defined such a > variable. With default of Debug/Release/RelWithDebInfo/MinSizeRel Ok. So does this mean you have a parser for the existing CMakeCache.txt format already? Thanks, Steve. From steveire at gmail.com Tue Mar 31 18:41:43 2015 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 01 Apr 2015 00:41:43 +0200 Subject: [cmake-developers] Generating buildsystem metadata from CMake References: <8C743887-8366-4A9E-A433-637F726746CB@jetbrains.com> Message-ID: Anton Makeev wrote: > The problem with the following format: > --- > "include_directories" : ["/foo", "/opt"] > "compile_definitions" : ["DEF=\"Foo\"", "OTHER_DEF=1"] > "compile_flags": [ "-c" ] > ? > Is that it?s incomplete and cannot be used directly: > * include directories list misses compiler-defined search paths CMake gathers those during configure time, and we can add them to the metadata too. > * quote include directories are not distinguishable CMake does not currently generate -iquote as a result of a user writing an include_directories() call. Are you asking for that as an option? That would be an independent feature request. I'd suggest filing it in the tracker. Otherwise, the only way CMake currently would pass such options to the compiler is if the user specified them in CMAKE_CXX_FLAGS or add_compile_options() or similar. CMake does not attempt to parse CMAKE_CXX_FLAGS for things which look like include directories. That variable is just an opaque string of data from the point of view of CMake. It is not clear to me whether you are suggesting that CMake should do that. If you do want to suggest that, please file an issue in the tracker. Similarly, CMake does not attempt to analyse the meaning of options specified in add_compile_options(). Again, it's not clear to me whether you are suggesting a new feature for CMake. If you are, please file it in the tracker. To avoid misunderstandings, please post snippets of CMake code together with a description of what information you want CMake to determine from the snippet and what metadata it should generate. > * compiler definition do not include compiler-defined(built-in) > definitions etc. CMake does not currently gather those during configure, as far as I know. That could be added though. > That is, to have the complete list of include directories and compiler > definitions, the IDE will have to call the compiler anyways. And here is > where it will need the actual compiler?s command line. > > Should we had the full list of include directories (split into groups > like: <>, quote, and frameworks) and the list of all compiler defines, we > would not need the compiler command-line at all. I think I understand what you're saying. However, it would help if you related what you write to existing CMake features and snippets of CMake code. I assume that you are medium-to-very familiar with CMake features already, given what you are working on? > we?ll need to call the compiler with the correct > command-line to get some more info like specific compiler features, but I > guess CMake could do it instead of the IDE). I don't know what you are refering to, but if you want CMake to record more compiler features than what it already does: http://www.cmake.org/cmake/help/v3.1/manual/cmake-compile-features.7.html then please file an issue in the tracker. The information gathered using the above feature can be added to the metadata file. > Though I don?t this it?s a > way to go for CMake generation, since the compiler should be called for > every unique command-line flags and undoubtedly make generation way > longer. It's not completely clear to me what you are suggesting here. Maybe you know something I don't know. Can you be clear about what you are suggesting CMake would have to do for each unique command line? I know you are not proposing that CMake should do it (you said the IDE should do it lazily instead), but what action are you actually talking about? What should the IDE do lazily instead of CMake doing it? Invoke the compiler to determine the compiler-defined/built-in include directories and definitions? They will always be the same, right? Or are you talking about the "-I-" GCC option here and how that clears the built-ins? Please be more specific. Thanks! Steve. From steveire at gmail.com Tue Mar 31 19:03:42 2015 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 01 Apr 2015 01:03:42 +0200 Subject: [cmake-developers] Generating buildsystem metadata from CMake References: <8C743887-8366-4A9E-A433-637F726746CB@jetbrains.com> Message-ID: Tobias Hunger wrote: > I think we can combine the include_directories, compile definitions > and flags ourselves though when that is needed for us to run the > compiler. I do not see the need to have the full command line that > would be run for each and every file, which is how I read "full > compiler command line". Ok, great. We've discussed some issues here about what the metadata file should contain, and you guys have made some proposals on specific details of what should be in the JSON. However, I think to bring this to a conclusion, you'll need to post 'structurally complete' JSON files for what you need (and what CMake is actually able to generate!), instead of suggestions on specific details. Please post some sample CMakeLists.txt files together with some corresponding sample JSON files that you propose would be generated by CMake. Please show all of the objects and properties that you propose should be in the JSON file, and in what positions. It's ok to elide things, but please make sure your proposal is clear. I think some of the suggestions that were brought up already have changed over the course of the thread, so I want to know what you guys now propose at this point. I know Tobias posted an example JSON file already, but that was too big to extract the meaning from it. Please use your knowledge of CMake features and post some interesting ones, because the interesting ones determine what the structure of the JSON needs to be to some extent. For example, here's small CMakeLists file which requires you to design something which allows a single source file to be compiled multiple times with different flags: cmake_minimum_required(VERSION 2.8) project(cmaketest) # CMake just copy-pastes this string without parsing. What should the # metadata contain? set(CMAKE_CXX_FLAGS "-I /opt/something -D INTERESTING -DANOTHER_DEFINE") add_executable(foo main.cpp) # The user specified /opt/specified/directory in the 'normal'way # for CMake. # Does that deserve special handling so that the IDE can just to the place # where the directory was specified, for example? target_include_directories(foo PRIVATE /opt/specified/directory ) target_compile_definitions(foo PRIVATE FOO_DEFINE ) add_executable(bar main.cpp) target_compile_definitions(bar PRIVATE BAR_DEFINE ) # main.cpp is compiled twice - both times with FILE_DEFINE and # -DFILE_FLAG and -DIN_OPAQUE_STRING, one time with # FOO_DEFINE and one time with BAR_DEFINE. # Run with make VERBOSE=1 to see where the defines appear on the # command line! # What should the metadata contain? set_source_files_properties(main.cpp PROPERTIES COMPILE_DEFINITIONS FILE_DEFINE COMPILE_FLAGS "-DFILE_FLAG -DIN_OPAQUE_STRING" ) Thanks, Steve.