Re: [cmake-developers] Extracting target metadata, IDE integration
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 -- 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
Re: [cmake-developers] Extracting target metadata, IDE integration
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 -- 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
Re: [cmake-developers] [PATCH 2/2] Ninja: Fix failing CMakeLib.testRST test
On 06.06.2014 16:53, Sam Spilsbury wrote: On Fri, Jun 6, 2014 at 10:49 PM, Brad King brad.k...@kitware.com wrote: On 06/06/2014 10:12 AM, Sam Spilsbury wrote: Ninja was passing a relative path to the compiler which causes __FILE__ to use that same relative path. This was causing the test to fail, because Ninja is not a recursive generator and so __FILE__ differed between generators. For the sake of consistency, an absolute path should always be passed to the compiler on each generator, so that __FILE__ is always consistent. This is a larger debate for those that develop and use the Ninja generator. For now let's just fix the test to not depend on a full path to __FILE__: Are there any threads where I can read up on background information for this? Having consistency seems like a no-brainer to me, so perhaps I missed something? This is very hairy, see here where we once already tried this: http://public.kitware.com/Bug/view.php?id=13894 Briefly reading[1], it seems like the Chromium developers are preferring consistency between generator backends. Sam. [1] https://code.google.com/p/chromium/issues/detail?id=326030 Tests: Fix CMakeLib.testRST for relative __FILE__ http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=218699eb -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/cgi-bin/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/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Default generator
Is there a way to configure the default generator for command-line cmake calls? If it's not configurable, what about reading a default from a environment variable? Peter -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja leaking localized /showIncludes(?)
On 26.11.2013 09:17, Nils Gladitz wrote: On 11/25/2013 06:31 PM, Nils Gladitz wrote: On 25.11.2013 18:21, Peter Kümmel wrote: Also this system is localized? I don't see any prefixes, e.g. here http://open.cdash.org/testDetails.php?test=220476713build=3114166 The system indeed has a german windows 7 installation. The system I ran that Experimental build on was not the same system that ran the dashboard builds. They may have been set up with different system languages (though I don't remember which used which). I ran the cmake testsuite on the original client where is saw the leaks initially (english windows 7 with german vs2010): http://open.cdash.org/viewTest.php?onlypassedbuildid=3115434 Would that be relevant? The compiler that I used on both systems was the same. Another difference would be that the dashboard build was using launchers. Could that change behavior? I disabled launchers and I can no longer see any showinclude messages in context of my build warnings. Seems the launcher breaks the ninja parser. Why are launcher needed? I never used them. On top of rules.ninja I've got: msvc_deps_prefix = Hinweis: Einlesen der Datei: Compile rule with launchers is: rule CXX_COMPILER deps = msvc command = C:/opt/cmake-git/bin/ctest.exe --launch --target-name scivis_tdng --build-dir C:\cdash\8496c13-bin --output $out --source $in --language CXX -- c:\PROGRA~2\MICROS~2.0\VC\bin\amd64\cl.exe /nologo /TP $FLAGS /showIncludes $DEFINES /Fo$out /Fd$OBJECT_DIR/ -c $in description = Building CXX object $out Without launchers: rule CXX_COMPILER deps = msvc command = c:\PROGRA~2\MICROS~2.0\VC\bin\amd64\cl.exe /nologo /TP $FLAGS /showIncludes $DEFINES /Fo$out /Fd$OBJECT_DIR/ -c $in description = Building CXX object $out Nils -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja leaking localized /showIncludes(?)
On 25.11.2013 10:34, Nils Gladitz wrote: I found output like this: Hinweis: Einlesen der Datei: c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\string Hinweis: Einlesen der Datei:c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\istream [...] In local dashboard builds with a german VS2010 installation and cmake master. The Ninja generator created an entry in rules.ninja: msvc_deps_prefix = Hinweis: Einlesen der Datei: Which I assume is meant to match and filter those lines from the rest of the compiler output. Is there something missing/incorrect on the cmake side or is this a ninja issue? The ninja version on the dashboard client is 1.4.0. 1.4.0 is too old, see here http://public.kitware.com/pipermail/cmake-developers/2013-October/008687.html Nils -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja leaking localized /showIncludes(?)
On 25.11.2013 11:54, Nils Gladitz wrote: On 11/25/2013 11:23 AM, Peter Kümmel wrote: 1.4.0 is too old, see here http://public.kitware.com/pipermail/cmake-developers/2013-October/008687.html I retried with master (7ccecee4f10036a74942ca406dcd4a7b41f291b4) but the problem seems to persist. Suspiciously enough I got the same leakage while bootstrapping ninja itself this time but they don't seem to be using msvc_deps_prefix in the build. So it does not work at all for localized VS versions? Nils -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja leaking localized /showIncludes(?)
On 25.11.2013 14:08, Nils Gladitz wrote: On 11/25/2013 12:53 PM, Nils Gladitz wrote: I'll try running the cmake testsuite to see if it breaks dependency scanning as well. There were no test failures: http://open.cdash.org/viewTest.php?onlypassedbuildid=3114166 So I assume it correctly detects the dependencies listed in those messages but does not remove the message itself from the output. Also assuming that CMake actually covers everything that can go wrong here with test cases. Nils Does rules.ninja contain msvc_deps_prefix = Hinweis: Einlesen der Datei: AND the compile rules define deps = msvc? Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja leaking localized /showIncludes(?)
On 25.11.2013 17:56, Nils Gladitz wrote: On 25.11.2013 17:53, Peter Kümmel wrote: Does rules.ninja contain msvc_deps_prefix = Hinweis: Einlesen der Datei: AND the compile rules define deps = msvc? I don't have access to the system right now but I think I saw both. Nils Also this system is localized? I don't see any prefixes, e.g. here http://open.cdash.org/testDetails.php?test=220476713build=3114166 So it seems to work. Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja pools
OK, merged a new version to next. Now the docu looks much better, thanks! On 25.11.2013 15:13, Brad King wrote: On 11/23/2013 09:04 AM, Peter Kümmel wrote: OK, I've pushed a patch which adds JOB_POOLS JOB_POOL_LINK JOB_POOL_COMPILE CMAKE_JOB_POOL_LINK CMAKE_JOB_POOL_COMPILE Great! Here are some comments. Please update the JOB_POOLS parsing to validate each entry instead of blindly passing the value through to Ninja. That will catch errors earlier and allow CMake to do something else with the values later if we want. After the find(=) then do something like unsigned int v; if(sscanf(value, =%u, v) == 1) ... The CMAKE_JOB_POOL_(COMPILE|LINK) variables should be implemented by initializing the corresponding target properties as each target is created. See cmTarget::SetMakefile calls to SetPropertyDefault for the place in the code to do this. The generator code should not have to look up the variable values directly. Please read the cmake-developer.7 manual section on the documentation cross-referencing syntax and use that to x-ref among the new variables and properties. Also in example code like: +For instance set_property(GLOBAL PROPERTY POOLS two_jobs=2;ten_jobs=10). please use a literal block, e.g. For instance:: set_property(GLOBAL PROPERTY POOLS two_jobs=2;ten_jobs=10) Note that set_property will combine multiple arguments as a ;-list anyway so the example could be:: set_property(GLOBAL PROPERTY POOLS two_jobs=2 ten_jobs=10) but without any support for custom commands because it is different to the compile/link code changes. I think it is cleaner to add an additional patch later. Agreed. It is much simpler to do just compile/link first. Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja pools
The purpose of SetPropertyDefault is to lookup the variable for you. You just need this-SetPropertyDefault(JOB_POOL_COMPILE, 0); this-SetPropertyDefault(JOB_POOL_LINK, 0); The second argument is just what to use when the variable is not set. Ah, very comfortable. I updated next. Brad -- -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja jumping progress indicator
On 11.11.2013 18:33, Matthew Woehlke wrote: On 2013-11-11 12:17, Nils Gladitz wrote: On 11.11.2013 17:38, Matthew Woehlke wrote: What else can you do? Until you re-run CMake, there is no way to know how many edges need to be executed. Even if ninja were to show the maximum possible number of edges, that could be too small e.g. because you've added a bunch of new targets since the last build. What I was hoping is that ninja could be enticed to not report its progress until cmake finished running (if it has to run). That seems reasonable to me. However it's still a ninja problem; I don't know how/if CMake would be able to affect ninja's behavior in this respect. (Alternatively, display something like 'inf' or 'unknown' as the number of remaining edges, either of which would be at least as accurate as '1'.) I recommend moving this discussion to ninja-bu...@googlegroups.com (please re-post the original problem description with the Qt Creator bug report). Will be fixed in QtCreator 3.0. Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja pools
OK, I've pushed a patch which adds JOB_POOLS JOB_POOL_LINK JOB_POOL_COMPILE CMAKE_JOB_POOL_LINK CMAKE_JOB_POOL_COMPILE but without any support for custom commands because it is different to the compile/link code changes. I think it is cleaner to add an additional patch later. Peter On 12.11.2013 16:33, Brad King wrote: On 11/09/2013 06:39 AM, Peter Kümmel wrote: On 08.11.2013 17:22, Brad King wrote: Without context the name POOL may not have clear meaning to a reader not already familiar with Ninja's feature. I think a name like JOB_POOL would be clearer. Even JOB_POOL leaves the question what a pool is. I think it would be better to completely drop pool, and to use something more obvious like PARALLEL_JOBS IMO the name JOB_POOL is clear enough. It is distinct and can be used to locate information about the feature. I would prefer to create a semantic which also fits for other generators and not to use the NINJA prefix. How could the limiting be very different for other generators? It always reduces the number of parallel processes. Maybe a property for just disabling parallel execution at all is enough. I couldn't imagine use cases where the fine-grained pool control of ninja is needed. Such a simplifies interface should also be compatible with other generators, and would be very strict, as requested. On second thought the semantics are already pretty general. If needed then future support in other generators could add restrictions like a max pool size or something. Since this is still experimental I'd rather not add an option to add_custom_command for it yet. Let's just go with global property JOB_POOLS to configure the pools, target properties JOB_POOL_LINK JOB_POOL_COMPILE JOB_POOL_CUSTOM to map rules to the pools, and variables CMAKE_JOB_POOL_LINK CMAKE_JOB_POOL_COMPILE CMAKE_JOB_POOL_CUSTOM to initialize the mapping in each target. A future option to add_custom_command could override JOB_POOL_CUSTOM but the simple default will allow projects to quickly group everything without marking up all their targets or custom commands. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja pools
On 08.11.2013 17:22, Brad King wrote: On 11/05/2013 02:15 PM, Peter Kümmel wrote: I merged a proposal to next which adds support for Ninja's pool: http://martine.github.io/ninja/manual.html#ref_pool This will be a really nice feature to support. Thanks for the detailed comments. Below some remarks. It adds three new properties, POOLS, LINK_POOL, COMPILE_POOL: http://www.cmake.org/cmake/help/git-next/manual/cmake-properties.7.html With a pool it is possible to limit the number of concurrent processes of a specific rule. Without context the name POOL may not have clear meaning to a reader not already familiar with Ninja's feature. I think a name like JOB_POOL would be clearer. Even JOB_POOL leaves the question what a pool is. I think it would be better to completely drop pool, and to use something more obvious like PARALLEL_JOBS The documentation of these properties all note that they are only for Ninja. While it is possible a future generator will also support them, it is unclear whether the semantics will be exactly the same. Therefore I prefer to use a NINJA_ prefix on the property names for now: NINJA_JOB_POOLS NINJA_JOB_POOL_LINK NINJA_JOB_POOL_COMPILE I would prefer to create a semantic which also fits for other generators and not to use the NINJA prefix. How could the limiting be very different for other generators? It always reduces the number of parallel processes. Maybe a property for just disabling parallel execution at all is enough. I couldn't imagine use cases where the fine-grained pool control of ninja is needed. Such a simplifies interface should also be compatible with other generators, and would be very strict, as requested. Peter Also look at cmTarget::SetMakefile for calls to SetPropertyDefault to see how to add variables like CMAKE_NINJA_JOB_POOL_LINK CMAKE_NINJA_JOB_POOL_COMPILE that set a default for the target properties at their creation. This will make it easy for projects to put all targets into the pools. We should also consider a way to allow users to define pools with cache entries when the projects don't. Current patch adds only the essentials, but maybe there are more comfortable ways to use pools. The patch also appears to try adding a POOL option to the add_custom_command command but does not provide documentation except in the commit message. In the final version of this topic that goes to master, I'd prefer not to have any docs or examples in the commit messages, just in the actual docs. (Again, I think the option should be named NINJA_JOB_POOL.) Should we have a NINJA_JOB_POOL_CUSTOM property that is used for custom commands within a target that do not explicitly set a job pool? It would of course come with a supporting CMAKE_NINJA_JOB_POOL_CUSTOM variable to initialize the property. This would allow projects to quickly add all their build rules to pools with just a few lines of code. Also please add error messages when the NINJA_JOB_POOLS value does not match the expected format, or when one of the other rules names a pool not on the global list. The add_custom_command option processing: + case doing_pool: + pool = copy; + break; should switch back to doing = doing_nothing so that a second value after the keyword is rejected with an error message. (Some of the other keyword options should be doing this but can't now for compatibility.) The interface should be as strict as possible when first created. It can always be relaxed in the future, but would require a policy to make it more strict. Please add RunCMake test cases that cover these error messages. Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Ninja pools
I merged a proposal to next which adds support for Ninja's pool:
http://martine.github.io/ninja/manual.html#ref_pool
It adds three new properties, POOLS, LINK_POOL, COMPILE_POOL:
http://www.cmake.org/cmake/help/git-next/manual/cmake-properties.7.html
With a pool it is possible to limit the number of concurrent
processes of a specific rule.
For instance if you have a project with multiple targets and
each target needs all your resources while linking (memory,
hard-disk bandwidth), it makes no sens to start multiple link
processes in parallel. To prevent this the pool feature was
introduced in ninja.
In concrete, with this patch:
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 25cd576..d257c97 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -21,6 +21,8 @@ if(CMAKE_BOOTSTRAP)
unset(CMAKE_BOOTSTRAP CACHE)
endif()
+set_property(GLOBAL PROPERTY POOLS compile=1)
+
if(${CMake_SOURCE_DIR} STREQUAL ${CMAKE_SOURCE_DIR})
diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index c01245c..d7c68d5 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -393,6 +393,8 @@ target_link_libraries(CMakeLib cmsys
${CMAKE_TAR_LIBRARIES} ${CMAKE_COMPRESS_LIBRARIES}
${CMAKE_CURL_LIBRARIES} )
+set_property(TARGET CMakeLib PROPERTY COMPILE_POOL compile)
+
and the current next branch, ninja builds CMakeLib single threaded,
without passing -j1 to ninja.
Current patch adds only the essentials, but maybe there are more
comfortable ways to use pools.
Peter
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja: using dependency database
On 21.10.2013 16:19, Bill Hoffman wrote: On 10/19/2013 7:09 AM, Peter Kümmel wrote: CMake now uses Ninja's database feature for dependency tracking. An empty build now takes about a third less (e.g. Clang 160ms-100ms) Therefore ninja master is needed, please update your build server. This looks like a real bug: http://open.cdash.org/testDetails.php?test=214096074build=3067806 When I revert my patch the test still fails, I have to check if why. Run Build Command:/home/kitware/Dashboards/My\ Tests/ninja/ninja [1/8] Building C object /home/kitware/Dashboards/My Tests/CMake-ninja-build/Tests/OutOfBinary/CMakeFiles/outlib.dir/outlib.c.o [2/8] Building CXX object SubDir/OutOfSourceSubdir/CMakeFiles/testlib.dir/testlib.cxx.o FAILED: /usr/bin/cc-MMD -MT /home/kitware/Dashboards/My Tests/CMake-ninja-build/Tests/OutOfBinary/CMakeFiles/outlib.dir/outlib.c.o -MF /home/kitware/Dashboards/My Tests/CMake-ninja-build/Tests/OutOfBinary/CMakeFiles/outlib.dir/outlib.c.o.d -o /home/kitware/Dashboards/My Tests/CMake-ninja-build/Tests/OutOfBinary/CMakeFiles/outlib.dir/outlib.c.o -c /home/kitware/Dashboards/My Tests/NinjaCMake/Tests/OutOfBinary/outlib.c depfile has multiple output paths. ninja: build stopped: subcommand failed. -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja: using dependency database
On 20.10.2013 17:13, David Cole wrote: Therefore ninja master is needed, please update your build server. When a particular ninja 'master' is required, it would be great if you could recommend a given snapshot by git commit rather than just saying 'master'. Especially for those of us submitting CMake dashboards using ninja, it would be very helpful to use a consistent ninja, preferably even a tag from their git repo once one becomes available that has the required features in it. For now, would you recommend a given commit? I see this one on github right now: https://github.com/martine/ninja/commit/a3c823c3da70bd46d69341f13184cdae4c77645d This commit is ok, at least 037b0934f929ba17434906fb781aeb1acb583385. Thanks, David -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ExternalProject and git clone
On 05.09.2013 14:28, Daniele E. Domenichelli wrote: I'd like to be able to modify files, commit, and push from the external git repositories, For this use case you could use submodules in git: http://git-scm.com/book/en/Git-Tools-Submodules Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ninja enforces explicit dependencies before order-only
On 02.04.2013 15:19, Brad King wrote:
Hi Peter,
We've come across a case where the Makefile, VS, and Xcode generators
work but Ninja does not::
cmake_minimum_required(VERSION 2.8.10)
project(DependSideEffect C)
add_library(A a.c)
add_custom_command(
TARGET A POST_BUILD
COMMAND cp ${CMAKE_CURRENT_SOURCE_DIR}/a.c a.txt
)
add_custom_command(
OUTPUT b.txt
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/a.txt
COMMAND cp a.txt b.txt
)
add_custom_target(B ALL DEPENDS b.txt)
add_dependencies(B A)
CMake's rule for target-level dependencies is that A must be up to
date before the build system evaluates the rules of B.
Building with Ninja fails with::
ninja: error: 'a.txt', needed by 'b.txt', missing and no known rule to make it
Relevant portions of build.ninja::
build libA.a: C_STATIC_LIBRARY_LINKER CMakeFiles/A.dir/a.c.o
POST_BUILD = cd .../build cp .../a.c a.txt
...
build b.txt: CUSTOM_COMMAND a.txt || libA.a
COMMAND = cd .../build cp a.txt b.txt
...
The rule for b.txt has an order-only dependency on libA.a and
an explicit dependency on a.txt. Ninja does not wait for the
order-only dependencies to be up to date before complaining that
the explicit dependency is missing.
Can ninja be taught to wait for order-only dependencies to be up to
date to see if they produce any of the explicit dependencies as
a side effect? Is there another way to do this in CMake's Ninja gen?
Thanks,
-Brad
In build.ninja is no rule for coping a.c to a.txt at all.
Seems support for add_custom_command(TARGET) is missing or broken.
Could you open a ticket and assign to me?
Peter
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja + Windows CE
On 17.02.2013 08:36, Patrick Gansterer wrote: Hi, Am 09.02.2013 um 10:39 schrieb Peter Kümmel: On 30.01.2013 15:17, Brad King wrote: On 01/26/2013 12:33 PM, Patrick Gansterer wrote: to compile WindowsCE C++ project with Ninja I need the attached patch applied. One problem with this patch is that it moves the initialization of C and CXX languages until after the RC initialization which tries to match the location of the C/CXX compilers. Have a look at these: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e3a1f727 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6547f369 Peter, can you explain why this is needed for Ninja but not the other generators? Why does the logic belong in that method? Thanks, -Brad It wasn't clear to me why it works with other generators so I patched only the ninja code. Maybe there is a better solution, but I couldn't figure it out. But the current Ninja generator does not work. Any variables not set in Modules/CMakeCCompiler.cmake.in get no value. E.g. SET_MSVC_CXX_ARCHITECTURE_ID stays empty, because it's set it Modules/CMakeCXXCompiler.cmake.in. Since the all other generators work it seams to my like a Ninja problem, where EnableLanguage() of the base class isn't called correctly. -- Patrick I'm sorry, but atm I have absolutely not time to fix this issue. And I could not simply apply your patch because it could have side effects which introduce other bugs, things are not very decoupled in cmake's code base. If you have time, try to figure out the cmake way of enabling a language and rewrite void cmGlobalNinjaGenerator::EnableLanguage(). There are two related tickets for this: http://www.cmake.org/Bug/view.php?id=13903 http://www.cmake.org/Bug/view.php?id=13606 Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja + Windows CE
On 30.01.2013 15:17, Brad King wrote: On 01/26/2013 12:33 PM, Patrick Gansterer wrote: to compile WindowsCE C++ project with Ninja I need the attached patch applied. One problem with this patch is that it moves the initialization of C and CXX languages until after the RC initialization which tries to match the location of the C/CXX compilers. Have a look at these: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e3a1f727 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6547f369 Peter, can you explain why this is needed for Ninja but not the other generators? Why does the logic belong in that method? Thanks, -Brad It wasn't clear to me why it works with other generators so I patched only the ninja code. Maybe there is a better solution, but I couldn't figure it out. Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] TestCocoon
Today I stumbled over Steven's Grantlee release blog http://steveire.wordpress.com/2012/11/01/grantlee-0-3-0-codename-leistungswasser-now-available/ and read about TestCocoon. Last year Alex had the idea to test it with CMake: http://www.mail-archive.com/kde-buildsystem@kde.org/msg06582.html Has anybody tried this? In meantime TestCocoon was absorbed by froglogic: http://www.froglogic.com/squish/coco/ The old code is still at https://gitorious.org/testcocoon/testcocoon . Is it still usable? Steve, which version have you used? Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Expression unit test
A unit tests for expressions is broken for ninja: http://open.cdash.org/testDetails.php?test=161505814build=2596684 ninja prints the wrong parameter as it is used in the cmake file, include_directories($TARGET_PROPERTY:Invali/dTarget,INCLUDE_DIRECTORIES) but the test wants the $ escaped one: Expected stderr to match: expect-err \$TARGET_PROPERTY:Invali/dTarget,INCLUDE_DIRECTORIES Actual stderr: actual-err $TARGET_PROPERTY:Invali/dTarget,INCLUDE_DIRECTORIES Is this a bug in the test (and the other generators) or in the ninja generator? Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0013559]: Ninja: Wrong dependency with PCH support
On 25.09.2012 14:53, Mantis Bug Tracker wrote:
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13559
==
There is the code below in the ninja generator, which doesn't use real
but order-only dependency
(order-only dependency: build when needed, don't rebuild on changes
http://martine.github.com/ninja/manual.html#ref_dependencies)
Isn't this wrong at all?
// Ensure that the target dependencies are built before any source file in
// the target, using order-only dependencies.
cmNinjaDeps orderOnlyDeps;
this-GetLocalGenerator()-AppendTargetDepends(this-Target, orderOnlyDeps);
if(const char* objectDeps = source-GetProperty(OBJECT_DEPENDS)) {
std::vectorstd::string depList;
cmSystemTools::ExpandListArgument(objectDeps, depList);
std::transform(depList.begin(), depList.end(),
std::back_inserter(orderOnlyDeps), MapToNinjaPath());
}
// Add order-only dependencies on custom command outputs.
for(std::vectorcmSourceFile*::const_iterator
si = this-GeneratorTarget-CustomCommands.begin();
si != this-GeneratorTarget-CustomCommands.end(); ++si)
{
cmCustomCommand const* cc = (*si)-GetCustomCommand();
const std::vectorstd::string ccoutputs = cc-GetOutputs();
std::transform(ccoutputs.begin(), ccoutputs.end(),
std::back_inserter(orderOnlyDeps), MapToNinjaPath());
}
// If the source file is GENERATED and does not have a custom command
// (either attached to this source file or another one), assume that one of
// the target dependencies, OBJECT_DEPENDS or header file custom commands
// will rebuild the file.
if (source-GetPropertyAsBool(GENERATED) !source-GetCustomCommand()
!this-GetGlobalGenerator()-HasCustomCommandOutput(sourceFileName)) {
this-GetGlobalGenerator()-AddAssumedSourceDependencies(sourceFileName,
orderOnlyDeps);
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Using the internal Code::Blocks builder
On 09.09.2012 19:50, Benjamin Eikel wrote:
Dear CMake developers,
I looked at the output of my CMake build/bin/cmake --system-information
with the Unix Makefiles generator and the new Code::Blocks generator. For the
new Code::Blocks generator, the variables CMAKE_LIBRARY_ARCHITECTURE (and the
analogous ones for the languages), CMAKE_${LANG}_IMPLICIT_LINK_DIRECTORIES,
and CMAKE_${LANG}_IMPLICIT_LINK_LIBRARIES are empty. They are not empty for
the Unix Makefiles generator. I have searched the place where they are set and
tried to trace it back to the generator code. But I still have not found it.
Can you tell me what I have to do to make these variables get the same content
when using the new Code::Blocks generator?
When you are looking for some cmake variables you should also search in the
Modules/ folder not only C++ files in Source/, because cmake by itself uses
cmake files.
Kind regards
Benjamin
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Using the internal Code::Blocks builder
On 08.09.2012 11:51, Benjamin Eikel wrote: Am Freitag, 7. September 2012 um 18:59:49 schrieb Bill Hoffman: On 9/7/2012 12:13 PM, Benjamin Eikel wrote: Yes, I have seen that in the beginning when the generator did not work as expected. At the moment, it builds from the command line, but only if you give it access to a display (a window is opened by C::B, but that closes immediately after the build has finished). So try-compiles work, but the situation with the window is unacceptable. I have to see if somebody from the C::B community is willing to help. OK, well, if that is working. Then build cmake, and then do ./bin/ctest, it should run all the tests and show what you need to do. Doing that everything seems to be fine (complex, complexOneConfig and CMake.CheckSourceTree fail with master branch for me, too). But I have the feeling that the new generator is used only in very few tests. I tried setting CMAKE_TEST_GENERATOR to the name of the new generator and that makes more tests fail. When you build cmake with your new generator it would be selected automatically. But it's a chicken-egg problem then. -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Using the internal Code::Blocks builder
On 05.09.2012 20:54, Alexander Neundorf wrote: Something like $ codeblocks --build foo.cbp Ah, a new build system ;) This is more or less necessary so cmake can run its test suite to verify the generator works correctly. Alex -- -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ninja test failing again...
On 05.09.2012 13:31, Brad King wrote: On 09/04/2012 07:46 PM, Peter Kümmel wrote: Any optimization that skips dependency checks should be done only for the first form, and never for the second form. This distinction should cover the BuildDepends test case too. http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=34b0cf6a3823e0d54958a0f337308b4c35342cc3 Is this better? Yes, thanks. Please revert the other topic and merge this one instead. OK, I merged this: http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=7b2bf28e183b5eacc22fe3030f0439853746f0bd -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ninja test failing again...
On 04.09.2012 21:56, Brad King wrote: On 09/04/2012 02:16 PM, Peter Kümmel wrote: On 04.09.2012 18:56, Bill Hoffman wrote: The BuildDepends test has been failing for some time now: http://open.cdash.org/viewUpdate.php?buildid=2522326 It seems to be from this commit: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4a35bd0e69e5cfaf7ca9604c90b609d1d333bb37 Here is the first failure: http://open.cdash.org/testDetails.php?test=156781454build=2522326 Any ideas? Maybe cmcldeps is not working for some reason? -Bill fixed it shortly before your email ;) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9b8b4c11d8e7807c0b8e6d9bea490f20f3ad0367 The try_compile command has two signature forms. One is meant to build a single source file in an auto-generated project in a discard-able temp dir. The other is meant to build a given source tree in a given build tree and keep the results around. Any optimization that skips dependency checks should be done only for the first form, and never for the second form. This distinction should cover the BuildDepends test case too. -Brad http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=34b0cf6a3823e0d54958a0f337308b4c35342cc3 Is this better? Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] lua bindings?
Here an example how a Lua based build system could look like: https://github.com/deplinenoise/tundra/blob/master/tundra.lua And more details here: http://deplinenoise.files.wordpress.com/2011/04/tundra43.pdf Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Directory for debug symbols
On 22.08.2012 15:13, Brad King wrote: On 08/22/2012 09:09 AM, Peter Kümmel wrote: I wouldn't introduce a variable which will become obsolete, because of the backward compatibility matra such a variable could never be removed. Why not simply document that SYMBOL_OUTPUT_DIRECTORY is currently only supported for pdb files? That's *because* of compatibility. It is easy to continue to support the PDB_OUTPUT_DIRECTORY name in the future and simply ignore it if the future-named property is set. If we make work only for PDB files now then in the future if we make it work for other toolchains then that will be a change in behavior for existing projects that expected it to work only for PDB files. But this way you end up with a redundant solution: PDB_OUTPUT_DIRECTORY and SYMBOL_OUTPUT_DIRECTORY do the same, PDB_OUTPUT_DIRECTORY can't be removed, and cmake gets polluted more and more. I think at such points backward compatibility should be reconsidered, because it enforce us to be compatible with cmake versions which simply have some functionality not implemented. On the other hand, updating cmake and absolutely nothing will break in existing cmake files, not even workarounds, is also a selling point for cmake. Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Directory for debug symbols
I wanna add a way to put all .pdb files into one directory. Therefore I've introduced the variable CMAKE_DEBUG_SYMBOL_DIRECTORY which could be set to an existing directory. I patched all the places where GetPDBName() is used. Is it OK to merge this patch to next? http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=b144d0ffa64afbdd971d84eb9567bb1eb02c3cf6 Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Directory for debug symbols
On 22.08.2012 14:47, Brad King wrote: On 08/22/2012 08:41 AM, Peter Kümmel wrote: I wanna add a way to put all .pdb files into one directory. Therefore I've introduced the variable CMAKE_DEBUG_SYMBOL_DIRECTORY which could be set to an existing directory. I patched all the places where GetPDBName() is used. Have a look at these issues: http://www.cmake.org/Bug/view.php?id=10830 http://www.cmake.org/Bug/view.php?id=11899 which discuss some complicating factors. Also, see these comments: http://www.cmake.org/Bug/view.php?id=10830#c24153 http://www.cmake.org/Bug/view.php?id=10830#c25068 Ah, seems you were already busy on this. Also the latest patch from Thomas Bernard looks very promising. I'd prefer PDB-specific names to leave room for future generalized cross-platform debug symbol features. I wouldn't introduce a variable which will become obsolete, because of the backward compatibility matra such a variable could never be removed. Why not simply document that SYMBOL_OUTPUT_DIRECTORY is currently only supported for pdb files? Peter Finally, you'll need to implement this as a target property with an optionally configuration-specific name. Follow the pattern already used for the RUNTIME_OUTPUT_DIRECTORY target property and the corresponding CMAKE_RUNTIME_OUTPUT_DIRECTORY variable. Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Ninja: files per second
I've added a nice feature to ninja which is now upstream: By setting the environment variable NINJA_STATUS bash: export NINJA_STATUS=[%s/%t %o(%c)/s] cmd.exe (with space at the end): set NINJA_STATUS=[%s/%t %o(%c)/s] Ninja prints the overall processed files per second and the the current rate of files per second (averaged over the last -j files). For instance compiling cmake I get (-DCMAKE_BUILD_TYPE=Release): - Linux gcc 4.6: [397/397 6.6(12)/s] - Windows gcc 4.7: [438/438 5.9(11)/s] - Mac gcc 4.2: [462/462 4.9(3)/s] See also https://github.com/martine/ninja/blob/master/doc/manual.asciidoc#environment-variables Happy benchmarking, Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja: files per second
On 28.07.2012 11:43, Shlomi Fish wrote: Nice. I was now able to get the Freecell Solver test suite to pass with ninja test, but there is one problem: when I run ninja -vv test, then ninja displays the line [1/1] cd /home/shlomif/progs/freecell/git/fc-solve/fc-solve/source/n perl /home/shlomif/progs/freecell/git/fc-solve/fc-solve/source/run-tests.pl and then it waits for the entire test suite to run, and only then displays its output. This is frustrating because I want to see the output while the test suite is running. Is there anyway to do it like that? No, this is by design, ninja collects the whole output so it is not interweaved with the output of other processes. Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Memory leak introduced with recent Mac+Ninja changes
On 21.07.2012 19:55, Nicolas Desprès wrote: Thanks for the feedback. Here the patches to cherry-pick: https://github.com/polrop/CMake/commit/af6b1979071e463ae397d3512e3a0366b58919f8 https://github.com/polrop/CMake/commit/be8039fab069b0efb2469932617b3ca8826d1865 Thanks, pushed them to stage. Cheers, Nico On Sat, Jul 21, 2012 at 1:32 PM, David Cole david.c...@kitware.com mailto:david.c...@kitware.com wrote: cmMakefileTargetGenerator leaks its OSXBundleGenerator -- please delete it in the destructor... Search for are definitely lost on this page: http://open.cdash.org/viewDynamicAnalysisFile.php?id=2784730 Thanks, David -- Nicolas Desprès -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Experimental BuildDepends test passed, but does not work?
On 21.07.2012 11:22, Claus Klein wrote: I can not understand the output, for me this test does not work. Change Dir: /Users/clausklein/Downloads/CmakeNinjaBuildDir/Tests/BuildDepends/Project Run Build Command:/usr/local/bin/ninja [1/14] Building CXX object CMakeFiles/foo.dir/foo.cxx.o [2/14] Generating zot_custom.hxx [3/14] Generating zot.hxx [4/14] Building CXX object CMakeFiles/zot.dir/zot.cxx.o [5/14] Building CXX object CMakeFiles/zot.dir/zot_macro_dir.cxx.o [6/14] Linking CXX static library libfoolib.a [7/14] Building CXX object CMakeFiles/generator.dir/generator.cxx.o [8/14] Building CXX object CMakeFiles/zot.dir/zot_macro_tgt.cxx.o [9/14] Linking CXX executable zot [10/14] Linking CXX executable gen [11/14] Generating noregen.h [12/14] Generating regen.h [13/14] Building CXX object CMakeFiles/bar.dir/bar.cxx.o [14/14] Linking CXX executable bar Running /Users/clausklein/Downloads/CmakeNinjaBuildDir/Tests/BuildDepends/Project/bar Run result: 0 Output: foo Worked! Running /Users/clausklein/Downloads/CmakeNinjaBuildDir/Tests/BuildDepends/Project/zot Run result: 0 Output: [zot] [zot_custom] [zot_macro_dir] [zot_macro_tgt] Worked! Waiting 3 seconds... Modifying Project/foo.cxx Building project second time Output from second build: Change Dir: /Users/clausklein/Downloads/CmakeNinjaBuildDir/Tests/BuildDepends/Project Run Build Command:/usr/local/bin/ninja ninja: no work to do. Running /Users/clausklein/Downloads/CmakeNinjaBuildDir/Tests/BuildDepends/Project/bar Run result: 0 Output: foo changed Worked! Running /Users/clausklein/Downloads/CmakeNinjaBuildDir/Tests/BuildDepends/Project/zot Run result: 0 Output: [zot changed] [zot_custom changed] [zot_macro_dir changed] [zot_macro_tgt changed] Worked! Configuring Configuring done Generating Generating done Build files have been written to: /Users/clausklein/Downloads/CmakeNinjaBuildDir/Tests/BuildDepends End CMake output == Change Dir: /Users/clausklein/Downloads/CmakeNinjaBuildDir/Tests/BuildDepends Run Clean Command:/opt/local/bin/ninja -t clean Cleaning... 0 files. Run Build Command:/opt/local/bin/ninja ninja: no work to do. see: http://open.cdash.org/testDetails.php?test=154196743build=2456799 http://open.cdash.org/testDetails.php?test=154196743build=2456799 Can anyone please help? You could not run the BuildDepends test twice. You always have to remove the BuildDepends folder in the build tree before running it again. Seems like a bug in the cmake file for the test. Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Experimental BuildDepends test passed, but does not work?
On 21.07.2012 12:08, Peter Kümmel wrote: Can anyone please help? You could not run the BuildDepends test twice. You always have to remove the BuildDepends folder in the build tree before running it again. Seems like a bug in the cmake file for the test. Or a bug in the ninja generator? Peter -- -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja passes all tests on OS X
On 18.07.2012 11:58, Nicolas Desprès wrote:
On Tue, Jul 17, 2012 at 11:39 PM, Bill Hoffmanbill.hoff...@kitware.com wrote:
On 7/17/2012 1:43 PM, Peter Kümmel wrote:
On 17.07.2012 19:32, Bill Hoffman wrote:
On 7/17/2012 1:21 PM, Peter Kümmel wrote:
OK, maybe it is simpler to add a the functions to
cmNinjaTargetGenerator which
forwards the call to the Local/Global classes.
Lets just add the friend stuff for now so we can get the dashboard
building again.
You could not add friend class
cmNinjaTargetGenerator::MacOSXContentGeneratorType
because cmNinjaTargetGenerator is forward declared, and including
cmNinjaTargetGenerator.h
doesn't help because it includes cmLocalNinjaGenerator.h again.
Maybe making MacOSXContentGeneratorType global helps.
'
There is also a warning here:
C:/Users/hoffman/Work/My Builds/cmake/Source/cmNinjaTargetGenerator.cxx(60)
: warning C4355: 'this' : used in base member initializer list
Making the helper class global should fix the problem. What about a letter
envelope type of thing. Move the whole MacOSXContentGeneratorType into the
.cxx file. Then forward declare the pointer to it in the
cmNinjaTargetGenerator class.
class cmMacOSXContentGeneratorType;
class cmNinjaTargetGenerator
{
...
cmMacOSXContentGeneratorType* MacOSXContentGenerator;
Then create it with new in the constructor. This would get rid of the above
warning as well. I would like to clean this up before the nightly
dashboards get going so we don't have a bunch of red tomorrow.
Bill,
You can find two patches in the following branch which should fix
these compilation issues. I have tested them with clang and gcc on Mac
OS X.
https://github.com/polrop/CMake/commits/ninja/fix_build
https://github.com/polrop/CMake/commit/5497caf3e0e14430a222e92f190d8d9ea4ee6e8a
https://github.com/polrop/CMake/commit/ae24daf591b12d8c23fa481f93a13270c9a0c00f
Note that this branch has been created from next so you better cherry
picked these two patches than merge them back to next.
Cheers,
Nico
I'm busy on this too. But I've removed the friend by making some functions
public.
Peter
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja passes all tests on OS X
On 18.07.2012 11:58, Nicolas Desprès wrote:
On Tue, Jul 17, 2012 at 11:39 PM, Bill Hoffmanbill.hoff...@kitware.com wrote:
On 7/17/2012 1:43 PM, Peter Kümmel wrote:
On 17.07.2012 19:32, Bill Hoffman wrote:
On 7/17/2012 1:21 PM, Peter Kümmel wrote:
OK, maybe it is simpler to add a the functions to
cmNinjaTargetGenerator which
forwards the call to the Local/Global classes.
Lets just add the friend stuff for now so we can get the dashboard
building again.
You could not add friend class
cmNinjaTargetGenerator::MacOSXContentGeneratorType
because cmNinjaTargetGenerator is forward declared, and including
cmNinjaTargetGenerator.h
doesn't help because it includes cmLocalNinjaGenerator.h again.
Maybe making MacOSXContentGeneratorType global helps.
'
There is also a warning here:
C:/Users/hoffman/Work/My Builds/cmake/Source/cmNinjaTargetGenerator.cxx(60)
: warning C4355: 'this' : used in base member initializer list
Making the helper class global should fix the problem. What about a letter
envelope type of thing. Move the whole MacOSXContentGeneratorType into the
.cxx file. Then forward declare the pointer to it in the
cmNinjaTargetGenerator class.
class cmMacOSXContentGeneratorType;
class cmNinjaTargetGenerator
{
...
cmMacOSXContentGeneratorType* MacOSXContentGenerator;
Then create it with new in the constructor. This would get rid of the above
warning as well. I would like to clean this up before the nightly
dashboards get going so we don't have a bunch of red tomorrow.
Bill,
You can find two patches in the following branch which should fix
these compilation issues. I have tested them with clang and gcc on Mac
OS X.
https://github.com/polrop/CMake/commits/ninja/fix_build
https://github.com/polrop/CMake/commit/5497caf3e0e14430a222e92f190d8d9ea4ee6e8a
https://github.com/polrop/CMake/commit/ae24daf591b12d8c23fa481f93a13270c9a0c00f
Thanks for the Cannot pass a reference to an anonymous object commit
I already wondered if it will work on all compilers.
Peter
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja passes all tests on OS X
On 17.07.2012 15:39, Nicolas Desprès wrote: On Tue, Jul 17, 2012 at 3:29 PM, Bill Hoffmanbill.hoff...@kitware.com wrote: On 7/17/2012 8:10 AM, Peter Kümmel wrote: On 17.07.2012 13:45, David Cole wrote: Peter, can you rebase this on current 'master', push this to our stage as a branch, and merge it to 'next'...? Done. Let's see what happens on CDash. Looks ok, but is not building on Borland: http://open.cdash.org/viewBuildError.php?buildid=2447645 Looks like cmNinjaTargetGenerator::MacOSXContentGeneratorType should be mark as friend of cmLocalNinjaGenerator and cmGlobalNinjaGenerator. Apparently Borland does not forward friendness to innerclass. Cheers, Nico Isn't it possible to avoid friend? 'friend' is not your friend Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja passes all tests on OS X
On 17.07.2012 19:11, Nicolas Desprès wrote: I don't like the friend keyword either but I try to follow the current architecture of CMake. Yes, I know. In cmLocalUnixMakefileGenerator you can see that: friend class cmMakefileTargetGenerator; friend class cmMakefileExecutableTargetGenerator; friend class cmMakefileLibraryTargetGenerator; friend class cmMakefileUtilityTargetGenerator; friend class cmGlobalUnixMakefileGenerator3; So it does in cmLocalNinjaGenerator. I have an alternate approach to factor this code without using a function object but it is much more complicated. See https://github.com/polrop/CMake/commit/525ec73fa765b7ee55cd89799ba81410da0dab34 OK, maybe it is simpler to add a the functions to cmNinjaTargetGenerator which forwards the call to the Local/Global classes. Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja passes all tests on OS X
On 17.07.2012 19:32, Bill Hoffman wrote: On 7/17/2012 1:21 PM, Peter Kümmel wrote: OK, maybe it is simpler to add a the functions to cmNinjaTargetGenerator which forwards the call to the Local/Global classes. Lets just add the friend stuff for now so we can get the dashboard building again. You could not add friend class cmNinjaTargetGenerator::MacOSXContentGeneratorType because cmNinjaTargetGenerator is forward declared, and including cmNinjaTargetGenerator.h doesn't help because it includes cmLocalNinjaGenerator.h again. Maybe making MacOSXContentGeneratorType global helps. Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] The BuildFlags test you attempted last week...
On 09.07.2012 17:35, David Cole wrote:
Not sure what your main goal was for that test, but a similar test already
exists to ensure proper definition of
http://www.cmake.org/Bug/view.php?id=13069
Seems there is no test which checks if -DCMAKE_BUILD_TYPE=XXX triggers the
selection of the matching CMAKE_C_FLAGS_XXX:
CMakeLists: set(CMAKE_C_FLAGS_DEBUG -DTEST_STRING=${CMAKE_BUILD_TYPE}
main.c: printf(%s\n, TEST_STRING)
test : output == ${CMAKE_BUILD_TYPE}
CMAKE_BUILD_TYPE or proper selection of build configuration in a multi-config
generator. But only in the context of
running a ctest -D dashboard or a ctest -S dashboard script.
See the files Tests/CTestConfig/CMakeLists.txt and
Tests/CTestConfig/CTestConfig.cxx for details.
You would need a block for if(CMAKE_CONFIGURATION_TYPES) in order to get the
logic just right w.r.t. CMAKE_BUILD_TYPE
in your test.
The Visual Studio and/or Xcode dashboards that did pass your test, passed it by
luck because the built configuration
happened to match the CMAKE_BUILD_TYPE that you were trying to expect.
The important piece of knowledge to have here is that CMAKE_BUILD_TYPE is not
defined for multi-config generators, and
in fact, it should be considered bad practice, although it's not strictly an
error, to define it in such a build tree.
Because in a multi-config generator you can actually have multiple builds
(Debug+Release+...) existing side-by-side in
the same build tree.
Hope this helps,
David
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja passes all tests on OS X
On 07.07.2012 20:54, Nicolas Desprès wrote: I have pushed the re-factor patch. Let me know what do you think. I have tested on Linux and MacOSX with the Makefile and Ninja generator and both work fine. I've tested it here and BundleTest still fails. It doesn't install the Resource files. Looking at your patch I assume you've overseen // write rules for Mac OS X Application Bundle content. void WriteMacOSXContentRules(std::vectorcmSourceFile* const sources); void WriteMacOSXContentRules(cmSourceFile source, const char* pkgloc); in class cmMakefileTargetGenerator. Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja passes all tests on OS X
On 06.07.2012 12:54, Nicolas Desprès wrote: Hi, I finally found the time to fix the Ninja generator on OS X. Mainly I have fixed ExportImport and Qt4Deploy. I based my work on jkp's work (https://github.com/jkp/CMake/commits/jkp/ninja-generator). Although there are other patches in this branch, I just included commits fixing tests. We could later add more tests if required. I also had a minor issue with CMake.Install because my Qt4, installed with Homebrew, did not have write access. You can find my patches here: https://github.com/polrop/CMake/commits/ninja-fix-macosx. I have tested my work on Linux too but not on Windows. I don't think my patch will break Windows, but we never know so I did not enable Ninja on MacOSX yet. I prefer to wait for a green dashboard. Great! I've rebased you branch on next and tested it on Windows, looks good so far! Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] new Generator
On 04.07.2012 02:10, J Decker wrote: ninja looks promising as an inbetween; lcc of course has it's own make. I however don't find ninja on windows latest download... there's a couple references in the /share/ Unofficial binaries you could find here: http://sourceforge.net/projects/cmakescript/files/ altneratively some other flavors of visual studio projects These would most likely be sub-classes of the existing generators. What flavors where you thinking of? (chocolate, vanilla?) :) a flag to enable generating a line when compiling CLR which allows adding references to .NET things to the project. (soemthing that has to be manually set for each target) something likeCLRSupportrue/CLRSupport http://www.mail-archive.com/cmake@cmake.org/msg39818.html Might also be just a flag or two set on existing generators. -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] CMake 2.8.9-rc1 ready for testing!
On 26.06.2012 23:00, Bill Hoffman wrote: On 6/26/2012 2:42 PM, Claus Klein wrote: yes, sure, On Darwin, I simply do: cmake -G 'Eclipse CDT4 - Ninja' -DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=1 ../LMX That works with any cmake project I work. Nightly build on uname -a Darwin claus-kleins-macbook-pro.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 i386 MacBookPro5,1 Darwin Can you run cmake in gdb with a debug build and get the exact location of the crash? It is working on my windows box... Works also here on Windows, Ubuntu 12.04, and Mac 10.8 (gcc-4.2, i386), at least when I use cmake as sources. Are you sure your sources are up to date? Recently I fixed another(?) crash reported by you: https://github.com/syntheticpp/CMake/commit/2fb07fc44c49da70a609fbc0df013c0301e9f36a#Source/cmExtraEclipseCDT4Generator.cxx -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ninja generator dashboard red
On 14.06.2012 17:05, Bill Hoffman wrote: Now that the ninja generator is on by default on windows, it is not building on the old compilers. Looks like it is missing a std:: on a make_pair call. I'll have a look at it. (I'm also busy fixing the broken Linux tests since my last commit) -Bill -- -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] The Borland compiler dashboard errors
On 14.06.2012 19:43, David Cole wrote:
I've got a fix locally in the ninja normal target generator:
std::string flags = (targetType == cmTarget::EXECUTABLE
? vars[FLAGS]
: vars[ARCH_FLAGS]);
locGtor-AddArchitectureFlags(flags,
this-GetTarget(),
this-TargetLinkLanguage,
this-GetConfigName());
if (targetType == cmTarget::EXECUTABLE) {
vars[FLAGS] = flags;
} else {
vars[ARCH_FLAGS] = flags;
}
That should fix the Borland compilers.
OK with you if I push it on top of the stage/ninja-cldeps branch? Or do you
already have something similar planned?
No problem. I have also looked at this, but I wasn't sure about the line number.
Which branch does the build server use?
Thanks,
David C.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] cmake -E vs_link with response files
I found a new problem were I could not find a good solution: cmd.exe /c $PRE_LINK cmake.exe -E vs_link_dll $in $POST_LINK Assume $in is to big for the command line, what could be done then. First I thought $PRE_LINK and $POST_LINK are then empty and could be dropped, but this is wrong. Is there something like response files for linking via vc_link already implemented? Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake -E vs_link with response files
On 15.06.2012 00:33, Peter Kümmel wrote: I found a new problem were I could not find a good solution: cmd.exe /c $PRE_LINK cmake.exe -E vs_link_dll $in $POST_LINK Assume $in is to big for the command line, what could be done then. First I thought $PRE_LINK and $POST_LINK are then empty and could be dropped, but this is wrong. Is there something like response files for linking via vc_link already implemented? This was a false alarm. But now I have to revert a bit. Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 13.06.2012 15:16, Bill Hoffman wrote: On 6/12/2012 7:08 PM, Peter Kümmel wrote: So we don't need any ninja patches, neither for msvc nor for mingw. All tests pass with ninja master. WOW! Congrats, this is awesome. The windows ninja dashboard is totally green today. Thanks for all the hard work, this is really great stuff. It is now the official speed daemon for windows builds. Look at this machine: http://open.cdash.org/index.php?project=CMakedate=2012-06-13filtercount=1showfilters=1field1=site/stringcompare1=63value1=dash2win64 Nice link, especially when Advanced View is clicked. ninja wins in build and test time over jom, nmake, and gmake! And configuring takes longer than building ;) But ninja automatically uses -j n+2 (n number of processors) Are the other build also multi threaded? The only thing left for ninja now is the OSX framework and bundle stuff. Also, we have to figure out how to get it to fortran 90 module depend stuff. But, windows is now done! I guess I also need to setup a ninja mingw dashboard. Thanks. -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 13.06.2012 18:09, Peter Collingbourne wrote: On Wed, Jun 13, 2012 at 05:34:14PM +0200, Peter Kümmel wrote: On 13.06.2012 15:31, Amine Khaldi wrote: Please don't consider Windows as done until proper dependency tracking is in place (it's lacking so far for rc files). Please test stage. I've added rc file dependency tracking. It's a bit brute force because I feed cl.exe with the .rc file and collect the included files. This works as long as all #includes are done before cl.exe stops because of rc specific stuff. I don't know if cmake could do it better. You could invoke cl.exe in preprocessor-only mode (/P /DRC_INVOKED), and then supply its output to rc.exe. This also prevents cl.exe from uselessly trying to compile the resource file as a C program. Yes, this looks like a more advanced solution. We only need to extract #line 1234 c:\... from the generated file. Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 13.06.2012 18:53, Bill Hoffman wrote: On 6/13/2012 12:41 PM, Peter Kümmel wrote: Yes, this looks like a more advanced solution. We only need to extract #line 1234 c:\... from the generated file. Peter -- Just do this: cl /P /showIncludes Then it won't error out, and will show the includes in the same format. Yes, perfect! -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
Putting quotes in and then taking them out. Where do the quotes come from? Is there another way to put paths with spaces into ninja? Yes sounds strange, but atm I've no better idea, ninja adds the quotes because it internally has a space separated list, see the link in my comment in merge request: https://github.com/martine/ninja/pull/324 This is the reason for the patch: http://open.cdash.org/testDetails.php?test=149373149build=2355021 Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 11.06.2012 13:23, Amine Khaldi wrote: Another thing I noticed while testing ReactOS is that we end up with entries like e:\reactos\ntoskrnl\include/../mm/ARM3/miarm.h (for example) in the .d files, and this triggers recompiles. If this /../ construct is eliminated (not that it's practically possible, I did it just for testing) the dependency works fine. Is fixed now, slashes are used: ninja ntoskrnl ninja: no work to do. Regards, Amine. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 12.06.2012 13:47, Amine Khaldi wrote: One of my last changes was to replaces back slashes with slashes exactly because of \../../ problems. Have you used cl and recent next? With cl and recent next: * Our host tools (the host-tools folder) basically get rebuilt everytime you run ninja, and -d explain suggests x86 is dirty and /Windows Kits/8.0/include/shared/sal.h is dirty...etc because we end up with entries like C:/Program\ Files\ (x86)/Windows\ Kits/8.0/include/shared/ConcurrencySal.h and C:/Program\ Files\ (x86)/Windows\ Kits/8.0/include/shared/sal.h in the .d files. Fixed. It was because of the parentheses. Such paths will be ignored. * As to ros itself, ntoskrnl produces a correct ninja: no work to do. when you rebuild and also tracks this E:/reactos/ntoskrnl/include/../mm/ARM3/miarm.h correctly if you alter it (leading to the recompilation of the dependent files). * Here we also lack the dependency tracking of the includes inside rc files. rc doesn't support something like /showInclude. Only idea I have to feed cl with the .rc file and to hope it prints the include paths before it breaks. But I don't know if it worth the effort. With gcc (windows) and recent next: * Our host tools (the host-tools folder) basically get rebuilt everytime you run ninja, and -d explain suggests psdk/guiddef.h is dirty (because of e:\reactos\include\host/../psdk/guiddef.h in the .d files) and reactos/wine/rpcfc.h is dirty (because of e:\reactos\include\host/wine/../../reactos/wine/rpcfc.h)... etc. * As to ros itself, ntoskrnl gets recompiled everytime, because of entries like e:\reactos\ntoskrnl\include/../kdbg/kdb.h and e:\reactos\ntoskrnl\include/../mm/ARM3/miarm.h... etc. Fixed by using slashes. Regards, Amine. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 12.06.2012 14:58, Amine Khaldi wrote: The gcc build issues are all fixed. Thanks ! The cl scenario for host-tools remains, I'm still getting entries like C:/Program\ Files\ (x86)/Windows\ Kits/8.0/include/shared/ConcurrencySal.h and C:/Program\ Files\ (x86)/Windows\ Kits/8.0/include/shared/sal.h Have you also rebuild cmcldeps? Thank you for looking into the rc handling too ;) Regards, Amine. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 12.06.2012 15:37, Bill Hoffman wrote: On 6/12/2012 5:27 AM, Peter Kümmel wrote: Yes sounds strange, but atm I've no better idea, ninja adds the quotes because it internally has a space separated list, see the link in my comment in merge request: https://github.com/martine/ninja/pull/324 This is the reason for the patch: http://open.cdash.org/testDetails.php?test=149373149build=2355021 Peter As I suspected the pull request is getting some questions. It seems like it is in the wrong place. Seems like the code that reads the string should be stripping it. When you debug it, you will see that it is not that simple. When the path is read you don't know what is done with it later on. And feeding fopen with is wrong anyway. When ninja read the string: C:\Dashboards\My Tests\CMake-ninja-build\Tests\OutOfBinary\CMakeFiles\outlib.dir\outlib.c.obj, it should have removed the start and end quotes if it found them. C:\Dashboards\My Tests\CMake-ninja-build\Tests\OutOfBinary\CMakeFiles\outlib.dir\outlib.c.obj.d -Bill -- -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 12.06.2012 17:43, Bill Hoffman wrote: On 6/12/2012 11:21 AM, Peter Kümmel wrote: When you debug it, you will see that it is not that simple. When the path is read you don't know what is done with it later on. Where is it read? Seems like at that point it does not matter where it is used later one. Once you read it in, it should strip them, and store it internally as a string. It would only need to be quoted again if it was being written out to the disk again. Here: https://github.com/syntheticpp/ninja/blob/master/src/graph.cc#L195 And the loop also builds the list of source files for the compiler, for instance: c:\my build\a.cpp c:\my build\b.cpp c:\my build\c.cpp in this case you need the quotes. But in case of a dependency file, which should be read from disk it must not have quotes. You could only speculate what will happen. All you know is that you evaluate the $out variable. Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 12.06.2012 18:07, Bill Hoffman wrote: On 6/12/2012 11:21 AM, Peter Kümmel wrote: When you debug it, you will see that it is not that simple. When the path is read you don't know what is done with it later on. And feeding fopen with is wrong anyway. BTW, you can create files with in the name on Windows, just not from explorer: touch \ Maybe you should use \ \ as build folder ;) $ ls -l total 69 -rw-r--r-- 1 hoffman Domain Users0 Jun 12 12:05 -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 12.06.2012 19:27, Bill Hoffman wrote: On 6/12/2012 1:22 PM, Peter Kümmel wrote: Maybe you should use \ \ as build folder ;) I agree, it is crazy Well, lets hope you can get them to accept your changes upstream. I found a much simpler patch: https://github.com/syntheticpp/ninja/commit/0ea34053a4692f190b8c13ce0ff032a57cece047 Could you please have a look at it before I create a merge request? Peter One thing that might help is if you created a case that failed on linux with spaces in the path. They seem to care more about that than windows :) -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 12.06.2012 19:59, Bill Hoffman wrote:
On 6/12/2012 1:44 PM, Peter Kümmel wrote:
I found a much simpler patch:
https://github.com/syntheticpp/ninja/commit/0ea34053a4692f190b8c13ce0ff032a57cece047
Could you please have a look at it before I create a merge request?
I would change RemoveQuotes to only remove them if they are at the start
and end of the string.
Something like this:
if(str.size() == 0)
return str;
if (str[0] == '\' str[str.size()-1] == '\')
{
cleaned = str.substr(1, str.size()-2);
return cleaned;
}
return str;
OK, but we need to handle strings like this:
... \outlib.dir\outlib.c.obj.d
Peter
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 12.06.2012 20:54, Bill Hoffman wrote: On 6/12/2012 2:30 PM, Peter Kümmel wrote: OK, but we need to handle strings like this: ... \outlib.dir\outlib.c.obj.d Peter OK, so where does the .d get added? That seems like the problem. It should not be adding a .d to the end of a quoted string. Defined in rules.ninja: # # Rule for compiling CXX files. rule CXX_COMPILER depfile = $out.d And $out is given by build.ninja: # = # Object build statements for EXECUTABLE target cmIML_test build Utilities\KWIML\test\CMakeFiles\cmIML_test.dir\test.c.obj: C_COMPILER -- depfile = $out.d = c:\my build\Utilities\KWIML\test\CMakeFiles\cmIML_test.dir\test.c.obj.d Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 12.06.2012 21:10, Peter Kümmel wrote: On 12.06.2012 20:54, Bill Hoffman wrote: On 6/12/2012 2:30 PM, Peter Kümmel wrote: OK, but we need to handle strings like this: ... \outlib.dir\outlib.c.obj.d Peter OK, so where does the .d get added? That seems like the problem. It should not be adding a .d to the end of a quoted string. Defined in rules.ninja: # # Rule for compiling CXX files. rule CXX_COMPILER depfile = $out.d And $out is given by build.ninja: # = # Object build statements for EXECUTABLE target cmIML_test build Utilities\KWIML\test\CMakeFiles\cmIML_test.dir\test.c.obj: C_COMPILER -- depfile = $out.d = c:\my build\Utilities\KWIML\test\CMakeFiles\cmIML_test.dir\test.c.obj.d First its evaluates the variable out https://github.com/syntheticpp/ninja/blob/master/src/eval_env.cc#L36 - c:\my build\Utilities\KWIML\test\CMakeFiles\cmIML_test.dir\test.c.obj then it appends a RAW string https://github.com/syntheticpp/ninja/blob/master/src/eval_env.cc#L34 - c:\my build\Utilities\KWIML\test\CMakeFiles\cmIML_test.dir\test.c.obj.d Peter -- -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 12.06.2012 21:17, Bill Hoffman wrote: On 6/12/2012 3:10 PM, Peter Kümmel wrote: -- depfile = $out.d = c:\my build\Utilities\KWIML\test\CMakeFiles\cmIML_test.dir\test.c.obj.d Maybe this should be mentioned on the ninja mailing list. If this were CMake, I would say that the should be stripped when $out is being expanded. It just seems like this is a fundamental issue with ninja and handling spaces in the path with .d files. Yes, that's the reason why that patches look so ugly. How does it work on linux? I guess it uses foo\ space? The way this is handled in CMake, is that all paths inside a CMake file have to be posix style using / even on windows. But I found a ninja-patch free solution. Busy with testing now Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 12.06.2012 21:30, Bill Hoffman wrote: On 6/12/2012 3:15 PM, Peter Kümmel wrote: First its evaluates the variable out https://github.com/syntheticpp/ninja/blob/master/src/eval_env.cc#L36 - c:\my build\Utilities\KWIML\test\CMakeFiles\cmIML_test.dir\test.c.obj So, if this removed the quotes would it work: env-LookupVariable(i-first) Remove the start and end quotes from the lookup? then it appends a RAW string https://github.com/syntheticpp/ninja/blob/master/src/eval_env.cc#L34 - c:\my build\Utilities\KWIML\test\CMakeFiles\cmIML_test.dir\test.c.obj.d Again, I think this should be moved to the ninja mailing list. My goal is to create a patch that makes them happen and works with spaces in the path on windows. Also, since ninja devs care more about linux if the problem could be re-created there that might help, but I suspect it can not be... Found a way around $out.d, the dep file path is now passed explicitly by DEP_FILE: # # Rule for compiling C files. rule C_COMPILER depfile = $DEP_FILE # Object build statements for EXECUTABLE target testing build CMakeFiles/testing.dir/testing.cxx.obj: CXX_COMPILER E$:/sandbox/cmake/cmake$ with$ spaces/Tests/Testing/testing.cxx DEP_FILE = CMakeFiles/testing.dir/testing.cxx.obj.d So we don't need any ninja patches, neither for msvc nor for mingw. All tests pass with ninja master. Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 12.06.2012 19:28, Bill Hoffman wrote: One more thing... Why is the MFC test failing now? Was a bug. rc files were compiled with cl. -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] KWStyle line length test failure
On 13.06.2012 01:04, David Cole wrote: If we want to increase the line length limitation, then we should discuss it and come to a reasonable consensus. We have reasons for wanting to keep the line length short, and we realize it's not always comfortable. But it really helps out viewing diffs in side-by-side diff viewers, (as one example). I'm sure there are other examples, too, and I'll let others chime in if they'd like to, but we will be putting this value back down to 79. We're not going to increase it unless it's discussed first, and everybody agrees that it would be better with a higher value. I simply tried it this way, because such things couldn't be discussed. Thanks for listening, David -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] KWStyle line length test failure
On 11.06.2012 18:02, David Cole wrote: In 'next' we are seeing dashboard test failures (and I am seeing it on my local build too, of course) that are related to recent edits in Source/cmNinjaTargetGenerator.cxx. 193: Processing /Users/davidcole/Dashboards/My Tests/CMake/Source/cmNinjaTargetGenerator.cxx 193: Error #0 (341) Line length exceed 80 (max=79) 193: Error #0 (382) Line length exceed 100 (max=79) Please fix them in time for the dashboard run tonight if it's at all possible. Brad and I would like to do our final merge session before 2.8.9-rc1 tomorrow. OK, I fix it. Maybe more than 'allowed'. Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 11.06.2012 13:23, Amine Khaldi wrote: Another thing I noticed while testing ReactOS is that we end up with entries like e:\reactos\ntoskrnl\include/../mm/ARM3/miarm.h (for example) in the .d files, and this triggers recompiles. If this /../ construct is eliminated (not that it's practically possible, I did it just for testing) the dependency works fine. One of my last changes was to replaces back slashes with slashes exactly because of \../../ problems. Have you used cl and recent next? Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
All tests pass now for MSVC and MinGW! With some small patches for ninja: https://github.com/syntheticpp/ninja/commits/ninja-for-cmake The changes are only needed for msvc when the build dir path contains spaces, and for mingw because of slashes in path names. Cheers, Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 12.06.2012 04:33, Bill Hoffman wrote: On 6/11/2012 10:21 PM, Peter Kümmel wrote: All tests pass now for MSVC and MinGW! With some small patches for ninja: https://github.com/syntheticpp/ninja/commits/ninja-for-cmake The changes are only needed for msvc when the build dir path contains spaces, and for mingw because of slashes in path names. Great work. Nice to see. What are the chances of those changes being accepted upstream? I am a bit concerned about the quote stuff. The patches are not critical, but there's not much traffic the last days. Putting quotes in and then taking them out. Where do the quotes come from? Is there another way to put paths with spaces into ninja? Yes sounds strange, but atm I've no better idea, ninja adds the quotes because it internally has a space separated list, see the link in my comment in merge request: https://github.com/martine/ninja/pull/324 But I think the patch is straight forward. The Win32 functions simply don't need them, even worse they reject the quoted path as Invalid argument. Most of the tests except the depend stuff was passing with spaces in the path before these changes. Is this all about the .d file contents? Yes, ninja can't open the .d files when they are behind a space and stops. It works when your build folder has no spaces. The other patch also isn't critical. https://github.com/martine/ninja/pull/322 It's like a fall back. Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 09.06.2012 16:22, Óscar Fuentes wrote: After looking that the ouptput of ninja -v, the problem is that ninja is recompiling some of the source files of llvm-tblgen.exe, which regenerates the llvm-tblgen.exe executable, which in turn triggers the regeneration of the files produced using that tool. ninja -d explain shows the files which are dirty, and having a look at the .d files shows that ninja couldn't parse them. (\\../) I've switched to slashes in .d files and this fixes it. All in stage/next, or https://sourceforge.net/projects/cmakescript/files/ ninja/master is ok when don't have spaces in your paths, otherwise ninja must be patched. Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 09.06.2012 01:29, Óscar Fuentes wrote: Peter Kümmelsyntheti...@gmx.net writes: It is not getting that far. It is not even running cmcldeps. :) The command= line is bad, so nothing builds, and we get no .d files. I added parentheses around cmcldeps, it should work now. With your binaries from 2 hours ago, changes on header files are correctly detected on my C++ projects. Thanks! LLVM builds fine, although re-running ninja results on re-executing all tablegen commands. Even with all those 70 or so tablegen invocations, ninja does a no-op rebuild in 16 seconds, which is faster than a true no-op rebuild with jom and much faster than msbuild. Windows XP SP3 32 bits, Visual Studio 2010. Many thanks for testing! I'm glad it mostly works. I assume the tablegen commands are some scripts and not compiler calls, maybe it can't find the generated one. Could you make a verbose run (-v) and post one rebuild? Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 09.06.2012 03:28, Bill Hoffman wrote: fails in a new way: http://open.cdash.org/viewConfigure.php?buildid=2345213 FAILED: CMAKE_CMCLDEPS_EXECUTABLE-NOTFOUND testCXXCompiler.cxx CMakeFiles\cmTryCompileExec4166421573.dir\testCXXCompiler.cxx.obj.d CMakeFiles\cmTryCompileExec4166421573.dir\testCXXCompiler.cxx.obj Note: including file: C:\PROGRA~2\MICROS~1.0\VC\bin\cl.exe /nologo /DWIN32 /D_WINDOWS /W3 /Zm1000 /EHsc /GR /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 /TP /FoCMakeFiles\cmTryCompileExec4166421573.dir\testCXXCompiler.cxx.obj /FdcmTryCompileExec4166421573.pdb -c testCXXCompiler.cxx CreateProcess failed: The system cannot find the file specified. For testing your system is better than any build server ;) I did a FIND_PROGRAM for setting CMAKE_CMCLDEPS_EXECUTABLE, now cmake.exe in CMAKE_COMMAND is simply replaced by cmcldeps.exe. But it seems I have also to switch to a patch with spaces. Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 09.06.2012 09:10, Peter Kümmel wrote: On 09.06.2012 01:29, Óscar Fuentes wrote: Peter Kümmelsyntheti...@gmx.net writes: It is not getting that far. It is not even running cmcldeps. :) The command= line is bad, so nothing builds, and we get no .d files. I added parentheses around cmcldeps, it should work now. With your binaries from 2 hours ago, changes on header files are correctly detected on my C++ projects. Thanks! LLVM builds fine, although re-running ninja results on re-executing all tablegen commands. Even with all those 70 or so tablegen invocations, ninja does a no-op rebuild in 16 seconds, which is faster than a true no-op rebuild with jom and much faster than msbuild. Windows XP SP3 32 bits, Visual Studio 2010. Does clang has another build system which supports ninja? Then we could compare the generated files. Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 09.06.2012 10:02, Claus Klein wrote:
Hi Peter,
I agree, we need your/our changes at upstream!
I will switch to our github:
https://github.com/syntheticpp/ninja
In times of git there is no our repository any more.
You could simply fork martine/ninja and push you changes
into your fork. Then, when you think something should go
upstream, create a merge request.
You could track multiple repositories by using git remote,
for instance in my cmake dir it looks like this:
$ git remote -v
origin git://cmake.org/cmake.git (fetch)
origin git://cmake.org/cmake.git (push)
pcc https://github.com/pcc/CMake.git (fetch)
pcc https://github.com/pcc/CMake.git (push)
polrop https://github.com/polrop/CMake.git (fetch)
polrop https://github.com/polrop/CMake.git (push)
stage g...@cmake.org:stage/cmake.git (fetch)
stage g...@cmake.org:stage/cmake.git (push)
steveires git://gitorious.org/~steveire/cmake/steveires-cmake.git (fetch)
steveires git://gitorious.org/~steveire/cmake/steveires-cmake.git (push)
syntheticpp g...@github.com:syntheticpp/CMake.git (fetch)
syntheticpp g...@github.com:syntheticpp/CMake.git (push)
On little more about ninja bootstrap:
Original bootstrap.py generated target rule:
ninja -t clean
does a really distclean. The re2c generted files are removed too!
Yes, you have to checkout again. When you don't have changes checkout -f
is the fasted way.
To be save, I added a rule to build/update them if needed:
Mostly I use my cmake file. Their python scripts are a bit sub-optimal.
#
set (RE2C_FOUND FALSE)
find_program (RE2C_EXECUTABLE re2c)
if (RE2C_EXECUTABLE)
set (RE2C_FOUND TRUE)
set (RE2C_FLAGS -b -i --no-generation-date)
# build src/depfile_parser.cc: re2c src/depfile_parser.in.cc
# build src/lexer.cc: re2c src/lexer.in.cc
foreach(_in depfile_parser.in.cc lexer.in.cc)
string(REGEX REPLACE .in.cc .cc _out ${_in})
message(STATUS Generate re2c src/${_in} -o src/${_out})
# CMake atrocity: if none of these OUTPUT files is used in a target in
# the current CMakeLists.txt file, the ADD_CUSTOM_COMMAND is plainly
# ignored and left out of the make files.
add_custom_command(OUTPUT ${srcdir}/${_out}
COMMAND ${RE2C_EXECUTABLE} ${${RE2C_FLAGS}} -o ${srcdir}/${_out}
${srcdir}/${_in}
DEPENDS ${srcdir}/${_in}
)
endforeach()
endif (RE2C_EXECUTABLE)
claus-kleins-macbook-pro:build clausklein$ ninja -d explain
ninja: no work to do.
claus-kleins-macbook-pro:build clausklein$ touch ../src/lexer.in.cc
claus-kleins-macbook-pro:build clausklein$ ninja -d explain
ninja explain: restat of output ../src/lexer.cc older than inputs
ninja explain: ../src/lexer.cc is dirty
ninja explain: ../src/lexer.cc is dirty
ninja explain: CMakeFiles/ninja_lib.dir/src/lexer.cc.o is dirty
ninja explain: libninja_lib.a is dirty
ninja explain: ninja is dirty
ninja explain: libninja_lib.a is dirty
[4/4] Linking CXX executable ninja
claus-kleins-macbook-pro:build clausklein$
//Regards
Claus
Nice, never tried -d explain.
Peter
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
The only thing to do is to figure out the prefix of /showIncludes, it's hard coded atm: https://github.com/syntheticpp/ninja/blob/cldeps/misc/cldeps.cc#L150 and to pass it to cldeps. Interesting problem... Maybe just look for the second : or something like that. I compile a test file and extract the translated string. I am thinking we should port cldeps to use the cmake cmSystemtools so that we can just build/ship the whole binary with cmake itself. Make it use CMakeLib instead of util from ninja. I've added cldeps as cmcldeps but included the SubProcess class from ninja (hope Apache 2 lisence is ok). We could port it to cmSystemtools later. BuildDepends only works when the binary BuildDepends folder doesn't exists, and ninja needs also as Xcode multiple runs, at the moment I don't know why. I've pushed it to next to see if the BuildDepends test also passes on the build server. Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 08.06.2012 18:10, Peter Kümmel wrote: The only thing to do is to figure out the prefix of /showIncludes, it's hard coded atm: https://github.com/syntheticpp/ninja/blob/cldeps/misc/cldeps.cc#L150 and to pass it to cldeps. Interesting problem... Maybe just look for the second : or something like that. I compile a test file and extract the translated string. I am thinking we should port cldeps to use the cmake cmSystemtools so that we can just build/ship the whole binary with cmake itself. Make it use CMakeLib instead of util from ninja. I've added cldeps as cmcldeps but included the SubProcess class from ninja (hope Apache 2 lisence is ok). We could port it to cmSystemtools later. BuildDepends only works when the binary BuildDepends folder doesn't exists, and ninja needs also as Xcode multiple runs, at the moment I don't know why. I've pushed it to next to see if the BuildDepends test also passes on the build server. If someone giv it a try, I've uploaded binaries here https://sourceforge.net/projects/cmakescript/files/ You need cmake and ninja (ninja/master, copy it into cmake's bin/). Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 08.06.2012 19:40, Bill Hoffman wrote:
On 6/8/2012 12:38 PM, Peter Kümmel wrote:
I've pushed it to next to see if the BuildDepends test also passes on
the build server.
If someone giv it a try, I've uploaded binaries here
https://sourceforge.net/projects/cmakescript/files/
You need cmake and ninja (ninja/master, copy it into cmake's bin/).
I just tried to run an experimental dashboard and it failed.
I think it was because my cmake build had a space in the path:
command = C:/Users/hoffman/Work/My
Builds/cmake-gmake/bin/cmcldeps.exe $in $out.d $out Note: including
file: C:\PROGRA~2\MICROS~1.0\VC\bin\cl.exe /nologo $FLAGS $DEFINES
/Fo$out /Fd$TARGET_PDB -c $in
description = Building C object $out
ninja gives this:
$ ../ninja/ninja
[1/437] Building C object
Utilities\KWIML\test\CMakeFiles\cmIML_test.dir\test.c.obj
ninja: FATAL: CreateProcess: %1 is not a valid Win32 application.
Dependency parsing is a bit hairy. It also breaks on '(', e.g. Program
Files(x86).
Could you have a look at the .d files?
Best place to debug this is a printf here:
https://github.com/syntheticpp/ninja/blob/master/src/graph.cc#L85
I also found that CMAKE_CL_SHOWINCLUDE_PREFIX is not set for different
CMakeLists.txt. I assume Windows-cl.cmake is the wrong place for it.
How can I make CMAKE_CL_SHOWINCLUDE_PREFIX as visible as CMAKE_C_COMPILER?
Peter
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 08.06.2012 21:11, Claus Klein wrote: Hi Peter, can you please explain what is the state of your ninja fork. It only adds cldeps and the CMakeLists.txt, nothing else. Is is sync with origin ninja? Yes, I branched yesterday. Will it merged later? Can you please apply my time-stamp patch? More interesting would be to bring it upstream. P.S. I tried to compile it with your CMakeLists.txt file, but it needs love on linux (UNIX) build hosts. Oh, yes, thanks. The last day I'm only on windows. //Regards Claus On 07.06.2012, at 23:46, Peter Kümmel wrote: Guessing configuration NoConfig Start 82: BuildDepends 1/1 Test #82: BuildDepends . Passed 5.06 sec ;) Bill, this was a great idea with cldeps! Only small patches for cldeps and cmake and we now have dependency tracking for msvc. A cldeps binary is here: http://sourceforge.net/projects/cmakescript/files/cldeps.exe Code is in misc/ also a CMakeLists.txt https://github.com/syntheticpp/ninja/tree/cldeps CMake: http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=1d40729eaa35dd643efdf5e793e6a541e890f33a The only thing to do is to figure out the prefix of /showIncludes, it's hard coded atm: https://github.com/syntheticpp/ninja/blob/cldeps/misc/cldeps.cc#L150 and to pass it to cldeps. Cheers, Peter -- -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
It is not getting that far. It is not even running cmcldeps. :) The command= line is bad, so nothing builds, and we get no .d files. I added parentheses around cmcldeps, it should work now. I also found that CMAKE_CL_SHOWINCLUDE_PREFIX is not set for different CMakeLists.txt. I assume Windows-cl.cmake is the wrong place for it. How can I make CMAKE_CL_SHOWINCLUDE_PREFIX as visible as CMAKE_C_COMPILER? I think it is going to have to go into CMakeCXXPlatform.cmake that gets configured just before the code you just added. Thanks, right direction. I added it to CMakeC*Compiler.cmake.in. Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 07.06.2012 16:21, Bill Hoffman wrote: On 6/7/2012 10:08 AM, Peter Kuemmel wrote: I changed the windows dashboard on dash2win64 to use ninja master. Looks better now. Thanks, only 2 left. Do you have an idea why CTestTestTimeout doesn't work? Not sure, might be a random thing. Let's see what it does tomorrow. It has failed 4 times in the last month... As for the depend stuff. Sounds like what we need is the wrapper for cl. https://github.com/sgraham/ninja/commit/1d0908951d3a93e06cf3582a67eada0b942489de Then we could put the command and depfile stuff into the generated files. This would not require a fix in upstream ninja. It could all be done on the CMake side, and we could use ninja master. Yes, I also think a solution on the cmake side make things much easier. What about using cmake's build-in dependency parser. AFAIK there is one. Could it be called by the command line? -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Canonical include pathes within ninja files
On 07.06.2012 20:44, Claus Klein wrote:
Hi Peter,
It seem not so important, but is it wanted that ninja generator creates
relative targets to PROJECT_BINARY_DIR?
claus-kleins-macbook-pro:Example clausklein$ ninja -t query Hello/libHello.a
Hello/libHello.a:
input: CXX_STATIC_LIBRARY_LINKER
Hello/CMakeFiles/Hello.dir/hello.o
outputs:
Demo/CMakeFiles/helloDemo.dir/demo.o
Demo/CMakeFiles/helloDemo.dir/demo_b.o
Demo/helloDemo
Hello
libHello.a
all
claus-kleins-macbook-pro:Example clausklein$
No, that looks like a bug.
The phony targes are OK, but all libs, obj, deps, and exe files use relative
paths.
I had problems in eclipse with relative paths, you should know.
It works as expected on shell.
This patch fix the ninja call without path and prevents the use of
std::ostringstream
It include a test with realpath, but this is disabled for now.
Thanks, will have a look at it later, currently I try to fix the dep problem :)
Peter
My other question about the not normalized include paths below could I solve.
I had simply to change the CMakeLists.txt of a subproject:
claus-kleins-macbook-pro:LMX clausklein$ bzr diff
examples/properties/CMakeLists.txt
=== modified file 'examples/properties/CMakeLists.txt'
--- examples/properties/CMakeLists.txt2011-05-10 06:13:29 +
+++ examples/properties/CMakeLists.txt2012-06-07 18:00:26 +
@@ -6,7 +6,8 @@
set(LIBLMX Lmx)
#FIXME find_library(LIBLMX Lmx ../../supporting-software/lib)
-include_directories(../../supporting-software/include)
+#XXX include_directories(../../supporting-software/include)
+include_directories(${PRJECT_DIR}/supporting-software/include)
# Tell CMake to build an executable
add_executable(testlmx properties.2.2.2-test.cpp properties.2.2.2.cpp
PropertyExtensions.cpp PropertyParser.cpp)
//Regards
Claus
On 07.06.2012, at 12:15, Claus Klein wrote:
Hi Peter,
I would like to know your opinion about Canonical path's
While testing with ninja generator, I found same rules with non Canonical
include pathes.
a simple example from my test program:
/tmp/some/deep/application/folder/../configuration/instance/../instance/myfile.cfg
/tmp/some/deep/application/configuration/instance/myfile.cfg
realpath -
/private/tmp/some/deep/application/configuration/instance/myfile.cfg (which does
not yet exists!)
see man realpath -- returns the canonicalized absolute pathname
http://www.kernel.org/doc/man-pages/online/pages/man3/realpath.3.html
Now the real questions:
1.) How can this done in a portable make insight cmake?
I know only boost!
2.) And should it done?
IMO yes! (It would be more clear and faster when we generate canonical path
entries.)
//Regards
Claus Klein
pathTricks.cpp
--
Powered by www.kitware.com http://www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
Guessing configuration NoConfig Start 82: BuildDepends 1/1 Test #82: BuildDepends . Passed5.06 sec ;) Bill, this was a great idea with cldeps! Only small patches for cldeps and cmake and we now have dependency tracking for msvc. A cldeps binary is here: http://sourceforge.net/projects/cmakescript/files/cldeps.exe Code is in misc/ also a CMakeLists.txt https://github.com/syntheticpp/ninja/tree/cldeps CMake: http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=1d40729eaa35dd643efdf5e793e6a541e890f33a The only thing to do is to figure out the prefix of /showIncludes, it's hard coded atm: https://github.com/syntheticpp/ninja/blob/cldeps/misc/cldeps.cc#L150 and to pass it to cldeps. Cheers, Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 06.06.2012 16:27, Bill Hoffman wrote: Maybe there is a better solution, which would automatically fix a lot of unit tests. Can you bring that up on the ninja mailing list? I tried it with not using slashes: https://github.com/syntheticpp/ninja/commit/262b7b951135eac51023512d2f788727828bac43 https://github.com/syntheticpp/CMake/commit/c95404d65229d1dd37f0579afb29e27f95501e06 but it doesn't help much. I have the impression it's a multi threading problem. Linking is only possible with -j1. Is that a patch that could go upstream ninja? Yes, the link points to a pull request. Sorry, no can do. If it is there, people will expect it to work for Yes, you are right. More testing with mingw shows that it is completely unusable. their project. Right now it is not working, so I don't want to enable it. The only feedback we will get, is these things are broken. We know what is broken, what more feedback do we need? To move forward on windows, I will change the dashboard to use ninja master. Right now it is still using your branch on git and is failing a bunch of tests. Also, it sounds like we took a step backwards with MinGW and the response files. Maybe until we figure that out we should disable response files for MinGW? ninja/master is not usable with mingw regardless what we do. And it has not much to do with the rsp files, most unit tests don't use a response file. Maybe I should switch back to my branch, master is a big mess for mingw. Did you ever run the unit tests before with mingw? Arn't they all broken because of the missing CMAKE_RC_COMPILER? Perhaps we can try one of the forks that has depend information for Seems we are forced to, nothing happen there. MSVC? If one of those works and the BuildDepends test passes, and we can get MinGW back into working shape, then we can enable ninja for Windows. I've hoped to get mingw to pass all tests because there is a dependency check, but it's worth than expected. -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 06.06.2012 16:27, Bill Hoffman wrote: I will change the dashboard to use ninja master. Right now it is still using your branch on git and is failing a bunch of tests. Now cmake prepends cmd.exe /c and the branched ninja also, so we have cmd.exe /c cmd.exe /c cd which makes no sense. Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 06.06.2012 20:21, Claus Klein wrote: Hi Peter, Today I have tried to work with ninja on MSYS. I have a view questions: 1. Is cmake build on MSYS or build on windows when you test with it the ninja generator? I tried the windows version, but it fails, Hi Claus, I only build with MSVC or mingw without MSYS. I never tried MinGW Makefile generator on msys, does this work? 2. MSYS has a bash sh program, why is cmd /c used at a unix like environment? It is not fast to start a a shell the old stupid dos cmd shell again and to have the cmdline length problems again! ATM it ignores MSYS: running cmake.exe == using cmd.exe But after the big mingw failure today, msys is maybe simpler than plain win32 mingw. 3. The gcc, ar, and other binutils I found are quite actual and the @response file options are known But it is a bash, not command, so only posix path separator must be used, '\' and spaces must be quoted! IMO cmake, at least the ninja generator should respect this, than it works. Overall I come to the conclusion, that cross-compiling with ninja and mingw on Linux is better supported than using mingw and ninja on Windows. An other question about dependancy generation on Windows and MSYS: I found the Makefile Generator creates dep files on MSYS, but the gcc can do it by the way? He, wait? It is it an open issue for the Nina generator to not create depend files on Windows with cl when cmake know to do it? With gcc you can produce dependency files, also on Windows. The problem is to use cl as single source for dependency files. cl supports /ShowIncludes but it has not a dependency file generation feature like gcc. But your idea to use gcc to generate dependencies even when the real work is done by cl is interesting. There are already several attempts discussed on the ninja list (or there are pull requests) to fix this issue, but the idea to mix a msvc and a mingw build is new. Would be a challenge. ... C:\Wascana\mingw\bin\ar.exe: CMakeFilescmTryCompileExec2945905931.dirtestCCompiler.c.obj: No such file Feeding MSYS with back-slashes will not work, no surprise. or directory ninja: build stopped: subcommand failed. Cheers, Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] Nina Generator on Windows generates too long link cmd lines
On 06.06.2012 21:32, Brad King wrote: On Tue, Jun 5, 2012 at 6:15 PM, Peter Kümmelsyntheti...@gmx.net wrote: The commits are here http://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/ninja-rspfile FYI, std::ostringstream is not portable to ancient platforms: http://www.cmake.org/Bug/view.php?id=13272 Please use cmOStringStream instead from now on. OK, I try to remember. But please don't blame me for introducing std::ostringstream. I only added a std::stringstream where a std::ostringstream already was there. Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] Nina Generator on Windows generates too long link cmd lines
On 04.06.2012 23:13, Bill Hoffman wrote: On 6/4/2012 2:22 PM, Peter Kümmel wrote: We use ninja's response files: # Rule for linking CXX static library. rule CXX_STATIC_LIBRARY_LINKER command = E:\sandbox\MinGW32\bin\ar.exe cr $out $LINK_FLAGS @$out.rsp description = Linking CXX static library $out rspfile = $out.rsp rspfile_content = $in But the problem is, that ar under windows doesn't like paths with one single '\' and on some UNIXs doesn't support response files at all. OK, my mistake. The tool has to support response files. So, currently with nmake files we do something like this: Platform/Windows.cmake: # for nmake make long command lines are redirected to a file # with the following syntax, see Windows-bcc32.cmake for use IF(CMAKE_GENERATOR MATCHES NMake) SET(CMAKE_START_TEMP_FILE @\n) SET(CMAKE_END_TEMP_FILE \n) ENDIF(CMAKE_GENERATOR MATCHES NMake) Does MinGW32 ar use a different format response file than MS link.exe? Seems like this should go in the Platform file. Maybe we don't use it on UNIX? -Bill -- I found the problem: using CMAKE_C_USE_RESPONSE_FILE_FOR_OBJECTS was wrong. I've fixed the patch: 1. also write rules with response files enabled 2. then the command line length is checked by cmake and if it is too long the rule with the response file is used 3. when MinGW is used the slashed pathes are used because ar.exe can't read \ in response files. The commits are here http://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/ninja-rspfile and I've merged it into next. Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] Nina Generator on Windows generates too long link cmd lines
On 04.06.2012 17:59, Bill Hoffman wrote: We are you using the linker support for response files? I thought ninja was handling this with its own response files? rspfile, rspfile_content rule link command = link.exe /OUT$out [usual link flags here] @$out.rsp rspfile = $out.rsp rspfile_content = $in We use ninja's response files: # Rule for linking CXX static library. rule CXX_STATIC_LIBRARY_LINKER command = E:\sandbox\MinGW32\bin\ar.exe cr $out $LINK_FLAGS @$out.rsp description = Linking CXX static library $out rspfile = $out.rsp rspfile_content = $in But the problem is, that ar under windows doesn't like paths with one single '\' and on some UNIXs doesn't support response files at all. Peter Seems like command could be anything at all. command = foobar $out bunch of stuff @$out.rsp Also, perhaps we should move this to the cmake-developers list? Are you both on that list? -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ninja bug
On 19.04.2012 16:21, Bill Hoffman wrote: On 4/19/2012 4:16 AM, Nicolas Desprès wrote: That's possible indeed. There are discussions whether to support all compilers deps file formats inside Ninja or in another program (see the deplist branch and discussion thread). The deplist branch is an attempt to provide a common format to store the dependencies in a fast-to-parse format. Currently, it is not merged yet and Ninja still relies on its own parser which is probably not bug free and does not have all the work-around required for all compilers versions. So, should I post this issue on the ninja list? I am also wondering if we could create a cmake depend generator for ninja. Then if the compiler did not support -M in a format that ninja likes, it could fall back to the cmake version. Does this mean cmake could preprocess C/C++ files and detect all #includes while using the search paths which are also passed to the compiler? Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ninja bug
On 21.04.2012 13:24, David Cole wrote: On Sat, Apr 21, 2012 at 6:53 AM, Peter Kümmel syntheti...@gmx.net mailto:syntheti...@gmx.net wrote: On 19.04.2012 16:21, Bill Hoffman wrote: On 4/19/2012 4:16 AM, Nicolas Desprès wrote: That's possible indeed. There are discussions whether to support all compilers deps file formats inside Ninja or in another program (see the deplist branch and discussion thread). The deplist branch is an attempt to provide a common format to store the dependencies in a fast-to-parse format. Currently, it is not merged yet and Ninja still relies on its own parser which is probably not bug free and does not have all the work-around required for all compilers versions. So, should I post this issue on the ninja list? I am also wondering if we could create a cmake depend generator for ninja. Then if the compiler did not support -M in a format that ninja likes, it could fall back to the cmake version. Does this mean cmake could preprocess C/C++ files and detect all #includes while using the search paths which are also passed to the compiler? Peter Yes. It does do that to generate the dependencies used for the Makefile generators. It's imperfect, but close enough for most purposes. Great! Is this the step which will be dropped when the /fast target is build? Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ninja status
On 08.04.2012 01:53, Bill Hoffman wrote: On 4/7/2012 5:03 PM, Peter Collingbourne wrote: On Sat, Apr 07, 2012 at 10:00:41PM +0200, Peter Kümmel wrote: On 07.04.2012 21:56, Peter Kümmel wrote: By default Ninja support is not enabled on Windows and Mac, somehow it was build the last times but I touched the cmake code there and introduced a FORCE: http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=f93e81858b5e1243714ed7f26aadfc791a7b0ff0 I wonder how Ninja was enabled on the build server? Manually by editing CMakeCache.txt? I believe they just use -DCMAKE_ENABLE_NINJA=ON. I don't see why your change is necessary at all, please revert it. Thanks, Yes, please reverse the change. We want ninja off on Mac and Windows by default until all of the tests are passing. I know ninja should not be enabled on other platforms than Linux, and it wasn't, even with my patch. This was not a try the enable ninja through the backdoor! I've fixed it and changed the message so it could not happen again: http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=2a081a2b3a3064530fe173a2930828e2232e844b -DCMAKE_ENABLE_NINJA=ON will work, or you can put it in the CMakeCache.txt with a dashboard script. Sorry, I though CMAKE_ENABLE_NINJA would be overwritten on each cmake run. Thanks. -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ninja status
On 08.04.2012 14:12, Óscar Fuentes wrote:
Peter Kümmelsyntheti...@gmx.net writes:
I know ninja should not be enabled on other platforms than Linux, and it wasn't,
even with my patch. This was not a try the enable ninja through the backdoor!
I've fixed it and changed the message so it could not happen again:
http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=2a081a2b3a3064530fe173a2930828e2232e844b
There is a typo on the patch:
SET(CMAKE_ENABLE_NINJA ${_CMAKE_DEFAULT_NINJA_VALUE} CACHE BOOL
-Enable the ninja generator for CMake. On Windows and OSX broken FORCE)
+Enable the ninja generator for CMake. On Windows and OSX broken)
[...]
ELSE()
- MESSAGE(STATUS Ninja generator disabled, enforce with -DENABLE_NINJA=ON)
+ MESSAGE(STATUS Ninja generator disabled, enforce with
-DCMAKE_ENABLE_NINJA=ON)
You mention CMAKE_USE_NINJA on the last message, when it should be
CMAKE_ENABLE_NINJA.
Thanks, CMAKE_ENABLE_NINJA is the name of the macro.
Peter
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ninja status
On 07.04.2012 20:46, David Cole wrote: On Fri, Apr 6, 2012 at 3:49 PM, David Coledavid.c...@kitware.com wrote: On Fri, Apr 6, 2012 at 3:10 PM, Peter Kümmelsyntheti...@gmx.net wrote: One nitpick with the patch, the KWStyle test fails because lines 58 63 exceed our max line length limit (79 characters is the max). Could you please put another commit on top of that one, fixing the lines that are too long, and then also push that to stage and merge it to next again? 79 limit... couldn't resist when typing the commit message ;) Yes, I don't blame you. I've had the same thought myself several hundred times. ;-) Thanks a bunch. It prevents a big red splotch on the dashboard tomorrow. David Despite fixing up the line length issue... there are several new ninja-related dashboard problems today after your commits from yesterday. Please take a look at them here: http://open.cdash.org/index.php?project=CMake and see what you can do to patch them up. There's one new compiler warning, and it looks like your CMakeLists Warning is fixed now. changes have somehow caused a massive failure of the test suite. I'm not sure I understand why yet, but perhaps you could try running the test suite on your end, too, on a Mac or Windows build? Thx, David By default Ninja support is not enabled on Windows and Mac, somehow it was build the last times but I touched the cmake code there and introduced a FORCE: http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=f93e81858b5e1243714ed7f26aadfc791a7b0ff0 I assume because of this Ninja support is not build: -- Ninja generator disabled, enforce with -DENABLE_NINJA=ON Could you configure the build server to use -DENABLE_NINJA=ON? Should ENABLE_NINJA be an option? Sometimes it remembers the ENABLE_NINJA value sometimes not. Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ninja status
On 07.04.2012 21:56, Peter Kümmel wrote: By default Ninja support is not enabled on Windows and Mac, somehow it was build the last times but I touched the cmake code there and introduced a FORCE: http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=f93e81858b5e1243714ed7f26aadfc791a7b0ff0 I wonder how Ninja was enabled on the build server? Manually by editing CMakeCache.txt? Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ninja status
Explanations of failing tests:
- The Plugin test is failing on Windows because the ENABLE_EXPORTS
target flag is not being processed:
Attached a patch which fixes this test. It was not an unprocessed flag
but a not existing directory.
I don't know where to commit this patch. stage/ninja-generator isn't
up to date any more, and I don't know if merging master is the right
way to proceed because it pollutes the history.
- I am not sure about the BuildDepend test and why it fails on both Mac,
Windows, and freebsd...
- all the bundle and framework tests fail on Mac because it is not
implemented.
Questions:
- Can we use master ninja for the windows dashboard now?
Still no respone file support.
- Does anyone know if the depend processing for windows has been or will
be accepted in ninja?
No, still nothing merged. It should pop up in this thread:
http://groups.google.com/group/ninja-build/browse_thread/thread/ad80094346ddfa1b
Peter
From 838dc0b44ffaaa8c25e61e09ac44c9a337ab01f6 Mon Sep 17 00:00:00 2001
From: Peter Kuemmel syntheti...@gmx.net
Date: Fri, 6 Apr 2012 17:40:22 +0200
Subject: [PATCH 1/2] Ninja: ensure output directories exist
---
Source/cmNinjaNormalTargetGenerator.cxx | 28 ++--
Source/cmNinjaNormalTargetGenerator.h |3 +++
2 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/Source/cmNinjaNormalTargetGenerator.cxx b/Source/cmNinjaNormalTargetGenerator.cxx
index 2bad32c..2bfe814 100644
--- a/Source/cmNinjaNormalTargetGenerator.cxx
+++ b/Source/cmNinjaNormalTargetGenerator.cxx
@@ -47,8 +47,7 @@ cmNinjaNormalTargetGenerator(cmTarget* target)
{
// on Windows the output dir is already needed at compile time
// ensure the directory exists (OutDir test)
-std::string outpath = target-GetDirectory(this-GetConfigName());
-cmSystemTools::MakeDirectory(outpath.c_str());
+EnsureDirectoryExists(target-GetDirectory(this-GetConfigName()));
}
}
@@ -56,6 +55,18 @@ cmNinjaNormalTargetGenerator::~cmNinjaNormalTargetGenerator()
{
}
+void cmNinjaNormalTargetGenerator::EnsureDirectoryExists(const std::string dir)
+{
+ cmSystemTools::MakeDirectory(dir.c_str());
+}
+
+void cmNinjaNormalTargetGenerator::EnsureParentDirectoryExists(const std::string path)
+{
+ EnsureDirectoryExists(cmSystemTools::GetParentDirectory(path.c_str()));
+}
+
+
+
void cmNinjaNormalTargetGenerator::Generate()
{
if (!this-TargetLinkLanguage) {
@@ -380,13 +391,18 @@ void cmNinjaNormalTargetGenerator::WriteLinkStatement()
}
}
+ std::string path;
if (!this-TargetNameImport.empty()) {
-vars[TARGET_IMPLIB] = this-GetLocalGenerator()-ConvertToOutputFormat(
- targetOutputImplib.c_str(), cmLocalGenerator::SHELL);
+path = this-GetLocalGenerator()-ConvertToOutputFormat(
+targetOutputImplib.c_str(), cmLocalGenerator::SHELL);
+vars[TARGET_IMPLIB] = path;
+EnsureParentDirectoryExists(path);
}
- vars[TARGET_PDB] = this-GetLocalGenerator()-ConvertToOutputFormat(
-this-GetTargetPDB().c_str(), cmLocalGenerator::SHELL);
+ path = this-GetLocalGenerator()-ConvertToOutputFormat(
+ this-GetTargetPDB().c_str(), cmLocalGenerator::SHELL);
+ vars[TARGET_PDB] = path;
+ EnsureParentDirectoryExists(path);
std::vectorcmCustomCommand *cmdLists[3] = {
this-GetTarget()-GetPreBuildCommands(),
diff --git a/Source/cmNinjaNormalTargetGenerator.h b/Source/cmNinjaNormalTargetGenerator.h
index 1702caf..7acbe8f 100644
--- a/Source/cmNinjaNormalTargetGenerator.h
+++ b/Source/cmNinjaNormalTargetGenerator.h
@@ -35,6 +35,9 @@ private:
void WriteObjectLibStatement();
std::vectorstd::string ComputeLinkCmd();
+ void EnsureDirectoryExists(const std::string dir);
+ void EnsureParentDirectoryExists(const std::string path);
+
private:
// Target name info.
std::string TargetNameOut;
--
1.7.4.msysgit.0
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
