Re: [cmake-developers] generator expression in install RENAME
Done: https://gitlab.kitware.com/cmake/cmake/issues/19903 On Tue, Oct 29, 2019 at 4:30 PM Kyle Edwards wrote: > Please open an issue at https://gitlab.kitware.com/cmake/cmake/issues > to request support for this. > > Kyle > > On Tue, Oct 29, 2019 at 9:58 AM Nicolas Desprès > wrote: > > > > Hi there, > > > > Generator expressions are allowed in the FILES/PROGRAMS and DESTINATION > part of an install command. > > > > Would that be possible to enable generator expression in the RENAME part > as well? > > > > The use-case is for the TARGET_FILE_BASE_NAME expression. > > > > Cheers, > > > > -- > > Nicolas Desprès > > > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > https://cmake.org/mailman/listinfo/cmake-developers > -- Nicolas Desprès -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
[cmake-developers] generator expression in install RENAME
Hi there, Generator expressions are allowed in the FILES/PROGRAMS and DESTINATION part of an install command. Would that be possible to enable generator expression in the RENAME part as well? The use-case is for the TARGET_FILE_BASE_NAME expression. Cheers, -- Nicolas Desprès -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Toward a more deterministic ninja generator
On Thu, Jun 16, 2016 at 7:14 PM, Brad King wrote: > On 06/14/2016 11:18 AM, Nicolas Desprès wrote: > > It makes the ninja generator more deterministic by sorting the > > build edge's inputs/outputs. It does not introduce any > > regression on my macbookpro. > > > > This could help to fix issue #15968. > > What examples of non-determinism have you observed after the changes > already made for that issue? > The LINK_LIBRARIES list has not the same order for an executable target. I have that after the 79th generation using cmake 3.5.2. With cmake master (d4283ca18b7) I did not reproduce it after 100 tries. > > + // We assume that commands using $in and $out varialbes do not care > > + // about the order of their inputs/outputs files, but commands that do > > + // not use them do care (like custom commands for instance). > > I'd prefer not to make this assumption. CMake should order the > inputs and outputs in a deterministic way before getting to the > code in question. If that is not happening then there may be > a deeper problem. Sorting this late is fixing the symptom. > > Yes you are right. I did not took enough time to read the issue history and I did not test with master. Sorry for the noise. -- Nicolas Desprès -- 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
[cmake-developers] Toward a more deterministic ninja generator
Hi, While working on something else I wrote this patch: https://github.com/nicolasdespres/CMake/commit/59e4e62ba014c6fcd4519b57b621d9434f99ff19 It makes the ninja generator more deterministic by sorting the build edge's inputs/outputs. It does not introduce any regression on my macbookpro. This could help to fix issue #15968. Regards, -- Nicolas Desprès -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Using CMake generated ninja file as a subninja file
On Tue, May 17, 2016 at 4:23 PM, Brad King wrote: > On 05/13/2016 07:19 PM, Nicolas Desprès wrote: > > Ok. See the new implementation > > Thanks. I've rebased your topic on 'master' after the style transition > commit and updated the style accordingly. Then I split the topic up into > more commits and simplified the prefix insertion logic a bit. > > I've merged the topic to 'next' for testing here: > > Merge topic 'ninja-output-path-prefix' into next > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=48d6c426 > > It consists of a series of minor cleanups/refactoring/fixes followed > by the main two commits: > > Ninja: Pass all build paths through a central method > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=038e7716 > > Ninja: Support embedding of CMake as subninja project > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8a862a4d > > Please review the revised approach. > That's great! The code is way cleaner this way. I have tested it with my generator and it works fine. > > > But the ExportImport and Plugin tests are likely to fail when used with > > this new feature. I can't figure out right now how to add a test for this > > without duplicating the Plugin and ExportImport test into > RunCMake/Ninja/. > > This is still the case, but I think it can be tackled as a follow-up > effort. The cmGlobalNinjaGenerator::NinjaOutputPath method could > just be hacked to skip "paths" starting in `-Wl,` (or even just `-`) > to handle the specific corner case. > I did not figure out a better way to handle this corner case. I have no strong requirements on this corner case at the moment, so I am ok to tackle it later. Thanks a lot for your help, -Nico -- 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] Using CMake generated ninja file as a subninja file
On Fri, May 13, 2016 at 9:38 PM, Brad King wrote:
> On 05/13/2016 03:25 PM, Brad King wrote:
> > so for now please make your logic recognize this case and work around it.
>
> Please split this into two commits to move hunks like this:
>
> > + this->TargetAll = this->NinjaOutputPath("all");
> > + this->CMakeCacheFile = this->NinjaOutputPath("CMakeCache.txt");
>
> into a preceding commit that performs refactoring with no functional
> change.
>
Done
>
> Also, in hunks like this:
>
> > - std::string convPath = ng->Convert(path,
> cmOutputConverter::HOME_OUTPUT);
> > + std::string convPath = ng->Convert(path, cmOutputConverter::FULL,
> format);
>
> please revise the logic so that *nothing changes* from the old logic
> when no subninja prefix is set. If this is going to break anything I'd
> like it to be isolated to when this feature is used. Consolidation of
> the two code paths can be done later when we've seen the new feature in
> use for a while and gained confidence in it.
>
>
Ok. See the new implementation of
cmGlobalNinjaGenerator::ConvertToNinjaPath() and
cmLocalNinjaGenerator::ConvertToLinkReference().
Now all the tests pass because the old logic is preserved when
CMAKE_NINJA_OUTPUT_PATH_PREFIX is empty. But the ExportImport and Plugin
tests are likely to fail when used with this new feature. I can't figure
out right now how to add a test for this without duplicating the Plugin and
ExportImport test into RunCMake/Ninja/.
https://github.com/nicolasdespres/CMake/commits/ninja-output-path-prefix
Thanks for your help,
-Nico
--
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] Using CMake generated ninja file as a subninja file
On Thu, May 12, 2016 at 10:07 PM, Brad King wrote: > On 05/12/2016 02:16 PM, Nicolas Desprès wrote: > > All done. Thank you for taking a look. > > https://github.com/nicolasdespres/CMake/commits/ninja-output-path-prefix > > The RunCMake.NinjaOutputPathPrefix test fails for me when I have > the CMake source and build trees in a directory with a space in > the path. Also, please move these test cases over to the > Tests/RunCMake/Ninja directory. You should be able to just append > the RunCMakeTest.cmake content. > > I have fixed the bug when a space is in the path and I added a test case when a space is in the contents of the CMAKE_NINJA_OUTPUT_PATH_PREFIX variable. I have 2 failing tests left that are not failing on master: Plugin and ExportImport. Both suffers from the same problem which comes from this part of my patch: https://github.com/nicolasdespres/CMake/commit/1f880c04bcb8cf36cf40be7fa4ef65f9525ea63e#diff-80cd058f986b2b3d5cdafc48a091411eL134 cmLocalNinjaGenerator::ConvertToLinkReference gets called by cmLocalGenerator::OutputLinkLibraries from here: https://github.com/nicolasdespres/CMake/blob/1f880c04bcb8cf36cf40be7fa4ef65f9525ea63e/Source/cmLocalGenerator.cxx#L1672 with a value that looks like this: "-Wl,-bundle_loader,/Users/polrop/Documents/cmake/_build ninja/Tests/ExportImport/Export/testExe2" The previous implementation of ConvertToLinkReference returned the string unchanged because it think it is a relative path, hiding the bug that lie on the caller site because the "if (li->IsPath)" in OutputLinkLibraries() should not be true for such a value. I don't know how to fix this. Cheers, -- Nicolas Desprès -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Using CMake generated ninja file as a subninja file
On Thu, May 12, 2016 at 3:16 PM, Brad King wrote: > On 05/12/2016 06:16 AM, Nicolas Desprès wrote: > > Brad has just sent a notification email about an upcoming feature freeze. > > Do you think we could have this feature merged before? > > I'll take a look. Please rebase on 'master' to resolve conflicts > and also reconcile with the ConvertToNinjaFolderRule logic that was > added. Also please squash your fixup commits. > > All done. Thank you for taking a look. https://github.com/nicolasdespres/CMake/commits/ninja-output-path-prefix -- Nicolas Desprès -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Using CMake generated ninja file as a subninja file
Hi Ben,
Brad has just sent a notification email about an upcoming feature freeze.
Do you think we could have this feature merged before?
Regards,
Nicolas
On Sun, Mar 20, 2016 at 1:47 PM, Nicolas Desprès
wrote:
>
>
> On Wed, Mar 9, 2016 at 9:41 PM, Ben Boeckel
> wrote:
>
>> On Tue, Mar 08, 2016 at 12:36:31 +0100, Nicolas Desprès wrote:
>> > Did you have a chance to review my patches?
>>
>> So I looked at it today, and it looks good overall. A few niggles:
>>
> Thanks
>
>>
>> +inline bool cmEndsWith(const std::string& str, const std::string& what)
>> +{
>> + assert(str.size() >= what.size());
>>
>> Probably better to just "return false;" if this would fire. Better than
>> crashing if something in a release would have hit this.
>>
>>
> Ok.
>
>
>> + return str.compare(str.size() - what.size(), what.size(), what) == 0;
>> +}
>> +
>> +inline void cmStripSuffixIfExists(std::string* str,
>> + const std::string& suffix)
>> +{
>> + assert(str != NULL);
>>
>> Why not just use a reference rather than a pointer?
>>
>
> I don't like to use non-const reference argument because the caller may
> not expect its variable to be modified since it not passed it by address.
> Anyway, reference argument are used in other places in the source code so
> it does not matter.
>
>
>>
>> + if (cmEndsWith(*str, suffix))
>> +str->resize(str->size() - suffix.size());
>>
>> Missing braces.
>>
>
> Ok.
>
>
>>
>> -std::string cmGlobalNinjaGenerator::ConvertToNinjaPath(const
>> std::string& path)
>> +static void EnsureTrailingSlash(std::string* path)
>> +{
>> + assert(path != NULL);
>>
>> Same thing: why not a reference?
>>
> Done.
>
>>
>> + if (path->empty())
>> +return;
>> + std::string::value_type last = (*path)[path->size()-1];
>> +#ifdef _WIN32
>> + if (last != '\\')
>> +*path += '\\';
>> +#else
>> + if (last != '/')
>> +*path += '/';
>> +#endif
>>
>> Missing braces in the if statements here.
>>
>>
> Ok.
>
>
>> - cmGlobalNinjaGenerator::WriteDefault(os,
>> - outputs,
>> - "Make the all target the
>> default.");
>> + if (!this->HasOutputPathPrefix())
>> +cmGlobalNinjaGenerator::WriteDefault(os,
>> + outputs,
>> + "Make the all target the
>> default.");
>>
>> Missing braces.
>>
> Ok.
>
>>
>> +void
>> +cmGlobalNinjaGenerator::StripNinjaOutputPathPrefixAsSuffix(std::string*
>> path)
>> +{
>> + assert(path != NULL);
>>
>> More pointers :) .
>>
> Ok.
>
>>
>> + if (path->empty())
>> +return;
>>
>> And braces.
>>
> Ok.
>
> The fixes are that commit:
>
> https://github.com/nicolasdespres/CMake/commit/3fa749a19847898fcbb5635a273b0d02707dd4bd
>
>
>> As for the tests:
>>
>> + file(WRITE "${top_build_ninja}" "\
>> +subninja sub/build.ninja
>> +default sub/all
>> +")
>>
>> I think adding the (documented) bit:
>>
>> +rule RERUN
>> + command = true
>> + description = Testing regeneration
>> + generator = 1
>> +
>> +build build.ninja: RERUN || sub/build.ninja
>> + pool = console
>>
>> here and testing that if the CMakeLists.txt is touched that CMake reruns
>> would be worth it. It seems to work here, so keeping it working would be
>> great.
>>
>
> I guess that test should exist on the super-generator side. But it is
> probably safer to test it here too.
>
> The fix is in that commit:
>
> https://github.com/nicolasdespres/CMake/commit/13f341588bc6ee1cb0ec5dce8f44602f5d066ca9
>
> Tell me if you prefer I squash all the commits together before you review.
>
> Thanks,
>
> --
> Nicolas Desprès
>
--
Nicolas Desprès
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Using CMake generated ninja file as a subninja file
On Wed, Mar 9, 2016 at 9:41 PM, Ben Boeckel wrote:
> On Tue, Mar 08, 2016 at 12:36:31 +0100, Nicolas Desprès wrote:
> > Did you have a chance to review my patches?
>
> So I looked at it today, and it looks good overall. A few niggles:
>
Thanks
>
> +inline bool cmEndsWith(const std::string& str, const std::string& what)
> +{
> + assert(str.size() >= what.size());
>
> Probably better to just "return false;" if this would fire. Better than
> crashing if something in a release would have hit this.
>
>
Ok.
> + return str.compare(str.size() - what.size(), what.size(), what) == 0;
> +}
> +
> +inline void cmStripSuffixIfExists(std::string* str,
> + const std::string& suffix)
> +{
> + assert(str != NULL);
>
> Why not just use a reference rather than a pointer?
>
I don't like to use non-const reference argument because the caller may not
expect its variable to be modified since it not passed it by address.
Anyway, reference argument are used in other places in the source code so
it does not matter.
>
> + if (cmEndsWith(*str, suffix))
> +str->resize(str->size() - suffix.size());
>
> Missing braces.
>
Ok.
>
> -std::string cmGlobalNinjaGenerator::ConvertToNinjaPath(const std::string&
> path)
> +static void EnsureTrailingSlash(std::string* path)
> +{
> + assert(path != NULL);
>
> Same thing: why not a reference?
>
Done.
>
> + if (path->empty())
> +return;
> + std::string::value_type last = (*path)[path->size()-1];
> +#ifdef _WIN32
> + if (last != '\\')
> +*path += '\\';
> +#else
> + if (last != '/')
> +*path += '/';
> +#endif
>
> Missing braces in the if statements here.
>
>
Ok.
> - cmGlobalNinjaGenerator::WriteDefault(os,
> - outputs,
> - "Make the all target the
> default.");
> + if (!this->HasOutputPathPrefix())
> +cmGlobalNinjaGenerator::WriteDefault(os,
> + outputs,
> + "Make the all target the
> default.");
>
> Missing braces.
>
Ok.
>
> +void
> +cmGlobalNinjaGenerator::StripNinjaOutputPathPrefixAsSuffix(std::string*
> path)
> +{
> + assert(path != NULL);
>
> More pointers :) .
>
Ok.
>
> + if (path->empty())
> +return;
>
> And braces.
>
Ok.
The fixes are that commit:
https://github.com/nicolasdespres/CMake/commit/3fa749a19847898fcbb5635a273b0d02707dd4bd
> As for the tests:
>
> + file(WRITE "${top_build_ninja}" "\
> +subninja sub/build.ninja
> +default sub/all
> +")
>
> I think adding the (documented) bit:
>
> +rule RERUN
> + command = true
> + description = Testing regeneration
> + generator = 1
> +
> +build build.ninja: RERUN || sub/build.ninja
> + pool = console
>
> here and testing that if the CMakeLists.txt is touched that CMake reruns
> would be worth it. It seems to work here, so keeping it working would be
> great.
>
I guess that test should exist on the super-generator side. But it is
probably safer to test it here too.
The fix is in that commit:
https://github.com/nicolasdespres/CMake/commit/13f341588bc6ee1cb0ec5dce8f44602f5d066ca9
Tell me if you prefer I squash all the commits together before you review.
Thanks,
--
Nicolas Desprès
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Using CMake generated ninja file as a subninja file
Ben, Did you have a chance to review my patches? Cheers, Nicolas On Sunday, February 14, 2016, Nicolas Desprès wrote: > Ben, > > I have pushed a complete version of the patch here: > https://github.com/nicolasdespres/CMake/commits/ninja-output-path-prefix > > Since the last push, I have addressed the comments you made in your > previous review (i.e. move some code to cmAlgorithm.h) and added a > RunCMake.NinjaOutputPathPrefix tests. > > The 'default' statement is no longer generated when > CMAKE_NINJA_OUTPUT_PATH_PREFIX is set because, unlike rules, "default" > statement are not scoped. Thus, if the user does not include one in the top > build.ninja only the default target of the subninja file was built. This > was a surprising behaviour for me, since I expected to build all "leaf" > output targets of the graph as usual when running ninja without argument. > > Let me know what you think about this change. > > Last note: some of the tests were failing on master (dec7d5c4de7870ec) on > my machines (macbookpro and linux box), so I don't know if they are broken > or not by my patch: > 194 - CTestCoverageCollectGCOV (Failed) > 393 - RunCMake.CommandLine (Failed) > 401 - RunCMake.IfacePaths_INCLUDE_DIRECTORIES (Failed) > > Cheers, > Nicolas > > > > On Fri, Jan 22, 2016 at 5:50 PM, Ben Boeckel > wrote: > >> On Fri, Jan 22, 2016 at 17:34:03 +0100, Nicolas Desprès wrote: >> > I have pushed a first draft of the patch here: >> > >> > >> https://github.com/nicolasdespres/CMake/commit/67a4faad47378c07c97a29dd229d6f9fa500763b >> > >> > I have tested with a small project and it looks good. >> >> Looks like a good start to me as well. I added some comments on the >> commit. >> >> > I would like to add some regression tests but I don't know from where to >> > start. >> > >> > The principle would be to duplicate and modify existing tests so that >> > CMAKE_NINJA_OUTPUT_PATH_PREFIX is set to "sub/" and the build directory >> is >> > changed from _build to _build/sub. A dummy build.ninja file containing >> > "subninja sub/build.ninja" should be generated in _build/build.ninja and >> > ninja should be called from _build instead of _build/sub. >> > >> > It would be great if you could point me some existing tests that could >> > serve as a base to do the above. >> >> The RunCMake test infrastructure would probably be the best place to >> start. It could be modified to do some of this work. >> >> Thanks, >> >> --Ben >> > > > > -- > Nicolas Desprès > -- Nicolas Desprès -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Using CMake generated ninja file as a subninja file
Ben, I have pushed a complete version of the patch here: https://github.com/nicolasdespres/CMake/commits/ninja-output-path-prefix Since the last push, I have addressed the comments you made in your previous review (i.e. move some code to cmAlgorithm.h) and added a RunCMake.NinjaOutputPathPrefix tests. The 'default' statement is no longer generated when CMAKE_NINJA_OUTPUT_PATH_PREFIX is set because, unlike rules, "default" statement are not scoped. Thus, if the user does not include one in the top build.ninja only the default target of the subninja file was built. This was a surprising behaviour for me, since I expected to build all "leaf" output targets of the graph as usual when running ninja without argument. Let me know what you think about this change. Last note: some of the tests were failing on master (dec7d5c4de7870ec) on my machines (macbookpro and linux box), so I don't know if they are broken or not by my patch: 194 - CTestCoverageCollectGCOV (Failed) 393 - RunCMake.CommandLine (Failed) 401 - RunCMake.IfacePaths_INCLUDE_DIRECTORIES (Failed) Cheers, Nicolas On Fri, Jan 22, 2016 at 5:50 PM, Ben Boeckel wrote: > On Fri, Jan 22, 2016 at 17:34:03 +0100, Nicolas Desprès wrote: > > I have pushed a first draft of the patch here: > > > > > https://github.com/nicolasdespres/CMake/commit/67a4faad47378c07c97a29dd229d6f9fa500763b > > > > I have tested with a small project and it looks good. > > Looks like a good start to me as well. I added some comments on the > commit. > > > I would like to add some regression tests but I don't know from where to > > start. > > > > The principle would be to duplicate and modify existing tests so that > > CMAKE_NINJA_OUTPUT_PATH_PREFIX is set to "sub/" and the build directory > is > > changed from _build to _build/sub. A dummy build.ninja file containing > > "subninja sub/build.ninja" should be generated in _build/build.ninja and > > ninja should be called from _build instead of _build/sub. > > > > It would be great if you could point me some existing tests that could > > serve as a base to do the above. > > The RunCMake test infrastructure would probably be the best place to > start. It could be modified to do some of this work. > > Thanks, > > --Ben > -- Nicolas Desprès -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] ninja command line options not propagated to ninja invocation for superbuild projects
On Thu, Jan 28, 2016 at 5:18 PM, Brad King wrote: > On 01/28/2016 11:04 AM, Taylor Braun-Jones wrote: > > Is this expected behavior, a known bug, or a new bug that I should file? > > Currently it is expected, but I don't think anyone has thoroughly > investigated it or tried to implement it. IIRC it works in Makefile > generators only because the make tool does it under the hood when > one uses $(MAKE) in a makefile to run another make. It is a feature > of the build tool itself, not of CMake. Unless Ninja offers some > equivalent it may not be possible. > > Unfortunately, Ninja won't offer it: https://github.com/ninja-build/ninja/pull/1079 -- Nicolas Desprès -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Using CMake generated ninja file as a subninja file
Ben, I have pushed a first draft of the patch here: https://github.com/nicolasdespres/CMake/commit/67a4faad47378c07c97a29dd229d6f9fa500763b I have tested with a small project and it looks good. I would like to add some regression tests but I don't know from where to start. The principle would be to duplicate and modify existing tests so that CMAKE_NINJA_OUTPUT_PATH_PREFIX is set to "sub/" and the build directory is changed from _build to _build/sub. A dummy build.ninja file containing "subninja sub/build.ninja" should be generated in _build/build.ninja and ninja should be called from _build instead of _build/sub. It would be great if you could point me some existing tests that could serve as a base to do the above. Cheers, Nicolas On Wed, Jan 6, 2016 at 7:46 PM, Nicolas Desprès wrote: > > > On Wed, Jan 6, 2016 at 7:35 PM, Ben Boeckel > wrote: > >> On Wed, Jan 06, 2016 at 19:26:11 +0100, Nicolas Desprès wrote: >> > Is that variable already available or a name suggestion? I cannot find >> any >> > reference to it neither in the source nor in the documentation. >> >> It's a suggestion. >> > > Ok, works for me too. > > >> > This is acceptable for me since I have a custom generator that would >> write >> > the top build.ninja containing "subninja sub/build.ninja". The end-user >> is >> > supposed to run ninja from the top directory not from the top/sub/ >> > directory. >> >> It looks like subclassing cmLocalNinjaGenerator to override some >> path-related bits and it should work (though it has changed enough with >> cmState that I can't tell what exactly without doing more digging). >> >> The hardest problem is going to be with testing. Every generate step >> will also have to dump a build.ninja file out so that it can be properly >> tested. >> >> Brad is back later this week and may have other ideas too. >> >> I will try to have a patch working on a helloworld project first and I > will get back to you for the testing part. That would be the hardest part > indeed. > > Thanks for your help. > > -- > Nicolas Desprès > -- Nicolas Desprès -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Using CMake generated ninja file as a subninja file
On Wed, Jan 6, 2016 at 7:35 PM, Ben Boeckel wrote: > On Wed, Jan 06, 2016 at 19:26:11 +0100, Nicolas Desprès wrote: > > Is that variable already available or a name suggestion? I cannot find > any > > reference to it neither in the source nor in the documentation. > > It's a suggestion. > Ok, works for me too. > > This is acceptable for me since I have a custom generator that would > write > > the top build.ninja containing "subninja sub/build.ninja". The end-user > is > > supposed to run ninja from the top directory not from the top/sub/ > > directory. > > It looks like subclassing cmLocalNinjaGenerator to override some > path-related bits and it should work (though it has changed enough with > cmState that I can't tell what exactly without doing more digging). > > The hardest problem is going to be with testing. Every generate step > will also have to dump a build.ninja file out so that it can be properly > tested. > > Brad is back later this week and may have other ideas too. > > I will try to have a patch working on a helloworld project first and I will get back to you for the testing part. That would be the hardest part indeed. Thanks for your help. -- Nicolas Desprès -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Using CMake generated ninja file as a subninja file
On Wed, Jan 6, 2016 at 6:25 PM, Ben Boeckel wrote: > On Wed, Jan 06, 2016 at 11:14:32 +0100, Nicolas Desprès wrote: > > To enable this type of generation, the "top/" directory must be passed to > > CMake somehow. An environment variable or a CMake variable called > > CMAKE_NINJA_TOP_BUILD_DIR would do the trick. > > I think CMAKE_NINJA_OUTPUT_PATH_PREFIX would work fine (passed as a -D > on the command line). > Is that variable already available or a name suggestion? I cannot find any reference to it neither in the source nor in the documentation. > > Note that the ninja file CMake generates is then invalid except as a > subninja file (since the build rules paths won't line up from its > directory). I don't know how acceptable that would be. Maybe a separate > Subninja generator which uses it and writes out a build.subninja file > instead? > This is acceptable for me since I have a custom generator that would write the top build.ninja containing "subninja sub/build.ninja". The end-user is supposed to run ninja from the top directory not from the top/sub/ directory. -- Nicolas Desprès -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Using CMake generated ninja file as a subninja file
Hello, I would like to be able to use a build.ninja file generated by CMake as a subninja file of a super build.ninja file generated by a custom generator. This way I could include a CMake projects in a bigger one. Currently, I call ninja recursively to build the CMake sub-project. But this approach goes against ninja philosophy (one file to ease parallel job handling because recursive makefile are considered harmful, etc...) and the maintainers are not willing to accept patches to properly support it [1, 2]. Consider the following build directory layout: top/build.ninja top/sub/build.ninja Where: - top/build.ninja contains, among other things, "subninja sub/build.ninja" and is generated by a custom generator - "top/sub/build.ninja" is generated by CMake. To properly work, build edge outputs in "top/sub/build.ninja" must be relative to the "top/" directory. Currently, it is impossible because to generate the "top/sub/build.ninja" file CMake must be invoked like this: "cd top/sub && cmake -G Ninja ". It has no knowledge of the "top/" directory being special and generates all the outputs relative to the "top/sub/" directory instead of the "top/" directory. For example, we should have this kind of generated build statements for an helloworld project: build sub/build.ninja: RERUN_CMAKE build sub/clean: CLEAN build hello: C_EXECUTABLE_LINKER__hello sub/CMakeFiles/hello.dir/hello.c.o build sub/all: phony sub/hello default sub/all To enable this type of generation, the "top/" directory must be passed to CMake somehow. An environment variable or a CMake variable called CMAKE_NINJA_TOP_BUILD_DIR would do the trick. Note that such a change requires scoped rules which was introduced by ninja 1.6. [3] I am willing to write the patch if you think there is a chance that it will be accepted. Best regards, [1] https://github.com/ninja-build/ninja/pull/1079 [2] https://github.com/ninja-build/ninja/pull/1078 [3] https://ninja-build.org/manual.html#ref_scope -- Nicolas Desprès -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] What about #line like feature in cmake language?
On Fri, May 23, 2014 at 3:11 PM, Brad King wrote: > > That is what the above variables were meant to be. They just > happen to be implemented by replacing during variable evaluation > instead of by the lexer. Having the lexer do actual replacements > would be a change to the language beyond the scope of the #line > proposal. > I see... > > I think this issue as a reason to not add a #line feature. For > your generated source case you can add comments that refer back > to the original source locations for human reference. > Indeed it is not a strong requirement at your suggestion will work too. > I will think more about it and get back to you if I have another idea. Thanks for your time, -- Nicolas Desprès -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] What about #line like feature in cmake language?
On Thu, May 22, 2014 at 3:16 PM, Brad King wrote: > > One remaining challenge is CMAKE_CURRENT_LIST_FILE and > CMAKE_CURRENT_LIST_LINE. Since the "current file" is not > handled by the lexer these may not be consistent unless some > kind of refactoring is done in the language implementation. > However, it is not clear whether CMAKE_CURRENT_LIST_FILE can > safely refer back to some transformed location because sometimes > code uses it to look next to the file being processed to locate > other files. If some source location mapping is in place then > that may not be well-defined. > I think we should not touch those variables because they have dynamic behavior and if they are used in the generated code I expect the current behavior. Why not adding __FILE__ and __LINE__ tokens that would be expanded by the lexer with the file name and line number last set by #cmake-source-line? -- Nicolas Desprès -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] What about #line like feature in cmake language?
On Wed, May 21, 2014 at 9:31 PM, Matthew Woehlke < mw_tr...@users.sourceforge.net> wrote: > On 2014-05-21 15:24, Nicolas Desprès wrote: > > On Wed, May 21, 2014 at 8:06 PM, Matthew Woehlke wrote: > >> On 2014-05-15 08:36, Ben Boeckel wrote: > >>> This will also likely need a policy since there's no guarantee that > >>> #line "directives" don't exist in already existing code as comments. > >> > >> Maybe we should not introduce pragma-like constructs that are > >> indistinguishable from comments? :-) > >> > >> TBH I'd be a little ambivalent about such a feature. A line pragma > >> itself isn't too bad, but opening the door for other types of pragmas > >> makes me a little more nervous :-). > > > > If it is possible I would rather prefer a cmake macro too. > > I don't see why not... in fact it may be easier, since you won't have to > fiddle with the parsing at all. > Maybe because at the time the AST node is created the file location is frozen. Locations are controlled by the lexer so do comments. I am not exactly sure because I have not written a parser since a while. CMake's folk would confirm or not. -- Nicolas Desprès -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] What about #line like feature in cmake language?
On Wed, May 21, 2014 at 8:06 PM, Matthew Woehlke < mw_tr...@users.sourceforge.net> wrote: > On 2014-05-15 08:36, Ben Boeckel wrote: > > On Thu, May 15, 2014 at 12:45:27 +0200, Nicolas Desprès wrote: > >> Nope. These variables are the cmake equivalent to the __LINE__ and > __FILE__ > >> C-pre-processor macro. What I need is the #line directive equivalent > which > >> force the value of these variables so that error messages reported by > cmake > >> uses the forced value. > > > > If you'd like to try a patch, the relevant code is in > > Source/cmExprParser*. Add a callback for #line nnn and update the > > CurrentLine variable cmExprParserHelper.cxx. Don't forget tests :) . > > > > This will also likely need a policy since there's no guarantee that > > #line "directives" don't exist in already existing code as comments. > > Maybe we should not introduce pragma-like constructs that are > indistinguishable from comments? :-) > > TBH I'd be a little ambivalent about such a feature. A line pragma > itself isn't too bad, but opening the door for other types of pragmas > makes me a little more nervous :-). > > If it is possible I would rather prefer a cmake macro too. -- Nicolas Desprès -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] What about #line like feature in cmake language?
On Thu, May 15, 2014 at 4:05 PM, Brad King wrote: > > Since the files are generated there is no reason the syntax has to > be short. We could use: > > #cmake-generated-from-line 1234 "/path/to/real/file" > > or: > > #cmake-source-line 1234 "/path/to/real/file" > > That's true. I mentioned #line just because every programmer know it but I don't have any requirement on its name. -- Nicolas Desprès -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] What about #line like feature in cmake language?
On Thu, May 15, 2014 at 2:54 PM, Brad King wrote: > On 05/15/2014 08:36 AM, Ben Boeckel wrote: > > If you'd like to try a patch, the relevant code is in > > Source/cmExprParser*. Add a callback for #line nnn and update the > > CurrentLine variable cmExprParserHelper.cxx. Don't forget tests :) . > > cmExprParser is just for the math() command. The language parser > is "cmListFileLexer.in.l" and "cmListFileCache.cxx". Tracking of > the current source file may need to be moved. The lexer would have > to recognize #line syntax and update lexer->line. Be careful to > only do so in the main state and not inside a quoted or bracket > argument. > Thanks for the hints. I will be hard for me to work on it during the next weeks. It is just a plan I have. Do you think such a patch would be accepted after version 3 has been released? -- Nicolas Desprès -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] What about #line like feature in cmake language?
On Thu, May 15, 2014 at 10:15 AM, Eric Noulard wrote:
> 2014-05-15 10:08 GMT+02:00 Nicolas Desprès :
> > Hi,
> >
> > I am planning to develop a python generator of CMakeLists.txt file for
> > easier integration in an already existing tool. This approach is
> different
> > from the others approaches consisting in binding the CMake language in a
> > foreign languages. Lua, Javascript and Python have already been tried
> > without success to my knowledge. Generating CMakeLists.txt files seems a
> > simpler approach to me since the CMake language is very stable and it
> keeps
> > the two projects separated. Finally it reaches the same goal since the
> idea
> > behind binding CMake in a foreign language is too gain a more general
> > purpose and feature full language with a larger standard library.
> >
> > To assist in such a task the CMake language could provide a command
> similar
> > to the #line directive found in the C-pre-processor. Changing the
> filename
> > and line number in the CMakeLists.txt file would make the generator able
> to
> > transparently run CMake behind the scene while the errors reported by
> CMake
> > would still refer to the generator input file written by the user.
> >
> > The last time I checked I could not find such a feature in CMake.
>
> Did you check those var:
> CMAKE_CURRENT_LIST_DIR
> CMAKE_CURRENT_LIST_FILE
> CMAKE_CURRENT_LIST_LINE
>
> message(STATUS "${CMAKE_CURRENT_LIST_LINE}: ${CMAKE_CURRENT_LIST_FILE}
> Your message")
>
> should print the line number and filename with "Your message".
>
> Is it the kind of feature you are looking for?
>
> Nope. These variables are the cmake equivalent to the __LINE__ and
__FILE__ C-pre-processor macro. What I need is the #line directive
equivalent which force the value of these variables so that error messages
reported by cmake uses the forced value.
[...]
--
Nicolas Desprès
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] What about #line like feature in cmake language?
Hi, I am planning to develop a python generator of CMakeLists.txt file for easier integration in an already existing tool. This approach is different from the others approaches consisting in binding the CMake language in a foreign languages. Lua, Javascript and Python have already been tried without success to my knowledge. Generating CMakeLists.txt files seems a simpler approach to me since the CMake language is very stable and it keeps the two projects separated. Finally it reaches the same goal since the idea behind binding CMake in a foreign language is too gain a more general purpose and feature full language with a larger standard library. To assist in such a task the CMake language could provide a command similar to the #line directive found in the C-pre-processor. Changing the filenameand line number in the CMakeLists.txt file would make the generator able to transparently run CMakebehind the scene while the errors reported by CMake would still refer to the generator input file written by the user. The last time I checked I could not find such a feature in CMake. I am realizing that since version 3 is still under development it might be a good occasion to show up and mention it here. I think that it is not a big change to CMake and that it should not overload the maintenance process. I hope it is not too late for such a proposal since the 5th candidate has just been released. Best regards, -- Nicolas Desprès -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake 2.8.12-rc4 ready for testing!
Hi, I have just download, compile and run the test suite on my Linux machine and I have two failing tests: The following tests FAILED: 25 - FindPackageTest (Failed) 291 - CTestTestMemcheckDummyValgrindInvalidSupFile (Failed) This is probably due to my setup. I have attached the log to this post. Cheers, -Nico On Tue, Oct 1, 2013 at 10:49 PM, Robert Maynard wrote: > The CMake 2.8.12 release candidate stream continues! > Thanks to numerous CMake users we uncovered a couple of critical > regressions > in RC3. We expect that RC4 will be the final RC unless a new critical, > regression is discovered. You can find the source and binaries here: > http://www.cmake.org/files/v2.8/?C=M;O=D > > Some of the notable changes in this release are: > > - Introduced target_compile_options command > - Specify compile options to use when compiling a given target. Supports > PUBLIC, PRIVATE, and INTERFACE options. PRIVATE and PUBLIC items will > populate the COMPILE_OPTIONS property of the target. PUBLIC and > INTERFACE items will populate the INTERFACE_COMPILE_OPTIONS property > of the target. Supports generator expressions. > - Introduced add_compile_options command > - Adds options to the compiler command line for sources in the > current directory and below. Supports generator expressions. > - Introduced CMake Policy CMP0021: > - It is now an error to add relative paths to the INCLUDE_DIRECTORIES > target property. > - Introduced CMake Policy CMP0022: > - Target properties matching > (IMPORTED_)LINK_INTERFACE_LIBRARIES(_) > are ignored, and will no longer be populated by the > target_link_libraries > command. It is now an error to populate the properties directly in user > code. Instead use the INTERFACE keyword with target_link_libraries, or > the target property INTERFACE_LINK_LIBRARIES. > - Introduced CMake Policy CMP0023: > - Plain and keyword target_link_libraries signatures cannot be mixed for > a > given target when this policy is enabled. Once PUBLIC,PRIVATE, or > INTERFACE keywords are used, all subsequent target_link_libraries calls > to the target must use one of these keywords. > - Introduced: Support for RPATH under OSX > - Please see the blog post by Clinton Stimpson about using RPATH on OSX > (http://www.kitware.com/blog/home/post/510) > > - CMake: New PUBLIC PRIVATE and INTERFACE options for target_link_libraries > - CMake: New ALIAS targets feature > - CMake: Automatically process Headers directory of Apple Frameworks as > a usage requirement > - CMake: File command now supports the GENERATE command to produce files at > generate time > - CMake: target_include_directories now supports the SYSTEM parameter > - CMake: Add support for Java in cross compilation toolchains > - CMake: Improved support for the IAR toolchain > - CMake: Improved support for the ARM toolchain under Visual Studio > - CMake: Improvements to the Visual Studio Generators Including > - Separate compiler and linker PDB files > - Support for subdirectory MSBuild projects > - Support for assembly code to VS10 > - Support for Windows CE to VS11 > - CMake: Added COMPILE_OPTIONS target property. > - CMake: Added INTERFACE_LINK_LIBRARIES added as a property to targets > - CMake: Now supports .zip files with the tar command > - CMake: try_compile now supports multiple source files > - CMake: Optimized custom command dependency lookup > - CMake: Removal of configured files will retrigger CMake when issuing a > build command > - CMake: Ninja now tracks custom command generated files that aren't listed > as output > - CMake: Added generator expression support for compiler versions > - CMake-Gui: Add search functions for Output window > - CTest: Improved memory checker support > - FindGTK2: General Improvements > - FindCUDA: Multiple improvements to the custom commands > > > The bug tracker change log page for this version is at: > http://public.kitware.com/Bug/changelog_page.php?version_id=112 > > The complete list of changes in RC4 since RC3 can be found at: > http://www.cmake.org/Wiki/CMake/ChangeLog > > As this is expected to be the last RC release please test it and report any > regressions to the list or the bug tracker. > > Thanks > -- > > 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 > -- Nicolas Desprès test.log Description:
Re: [cmake-developers] CMake is slow for project with hundred target and one command with large number of dependencies
On Tue, Aug 6, 2013 at 10:19 PM, Brad King wrote: > On 08/06/2013 01:30 PM, Brad King wrote: > > IMO it is not worth the effort to establish this test. > > I've applied a patch based on yours to implement the > optimization and merged to 'next' for testing tonight: > > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2268c41a > > Thank you very much for your help. I guess this topic is closed now. Sorry for not answering earlier. I was away from keyboard (time shift). I will delete my branches tomorrow. -Nico -- 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 is slow for project with hundred target and one command with large number of dependencies
On Tue, Aug 6, 2013 at 4:31 PM, Brad King wrote:
> On 08/06/2013 09:40 AM, Nicolas Desprès wrote:
> > I have force-pushed all the fixes you've asked for:
>
> Great, thanks!
>
> > * I taught cmMakefile copy-ctor
>
> Good.
>
> > * I re-write the test so that it is part of CMakeOnly sub-test suite. I
> also make it more robust to machine load by increasing the number of
> targets. This way the performance gap between the logarithmic version and
> the linear version is bigger. On my machine the logarithmic version run in
> 60sec
> > whereas the linear version had not finished after 10min. The timeout is
> at 90sec now. When running the whole test suite in parallel with 8 jobs it
> passes.
>
> Okay. Timing-dependent tests have been frequently sporadic on
> our test infrastructure because the machines are often busy
> with other projects' tests and there is a wide variety of
> machine speeds available. We'll see how it goes.
>
Sure.
>
> > * I added a test covering the issue I got while testing the previous
> buggy version of the optimized algorithm. This is a very weird bug. Master
> does not suffer from it, neither this topic branch. Basically the previous
> version had problem with empty dependency and it was not covered by the test
> > suite. I think there is something else involved in this test case
> because the test file named "0" is important too. At least the test is here
> now and we could investigate that later if it fails again.
>
> It looks like
>
> + add_test_macro(EmptyDepAndZeroOutput
> +${CMAKE_CMAKE_COMMAND} -P check.cmake)
>
> appears twice, once in each test addition commit.
>
Oups. Squashing error. Fixed now.
>
> While hunting down all the call sites for GetSourceFileWithOutput
> I found two that are not needed and removed them:
>
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eccb39d7
>
> Please rebase your topic on that.
>
> I still can't convince myself that the comparison function is
> correct. Also as Steve suggested it will be faster to use a
> standard ordering function. That should work if we always
> use it with full paths. The expected use cases always use
> full paths and it is only for backward compatibility that we
> support the path suffix magic. Therefore I think the best
> approach is to optimize the common (full-path) case with a
> direct lookup, perhaps even with "cmsys/hash_map.hxx". Only
> when the input path is relative should we fall back to the
> linear suffix search for compatibility.
Good idea! I should have done that in the first place it would have save me
a lot of effort understanding the old behavior.
> The test suite passes on my computer. I have force-pushed again.
However I had one problem with BootstrapTest when trying to use
cmsys::hash_map. I pushed by work so far on this topic in another branch (
https://github.com/nicolasdespres/CMake/commits/topic/use-cmsys-hash_map):
https://github.com/nicolasdespres/CMake/commit/1437d51a87b5a5a131b3829210710734266d29cc
I did not succeed to teach the bootstrap script how to include cstddef.
Cheers,
--
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] CMake is slow for project with hundred target and one command with large number of dependencies
Hi Brad, I have force-pushed all the fixes you've asked for: * I taught cmMakefile copy-ctor * I re-write the test so that it is part of CMakeOnly sub-test suite. I also make it more robust to machine load by increasing the number of targets. This way the performance gap between the logarithmic version and the linear version is bigger. On my machine the logarithmic version run in 60sec whereas the linear version had not finished after 10min. The timeout is at 90sec now. When running the whole test suite in parallel with 8 jobs it passes. * I added a test covering the issue I got while testing the previous buggy version of the optimized algorithm. This is a very weird bug. Master does not suffer from it, neither this topic branch. Basically the previous version had problem with empty dependency and it was not covered by the test suite. I think there is something else involved in this test case because the test file named "0" is important too. At least the test is here now and we could investigate that later if it fails again. Let me know what do you think. Thanks, -Nico On Mon, Aug 5, 2013 at 10:50 PM, Brad King wrote: > On 08/05/2013 04:37 PM, Nicolas Desprès wrote: > > * Why is special logic in Tests/CMakeLists.txt needed to add > > the test case? > > > > Since it is a performance test on configuration phase only, I need a > > specific timeout value and to run cmake only > > Take a look at the Tests/RunCMake and Tests/CMakeOnly groups of > tests. They are for running CMake without building. > > -Brad > -- 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] CMake is slow for project with hundred target and one command with large number of dependencies
On Mon, Aug 5, 2013 at 9:50 PM, Brad King wrote: > On 08/05/2013 12:06 PM, Brad King wrote: > > Here are a couple comments: > > Also I think the cmMakefile copy constructor needs to be taught > about the member you're adding. > Yep I do that tomorrow morning. It is late now in France. -- 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] CMake is slow for project with hundred target and one command with large number of dependencies
On Mon, Aug 5, 2013 at 6:06 PM, Brad King wrote: > On 08/05/2013 11:28 AM, Nicolas Desprès wrote: > > I have just rebased my branch on top of the master and the test suite > still pass. > [snip] > > I really want to have this patch in the next release > > I can't promise to accept it since 2.8.12 rc1 is coming out > tomorrow or Wednesday and this topic isn't even in 'next' yet. > This touches some pretty fundamental logic and could easily > have a subtle behavior change so I consider it high risk. > I understand. I have just found an issue that is not covered by CMake's test suite. It happens when one of the file path is empty. I will add a test for this case tomorrow. > > On 07/29/2013 08:25 AM, Stephen Kelly wrote: > > I think Brad will have to do the rest. > > Sorry, I stopped reading this thread assuming that it would end > with Steve bringing the change to the topic stage at which point > my attention would be drawn again. > No problem. > > I just fetched the large-deps-perf topic from your Github repo. > I've never been happy with the linear search so thanks for working > on this. Here are a couple comments: > > * Please replace large_list.cmake in the test with use of the > foreach() command's RANGE signature and list(APPEND). > Done. > > * Why is special logic in Tests/CMakeLists.txt needed to add > the test case? > Since it is a performance test on configuration phase only, I need a specific timeout value and to run cmake only (neither make, nor any extra program built the test project). I have added a comment saying so. > > * Please add comments explaining in prose what the lookup map > comparison functor is doing and why. I could infer it only > by looking at the old code (which should have been commented > before too). The assert examples are good for verification > but not for understanding from scratch. > I added the comment. I hope it is understandable. The best would be to have a unit test for this method but I can't think of a simple way to do it since there will be too many objects to mock. I have pushed a bunch of fixup commit if you want to review them. I will squash them tomorrow. Thanks, -- 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] CMake is slow for project with hundred target and one command with large number of dependencies
Hi, I have just rebased my branch on top of the master and the test suite still pass. I have a real world example here with performance. My project's build system has 7113 commands to run. This is roughly 7 commands for each input files. There are 1000 inputs files. Just for the configuration step: cmake latest release takes 59:50.10 minutes cmake with my branch takes 1:06.98 minutes So it is about an hour with the latest release and 1 minutes with the patch. I have updated the code, so I hope it will be clearer now. I really want to have this patch in the next release, since I cannot use cmake for my project otherwise. I can work full time on this patch until the end of this week if there is something to change. Cheers, -Nico On Mon, Jul 29, 2013 at 2:40 PM, Nicolas Desprès wrote: > > > > On Mon, Jul 29, 2013 at 2:25 PM, Stephen Kelly wrote: > >> Nicolas Desprès wrote: >> >> >> Also, I don't see why the custom comparison functor is needed at all. I >> >> removed it and sped up the test significantly. Can you explain? >> >> >> > >> > I had some failing tests because the previous algorithm was not a plain >> > strcpy(). >> >> I don't see any strcpy(). Anyway, I think that's as much useful review I >> can >> do for you. I think Brad will have to do the rest. >> >> > Arg. Sorry for being unclear (English is not my mother tongue). > > The std::less comparator do the same thing (as strcpy() < 0). > Unfortunately, we cannot use it here because the previous (O(N)) > implementation of cmMakefile::GetSourceFileWithOutput(const char*) was more > complex than that (have a look to the code my path replaces). Of course, I > first tried with the default comparator to save me some work but some tests > were failing. Namely: ExportImport and CustomCommand. > > Hope this help. > Thanks for your time. > -Nico > > -- 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] CMake is slow for project with hundred target and one command with large number of dependencies
On Mon, Jul 29, 2013 at 2:25 PM, Stephen Kelly wrote: > Nicolas Desprès wrote: > > >> Also, I don't see why the custom comparison functor is needed at all. I > >> removed it and sped up the test significantly. Can you explain? > >> > > > > I had some failing tests because the previous algorithm was not a plain > > strcpy(). > > I don't see any strcpy(). Anyway, I think that's as much useful review I > can > do for you. I think Brad will have to do the rest. > > Arg. Sorry for being unclear (English is not my mother tongue). The std::less comparator do the same thing (as strcpy() < 0). Unfortunately, we cannot use it here because the previous (O(N)) implementation of cmMakefile::GetSourceFileWithOutput(const char*) was more complex than that (have a look to the code my path replaces). Of course, I first tried with the default comparator to save me some work but some tests were failing. Namely: ExportImport and CustomCommand. Hope this help. Thanks for your time. -Nico -- 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 is slow for project with hundred target and one command with large number of dependencies
On Mon, Jul 29, 2013 at 2:09 PM, Stephen Kelly wrote:
> Nicolas Desprès wrote:
>
> > On Mon, Jul 29, 2013 at 12:57 PM, Stephen Kelly
> > wrote:
> >
> >> Nicolas Desprès wrote:
> >> > It was fastest because it was not doing the right thing. I tried to
> >> > patch it properly and the benchmark are the same whether we use the
> >> > default comparison functor or mine.
> >> >
> >> > So I think you can merge it like that. I have pushed a new version
> >> without
> >> > the comment.
> >> >
> >>
> >> I still haven't tried it, but there are still style issues.
> >
> >
> >> * Don't put an else after a return
> >> * Wrap single line blocks in {}
> >>
> >
> > Fixed and force-pushed. Sorry for the inconvenience. I am not used to
> this
> > style yet.
>
> Your Compare::operator() contains this:
>
> if (j == s2.rend())
>{
>return false;
>}
> return false;
>
> Any reason not to simplify that?
>
Because I used to have a comment in the else branch of the if, that I
removed because part of it was wrong
https://github.com/nicolasdespres/CMake/commit/59c871da8b00554812e93ba9c6e47d864424efb0#L0R2023(the
part about the optimization). Then I kept the code without thinking
more about it.
>
> Also, I don't see why the custom comparison functor is needed at all. I
> removed it and sped up the test significantly. Can you explain?
>
I had some failing tests because the previous algorithm was not a plain
strcpy().
I have restored the comment. I prefer to keep the too branch even if both
return false to make it clear that the comment apply only in this case and
that it is the only difference with a normal strcpy(3) algorithm.
Cheers,
--
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] CMake is slow for project with hundred target and one command with large number of dependencies
On Mon, Jul 29, 2013 at 12:57 PM, Stephen Kelly wrote:
> Nicolas Desprès wrote:
> > It was fastest because it was not doing the right thing. I tried to patch
> > it properly and the benchmark are the same whether we use the default
> > comparison functor or mine.
> >
> > So I think you can merge it like that. I have pushed a new version
> without
> > the comment.
> >
>
> I still haven't tried it, but there are still style issues.
> * Don't put an else after a return
> * Wrap single line blocks in {}
>
Fixed and force-pushed. Sorry for the inconvenience. I am not used to this
style yet.
Thanks for the review.
-Nico
--
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 is slow for project with hundred target and one command with large number of dependencies
On Wed, Jul 24, 2013 at 10:48 AM, Nicolas Desprès wrote: > > > > On Tue, Jul 23, 2013 at 5:59 PM, Stephen Kelly wrote: > >> Nicolas Desprès wrote: >> >> > Hi Stephen, >> > >> > Did you have any chance to look at the code? I would love to see it >> > integrated in the next release. That being said, there is no pressure. >> > >> >> I'll have a look now. >> > Thanks! > >> >> >> +UpdateOutputToSourceMap(outputs, file); >> >> is missing a 'this->', as per the style. There's a couple of repeats of >> that. >> > Done > >> >> Please rename >> >> typedef std::map OutputToInputMap; >> >> to OutputToSourceMap for similarity to the OutputToSource variable. >> > Done > >> >> I haven't tried it out yet, but it looks sane to me. The >> UpdateOutputToSourceMap could probably be faster if outputs is sorted and >> you use lower-bound insertion in a loop over the map or so. If it's fast >> enough already though, probably no need for that :). >> > Currently, it is fast enough. The path to optimize was search not the > insertion. I have not noticed any performance regression in the insertion. > I liked your idea of inserting in at the end of list/vector and then to > sort it once the configuration is done but I am afraid this require more > knowledge of cmake code base than I have and the patch will be harder to > write. > > That's said we can optimize further as I mentioned in my comment ( > https://github.com/nicolasdespres/CMake/commit/59c871da8b00554812e93ba9c6e47d864424efb0#L0R2023). > Do you have an opinion about it? > > That was not true! It was fastest because it was not doing the right thing. I tried to patch it properly and the benchmark are the same whether we use the default comparison functor or mine. So I think you can merge it like that. I have pushed a new version without the comment. Thaks, -- 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] CMake is slow for project with hundred target and one command with large number of dependencies
On Wed, Jul 24, 2013 at 7:56 PM, Nicolas Desprès wrote: > > > > On Wed, Jul 24, 2013 at 12:18 PM, Stephen Kelly wrote: > >> Nicolas Desprès wrote: >> >> >> > That's said we can optimize further as I mentioned in my comment ( >> >> > >> >> >> >> >> >> https://github.com/nicolasdespres/CMake/commit/59c871da8b00554812e93ba9c6e47d864424efb0#L0R2023 >> >> ). >> >> > Do you have an opinion about it? >> >> >> >> Do I understand correctly that the issue is that OutputToSource values >> >> can be absolute or relative paths? That would be fixable by patching >> only >> >> UpdateOutputToSourceMap, right? >> >> >> > Not exactly. According to my tests only >> > cmMakefiles::GetSourceFileWithOutput's cname argument can be either >> > relative or absolute. >> >> Then patching the callers of GetSourceFileWithOutput is worth looking >> into. >> There are not many. You'd have to try it and see if any issues come up. >> >> Ok. I will give it a try tomorrow. I hope it won't bring in part of CMake > I do not know. > > Hi Stephen, I think I need your insight of CMake code base here. According to my tests (ie ExportImport and CustomCommand), GetSourceFileWithOutput() is called with a relative path only from here: https://github.com/Kitware/CMake/blob/master/Source/cmTarget.cxx#L1939 How can I convert this name to an absolute path? Cheers, -- 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] CMake is slow for project with hundred target and one command with large number of dependencies
On Wed, Jul 24, 2013 at 12:18 PM, Stephen Kelly wrote: > Nicolas Desprès wrote: > > >> > That's said we can optimize further as I mentioned in my comment ( > >> > > >> > >> > > https://github.com/nicolasdespres/CMake/commit/59c871da8b00554812e93ba9c6e47d864424efb0#L0R2023 > >> ). > >> > Do you have an opinion about it? > >> > >> Do I understand correctly that the issue is that OutputToSource values > >> can be absolute or relative paths? That would be fixable by patching > only > >> UpdateOutputToSourceMap, right? > >> > > Not exactly. According to my tests only > > cmMakefiles::GetSourceFileWithOutput's cname argument can be either > > relative or absolute. > > Then patching the callers of GetSourceFileWithOutput is worth looking into. > There are not many. You'd have to try it and see if any issues come up. > > Ok. I will give it a try tomorrow. I hope it won't bring in part of CMake I do not know. Cheers, -Nico -- 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 is slow for project with hundred target and one command with large number of dependencies
On Wed, Jul 24, 2013 at 11:29 AM, Stephen Kelly wrote:
> Nicolas Desprès wrote:
>
> >> +UpdateOutputToSourceMap(outputs, file);
> >>
> >> is missing a 'this->', as per the style. There's a couple of repeats of
> >> that.
> >>
> > Done
>
> You seem to have missed this one.
>
> There are also other style issues.
>
> * Don't put an else after a return
> * Wrap single line blocks in {}
>
> Done. I hope I did them all.
>
> > That's said we can optimize further as I mentioned in my comment (
> >
>
> https://github.com/nicolasdespres/CMake/commit/59c871da8b00554812e93ba9c6e47d864424efb0#L0R2023
> ).
> > Do you have an opinion about it?
>
> Do I understand correctly that the issue is that OutputToSource values can
> be absolute or relative paths? That would be fixable by patching only
> UpdateOutputToSourceMap, right?
>
Not exactly. According to my tests only
cmMakefiles::GetSourceFileWithOutput's cname argument can be either
relative or absolute. When the mapping table is updated it always get an
absolute path. The previous code of GetSourceFileWithOutput() supported
both relative and absolute paths.
Here my test setup:
diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index b68460d..d035e25 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -1029,6 +1029,10 @@ void
cmMakefile::UpdateOutputToSourceMap(const std::string& output,
cmSourceFile* source)
{
+ std::cout << "UPDATE: " << source->GetFullPath()
+<< " -> "
+<< output
+<< std::endl;
this->OutputToSource[output] = source;
}
@@ -2051,6 +2055,7 @@ cmMakefile::Compare::operator()(const std::string& s1,
cmSourceFile *cmMakefile::GetSourceFileWithOutput(const char *cname)
{
std::string name = cname;
+ std::cout << "QUERY: " << name << std::endl;
OutputToSourceMap::iterator o = this->OutputToSource.find(name);
if (o != this->OutputToSource.end())
{
Now when I run either:
ctest -VV -R ExportImport | tee /tmp/ImportExport-master.log
or
ctest -VV -R '^CustomCommand$' | tee /tmp/CustomCommand-master.log
I get some relative path in the QUERY debug message. That's reason why I
wrote the Compare functor because those tests were failing after my first
patch.
I hope it is clearer now.
Cheers,
-Nico
--
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 is slow for project with hundred target and one command with large number of dependencies
On Tue, Jul 23, 2013 at 5:59 PM, Stephen Kelly wrote: > Nicolas Desprès wrote: > > > Hi Stephen, > > > > Did you have any chance to look at the code? I would love to see it > > integrated in the next release. That being said, there is no pressure. > > > > I'll have a look now. > Thanks! > > > +UpdateOutputToSourceMap(outputs, file); > > is missing a 'this->', as per the style. There's a couple of repeats of > that. > Done > > Please rename > > typedef std::map OutputToInputMap; > > to OutputToSourceMap for similarity to the OutputToSource variable. > Done > > I haven't tried it out yet, but it looks sane to me. The > UpdateOutputToSourceMap could probably be faster if outputs is sorted and > you use lower-bound insertion in a loop over the map or so. If it's fast > enough already though, probably no need for that :). > Currently, it is fast enough. The path to optimize was search not the insertion. I have not noticed any performance regression in the insertion. I liked your idea of inserting in at the end of list/vector and then to sort it once the configuration is done but I am afraid this require more knowledge of cmake code base than I have and the patch will be harder to write. That's said we can optimize further as I mentioned in my comment ( https://github.com/nicolasdespres/CMake/commit/59c871da8b00554812e93ba9c6e47d864424efb0#L0R2023). Do you have an opinion about it? > I'd say the topic can be cleaned up and force pushed for another review. > Done. -Nico -- 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 is slow for project with hundred target and one command with large number of dependencies
Hi Stephen, Did you have any chance to look at the code? I would love to see it integrated in the next release. That being said, there is no pressure. Thanks, -Nico On Tue, Jul 16, 2013 at 1:40 PM, Nicolas Desprès wrote: > Hi Stephen, > > I have pushed more commits and now the problem is fixed and all the test > suite passes on my machine. > > However it could even be faster. See my comment > in cmMakefile::Compare::operator(): > https://github.com/nicolasdespres/CMake/blob/7c873c8f3e0b893b1a96d8097105aa79e0477651/Source/cmMakefile.cxx#L2023-L2036 > > What do you think? > > Have a good day, > Nico > > > > > On Mon, Jul 15, 2013 at 5:33 PM, Nicolas Desprès < > nicolas.desp...@gmail.com> wrote: > >> >> >> >> On Mon, Jul 15, 2013 at 1:51 PM, Stephen Kelly wrote: >> >>> Nicolas Desprès wrote: >>> >>> >> Yes that one or cmMakefile::GetSourceFileWithOutput(char const*). I >>> can >>> >> send you a gzipped of my callgrind data off-list if you want (it >>> >> weights 534K). >>> >> >>> > If we had a map associating each input to output, we could maybe have >>> > better performance. WDYT? >>> >>> Perhaps. I can probably create the same callgrind data locally anyway, >>> but I >>> won't have a change until later to dig into this. >>> >>> On looking at the cmMakefile::GetSourceFileWithOutput code though, it >>> seems >>> that it might also be useful to maintain this->SourceFiles >>> and (*i)->GetCustomCommand()->GetOutputs() as sorted vectors. They are >>> rarely modified, so the O(1) -> O(log N) inserts probably won't matter >>> much, >>> but the O(N) -> O(log N) might provide a useful gain. Or, as most access >>> is >>> at generate time, keep the O(1) insertions, sort() after the configure >>> step, >>> and then use the binary search at generate time. Of course, I don't know >>> if >>> there are also configure-time accesses which would be difficult to >>> isolate >>> from the generate-time ones. >>> >>> Does that make any sense? >>> >> >> I think so. >> >> I fixed my "timeout" problem for writing the test, and pushed a first >> draft of a commit fixing this issue. >> >> I have the remaining test failling: >> 56 - ExportImport (Failed) >> 87 - CustomCommand (Failed) >> >> I will investigate them tomorrow. >> >> -- >> Nicolas Desprès >> > > > > -- > Nicolas Desprès > -- 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] How to set environment variable for custom command.
On Fri, Jul 19, 2013 at 8:29 PM, Alan W. Irwin wrote:
> On 2013-07-19 12:35-0400 Matthew Woehlke wrote:
>
> On 2013-07-19 10:36, Nicolas Desprès wrote:
>>
>>> In Unix shell we can do that:
>>> $ VAR=foo cmd in out
>>>
>>> This way the environment variable is only set in the environment of the
>>> process of the command and not the in current shell like when using the
>>> "export" built-in.
>>>
>>> I would like to be able to do the same for a custom command in CMake.
>>> Ideally I was looking for something like that:
>>>
>>> add_custom_command(
>>>OUTPUT out
>>>COMMAND cmd in out
>>>DEPENDS in
>>>ENVIRONMENT VAR foo
>>>)
>>>
>>> Any idea?
>>>
>>
>> Well, if you only care about UNIX you can always use /bin/env :-).
>>
>
> Actually, using env is not that platform-limiting since it is
> available with MSYS. For those not aware of the env capabilities a
> simple example (setting the PATH in various ways to run different
> cmake varsions) is
>
> COMMAND ${ENV_EXECUTABLE} PATH= ${CMAKE_COMMAND} --version
>
> where ENV_EXECUTABLE is the result of "find_program(ENV_EXECUTABLE
> env)". Also note that env can be used to set multiple environment
> variables for a particular command.
>
> I use env a lot for the custom commands in the build_projects project.
> I have found it works fine (with some care) for a number of different
> generators/platforms, e.g., "Unix Makefiles" on Linux, "Ninja" (both
> on Linux and for MinGW/MSYS/Windows), "MSYS Makefiles", "MinGW
> Makefiles", and "NMake Makefiles Jom".
>
>
That's greate. I did not think about it. Actually, like many developpers I
guess, I use env only the she-bang line of my script or to print the
environment.
Thanks!
--
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
[cmake-developers] How to set environment variable for custom command.
Hi, In Unix shell we can do that: $ VAR=foo cmd in out This way the environment variable is only set in the environment of the process of the command and not the in current shell like when using the "export" built-in. I would like to be able to do the same for a custom command in CMake. Ideally I was looking for something like that: add_custom_command( OUTPUT out COMMAND cmd in out DEPENDS in ENVIRONMENT VAR foo ) Any idea? Cheers, -- 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] How to set environment variable for custom command.
Sorry wrong ML :(. On Fri, Jul 19, 2013 at 4:36 PM, Nicolas Desprès wrote: > Hi, > > In Unix shell we can do that: > $ VAR=foo cmd in out > > This way the environment variable is only set in the environment of the > process of the command and not the in current shell like when using the > "export" built-in. > > I would like to be able to do the same for a custom command in CMake. > Ideally I was looking for something like that: > > add_custom_command( > OUTPUT out > COMMAND cmd in out > DEPENDS in > ENVIRONMENT VAR foo > ) > > Any idea? > > Cheers, > > -- > Nicolas Desprès > -- 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] CMake is slow for project with hundred target and one command with large number of dependencies
Hi Stephen, I have pushed more commits and now the problem is fixed and all the test suite passes on my machine. However it could even be faster. See my comment in cmMakefile::Compare::operator(): https://github.com/nicolasdespres/CMake/blob/7c873c8f3e0b893b1a96d8097105aa79e0477651/Source/cmMakefile.cxx#L2023-L2036 What do you think? Have a good day, Nico On Mon, Jul 15, 2013 at 5:33 PM, Nicolas Desprès wrote: > > > > On Mon, Jul 15, 2013 at 1:51 PM, Stephen Kelly wrote: > >> Nicolas Desprès wrote: >> >> >> Yes that one or cmMakefile::GetSourceFileWithOutput(char const*). I can >> >> send you a gzipped of my callgrind data off-list if you want (it >> >> weights 534K). >> >> >> > If we had a map associating each input to output, we could maybe have >> > better performance. WDYT? >> >> Perhaps. I can probably create the same callgrind data locally anyway, >> but I >> won't have a change until later to dig into this. >> >> On looking at the cmMakefile::GetSourceFileWithOutput code though, it >> seems >> that it might also be useful to maintain this->SourceFiles >> and (*i)->GetCustomCommand()->GetOutputs() as sorted vectors. They are >> rarely modified, so the O(1) -> O(log N) inserts probably won't matter >> much, >> but the O(N) -> O(log N) might provide a useful gain. Or, as most access >> is >> at generate time, keep the O(1) insertions, sort() after the configure >> step, >> and then use the binary search at generate time. Of course, I don't know >> if >> there are also configure-time accesses which would be difficult to isolate >> from the generate-time ones. >> >> Does that make any sense? >> > > I think so. > > I fixed my "timeout" problem for writing the test, and pushed a first > draft of a commit fixing this issue. > > I have the remaining test failling: > 56 - ExportImport (Failed) > 87 - CustomCommand (Failed) > > I will investigate them tomorrow. > > -- > Nicolas Desprès > -- 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] CMake is slow for project with hundred target and one command with large number of dependencies
On Mon, Jul 15, 2013 at 1:51 PM, Stephen Kelly wrote: > Nicolas Desprès wrote: > > >> Yes that one or cmMakefile::GetSourceFileWithOutput(char const*). I can > >> send you a gzipped of my callgrind data off-list if you want (it > >> weights 534K). > >> > > If we had a map associating each input to output, we could maybe have > > better performance. WDYT? > > Perhaps. I can probably create the same callgrind data locally anyway, but > I > won't have a change until later to dig into this. > > On looking at the cmMakefile::GetSourceFileWithOutput code though, it seems > that it might also be useful to maintain this->SourceFiles > and (*i)->GetCustomCommand()->GetOutputs() as sorted vectors. They are > rarely modified, so the O(1) -> O(log N) inserts probably won't matter > much, > but the O(N) -> O(log N) might provide a useful gain. Or, as most access is > at generate time, keep the O(1) insertions, sort() after the configure > step, > and then use the binary search at generate time. Of course, I don't know if > there are also configure-time accesses which would be difficult to isolate > from the generate-time ones. > > Does that make any sense? > I think so. I fixed my "timeout" problem for writing the test, and pushed a first draft of a commit fixing this issue. I have the remaining test failling: 56 - ExportImport (Failed) 87 - CustomCommand (Failed) I will investigate them tomorrow. -- 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] CMake is slow for project with hundred target and one command with large number of dependencies
On Mon, Jul 15, 2013 at 12:45 PM, Nicolas Desprès wrote: > > > > On Mon, Jul 15, 2013 at 11:53 AM, Stephen Kelly wrote: > >> Nicolas Desprès wrote: >> >>> > I have pushed my work so far on my github clone of CMake. >> >>> > https://github.com/nicolasdespres/CMake/tree/topic/large-deps-perf >> >>> >> >> Thanks. The bottleneck seems to be in >> >> cmTargetTraceDependencies::FollowName >> >> as it follows each entry in the LARGE_LIST for each of the 100 targets. >> > > Yes that one or cmMakefile::GetSourceFileWithOutput(char const*). I can > send you a gzipped of my callgrind data off-list if you want (it > weights 534K). > If we had a map associating each input to output, we could maybe have better performance. WDYT? > > > >> >> >> >> I also cleaned that up a bit. >> >> At least ninja_convenience_targets seems to be obsolete too? I didn't >> check >> the others. Just looking through my 'git branch -a' output :). >> >> > That's right. I have deleted it. > Thanks, > Nico > > -- 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] CMake is slow for project with hundred target and one command with large number of dependencies
On Mon, Jul 15, 2013 at 11:53 AM, Stephen Kelly wrote: > Nicolas Desprès wrote: > >>> > I have pushed my work so far on my github clone of CMake. > >>> > https://github.com/nicolasdespres/CMake/tree/topic/large-deps-perf > >>> > > Thanks. The bottleneck seems to be in > > cmTargetTraceDependencies::FollowName > > as it follows each entry in the LARGE_LIST for each of the 100 targets. > Yes that one or cmMakefile::GetSourceFileWithOutput(char const*). I can send you a gzipped of my callgrind data off-list if you want (it weights 534K). > >> > >> I also cleaned that up a bit. > > At least ninja_convenience_targets seems to be obsolete too? I didn't check > the others. Just looking through my 'git branch -a' output :). > > That's right. I have deleted it. Thanks, Nico -- 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 is slow for project with hundred target and one command with large number of dependencies
On Sat, Jul 13, 2013 at 10:21 AM, Nicolas Desprès wrote:
>
>
>
> On Fri, Jul 12, 2013 at 11:35 PM, Stephen Kelly wrote:
>
>> Nicolas Desprès wrote:
>>
>> > I have pushed my work so far on my github clone of CMake.
>> > https://github.com/nicolasdespres/CMake/tree/topic/large-deps-perf
>>
>> Something must have gone wrong with the push :)
>>
>> Oups, sorry :(. Friday evening after a long hard week...
>
This is now fixed. The patch is 3ac529b4a568dbd78d7ccd9b0ec1443efd75f6ae
>
>
>> stephen@hal:~/dev/src/cmake{master}$ git show origin/master | grep
>> commit
>> commit b9412889e9c5028e32ef3b978d8cdd1175f14b0f
>> stephen@hal:~/dev/src/cmake{master}$ git show nicolasdespres/topic/large-
>> deps-perf | grep commit
>> commit b9412889e9c5028e32ef3b978d8cdd1175f14b0f
>>
>> I noticed a lot of obsolete branches in your clone. I noticed a lot of
>> branches, but mostly it looks like ninja stuff that's already been merged.
>> Is there anything else interesting there?
>>
>> Yes I have many old branches I should get rid of. There is only the
> topic/large-deps-perf branch interesting at the moment. I pushed one commit
> on it containing the test I mentioned above. All that work is on my
> computer at the office so I could only fix the push on monday morning.
> Sorry again.
>
> I also cleaned that up a bit.
Have a good day,
--
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] CMake is slow for project with hundred target and one command with large number of dependencies
On Fri, Jul 12, 2013 at 11:35 PM, Stephen Kelly wrote:
> Nicolas Desprès wrote:
>
> > I have pushed my work so far on my github clone of CMake.
> > https://github.com/nicolasdespres/CMake/tree/topic/large-deps-perf
>
> Something must have gone wrong with the push :)
>
> Oups, sorry :(. Friday evening after a long hard week...
> stephen@hal:~/dev/src/cmake{master}$ git show origin/master | grep commit
> commit b9412889e9c5028e32ef3b978d8cdd1175f14b0f
> stephen@hal:~/dev/src/cmake{master}$ git show nicolasdespres/topic/large-
> deps-perf | grep commit
> commit b9412889e9c5028e32ef3b978d8cdd1175f14b0f
>
> I noticed a lot of obsolete branches in your clone. I noticed a lot of
> branches, but mostly it looks like ninja stuff that's already been merged.
> Is there anything else interesting there?
>
> Yes I have many old branches I should get rid of. There is only the
topic/large-deps-perf branch interesting at the moment. I pushed one commit
on it containing the test I mentioned above. All that work is on my
computer at the office so I could only fix the push on monday morning.
Sorry again.
Cheers,
--
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
[cmake-developers] CMake is slow for project with hundred target and one command with large number of dependencies
Hi all,
I am using CMake again since a couple of weeks for a project involving the
build of recognition system. This system is made of hundred sub recognition
system that must be all trained with about ~10k files as input.
I ended up writing something like that:
== BEGIN
# A project with hundred targets depending on one command with 10k
dependencies.
cmake_minimum_required(VERSION 2.8)
project(HundredTargetsDepOnOneCommandWithManyDeps)
include(CTest)
# Define LARGE_LIST with 1 input files.
include(large_list.cmake)
foreach(i ${LARGE_LIST})
file(WRITE ${i} "input")
endforeach(i)
add_custom_command(
OUTPUT bottle_neck
COMMAND ${CMAKE_COMMAND} -E touch bottle_neck
DEPENDS ${LARGE_LIST}
COMMENT "Executing command with large number of dependencies..."
)
set(OUTPUTS )
foreach(i RANGE 100)
set(_output output_${i})
add_custom_target(${_output}-target ALL
DEPENDS bottle_neck
)
list(APPEND OUTPUTS ${_output})
endforeach(i)
add_executable(AlwaysTrue AlwaysTrue.c)
== END
Note that the hundred targets have only one dependency. Running CMake on
this project is slow. The configuration is fast but the generation is very
slow. Here some examples:
With Unix Makefiles
$ time make rebuild_cache
Running CMake to regenerate build system...
-- Configuration done
(this is long)
-- Generation done
(this is long)
-- Build files have been written to: ...
make rebuild_cache 120.54s user 6.08s system 97% cpu 2:10.07 total
Memory used is normal (htop indicates 82488 VIRT) and CPU is at 100%.
$ time make
make 129.46s user 3.76s system 99% cpu 2:14.28 total
With Ninja:
$ time ninja -v rebuild_cache
ninja rebuild_cache 98.89s user 0.10s system 99% cpu 1:39.02 total
$ time ninja
ninja 0.01s user 0.04s system 86% cpu 0.055 total
So here my two questions:
1/ Do you think it is possible to improve the performance? (I have not
profile it yet).
2/ Is there a way to set a timeout to ctest so that my test fail. I have
that in Tests/CMakeLists.txt but it does not work:
set(_test_name HundredTargetsDepOnOneCommandWithManyDeps)
add_test(${_test_name} ${CMAKE_CTEST_COMMAND}
--build-and-test
"${CMake_SOURCE_DIR}/Tests/${_test_name}"
"${CMake_BINARY_DIR}/Tests/${_test_name}"
--build-two-config
${build_generator_args}
--build-project ${_test_name}
--timeout 10
--test-command AlwaysTrue)
list(APPEND TEST_BUILD_DIRS
"${CMake_BINARY_DIR}/Tests/${_test_name}")
unset(_test_name)
I have pushed my work so far on my github clone of CMake.
https://github.com/nicolasdespres/CMake/tree/topic/large-deps-perf
I am willing to do the work on this topic but I wanted to have your insight
first.
Thanks,
--
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] [CMake] please review: fix UseJava.cmake to support dependent jars
On Sun, Mar 17, 2013 at 10:49 AM, Nicolas Desprès wrote: > On Thu, Mar 14, 2013 at 3:57 PM, Brad King wrote: > >> On 03/14/2013 10:47 AM, Matthew Woehlke wrote: >> > This is now pushed to stage/fix-java-jar-depends. If someone >> > knowledgeable could have a look, that would be much appreciated. >> >> Andreas, Nicholas? >> >> Sorry for the delayed response, but I have no longer that much time to > spent on CMake, unfortunately. > > I have reviewed the patches and they look good to m. I cannot test them > because I am no longer working on the Java project I used to do my previous > patches to this module. I know someone who is still working on so I have > asked him to give it a try. > He said that the project is not broken by the new patches. -- 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] [CMake] please review: fix UseJava.cmake to support dependent jars
On Thu, Mar 14, 2013 at 3:57 PM, Brad King wrote: > On 03/14/2013 10:47 AM, Matthew Woehlke wrote: > > This is now pushed to stage/fix-java-jar-depends. If someone > > knowledgeable could have a look, that would be much appreciated. > > Andreas, Nicholas? > > Sorry for the delayed response, but I have no longer that much time to spent on CMake, unfortunately. I have reviewed the patches and they look good to m. I cannot test them because I am no longer working on the Java project I used to do my previous patches to this module. I know someone who is still working on so I have asked him to give it a try. Cheers, -- 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] CTEST_USE_LAUNCHERS and Ninja
On Sun, Oct 14, 2012 at 4:38 AM, Mathias Gaunard < mathias.gaun...@ens-lyon.org> wrote: > CTEST_USE_LAUNCHERS is a feature that allows better reporting of > compilation errors to a dashboard. > Unfortunately, it only works with the Makefile generator. > > Since ninja is significantly faster and just plain better, I use ninja on > all the builders in my test farm. > > I'd like to know if there is any plan to add CTEST_USE_LAUNCHERS support > to Ninja. > If someone is willing to guide me (I have no idea how to do this and this > option seems barely documented), I can try to implement it. > You could try to compare the output of the Makefile generator test related to this feature and the Ninja generator one. If there is no test maybe a good start would be to add one. -- 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] Mantis limitation
I personally use the "Lazareus: Form Recovery" web browser extension for this purpose. I have never lost any typed message since it is enabled. Available for Chrome and Firefox. On Mon, Aug 27, 2012 at 4:24 PM, David Cole wrote: > That would be awesome. I HATE it when that happens to me in Mantis (at > least once every few months, and it's always very irritating...) > > I'll ask our sysadmin guys, don't know if there's a Mantis update we > could take or something but I'll ask. > > > On Sun, Aug 26, 2012 at 2:44 AM, Eric Noulard > wrote: > > Hi Guys, > > > > Is there anything that can be done with the Mantis Installation that > > prevent loosing > > a comment when session expired? > > > > I got caught several time and it looks like I'm not alone > > on this: > > http://public.kitware.com/Bug/view.php?id=13490#c30764 > > > > Now when I type a long comment I do it in a text editor and > > copy/paste it to mantis form in order to be sure not to loose > > it. > > > > May be it can fixed on Mantis side? > > -- > > Erk > > Le gouvernement représentatif n'est pas la démocratie -- > > http://www.le-message.org > > -- > > > > 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 > -- 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] [CMake] Ninja: files per second
On Sat, Jul 28, 2012 at 11:43 AM, Shlomi Fish wrote: [...] > 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? > > Hi Shlomi, I have sent a pull request that should address your issue and initiated the discussion here: https://groups.google.com/forum/?hl=en&fromgroups#!topic/ninja-build/_xvapjxWDig. Vote for it :) Here the required patches for CMake: https://github.com/polrop/CMake/commits/ninja/flush_long_output https://github.com/polrop/CMake/commit/a757a6518868b09c5beb1ef591430b8c5d50bd59 Cheers, Nico -- 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
Thanks for the feedback. Here the patches to cherry-pick: https://github.com/polrop/CMake/commit/af6b1979071e463ae397d3512e3a0366b58919f8 https://github.com/polrop/CMake/commit/be8039fab069b0efb2469932617b3ca8826d1865 Cheers, Nico On Sat, Jul 21, 2012 at 1:32 PM, David Cole 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] Ninja passes all tests on OS X
On Wed, Jul 18, 2012 at 12:10 PM, Peter Kümmel wrote:
> On 18.07.2012 11:58, Nicolas Desprès wrote:
>>
>> On Tue, Jul 17, 2012 at 11:39 PM, Bill Hoffman
>> 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.
>
Ok. So I let you fix these errors too:
http://open.cdash.org/viewBuildError.php?buildid=2449176
Good luck,
Nico
--
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 Tue, Jul 17, 2012 at 11:39 PM, Bill Hoffman 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
--
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 Tue, Jul 17, 2012 at 7:21 PM, Peter Kümmel wrote: > 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. > I tried that first but this imply the use of function pointer which is not appropriated with non-static member functions. That's why I have used a function object. -Nico -- 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 Tue, Jul 17, 2012 at 7:01 PM, Peter Kümmel wrote: > On 17.07.2012 15:39, Nicolas Desprès wrote: >> >> On Tue, Jul 17, 2012 at 3:29 PM, Bill Hoffman >> 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" > I don't like the friend keyword either but I try to follow the current architecture of CMake. 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 -- 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] Ninja passes all tests on OS X
On Tue, Jul 17, 2012 at 3:29 PM, Bill Hoffman 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 -- 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
I have pushed a new version of ninja-fix-macosx which fix BundleTest, CFBundleTest, enable them for clang and re-factor some code. Tested on MacOSX and Linux. Let me know what do you think. https://github.com/polrop/CMake/commits/ninja-fix-macosx Cheers, Nico On Tue, Jul 10, 2012 at 4:55 PM, Peter Kümmel wrote: > On 10.07.2012 16:41, Nicolas Desprès wrote: >> >> On Tue, Jul 10, 2012 at 2:51 PM, Peter Kümmel wrote: >>> >>> 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::vector const& >>> sources); >>> void WriteMacOSXContentRules(cmSourceFile& source, const char* pkgloc); >>> >>> in class cmMakefileTargetGenerator. >>> >> >> Peter, >> >> Thanks for the feedback. After a deeper look, the BundleTest is not >> enabled on my platform. That's why I did not see it. >> >> It is protected by this condition: >>IF (APPLE AND CMAKE_COMPILER_IS_GNUCXX) >> >> APPLE is true, but CMAKE_COMPILER_IS_GNUCXX is not. My compiler was: >> >> Apple clang version 3.1 (tags/Apple/clang-318.0.45) (based on LLVM 3.1svn) >> Target: x86_64-apple-darwin11.4.0 >> Thread model: posix >> >> I'm going to try with g++, but why is this test only required for GNU >> compiler? Isn't clang concerned too? > > > Yes, I think you could enable the test also for clang, as clang mostly is a > drop in for ggc. > >> >> Cheers, >> Nico >> > -- > > 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 -- 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] Why not disable the Unix Makefiles generator for Darwin?
I am almost ready to push a branch fixing all the failing tests on
Darwin with Ninja. So it is coming soon.
Cheers,
Nico
On Sat, Jul 14, 2012 at 2:33 PM, Claus Klein wrote:
> I am wondering why Nina generator is disabled on Darwin.
> I have just the same problems with Unix Makefile generator?
>
> Or it would be nice to enable Ninja too for Darwin, I need it to cross
> compile my projects ...
>
> Claus
>
> See
>
> http://open.cdash.org/index.php?project=CMake&display=project&filtercount=3&showfilters=1&filtercombine=and&field1=buildname/string&compare1=65&value1=Darwin-i386&field2=site/string&compare2=61&value2=claus-kleins-macbook-pro.local&field3=buildstamp/string&compare3=66&value3=Experimental&collapse=0
>
> The test is based on current nightly build.
>
> But I use the newest MacPorts gcc-4.7:
>
> $ sw_vers
> ProductName: Mac OS X
> ProductVersion: 10.5.8
> BuildVersion: 9L30
>
> $ i386-apple-darwin9-gcc-4.7.1 --version
> i386-apple-darwin9-gcc-4.7.1 (MacPorts gcc47 4.7.1_1) 4.7.1
> Copyright (C) 2012 Free Software Foundation, Inc.
>
> I make sure, that this generator and tools are used while cmake selftest!
>
> export CC=/opt/local/bin/i386-apple-darwin9-gcc-mp-4.7
> export CXX=/opt/local/bin/i386-apple-darwin9-g++-mp-4.7
> export MAKECOMMAND=/opt/local/bin/gmake
>
> # configure
> /opt/local/bin/cmake -G "Unix Makefiles" -DCMAKE_TEST_GENERATOR:STRING="Unix
> Makefiles" \
> -DCMAKE_TEST_MAKEPROGRAM:FILEPATH="${MAKECOMMAND}"
> -DCMAKE_ENABLE_NINJA:BOOL="ON" \
> -DCMAKE_C_COMPILER=${CC} -DCMAKE_CXX_COMPILER=${CXX} \
> -DCMAKE_LINKER:FILEPATH=/opt/local/bin/ld \
> -DCMAKE_AR:FILEPATH=/opt/local/bin/i386-apple-darwin9-gcc-ar-mp-4.7 \
>
> -DCMAKE_RANLIB:FILEPATH=/opt/local/bin/i386-apple-darwin9-gcc-ranlib-mp-4.7
> \
> -DMAKECOMMAND:STRING="${MAKECOMMAND}" \
>
> -DCMAKE_FIND_ROOT_PATH="/opt/local/libexec/gcc/i386-apple-darwin9/4.7.1/;/opt/local/bin"
> \
> \
> -DBUILD_CursesDialog:BOOL="ON" -DBUILD_QtDialog:BOOL="OFF" \
> ../cmake
>
>
> gmake Experimental
> ...
>
>
>
> --
>
> 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
--
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] Ninja passes all tests on OS X
On Tue, Jul 10, 2012 at 2:51 PM, Peter Kümmel wrote: > 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::vector const& sources); > void WriteMacOSXContentRules(cmSourceFile& source, const char* pkgloc); > > in class cmMakefileTargetGenerator. > Peter, Thanks for the feedback. After a deeper look, the BundleTest is not enabled on my platform. That's why I did not see it. It is protected by this condition: IF (APPLE AND CMAKE_COMPILER_IS_GNUCXX) APPLE is true, but CMAKE_COMPILER_IS_GNUCXX is not. My compiler was: Apple clang version 3.1 (tags/Apple/clang-318.0.45) (based on LLVM 3.1svn) Target: x86_64-apple-darwin11.4.0 Thread model: posix I'm going to try with g++, but why is this test only required for GNU compiler? Isn't clang concerned too? Cheers, Nico -- 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 selftest use different compiler and binutils as configured on Darwin
Hi Claus,
Have a look here: http://kennethreitz.com/xcode-gcc-and-homebrew.html
I advice you to install the Apple command line tools for xcode and
stop to use gcc.
Cheers,
Nico
On Sat, Jul 7, 2012 at 8:58 PM, Claus Klein wrote:
> I tried to check if ninja works now on Darwin, but some tests still fails.
>
> I use this configuration, but I have the gcc-4.7 installed too under
> /opt/local/bin.
>
> /usr/local/bin/cmake -G "Ninja" -DCMAKE_TEST_GENERATOR:STRING="Ninja" \
> -DCMAKE_TEST_MAKEPROGRAM:FILEPATH="${MAKECOMMAND}"
> -DCMAKE_ENABLE_NINJA:BOOL="ON" \
> -DCMAKE_C_COMPILER="/opt/local/libexec/ccache/gcc-4.2"
> -DCMAKE_CXX_COMPILER="/opt/local/libexec/ccache/g++-4.2" \
> -DCMAKE_LINKER:FILEPATH=/usr/bin/ld \
> -DCMAKE_AR:FILEPATH=/usr/bin/ar \
> -DCMAKE_RANLIB:FILEPATH=/usr/bin/ranlib \
> -DMAKECOMMAND:STRING="${MAKECOMMAND} -d stats" \
> -DBUILD_CursesDialog:BOOL="ON" -DBUILD_QtDialog:BOOL="OFF" \
> ../cmake
>
>
> The build works fine, but some test still fails!
> see http://open.cdash.org/viewTest.php?onlyfailed&buildid=2421596
>
> As you can see at build command, the configured binutils are not used while
> test?
>
>
> Than I tried this:
> claus-kleins-macbook-pro:CmakeNinjaBuildDir clausklein$
> /Users/clausklein/Downloads/CmakeNinjaBuildDir/bin/ctest "--build-and-test"
> "/Users/clausklein/Downloads/cmake/Tests/Architecture"
> "/Users/clausklein/Downloads/CmakeNinjaBuildDir/Tests/Architecture"
> "--build-two-config" "--build-generator" "Ninja" "--build-makeprogram"
> "/opt/local/bin/ninja" "--build-options"
> -DCMAKE_C_COMPILER="/opt/local/libexec/ccache/gcc-4.2"
> -DCMAKE_CXX_COMPILER="/opt/local/libexec/ccache/g++-4.2"
> -DCMAKE_LINKER:FILEPATH=/usr/bin/ld -DCMAKE_AR:FILEPATH=/usr/bin/ar
> -DCMAKE_RANLIB:FILEPATH=/usr/bin/ranlib
> Internal cmake changing into directory:
> /Users/clausklein/Downloads/CmakeNinjaBuildDir/Tests/Architecture
> CMake output ==
> is_xcode4='0'
> archs=''
> arch0='i386'
> arch1='ppc'
> Configuring
> Configuring done
> Generating
> Generating done
> CMake Warning:
> Manually-specified variables were not used by the project:
>
> CMAKE_CXX_COMPILER
>
>
> Build files have been written to:
> /Users/clausklein/Downloads/CmakeNinjaBuildDir/Tests/Architecture
> is_xcode4='0'
> archs=''
> arch0='i386'
> arch1='ppc'
> Configuring
> Configuring done
> Generating
> Generating done
> CMake Warning:
> Manually-specified variables were not used by the project:
>
> CMAKE_CXX_COMPILER
>
>
> Build files have been written to:
> /Users/clausklein/Downloads/CmakeNinjaBuildDir/Tests/Architecture
> End CMake output ==
> Change Dir:
> /Users/clausklein/Downloads/CmakeNinjaBuildDir/Tests/Architecture
>
> Run Clean Command:/opt/local/bin/ninja -t clean
> Cleaning... 5 files.
>
> Run Build Command:/opt/local/bin/ninja
> [1/4] Building C object CMakeFiles/foo.dir/foo.c.o
> [2/4] Linking C static library libfoo.a
> [3/4] Building C object CMakeFiles/bar.dir/bar.c.o
> [4/4] Linking C executable Architecture
> FAILED: : && /opt/local/libexec/ccache/gcc-4.2 -arch ppc -isysroot
> /Developer/SDKs/MacOSX10.5.sdk -Wl,-search_paths_first
> -Wl,-headerpad_max_install_names CMakeFiles/bar.dir/bar.c.o -o
> Architecture libfoo.a && :
> ld warning: in libfoo.a, file is not of required architecture
> Undefined symbols:
> "_foo", referenced from:
> _main in bar.c.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> ninja: build stopped: subcommand failed.
> claus-kleins-macbook-pro:CmakeNinjaBuildDir clausklein$
>
> What goes wrong with this test?
>
> //Regards
> Claus
>
>
>
>
>
>
> --
>
> 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
--
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] Ninja passes all tests on OS X
On Sat, Jul 7, 2012 at 9:02 PM, Claus Klein wrote: > On 07.07.2012, at 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. > > > Which OS version and Tools do you have installed? Mac OS X 10.7.4 Apple clang version 3.1 (tags/Apple/clang-318.0.45) (based on LLVM 3.1svn) Target: x86_64-apple-darwin11.4.0 Thread model: posix > > I merged in your patch and have still Problems? > > see http://open.cdash.org/viewTest.php?onlyfailed&buildid=2421596 > FAILED: /opt/local/bin/gcc -arch ppc -isysroot /Developer/SDKs/MacOSX10.5.sdk -MMD -MT CMakeFiles/bar.dir/bar.c.o -MF "CMakeFiles/bar.dir/bar.c.o.d" -o CMakeFiles/bar.dir/bar.c.o -c /Users/clausklein/Downloads/cmake/Tests/Architecture/bar.c gcc: error: unrecognized option '-arch' Looks like you have a problem with your setup. Cheers, Nico -- 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 Fri, Jul 6, 2012 at 9:56 PM, Bill Hoffman wrote: > On 7/6/2012 12:45 PM, Nicolas Desprčs wrote: >> >> Both work. Generally I use helper class with language not supporting >> multiple inheritance but if you prefer not to use it that's not a >> problem. I'll do the patch. Thanks for answering. > > Great, thanks for doing the work. Lets go with the helper class, should be > pretty easy to implement. > > Thanks again. 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. > > Only one thing left that the ninja generator won't do correctly. It won't > build fortran 90 code with modules. I posted to the ninja list, but no one > seems interested in helping to solve the problem... :( I'm afraid there is not so many people interested in Fortran 90 support :(. I think the problem would be the same in C++ if we had to use CMake's own dependency parser instead of -M options. In this case, my first try would be to generate the build.ninja once the dependency scan has been done. When the dependencies change the build.ninja would have to be rewritten. Cheers, Nico -- 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 Fri, Jul 6, 2012 at 3:52 PM, Bill Hoffman wrote: > On 7/6/2012 7:33 AM, Nicolas Desprès wrote: >> >> I agree. Any idea how you would like to re-factor it? I am thinking >> about using multiple inheritance by introducing a cmOSXBundleGenerator >> class with CreateFramework and CreateAppBundle. WDYT? >> >> Cheers, >> Nico > > Thanks, this is great. > > I am not a big fan of multiple inheritance. What about a helper class? > cmOSXBundleCreator with the two methods and a pointer to the target and the > makefile. > Both work. Generally I use helper class with language not supporting multiple inheritance but if you prefer not to use it that's not a problem. I'll do the patch. Thanks for answering. Cheers, Nico -- 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 Fri, Jul 6, 2012 at 1:29 PM, Peter Kümmel wrote: > 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! > Thanks Peter. Happy to read that. Nico -- 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
I agree. Any idea how you would like to re-factor it? I am thinking about using multiple inheritance by introducing a cmOSXBundleGenerator class with CreateFramework and CreateAppBundle. WDYT? Cheers, Nico On Fri, Jul 6, 2012 at 1:13 PM, David Cole wrote: > We should re-factor it sooner (not later). > > This is great, thank you very much! > > But we should definitely re-factor it before merging it to 'master' > > > Thx, > David > > > On Fri, Jul 6, 2012 at 7:05 AM, Nicolas Desprès > wrote: >> I forgot to say that most of the code is duplicated from the Makefile >> generator. I have left some todo but this code will need to be >> factored sooner or later. >> >> On Fri, Jul 6, 2012 at 12:54 PM, 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. >>> >>> Cheers, >>> Nico >> >> >> >> -- >> 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 -- 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] Ninja passes all tests on OS X
I forgot to say that most of the code is duplicated from the Makefile generator. I have left some todo but this code will need to be factored sooner or later. On Fri, Jul 6, 2012 at 12:54 PM, 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. > > Cheers, > Nico -- 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
[cmake-developers] Ninja passes all tests on OS X
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. Cheers, Nico -- 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] Github pull request for UseJava
Brad, This issue must be closed. It has been fixed by these patches: 18e8d2f0ccfd853425c86b092693ac11db9ab906 525bb92a3d4149aae1b268315ac746a6142d1fec 17a8e16cd243f06597ad1246775f80fc5a4337b4 Cheers, -Nico On Fri, May 25, 2012 at 3:05 PM, Brad King wrote: > Andreas, Nicolas, > > Please take a look at this request: > > https://github.com/Kitware/CMake/pull/9 > > You can fetch the branch like this: > > $ git fetch git://github.com/viandfraich/CMake.git > add_executable_jar-in-UseJava > $ git checkout -b add_executable_jar-in-UseJava 717f1586 > > Thanks, > -Brad -- 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] Supported targets with the ninja generator ?
On Thu, Apr 19, 2012 at 5:11 PM, Nicolas Desprès wrote: > 2012/4/5 Nicolas Desprès : >> On Thu, Apr 5, 2012 at 9:44 PM, David Cole wrote: > [...] >>> >>> It would be very simple to add a "clean" target that simply executes >>> "ninja -t clean" as a custom command, if the ninja generator guys >>> think that's a reasonable idea to keep things similar to the Makefiles >>> generator. >> >> Sounds reasonnable. >> > > I have just pushed on my GitHub CMake fork a branch called > 'ninja_convenience_targets' that implement that: > https://github.com/polrop/CMake/commits/ninja_convenience_targets > I know this branch does not solved all the issues mentioned in this thread but it is a good start. Could somebody have a look at them David please? @alex This is not Ninja philosophy to add such target name so I have added them only because you ask for them for Eclipse. I hope they will help you. For your information, I have tried (without any hope) to add them to Ninja it self (https://github.com/martine/ninja/pull/275 and https://github.com/martine/ninja/pull/276) but they have been rejected. Thanks, -- 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] Test suite broken if PackageMaker not installed in default location
On Tue, May 1, 2012 at 5:51 PM, Eric Noulard wrote: > 2012/5/1 David Cole : >>> >>> That's what I saw actually, but mine was not in the list. Setting >>> CPACK_INSTALLER_PROGRAM as in line 390 does not help because the it is >>> not "transfered" to the test project. >>> >>> Is there a robust way to tell cmake where is installed PackageMaker if >>> it is not installed in one of the searched paths? >>> >> >> Not yet, but we can definitely fix that moving forward. > > Some CPack generators assumes some commands are found. > RPM assumes rpmbuild > NSIS assumes makensis > PackageMaker assumes PackageMaker > > simply testing the system (APPLE, LINUX, Windows...) may not be enough > or even worse (or better depending on your opinion), some people > may want to uses some unusual packager on particular system > like using DEB or RPM on MacOS: > see http://public.kitware.com/Bug/view.php?id=13064 > > Some tests in CMake source tree already checks that the required tool > is found **before** adding the test but it causes code duplication. > (because users may have to do the very same check in their project) > so may be we need something like: > > cpack -G --check-only that would verify that the > CPack generator may be run? Why not creating a CMakeFindPackageMaker.cmake instead of making it built-in the C++ code? Most of the other "build tools" required by cmake already have their module like: CMakeUnixFindMake.cmake, CMakeFindXCode.cmake, CMakeNinjaFindMake.cmake, etc... > > Concerning a way to make CPACK_INSTALLER_PROGRAM be > transmitted to the test, it's possible if we define a CPack Project Config > file > template for this test and forward the definition of CPACK_INSTALLER_PROGRAM > done at CMake time (using configure_file on the CPack project config > file) to CPack time. > That's a good idea. Also, if not found the CPACK_INSTALLER_PROGRAM is not set to NOT-FOUND. Using a module as I suggested above could give use a variable to set via the GUI. Thanks, -Nico -- 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.Install test broken on MacOSX Lion XCode 4.3
Hi,
If you enable CMake_TEST_INSTALL=ON (not enabled by default) you have
one more test: CMake.Install and it fails with the following errors on
my machine (MacOSX Lion, XCode 4.3, cmake master):
1: -- fixup_bundle: preparing...
1: -- fixup_bundle: copying...
1: -- 1/28: *NOT* copying
'/Users/polrop/src/cmake/_build/Tests/CMakeInstall/CMake
2.8-8.app/Contents/bin/ccmake'
1: -- 2/28: *NOT* copying
'/Users/polrop/src/cmake/_build/Tests/CMakeInstall/CMake
2.8-8.app/Contents/bin/cmake'
1: -- 3/28: *NOT* copying
'/Users/polrop/src/cmake/_build/Tests/CMakeInstall/CMake
2.8-8.app/Contents/bin/cmake-gui'
1: -- 4/28: copying '/usr/X11/lib/libpng15.15.dylib'
1: -- 5/28: copying
'/usr/local/Cellar/qt/4.8.1/lib/QtCore.framework/Versions/4/QtCore'
1: -- 6/28: copying
'/usr/local/Cellar/qt/4.8.1/lib/QtGui.framework/Versions/4/QtGui'
1: -- 7/28: *NOT* copying
'/Users/polrop/src/cmake/_build/Tests/CMakeInstall/CMake
2.8-8.app/Contents/bin/cmakexbuild'
1: -- 8/28: *NOT* copying
'/Users/polrop/src/cmake/_build/Tests/CMakeInstall/CMake
2.8-8.app/Contents/bin/cpack'
1: -- 9/28: *NOT* copying
'/Users/polrop/src/cmake/_build/Tests/CMakeInstall/CMake
2.8-8.app/Contents/bin/ctest'
1: -- 10/28: copying '/usr/local/lib/libxmlrpc.3.16.dylib'
1: -- 11/28: copying '/usr/local/lib/libxmlrpc_client.3.16.dylib'
1: -- 12/28: copying '/usr/local/lib/libxmlrpc_util.3.16.dylib'
1: -- 13/28: *NOT* copying
'/Users/polrop/src/cmake/_build/Tests/CMakeInstall/CMake
2.8-8.app/Contents/MacOS/CMake 2.8-8'
1: -- 14/28: *NOT* copying
'/Users/polrop/src/cmake/_build/Tests/CMakeInstall/CMake
2.8-8.app/Contents/share/cmake-2.8/Modules/CPack.OSXScriptLauncher.in'
1: -- fixup_bundle: fixing...
1: -- 15/28: fixing up
'/Users/polrop/src/cmake/_build/Tests/CMakeInstall/CMake
2.8-8.app/Contents/bin/ccmake'
1: -- 16/28: fixing up
'/Users/polrop/src/cmake/_build/Tests/CMakeInstall/CMake
2.8-8.app/Contents/bin/cmake'
1: -- 17/28: fixing up
'/Users/polrop/src/cmake/_build/Tests/CMakeInstall/CMake
2.8-8.app/Contents/bin/cmake-gui'
1: -- 18/28: fixing up
'/Users/polrop/src/cmake/_build/Tests/CMakeInstall/CMake
2.8-8.app/Contents/MacOS/libpng15.15.dylib'
1: -- 19/28: fixing up
'/Users/polrop/src/cmake/_build/Tests/CMakeInstall/CMake
2.8-8.app/Contents/Frameworks/QtCore.framework/Versions/4/QtCore'
1: install_name_tool: can't open input file:
/Users/polrop/src/cmake/_build/Tests/CMakeInstall/CMake
2.8-8.app/Contents/Frameworks/QtCore.framework/Versions/4/QtCore for
writing (Permission denied)
1: install_name_tool: can't lseek to offset: 0 in file:
/Users/polrop/src/cmake/_build/Tests/CMakeInstall/CMake
2.8-8.app/Contents/Frameworks/QtCore.framework/Versions/4/QtCore for
writing (Bad file descriptor)
1: install_name_tool: can't write new headers in file:
/Users/polrop/src/cmake/_build/Tests/CMakeInstall/CMake
2.8-8.app/Contents/Frameworks/QtCore.framework/Versions/4/QtCore (Bad
file descriptor)
1: install_name_tool: can't close written on input file:
/Users/polrop/src/cmake/_build/Tests/CMakeInstall/CMake
2.8-8.app/Contents/Frameworks/QtCore.framework/Versions/4/QtCore (Bad
file descriptor)
1: -- 20/28: fixing up
'/Users/polrop/src/cmake/_build/Tests/CMakeInstall/CMake
2.8-8.app/Contents/Frameworks/QtGui.framework/Versions/4/QtGui'
1: install_name_tool: can't open input file:
/Users/polrop/src/cmake/_build/Tests/CMakeInstall/CMake
2.8-8.app/Contents/Frameworks/QtGui.framework/Versions/4/QtGui for
writing (Permission denied)
1: install_name_tool: can't lseek to offset: 0 in file:
/Users/polrop/src/cmake/_build/Tests/CMakeInstall/CMake
2.8-8.app/Contents/Frameworks/QtGui.framework/Versions/4/QtGui for
writing (Bad file descriptor)
1: install_name_tool: can't write new headers in file:
/Users/polrop/src/cmake/_build/Tests/CMakeInstall/CMake
2.8-8.app/Contents/Frameworks/QtGui.framework/Versions/4/QtGui (Bad
file descriptor)
1: install_name_tool: can't close written on input file:
/Users/polrop/src/cmake/_build/Tests/CMakeInstall/CMake
2.8-8.app/Contents/Frameworks/QtGui.framework/Versions/4/QtGui (Bad
file descriptor)
That's because they are readonly. If you change the code like this:
diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake
index 0143d59..d664e92 100644
--- a/Modules/BundleUtilities.cmake
+++ b/Modules/BundleUtilities.cmake
@@ -585,9 +585,9 @@ function(fixup_bundle_item resolved_embedded_item
exepath dirs)
endif(NOT "${${rkey}_EMBEDDED_ITEM}" STREQUAL "")
endforeach(pr)
- if(BU_CHMOD_BUNDLE_ITEMS)
+ # if(BU_CHMOD_BUNDLE_ITEMS)
execute_process(COMMAND chmod u+w "${resolved_embedded_item}")
- endif()
+ # endif()
# Change this item's id and all of its references in one call
# to install_name_tool:
It works well.
As for the CPACK
Re: [cmake-developers] Test suite broken if PackageMaker not installed in default location
Sorry for the lake of information. On Tue, May 1, 2012 at 4:51 PM, David Cole wrote: > Are you talking about PackageMaker from Xcode 4.3, which you must take > extra care to install yourself (in any location you'd like...)? Yes Xcode 4.3 and I have installed PackageMaker myself in "/Applications/Xcode tools" > > Or are you talking about PackageMaker from an earlier Xcode? No. > > And which version of cmake/cpack? master: v2.8.8-89-g94f17c6 > > The recent work to add support for Xcode 4.3 searches several > locations for PackageMaker, as seen in this code: > > http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/CPack/cmCPackPackageMakerGenerator.cxx;h=3a0e89bbd923871ddfb66b98262687c916c467db;hb=94f17c696c6f996a719f276322b1f141a15d4ffb#l359 > > With CMake 2.8.8 and later, or with current 'master' or 'next', cpack > should find PackageMaker in any of the following locations: > > "/Applications/Xcode.app/Contents/Applications" > "/Applications/Utilities" > "/Applications" > "/Developer/Applications/Utilities" > "/Developer/Applications" > That's what I saw actually, but mine was not in the list. Setting CPACK_INSTALLER_PROGRAM as in line 390 does not help because the it is not "transfered" to the test project. Is there a robust way to tell cmake where is installed PackageMaker if it is not installed in one of the searched paths? Thanks, Nico > > 2012/5/1 Nicolas Desprès : >> Hi, >> >> On MacOXS I used to have the SimpleInstall test failing because it >> could not find the PackageMaker compiler. After looking into the code, >> I realized I had to set CPACK_INSTALLER_PROGRAM. But this variable >> does not get used by the test. So the only solution I had was to move >> PackageMaker to "/Applications/Utilities" (on of the searched paths) >> and no longer keep it in "/Applications/Xcode\ Utils". >> >> So, from my point of view the test suite is broken if PackageMaker is >> not installed in a default location and I don't know anyway to tell >> CMake where the PackageMaker application is. >> >> If someone has a better solution? >> >> Cheers, >> >> -- >> 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 -- 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
[cmake-developers] Test suite broken if PackageMaker not installed in default location
Hi, On MacOXS I used to have the SimpleInstall test failing because it could not find the PackageMaker compiler. After looking into the code, I realized I had to set CPACK_INSTALLER_PROGRAM. But this variable does not get used by the test. So the only solution I had was to move PackageMaker to "/Applications/Utilities" (on of the searched paths) and no longer keep it in "/Applications/Xcode\ Utils". So, from my point of view the test suite is broken if PackageMaker is not installed in a default location and I don't know anyway to tell CMake where the PackageMaker application is. If someone has a better solution? Cheers, -- 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] ninja bug
On Mon, Apr 23, 2012 at 3:52 PM, Bill Hoffman wrote: > On 4/21/2012 7:37 AM, Peter Kümmel wrote: >> >> >> Great! Is this the step which will be dropped when the /fast target is >> build? >> >> >> Peter > > No, that drops building all the dependent targets. > > > So, would it be possible to use CMake's depend generation with ninja? Right > now ninja creates the .d files as part of the compilation. Is it possible > to move that to a separate pass? Is it possible to have a per target .d > file? > > This is actually important for Fortran support, which right now is totally > broken in ninja. For Fortran, you have to parse all the files first to find > out what order they need to be compiled in. So, doing it on the compile > line is too late. > Bill, A short answer, because it is topic that will require more work in the generator and I have to think more about it. I don't think it is trivial. The depfile attribute for a rule is not mandatory. So, yes I think it is possible to use the CMake's depend generation with Ninja as a fallback. Actually, that was one of the question I had in mind when I started to work on this generator. When Peter picked up the torch, he went straight to the "usual" depfile as it is done in Ninja itself. For the per target .d file, I think it is possible too. It is close the request to have .s and .i target for each built files. I add that to my todo list but it is growing faster than I removed items. Spare time... Maybe Peter has an idea about how to implement this quickly. Cheers, -- 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] Supported targets with the ninja generator ?
2012/4/5 Nicolas Desprès : > On Thu, Apr 5, 2012 at 9:44 PM, David Cole wrote: [...] >> >> It would be very simple to add a "clean" target that simply executes >> "ninja -t clean" as a custom command, if the ninja generator guys >> think that's a reasonable idea to keep things similar to the Makefiles >> generator. > > Sounds reasonnable. > I have just pushed on my GitHub CMake fork a branch called 'ninja_convenience_targets' that implement that: https://github.com/polrop/CMake/commits/ninja_convenience_targets Cheers, -- 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] ninja bug
On Thu, Apr 19, 2012 at 4:21 PM, 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 think so. > > 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. It would be interesting if we could > do it at a target level so that it would work better one windows which does > not handle lots of small .d files. (CMake gave up on a .d file per file > because of this problem on windows). > There are several people trying to deals with .d files on Windows and to optimize their processing. Some have tried to group them and zip them. I think your experience would help them. Parsing deps files is one of the major bottle neck of Ninja optimization since it does that at start up time which is exactly the purpose of ninja vs make. The fall-back idea sounds great too. Cheers, -- 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] ninja bug
On Wed, Apr 18, 2012 at 10:48 PM, Bill Hoffman wrote: > On 4/18/2012 1:12 PM, Richard Wackerbarth wrote: >> >> Let me know if someone needs information from the run which has not been >> posted to the dashboard. >> I can bring the machine online and retrieve things. >> > > OK, so looking at the .d files, they are wrong. > > I see this: > > CMakeFiles/bar.dir/bar.cxx.o CMakeFiles/bar.dir/bar.cxx.o: \ > > /home/dashboard/BotFarm/Chameleon-12/CMake/Ninja/CMake/Tests/BuildDepends/Project/bar.cxx > \ > regen.h noregen.h > > > On other machines it looks like this: > > CMakeFiles/bar.dir/bar.cxx.o: \ > > /home/dashboard/BotFarm/Chameleon-12/CMake/Ninja/CMake/Tests/BuildDepends/Project/bar.cxx > \ > regen.h noregen.h > > > Is there a known problem with gcc-4.2.2 and ninja? 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. Cheers, -- 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] Supported targets with the ninja generator ?
On Thu, Apr 5, 2012 at 9:44 PM, David Cole wrote: > 2012/4/5 Alexander Neundorf : >> On Thursday 05 April 2012, Nicolas Desprès wrote: >>> 2012/4/4 Alexander Neundorf : >>> > On Wednesday 04 April 2012, Nicolas Desprès wrote: >>> >> On Tue, Apr 3, 2012 at 10:03 PM, Alexander Neundorf >>> > >>> > wrote: >>> >> > On Tuesday 03 April 2012, Alexander Neundorf wrote: >>> >> >> On Tuesday 03 April 2012, Alexander Neundorf wrote: >>> >> >> > Hi, >>> >> >> > >>> >> >> > which "additional" targets are supported with the ninja generator ? >>> >> >> > >>> >> >> > The "help" target does not seem to be supported. This would be >>> >> >> > nice. >>> >> >> > >>> >> >> > With Makefiles, for every target foo there is also a target >>> >> >> > foo/fast. This seems to be not supported currently. Is it planned >>> >> >> > ? >>> >> >>> >> If I remember well the /fast version is to skip dependency checking >>> >> right? If we consider that Ninja is fast enough do we need them? >>> > >>> > I thought the same, but I wanted to raise the question nevertheless. >>> > >>> >> >> > With Makefiles, there are targets to >>> >> >> > - compile a single source file foo.c -> foo.o >>> >> >> > - preprocess a single source file foo.c -> foo.i >>> >> >> > - assemble (actually compile but do not assemble) a single source >>> >> >> > file >>> >> >> > >>> >> >> > foo.c -> foo.s >>> >> >> > >>> >> >> > Those also seem not to be supported currently. >>> >> >> > Is this planned ? It would be nice. >>> >> >>> >> I think both could be implemented but there is no plan. >>> >> >>> >> ninja foo.o should already work I think. >>> > >>> > Doesn't look like it: >>> > >>> > ~/src/CMake/build dir/build-Ninja$ ninja cmake.o >>> > ninja: ERROR: unknown target 'cmake.o', did you mean 'cmake'? >>> > ~/src/CMake/build dir/build-Ninja$ ninja Source/cmake.o >>> > ninja: ERROR: unknown target 'Source/cmake.o' >>> > ~/src/CMake/build dir/build-Ninja$ >>> >>> Well we can get the list of all available target (i.e. all output file >>> in the graph) by doing: ninja -t targets all (see the manual for all >>> options supported by the target tool) >>> >>> $ ninja -t targets all | grep cmake.cxx.o >>> Source/CMakeFiles/CMakeLib.dir/cmake.cxx.o: CXX_COMPILER >>> Source/CMakeFiles/ccmake.dir/CursesDialog/ccmake.cxx.o: CXX_COMPILER >>> >>> So you will have to do: >>> $ ninja Source/CMakeFiles/CMakeLib.dir/cmake.cxx.o >> >> Hmm, this may be ok for doing it manually, but not for doing it in the >> project >> generator in Eclipse. I can't hardcode guessing how the object file will be >> named, it should be one of the targets known to cmake (at least it would be >> nice). >> >> >> ... >>> >> >> Maybe it shouldn't return a valid string, since it does not really >>> >> >> have a "clean" target ? >>> >> >>> >> I think it will never have a clean target since the clean tool is >>> >> quite more powerful and faster in the sense that it uses only the >>> >> dependency graph and does not require any logic in the generator. >>> > >>> > I didn't check where GetCleanTargetName() is used, but this sounds like >>> > for ninja it currently does not return what one would expect. >>> >>> I don't know what it should return then. >> >> I don't know either, but it sounds wrong. I mean, I can't do "ninja clean", >> which is what GetCleanTargetName() returns. >> Returning an empty string would seem appropriate to me (but I have no idea >> where this function is used otherwise). >> >> 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 c
Re: [cmake-developers] Supported targets with the ninja generator ?
2012/4/5 Alexander Neundorf : > On Thursday 05 April 2012, Nicolas Desprès wrote: >> 2012/4/4 Alexander Neundorf : >> > On Wednesday 04 April 2012, Nicolas Desprès wrote: >> >> On Tue, Apr 3, 2012 at 10:03 PM, Alexander Neundorf >> > >> > wrote: >> >> > On Tuesday 03 April 2012, Alexander Neundorf wrote: >> >> >> On Tuesday 03 April 2012, Alexander Neundorf wrote: >> >> >> > Hi, >> >> >> > >> >> >> > which "additional" targets are supported with the ninja generator ? >> >> >> > >> >> >> > The "help" target does not seem to be supported. This would be >> >> >> > nice. >> >> >> > >> >> >> > With Makefiles, for every target foo there is also a target >> >> >> > foo/fast. This seems to be not supported currently. Is it planned >> >> >> > ? >> >> >> >> If I remember well the /fast version is to skip dependency checking >> >> right? If we consider that Ninja is fast enough do we need them? >> > >> > I thought the same, but I wanted to raise the question nevertheless. >> > >> >> >> > With Makefiles, there are targets to >> >> >> > - compile a single source file foo.c -> foo.o >> >> >> > - preprocess a single source file foo.c -> foo.i >> >> >> > - assemble (actually compile but do not assemble) a single source >> >> >> > file >> >> >> > >> >> >> > foo.c -> foo.s >> >> >> > >> >> >> > Those also seem not to be supported currently. >> >> >> > Is this planned ? It would be nice. >> >> >> >> I think both could be implemented but there is no plan. >> >> >> >> ninja foo.o should already work I think. >> > >> > Doesn't look like it: >> > >> > ~/src/CMake/build dir/build-Ninja$ ninja cmake.o >> > ninja: ERROR: unknown target 'cmake.o', did you mean 'cmake'? >> > ~/src/CMake/build dir/build-Ninja$ ninja Source/cmake.o >> > ninja: ERROR: unknown target 'Source/cmake.o' >> > ~/src/CMake/build dir/build-Ninja$ >> >> Well we can get the list of all available target (i.e. all output file >> in the graph) by doing: ninja -t targets all (see the manual for all >> options supported by the target tool) >> >> $ ninja -t targets all | grep cmake.cxx.o >> Source/CMakeFiles/CMakeLib.dir/cmake.cxx.o: CXX_COMPILER >> Source/CMakeFiles/ccmake.dir/CursesDialog/ccmake.cxx.o: CXX_COMPILER >> >> So you will have to do: >> $ ninja Source/CMakeFiles/CMakeLib.dir/cmake.cxx.o > > Hmm, this may be ok for doing it manually, but not for doing it in the project > generator in Eclipse. I can't hardcode guessing how the object file will be > named, it should be one of the targets known to cmake (at least it would be > nice). > Ok. So phony targets have to generated for that purpose. [...] -- 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] Supported targets with the ninja generator ?
2012/4/4 Alexander Neundorf :
> On Wednesday 04 April 2012, Nicolas Desprès wrote:
>> On Tue, Apr 3, 2012 at 10:03 PM, Alexander Neundorf
> wrote:
>> > On Tuesday 03 April 2012, Alexander Neundorf wrote:
>> >> On Tuesday 03 April 2012, Alexander Neundorf wrote:
>> >> > Hi,
>> >> >
>> >> > which "additional" targets are supported with the ninja generator ?
>> >> >
>> >> > The "help" target does not seem to be supported. This would be nice.
>> >> >
>> >> > With Makefiles, for every target foo there is also a target foo/fast.
>> >> > This seems to be not supported currently. Is it planned ?
>>
>> If I remember well the /fast version is to skip dependency checking
>> right? If we consider that Ninja is fast enough do we need them?
>
> I thought the same, but I wanted to raise the question nevertheless.
>
>> >> > With Makefiles, there are targets to
>> >> > - compile a single source file foo.c -> foo.o
>> >> > - preprocess a single source file foo.c -> foo.i
>> >> > - assemble (actually compile but do not assemble) a single source file
>> >> >
>> >> > foo.c -> foo.s
>> >> >
>> >> > Those also seem not to be supported currently.
>> >> > Is this planned ? It would be nice.
>>
>> I think both could be implemented but there is no plan.
>>
>> ninja foo.o should already work I think.
>
> Doesn't look like it:
>
> ~/src/CMake/build dir/build-Ninja$ ninja cmake.o
> ninja: ERROR: unknown target 'cmake.o', did you mean 'cmake'?
> ~/src/CMake/build dir/build-Ninja$ ninja Source/cmake.o
> ninja: ERROR: unknown target 'Source/cmake.o'
> ~/src/CMake/build dir/build-Ninja$
>
Well we can get the list of all available target (i.e. all output file
in the graph) by doing: ninja -t targets all (see the manual for all
options supported by the target tool)
$ ninja -t targets all | grep cmake.cxx.o
Source/CMakeFiles/CMakeLib.dir/cmake.cxx.o: CXX_COMPILER
Source/CMakeFiles/ccmake.dir/CursesDialog/ccmake.cxx.o: CXX_COMPILER
So you will have to do:
$ ninja Source/CMakeFiles/CMakeLib.dir/cmake.cxx.o
or
$ ninja '../Source/cmake.cxx^'
see ninja -h for the last example.
(note: ninja -t targets all is used in the beginning of zsh completion
implementation for ninja in misc/zsh-completion)
There were a request to be able to build only targets under a given
sub-directory as it is possible with recursive Makefiles. I think it
should be implemented more or less the same way 'target^' is
implemented. Ninja can do it itself based on the dependency graph it
has without requiring any logic in the generator. Also some benchmark
as proven than ninja -t clean is faster than make clean since it
actually does not do any call to stat(2) or complex things. It just
load the dependency graph, walk through it and remove generated files.
>> ninja foo.i and ninja foo.s could be added without to much effort I think.
>>
>> >> cmGlobalNinjaGenerator.h contains:
>> >>
>> >> virtual const char* GetCleanTargetName() const { return "clean";
>> >> }
>> >>
>> >> but there actually no "clean" target:
>> >> tests/build-hello-eclipse-ninja$ ninja clean
>> >> ninja: ERROR: unknown target 'clean', did you mean 'ninja -t clean'?
>> >>
>> >>
>> >> Maybe it shouldn't return a valid string, since it does not really have
>> >> a "clean" target ?
>>
>> I think it will never have a clean target since the clean tool is
>> quite more powerful and faster in the sense that it uses only the
>> dependency graph and does not require any logic in the generator.
>
> I didn't check where GetCleanTargetName() is used, but this sounds like for
> ninja it currently does not return what one would expect.
I don't know what it should return then.
[...]
Cheers,
Nico
--
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 Tue, Apr 3, 2012 at 6:48 PM, Bill Hoffman wrote: > Hi, I just wanted to get an update on the ninja generator status. Right now > all linux tests are passing, and that platform seems to be done. > Hi Bill, Thanks for the status. > Windows: > - No file level depend information > - Failing Tests: BuildDepends, Plugin > > > OSX: > - application bundle and framework creation is unimplemented > - Failing tests: BuildDepends, BundleTest, CFBundleTest, ExportImport, > Qt4Deploy > On my Mac OSX 10.7.3 I have these tests failing: with "Unix Makefiles": 1 - CMake.Install (Failed) 88 - SimpleInstall (Failed) 90 - CPackComponents (Failed) 235 - CMake.CheckSourceTree (Failed) with "Ninja": 1 - CMake.Install (Failed) 54 - ExportImport (Failed) 61 - Qt4Deploy (Failed) 84 - SimpleInstall (Failed) 86 - CPackComponents (Failed) 227 - CMake.CheckSourceTree (Failed) Apparently BundleTest and CFBundleTest are run IF (APPLE AND CMAKE_COMPILER_IS_GNUCXX). Is CMAKE_COMPILER_IS_GNUCXX mandatory? Clang is used by default on this machine. However BuildDepends passes. On next 68160664982d8f42ccfa8d68de778df823b52979 and on master 5e9c7731e16fc077a3637a02cb983d397329a23a with "Ninja": The following tests FAILED: 1 - CMake.Install (Failed) 54 - ExportImport (Failed) 61 - Qt4Deploy (Failed) 84 - SimpleInstall (Failed) 86 - CPackComponents (Failed) 129 - BundleGeneratorTest (Failed) 227 - CMake.CheckSourceTree (Failed) Cheers, -Nico -- 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] Supported targets with the ninja generator ?
On Tue, Apr 3, 2012 at 10:03 PM, Alexander Neundorf wrote:
> On Tuesday 03 April 2012, Alexander Neundorf wrote:
>> On Tuesday 03 April 2012, Alexander Neundorf wrote:
>> > Hi,
>> >
>> > which "additional" targets are supported with the ninja generator ?
>> >
>> > The "help" target does not seem to be supported. This would be nice.
>> >
>> > With Makefiles, for every target foo there is also a target foo/fast.
>> > This seems to be not supported currently. Is it planned ?
If I remember well the /fast version is to skip dependency checking
right? If we consider that Ninja is fast enough do we need them?
>> >
>> > With Makefiles, there are targets to
>> > - compile a single source file foo.c -> foo.o
>> > - preprocess a single source file foo.c -> foo.i
>> > - assemble (actually compile but do not assemble) a single source file
>> >
>> > foo.c -> foo.s
>> >
>> > Those also seem not to be supported currently.
>> > Is this planned ? It would be nice.
>>
I think both could be implemented but there is no plan.
ninja foo.o should already work I think.
ninja foo.i and ninja foo.s could be added without to much effort I think.
>> cmGlobalNinjaGenerator.h contains:
>>
>> virtual const char* GetCleanTargetName() const { return "clean"; }
>>
>> but there actually no "clean" target:
>> tests/build-hello-eclipse-ninja$ ninja clean
>> ninja: ERROR: unknown target 'clean', did you mean 'ninja -t clean'?
>>
>>
>> Maybe it shouldn't return a valid string, since it does not really have a
>> "clean" target ?
I think it will never have a clean target since the clean tool is
quite more powerful and faster in the sense that it uses only the
dependency graph and does not require any logic in the generator.
>
> And one more comment: a nice feature of the makefile generators is that they
> don't only have one global "clean" target, but you can clean per-directory
> (via make clean in a subdir), and even per target
> (cmake -P CMakeFiles/foo.dir/cmake_clean.cmake).
>
> Having these per-target clean scripts available would be really nice.
Ninja clean tool support per-target and per-rule cleaning. See:
http://martine.github.com/ninja/manual.html#_extra_tools
So for instance if you want to remove all files generated using the
CXX_EXECUTABLE_LINKER rule (which will basically remove all files
produced by a link) you can do: ninja -t clean -r
CXX_EXECUTABLE_LINKER
You can also remove all files generated a given target (i.e. any
output of the dependency graph) by doing: ninja -t clean
Cheers,
-Nico
--
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 Issues with dependencies
It has been merged into master: https://github.com/martine/ninja/commit/abd33d5e3b11ae5470f62cbce49723a4cf62870d So you can now use the "normal" Ninja for your project. Cheers, -Nico 2012/3/14 Chuck Atkins : > Yep. That fixed it. Thanks! > > > Chuck Atkins > R&D Engineer, Kitware, Inc. > > -- "Mathematicians are tools for turning coffee grounds into formulas.", > Paul Erdos > > > 2012/3/14 Nicolas Desprès >> >> Try with this branch: >> https://github.com/polrop/ninja/tree/depfile-parser-accept-tilde >> I think that should fix your problem. >> >> On Wed, Mar 14, 2012 at 7:58 PM, Chuck Atkins >> wrote: >> > Just to clarify with more information: >> > >> > cmake: d2d492f492a8a6082345e439a9c15418f0d483db >> > - This is the head of the branch that was merged into next >> > >> > ninja: fdec96f54e92d2990ebf1ba5434b317d3d8ad49d >> > - Tues, Mar. 13 >> > >> > >> > Chuck Atkins >> > R&D Engineer, Kitware, Inc. >> > (518) 371-3971 x603 >> > chuck.atk...@kitware.com >> > >> > >> > -- "Mathematicians are tools for turning coffee grounds into formulas.", >> > Paul Erdos >> > >> > >> > On Wed, Mar 14, 2012 at 2:00 PM, Chuck Atkins >> > wrote: >> >> >> >> I'm trying to build a fairly large project (VXL, 4000 make targets) >> >> with >> >> cmake+Ninja and I'm experiencing some strange issues: >> >> >> >> 1. I configure the project with 'cmake -G Ninja'. Everything works >> >> great. >> >> 2. Build the project with 'ninja'. Everything builds just fine (and >> >> VERY >> >> fast I might add, nice job Ninja guys) >> >> 3. Rebuild with 'ninja', BREAK: >> >> Recompacting log... >> >> ninja: ERROR: expected depfile >> >> 'v3p/Qv/CMakeFiles/Qv.dir/Templates/vcl_vector+QvNode~-.o.d' to mention >> >> 'v3p/Qv/CMakeFiles/Qv.dir/Templates/vcl_vector+QvNode~-.o', got >> >> 'v3p/Qv/CMakeFiles/Qv.dir/Templates/vcl_vector+QvNode' >> >> >> >> I can only re-build if I clean first with 'ninja -t clean'. And yes, >> >> the >> >> filenames are correct. There are some files named >> >> "vcl_vector+QvNode~-.cxx" >> >> (The result of some auto-code generating scripts). Could it be that >> >> the >> >> odd-ball characters in the filenames are breaking some regex >> >> somewhere? Not >> >> sureif the issue would be in ninja itself or in the cmake-ninja >> >> integration. >> >> >> >> Thanks >> >> >> >> Chuck Atkins >> >> R&D Engineer, Kitware, Inc. >> >> >> >> -- "Mathematicians are tools for turning coffee grounds into >> >> formulas.", >> >> Paul Erdos >> > >> > >> > >> > -- >> > >> > 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 >> >> >> >> -- >> Nicolas Desprès > > -- 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] Ninja Issues with dependencies
Try with this branch: https://github.com/polrop/ninja/tree/depfile-parser-accept-tilde I think that should fix your problem. On Wed, Mar 14, 2012 at 7:58 PM, Chuck Atkins wrote: > Just to clarify with more information: > > cmake: d2d492f492a8a6082345e439a9c15418f0d483db > - This is the head of the branch that was merged into next > > ninja: fdec96f54e92d2990ebf1ba5434b317d3d8ad49d > - Tues, Mar. 13 > > > Chuck Atkins > R&D Engineer, Kitware, Inc. > (518) 371-3971 x603 > chuck.atk...@kitware.com > > > -- "Mathematicians are tools for turning coffee grounds into formulas.", > Paul Erdos > > > On Wed, Mar 14, 2012 at 2:00 PM, Chuck Atkins > wrote: >> >> I'm trying to build a fairly large project (VXL, 4000 make targets) with >> cmake+Ninja and I'm experiencing some strange issues: >> >> 1. I configure the project with 'cmake -G Ninja'. Everything works >> great. >> 2. Build the project with 'ninja'. Everything builds just fine (and VERY >> fast I might add, nice job Ninja guys) >> 3. Rebuild with 'ninja', BREAK: >> Recompacting log... >> ninja: ERROR: expected depfile >> 'v3p/Qv/CMakeFiles/Qv.dir/Templates/vcl_vector+QvNode~-.o.d' to mention >> 'v3p/Qv/CMakeFiles/Qv.dir/Templates/vcl_vector+QvNode~-.o', got >> 'v3p/Qv/CMakeFiles/Qv.dir/Templates/vcl_vector+QvNode' >> >> I can only re-build if I clean first with 'ninja -t clean'. And yes, the >> filenames are correct. There are some files named "vcl_vector+QvNode~-.cxx" >> (The result of some auto-code generating scripts). Could it be that the >> odd-ball characters in the filenames are breaking some regex somewhere? Not >> sureif the issue would be in ninja itself or in the cmake-ninja integration. >> >> Thanks >> >> Chuck Atkins >> R&D Engineer, Kitware, Inc. >> >> -- "Mathematicians are tools for turning coffee grounds into formulas.", >> Paul Erdos > > > > -- > > 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 -- 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] new ninja rebuild too much issue
On Wed, Mar 14, 2012 at 6:10 PM, Peter Collingbourne wrote: > On Wed, Mar 14, 2012 at 10:45:39AM -0400, Bill Hoffman wrote: >> On 3/14/2012 7:34 AM, Nicolas Desprčs wrote: >>> Nope if you like in the generated build.ninja "build.ninja" appears >>> only once as an output using the RERUN_CMAKE rule. >>> >>> I rather think it is a bug in ninja of the restat implementation. >> What is the way to debug this? Can you get ninja to tell you why it is >> choosing to do a build of a file? This is quite reproducible. > > Most likely, this is due to the compile command line changing between > runs. If any command line changes, Ninja will need to re-run that > command. In particular, toggling CMAKE_ENABLE_NINJA would affect > whether CMAKE_USE_NINJA is defined on the command line for anything > under Source. Ninja stores previously run commands in .ninja_log so > you can examine that to verify that the command line is changing. > > We can probably reduce the amount of recompilation required by only > defining CMAKE_ENABLE_NINJA for cmake.cxx (the only source file that > uses it). > $ ../_build/bin/cmake -DCMAKE_ENABLE_NINJA=OFF . $ ../_build/bin/cmake -DCMAKE_ENABLE_NINJA=ON . $ ninja ninja: no work to do. $ ../_build/bin/cmake -DCMAKE_ENABLE_NINJA=OFF . $ ninja [...compile 200 outputs...] I just check the .ninja_log and Peter is right. Cheers, -- 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] new ninja rebuild too much issue
On Wed, Mar 14, 2012 at 12:22 AM, Bill Hoffman wrote: > It seems that if the CMakeCache.txt changes, and cmake re-runs, ninja > rebuilds almost ever single .obj file. For example, if I turn on and off > CMAKE_ENABLE_NINJA, Then it rebuilds all the .obj files instead of > relinking just a few executables since the .obj files are there all ready. > I had a report of this from someone else at Kitware working on a larger > project. They said if they changed options with ccmake, that ninja rebuild > the whole thing. > > Is there a way to debug ninja and have it print out why it is building > something? > > > Here is the example: > > $ ninja > [1/1] Re-running CMake... > -- Enable ninja generator. > -- Found Qt4: > C:/Users/hoffman/Work/qt-everywhere-opensource-src-4.7.4/bin/qmake.exe > (found suitable version "4.7.4", required is "4.4.0") > -- Found Qt4: > C:/Users/hoffman/Work/qt-everywhere-opensource-src-4.7.4/bin/qmake.exe > (found version "4.7.4") > -- No CTest.UpdateCVS test with cygwin cvs.exe outside cygwin! > -- Configuring done > -- Generating done > -- Build files have been written to: C:/Users/hoffman/Work/My > Builds/cmake-ninja > [1/206] Building CXX object > Source\CMakeFiles\CMakeLib.dir\cmGlobalVisualStudio7[2/206] Building CXX > object Source\CMakeFiles\CMakeLib.dir\cmGlobalVisualStudio7 > > This should be an almost no-op. Is it because everything depends on the > build.ninja file? Nope if you like in the generated build.ninja "build.ninja" appears only once as an output using the RERUN_CMAKE rule. I rather think it is a bug in ninja of the restat implementation. -- 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] Ninja windows
On Fri, Mar 9, 2012 at 3:24 AM, Peter Collingbourne wrote: > On Tue, Mar 06, 2012 at 03:56:24PM -0500, Bill Hoffman wrote: >> On 3/6/2012 1:29 PM, Peter Collingbourne wrote: >> >>> We can certainly do that, but the ninja binary would need to be >>> switched as soon as we get around to using rspfile in Ninja (and >>> no sooner). >>> >> >> OK, so is there a ninja binary that I can download right now that will >> work if I change the cmake files for cmake to build the ninja generator >> on windows? If so, where is it? My idea is to try it on my machine. If >> it works I will push the change into next that enables ninja on windows >> and setup a dashboard that pulls ninja from that spot each night. When >> cmake is changed to work with master ninja if someone updates that >> binary, then it will pull that and just work. That is what I have been >> doing with jom. > > That would be Peter Kummel's ninja. But what I would suggest we do, > as I suggested before, is to use an internal variable to turn on the > Ninja generator on Windows and Mac. This way, we can safely merge > ninja-generator into master without confusing users on Windows or > Mac by shipping a non-working Ninja generator in the next release, > while keeping the ability to test (on the dashboard and otherwise). > I have no idea what the timeframe for the Windows and Mac people > is, but I really would like the Ninja generator to be available on > non-Windows/Mac platforms in 2.8.8. Sounds fair enough. -- 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] CPackComponents fails with spaces in paths
2012/2/19 Eric Noulard > Le 19 février 2012 17:20, Nicolas Desprès a > écrit : > > > > > > 2012/2/19 Eric Noulard > >> > >> Le 19 février 2012 16:07, Nicolas Desprès a > >> écrit : > >> > Hi, > >> > > >> > The CPackComponents test fails on master where there is a space in the > >> > source tree. Here I think the trace: > >> > > >> > $ ctest -V -R 'CPackComponents$' > >> > > >> > == > >> > UpdateCTestConfiguration from :/home/despre_n/tmp/cmake > >> > space/_build/DartConfiguration.tcl > >> > Parse Config file:/home/despre_n/tmp/cmake > >> > space/_build/DartConfiguration.tcl > >> > Add coverage exclude regular expressions. > >> > Add coverage exclude: XCode > >> > Add coverage exclude: Kdevelop > >> > Add coverage exclude: /Source/(cm|kw)sys/ > >> > Add coverage exclude: /CMakeFiles/CMakeTmp/ > >> > Add coverage exclude: [A-Za-z]./[Qq]t/qt-.+-opensource-src > >> > UpdateCTestConfiguration from :/home/despre_n/tmp/cmake > >> > space/_build/DartConfiguration.tcl > >> > Parse Config file:/home/despre_n/tmp/cmake > >> > space/_build/DartConfiguration.tcl > >> > Test project /home/despre_n/tmp/cmake space/_build > >> > Constructing a list of tests > >> > Guessing configuration NoConfig > >> > Done constructing a list of tests > >> > Checking test dependency graph... > >> > Checking test dependency graph end > >> > test 89 > >> > Start 89: CPackComponents > >> > > >> > 89: Test command: /home/despre_n/tmp/cmake\ space/_build/bin/ctest > >> > "--build-and-test" "/home/despre_n/tmp/cmake > >> > space/Tests/CPackComponents" > >> > "/home/despre_n/tmp/cmake space/_build/Tests/CPackComponents" > >> > "--build-generator" "Unix Makefiles" "--build-project" > "CPackComponents" > >> > "--build-makeprogram" "/usr/bin/make" "--build-two-config" > >> > "--build-target" > >> > "package" "--build-options" "-DCPACK_BINARY_DEB:BOOL=ON" > >> > "-DCPACK_BINARY_RPM:BOOL=ON" "-DCPACK_BINARY_NSIS:BOOL=ON" > >> > "--graphviz=CPackComponents.dot" "--test-command" > >> > "/home/despre_n/tmp/cmake > >> > space/_build/bin/cmake" > >> > "-DCPackComponents_BINARY_DIR:PATH=/home/despre_n/tmp/cmake > >> > space/_build/Tests/CPackComponents" "-P" "/home/despre_n/tmp/cmake > >> > space/Tests/CPackComponents/VerifyResult.cmake" > >> > 89: Test timeout computed to be: 1500 > >> > 89: Generate graphviz: /home/despre_n/tmp/cmake > >> > space/_build/Tests/CPackComponents/CPackComponents.dot > >> > 89: Writing /home/despre_n/tmp/cmake > >> > space/_build/Tests/CPackComponents/CPackComponents.dot.mylib... > >> > 89: Writing /home/despre_n/tmp/cmake > >> > space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp... > >> > 89: Writing /home/despre_n/tmp/cmake > >> > > >> > > space/_build/Tests/CPackComponents/CPackComponents.dot.mylib.dependers... > >> > 89: Writing /home/despre_n/tmp/cmake > >> > > >> > > space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp.dependers... > >> > 89: Writing /home/despre_n/tmp/cmake > >> > space/_build/Tests/CPackComponents/CPackComponents.dot... > >> > 89: Generate graphviz: /home/despre_n/tmp/cmake > >> > space/_build/Tests/CPackComponents/CPackComponents.dot > >> > 89: Writing /home/despre_n/tmp/cmake > >> > space/_build/Tests/CPackComponents/CPackComponents.dot.mylib... > >> > 89: Writing /home/despre_n/tmp/cmake > >> > space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp... > >> > 89: Writing /home/despre_n/tmp/cmake > >> > > >> > > space/_build/Tests/CPackComponents/CPackComponents.dot.mylib.dependers... > >> > 89: Writing /home/despre_n/tmp/cmake > >> > > >> > > space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp.dependers... > >> > 89: Writing /home/despre_n/tmp/cmake > >> > space/_build/Tests/CPackComponents/CPackCompo
Re: [cmake-developers] CPackComponents fails with spaces in paths
2012/2/19 Eric Noulard > Le 19 février 2012 16:07, Nicolas Desprès a > écrit : > > Hi, > > > > The CPackComponents test fails on master where there is a space in the > > source tree. Here I think the trace: > > > > $ ctest -V -R 'CPackComponents$' > > > > == > > UpdateCTestConfiguration from :/home/despre_n/tmp/cmake > > space/_build/DartConfiguration.tcl > > Parse Config file:/home/despre_n/tmp/cmake > > space/_build/DartConfiguration.tcl > > Add coverage exclude regular expressions. > > Add coverage exclude: XCode > > Add coverage exclude: Kdevelop > > Add coverage exclude: /Source/(cm|kw)sys/ > > Add coverage exclude: /CMakeFiles/CMakeTmp/ > > Add coverage exclude: [A-Za-z]./[Qq]t/qt-.+-opensource-src > > UpdateCTestConfiguration from :/home/despre_n/tmp/cmake > > space/_build/DartConfiguration.tcl > > Parse Config file:/home/despre_n/tmp/cmake > > space/_build/DartConfiguration.tcl > > Test project /home/despre_n/tmp/cmake space/_build > > Constructing a list of tests > > Guessing configuration NoConfig > > Done constructing a list of tests > > Checking test dependency graph... > > Checking test dependency graph end > > test 89 > > Start 89: CPackComponents > > > > 89: Test command: /home/despre_n/tmp/cmake\ space/_build/bin/ctest > > "--build-and-test" "/home/despre_n/tmp/cmake space/Tests/CPackComponents" > > "/home/despre_n/tmp/cmake space/_build/Tests/CPackComponents" > > "--build-generator" "Unix Makefiles" "--build-project" "CPackComponents" > > "--build-makeprogram" "/usr/bin/make" "--build-two-config" > "--build-target" > > "package" "--build-options" "-DCPACK_BINARY_DEB:BOOL=ON" > > "-DCPACK_BINARY_RPM:BOOL=ON" "-DCPACK_BINARY_NSIS:BOOL=ON" > > "--graphviz=CPackComponents.dot" "--test-command" > "/home/despre_n/tmp/cmake > > space/_build/bin/cmake" > > "-DCPackComponents_BINARY_DIR:PATH=/home/despre_n/tmp/cmake > > space/_build/Tests/CPackComponents" "-P" "/home/despre_n/tmp/cmake > > space/Tests/CPackComponents/VerifyResult.cmake" > > 89: Test timeout computed to be: 1500 > > 89: Generate graphviz: /home/despre_n/tmp/cmake > > space/_build/Tests/CPackComponents/CPackComponents.dot > > 89: Writing /home/despre_n/tmp/cmake > > space/_build/Tests/CPackComponents/CPackComponents.dot.mylib... > > 89: Writing /home/despre_n/tmp/cmake > > space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp... > > 89: Writing /home/despre_n/tmp/cmake > > space/_build/Tests/CPackComponents/CPackComponents.dot.mylib.dependers... > > 89: Writing /home/despre_n/tmp/cmake > > > space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp.dependers... > > 89: Writing /home/despre_n/tmp/cmake > > space/_build/Tests/CPackComponents/CPackComponents.dot... > > 89: Generate graphviz: /home/despre_n/tmp/cmake > > space/_build/Tests/CPackComponents/CPackComponents.dot > > 89: Writing /home/despre_n/tmp/cmake > > space/_build/Tests/CPackComponents/CPackComponents.dot.mylib... > > 89: Writing /home/despre_n/tmp/cmake > > space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp... > > 89: Writing /home/despre_n/tmp/cmake > > space/_build/Tests/CPackComponents/CPackComponents.dot.mylib.dependers... > > 89: Writing /home/despre_n/tmp/cmake > > > space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp.dependers... > > 89: Writing /home/despre_n/tmp/cmake > > space/_build/Tests/CPackComponents/CPackComponents.dot... > > 89: Internal cmake changing into directory: /home/despre_n/tmp/cmake > > space/_build/Tests/CPackComponents > > 89: CMake output == > > 89: Configuring > > 89: Configuring done > > 89: Generating > > 89: Generating done > > 89: Build files have been written to: /home/despre_n/tmp/cmake > > space/_build/Tests/CPackComponents > > 89: Configuring > > 89: Configuring done > > 89: Generating > > 89: Generating done > > 89: Build files have been written to: /home/despre_n/tmp/cmake > > space/_build/Tests/CPackComponents > > 89: End CMake output == > > 89: Change Dir: /home/despre_n/tmp/cmake > space/_build/Tests/CPackComponents > > 89: > > 89: Run Clean Command:/usr/bin/make "clean" > > 89: > > 89: Run Build
[cmake-developers] CPackComponents fails with spaces in paths
Wno-dev to suppress it. 89: 89: CPack: Create package using DEB 89: CPack: Install projects 89: CPack: - Run preinstall target for: CPackComponents 89: CPack: - Install project: CPackComponents 89: CPack: Create package 89: CPack: - package: /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/MyLib-1.0.0-Linux.deb generated. 89: CPack: Create package using RPM 89: CPack: Install projects 89: CPack: - Run preinstall target for: CPackComponents 89: CPack: - Install project: CPackComponents 89: CPack: Create package 89: CMake Error at /home/despre_n/tmp/cmake space/Modules/CPackRPM.cmake:298 (MESSAGE): 89: /usr/bin/rpmbuild can't handle paths with spaces, use a build directory 89: without spaces for building RPMs. 89: 89: 89: CPack Error: Error while execution CPackRPM.cmake 89: CPack Error: Problem compressing the directory 89: CPack Error: Error when generating package: MyLib 89: make: *** [package] Error 1 1/1 Test #89: CPackComponents ..***Failed3.31 sec 0% tests passed, 1 tests failed out of 1 Total Test time (real) = 4.31 sec The following tests FAILED: 89 - CPackComponents (Failed) Errors while running CTest == So I think the culprit is RPM. Cheers, -- 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] ninja spaces in the path do not work on linux
2012/2/19 Eric Noulard > Le 19 février 2012 15:19, Nicolas Desprès a > écrit : > > > > Thanks for this Peter. I have just tried the new stage/ninja-generator > > branch with spaces in both the source and the binary directory and I got > > this result for the test suite: > > > > The following tests FAILED: > > 83 - CPackComponents (Failed) > > 217 - CMake.CheckSourceTree (Failed) > > > > Note that on my Linux box: > > - CMake.CheckSourceTree always fail even on the master branch (I never > tried > > to understand why). > > Because you should have some local modification in the source tree. > Try: > ctest -V -R CMake.CheckSourceTree > > and you'll possibly get an explanation like: > 232: additions='0' > 232: conflicts='0' > 232: modifications='0' > 232: nonadditions='1' > ... > 232: CMake Error at CheckSourceTreeTest.cmake:422 (message): > 232: test fails: local source tree non-additions: use git add before > committing, > 232: or remove the files from the source tree > > True I had some untracked files. Thanks it works now :) > > - CPackComponents fails only when there are spaces but the Unix > Makefiles > > generator has the same issue. > > I think this should not happen, normally CPack generators that cannot > handle space in build tree (like CPackRPM) should be filtered out. > > In order to know the culprit same method applies here: > ctest -V -R "^CPackComponents$" > > (you can do ctest -V -R CPackComponents > but you'll get more tests) > I open a new discussion thread "CPackComponents fails with spaces in paths" cause it is off-topic. Thanks, -- 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] ninja spaces in the path do not work on linux
2012/2/19 Peter Collingbourne > On Fri, Feb 17, 2012 at 09:16:31PM +0100, Nicolas Desprès wrote: > > 2012/2/17 Bill Hoffman > > > > > On 2/17/2012 12:26 PM, Nicolas Desprès wrote: > > > > > >> > > >> I think it is a bug in the generator which do not escape the space > > >> properly using the $ character as supported by Ninja. > > >> > > >> -- > > >> Nicolas Desprès > > >> > > >> Will you be able to fix that? > > > > > > > I think yes. It is just a matter of time. My weekend is already > overloaded. > > I'll try to do it. If Peter or someone else in the community comes up > with > > a patch before me everybody would be happy :-) > > I decided to look into escaping rules this weekend. Now with the > code on the ninja-generator branch, CMake can build itself with both > source and build directories containing spaces, and pass all tests. > LLVM/Clang can also build with both directory names containing spaces. > > Thanks for this Peter. I have just tried the new stage/ninja-generator branch with spaces in both the source and the binary directory and I got this result for the test suite: The following tests FAILED: 83 - CPackComponents (Failed) 217 - CMake.CheckSourceTree (Failed) Note that on my Linux box: - CMake.CheckSourceTree always fail even on the master branch (I never tried to understand why). - CPackComponents fails only when there are spaces but the Unix Makefiles generator has the same issue. Cheers, -- 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] ninja spaces in the path do not work on linux
On Fri, Feb 17, 2012 at 11:09 PM, Peter Kümmel wrote: > On 17.02.2012 21:37, Bill Hoffman wrote: > > On 2/17/2012 3:16 PM, Nicolas Desprès wrote: >> >> >>> I think yes. It is just a matter of time. My weekend is already >>> overloaded. I'll try to do it. If Peter or someone else in the community >>> comes up with a patch before me everybody would be happy :-) >>> >>> I'll try to do my best. >>> >>> I could give it a try if you pointed me to the right spot in the code... >> > > Does attached patch help? I don't think so because EncodeLiteral is only called in WriteCustomCommandBuild to encode the description: vars["DESC"] = EncodeLiteral(description); Plus I think we should keep the description untouched since it is printed in the terminal. This description is the description of custom command rule used here in rules.ninja: rule CUSTOM_COMMAND command = $COMMAND description = $DESC restat = 1 Thanks for the patch anyway. -- 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] ninja spaces in the path do not work on linux
2012/2/17 Nicolas Desprès > > > 2012/2/17 Bill Hoffman > >> On 2/17/2012 3:16 PM, Nicolas Desprčs wrote: >> >> >>> I think yes. It is just a matter of time. My weekend is already >>> overloaded. I'll try to do it. If Peter or someone else in the community >>> comes up with a patch before me everybody would be happy :-) >>> >>> I'll try to do my best. >>> >>> I could give it a try if you pointed me to the right spot in the code... > > > I think the first place to look at is cmGlobalNinjaGenerator.cxx. There > are a bunch of class methods there that are used to write the statements in > the .ninja files. > > Look at WriteBuild() in particular. Many others are convenient methods > based on this one. So the escaping logic should happen there. "build" > statements in ninja are where most of the path are written. > Some problem may arise from WriteRule() since the path to the command is > written by it. > > Also there are: > static std::string EncodeIdent(const std::string &ident, std::ostream > &vars); > static std::string EncodeLiteral(const std::string &lit); > > which I don't really know since I haven't written them and they are not > documented. Peter did. But their name are pretty explicit and their code > trivial. > > I think we should add an EncodePath() method to follow the same logic and > use it in WriteBuild() and WriteRule(). > > In WriteBuild(), arguments like ouputs, explictDeps, implicitDeps, > orderOnlyDeps must be encoded. The tricky part would be that some part of > the value of the "variables" arguments (which is a hash_map) must be > encoded because they may be a white space sparated list of word which may > contains some paths... > Just to be clearer, "outputs", "explicitDeps", "implicitDeps" and "orderOnlyDeps" are all a list of paths (types are declared in cmNinjaTypes.h) so each item of the list must be encoded. A "build" statements look like this (using the argument name of WriteBuild): comment build outputs: rule explicitDeps | implicitDeps || orderOnlyDeps variables > > For exemple look at this part of the build.ninja file generated for cmake: > > build Tests/CMakeLib/CMakeFiles/CMakeLibTests.dir/testXMLParser.cxx.o: > CXX_COMPILER ../Tests/CMakeLib/testXMLParser.cxx || Source/libCMakeLib.a > DEFINES = -DLIBARCHIVE_STATIC > FLAGS = -Wall -g -IUtilities -I../Utilities -ITests/CMakeLib -ISource > -I../Source > > or this one: > > # Link the executable Tests/CMakeLib/CMakeLibTests > build Tests/CMakeLib/CMakeLibTests: CXX_EXECUTABLE_LINKER > Tests/CMakeLib/CMakeFiles/CMakeLibTests.dir/CMakeLibTests.cxx.o > Tests/CMakeLib/CMakeFiles/CMakeLibTests.dir/testGeneratedFileStream.cxx.o > Tests/CMakeLib/CMakeFiles/CMakeLibTests.dir/testSystemTools.cxx.o > Tests/CMakeLib/CMakeFiles/CMakeLibTests.dir/testUTF8.cxx.o > Tests/CMakeLib/CMakeFiles/CMakeLibTests.dir/testXMLParser.cxx.o > Tests/CMakeLib/CMakeFiles/CMakeLibTests.dir/testXMLSafe.cxx.o | > Source/libCMakeLib.a Source/kwsys/libcmsys.a /usr/lib/libexpat.so > Utilities/cmlibarchive/libarchive/libcmlibarchive.a /usr/lib/libz.so > Utilities/cmbzip2/libcmbzip2.a Utilities/cmcompress/libcmcompress.a > /usr/lib/libcurl.so > FLAGS = -Wall -fPIC > LINK_LIBRARIES = -rdynamic Source/libCMakeLib.a Source/kwsys/libcmsys.a > -ldl -lexpat Utilities/cmlibarchive/libarchive/libcmlibarchive.a -lz > Utilities/cmbzip2/libcmbzip2.a Utilities/cmcompress/libcmcompress.a -lcurl > POST_BUILD = : > PRE_LINK = : > > In this case I think the encoding should happen before the call to > WriteBuild when the "variables" argument is built because WriteBuild would > not have enough information to figure out which part of the variable value > is a path or not, specially for things like: "-I../Utilities" > > Hope this helps, > Cheers, > -Nico > > -- 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
