[cmake-developers] [CMake 0013591]: Ninja generator fail with multi-line COMMENT in custom command
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13591
==
Reported By:Eric NOULARD
Assigned To:
==
Project:CMake
Issue ID: 13591
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-10-16 13:04 CEST
Last Modified: 2012-10-16 13:04 CEST
==
Summary:Ninja generator fail with multi-line COMMENT in
custom command
Description:
If one uses a newline character \n in a COMMENT of a
custom command/target, the Nija generator will produce an
invalid build.ninja file.
Steps to Reproduce:
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(NinjaCustomCommand NONE)
add_custom_target(GotYou ALL
COMMAND ${CMAKE_COMMAND} -E echo \Got You\
COMMENT This may \n breaks Ninja)
$ mkdir b
$ cd b
$ cmake -G Ninja ..
-- Configuring done
-- Generating done
-- Build files have been written to:
/home/erk/CMake/Contrib/NinjaAndCustomCommand/b
erk@CT-WDTIM102H:b$ ninja
ninja: error: build.ninja:54: expected '=', got identifier
breaks Ninja
^ near here
==
Issue History
Date ModifiedUsername FieldChange
==
2012-10-16 13:04 Eric NOULARD New Issue
==
--
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] Bug introduced in generate-time target checking code
Stephen Kelly wrote: Stephen Kelly wrote: Stephen Kelly wrote: None of the outputs have a backtrace. Any idea why? Can a backtrace be provided? Reading the code, I'm not seeing which iteration is going past the end. I added some asserts and found that the problem is in iterating over comma tokens somehow. I'll see about fixing it. I wrote a topic to attempt to fix this, but it seems to have had mixed results. Bcc still fails, vs10 passes, but has a new failure in RunCMake.TargetPropertyGeneratorExpressions: http://open.cdash.org/viewTest.php?onlyfailedbuildid=2614187 http://open.cdash.org/viewTest.php?onlydeltabuildid=2614232 I'm not sure if the new failure is the result of the merge or not. I'd probably need a backtrace to diagnose the bcc failure. The RunCMake.TargetPropertyGeneratorExpressions failure was probably a side- effect of the incremental builds of the Continuous configuration. Still, some of the platforms fail the test, and don't give any information about why: http://open.cdash.org/testSummary.php?project=1name=GeneratorExpressiondate=2012-10-16 Can someone please provide more information (backtrace or further investigation) for one of the failing platforms? Thanks, Steve. -- 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] patch for cmake that adds a new timestamp command
I had to do this to get the bootstrap version of CMake to work (and the BootstrapTest to pass): $ git diff diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt index 9d46355..8bf6c40 100644 --- a/Source/CMakeLists.txt +++ b/Source/CMakeLists.txt @@ -264,8 +264,6 @@ set(SRCS cmTarget.cxx cmTarget.h cmTargetExport.h - cmTimestamp.h - cmTimestamp.cxx cmTest.cxx cmTest.h cmTestGenerator.cxx diff --git a/Source/cmBootstrapCommands.cxx b/Source/cmBootstrapCommands.cxx index 9097a74..e3a2ad4 100644 --- a/Source/cmBootstrapCommands.cxx +++ b/Source/cmBootstrapCommands.cxx @@ -89,6 +89,7 @@ #include cmStringCommand.cxx #include cmSubdirCommand.cxx #include cmTargetLinkLibrariesCommand.cxx +#include cmTimestamp.cxx #include cmTryCompileCommand.cxx #include cmTryRunCommand.cxx #include cmUnsetCommand.cxx After amending this, I'll push to next later today unless somebody objects to this?? Thanks, David On Fri, Oct 5, 2012 at 4:16 PM, Nils Gladitz glad...@sci-vis.de wrote: I've updated the patch (attached) to return empty string on failure. I also tried to use the time definitions from global namespace rather than std::. Nils On 10/05/2012 09:17 PM, Brad King wrote: On 10/05/2012 02:53 PM, Nils Gladitz wrote: My initial thought was that NOTFOUND would be a good idea since it evaluates to false and the get_*_property commands also seem to use it. I wrote the more general get_property command to replace those and the newer command uses empty string rather than NOTFOUND. It is more useful when computing pieces of a string to put together, perhaps when appending to a property value. Looking at the documentation for if() again only -NOTFOUND as a suffix should evaluate to false though (I assume the documentation is incomplete here?). Yes, thanks for pointing it out. Fixed: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f63304d9 On second though relying on timestamps to evaluate to false on failure is probably a bad idea since I could have a format string of e.g. %w (day of the week) which might produce a valid timestamp 0 which would also evaluate to false. Yes, so a comparison against would be more reliable. Thanks, -Brad -- Nils Gladitz, B.Sc. DICOM, Konnektivität und Entwicklung Scivis wissenschaftliche Bildverarbeitung GmbH Bertha-von-Suttner-Str. 5 D-37085 Göttingen GERMANY Handelsregister Nr. / Trade Register No. B3100 Göttingen Geschäftsführer / Managing Directors Dr. Gernot Ebel, Dr. Uwe Engeland Tel: 0049 (0)551 634181-28 E-Mail: glad...@scivis.de Web: www.scivis.de -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Bug introduced in generate-time target checking code
On 10/16/2012 08:43 AM, Stephen Kelly wrote: Still, some of the platforms fail the test, and don't give any information about why: http://open.cdash.org/testSummary.php?project=1name=GeneratorExpressiondate=2012-10-16 Can someone please provide more information (backtrace or further investigation) for one of the failing platforms? Borland Make and NMake both have an inline file syntax that starts with : http://msdn.microsoft.com/en-us/library/z440c98k.aspx The custom command generated by this test accidentally triggers that. I don't know if there is a way to escape it. It's probably simplest for your purposes to just do something else in the test. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013592]: Inefficient Ninja DAG with add_custom_command
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13592
==
Reported By:Frank Miller
Assigned To:
==
Project:CMake
Issue ID: 13592
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-10-16 10:00 EDT
Last Modified: 2012-10-16 10:00 EDT
==
Summary:Inefficient Ninja DAG with add_custom_command
Description:
The ninja generator is not handling dependencies of custom commands
efficiently. As far as I can tell, it is producing correct builds but
with an only overly conservative DAG.
Here is a toy project:
cmake_minimum_required( VERSION 2.8.0 )
project( ndep )
file( WRITE ${CMAKE_BINARY_DIR}/main.cpp
#include iostream
#include \foo.h\
int bar();
int main()
{
std::cout foo() bar() std::endl;
}
)
file( WRITE ${CMAKE_BINARY_DIR}/foo.in
int foo() { return VALUE; }
)
file( WRITE ${CMAKE_BINARY_DIR}/bar.in
int bar() { return VALUE; }
)
add_custom_command(
OUTPUT foo.h
COMMAND cat ${CMAKE_BINARY_DIR}/foo.in | sed 's/VALUE/4/'
${CMAKE_BINARY_DIR}/foo.h
DEPENDS ${CMAKE_BINARY_DIR}/foo.in
)
add_custom_command(
OUTPUT bar.cpp
COMMAND cat ${CMAKE_BINARY_DIR}/bar.in | sed 's/VALUE/2/'
${CMAKE_BINARY_DIR}/bar.cpp
DEPENDS ${CMAKE_BINARY_DIR}/bar.in
)
add_executable( ndep main.cpp foo.h bar.cpp )
For this case, using git master, the generated object dependencies are
(in Ninja syntax):
build main.cpp.o: main.cpp | foo.h bar.cpp
build bar.cpp.o: bar.cpp | foo.h bar.cpp
If foo.h changes (because of foo.in) then bar.cpp.o will be recompiled
when it need not be. Similarly, main.cpp need not be recompiled if
bar.cpp changes. Also, bar.cpp is stated to be both an explicit and an
implicit dependency of bar.cpp.o.
What we want here is:
build main.cpp.o: main.cpp || foo.h
build bar.cpp.o: bar.cpp
Additional Information:
I have studied the Ninja generator code a bit and found the logic
responsible for writing the object build statements in
cmNinjaTargetGenerator::WriteObjectBuildStatement(.) on line 554 in
cmNinjaTargetGenerator.cxx. I see that this logic recently changed.
Previously the generated files would have showed up as order-only
dependencies. This is closer to the desired result but still not
perfect. There must be a better way but I am not familiar enough with
cmake internals to know what that is.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-10-16 10:00 Frank Miller New Issue
==
--
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] patch for cmake that adds a new timestamp command
I certainly wouldn't mind though I'm not sure what that means. Do the changes in next still potentially make it into 2.8.10? Brad mentioned this would be on the TODO list for after 2.8.10. I've tried to run all tests successfully before submitting but I can't tell if any of those were called BootstrapTest. Is there anything special required to run it? Nils On 10/16/2012 02:49 PM, David Cole wrote: I had to do this to get the bootstrap version of CMake to work (and the BootstrapTest to pass): $ git diff diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt index 9d46355..8bf6c40 100644 --- a/Source/CMakeLists.txt +++ b/Source/CMakeLists.txt @@ -264,8 +264,6 @@ set(SRCS cmTarget.cxx cmTarget.h cmTargetExport.h - cmTimestamp.h - cmTimestamp.cxx cmTest.cxx cmTest.h cmTestGenerator.cxx diff --git a/Source/cmBootstrapCommands.cxx b/Source/cmBootstrapCommands.cxx index 9097a74..e3a2ad4 100644 --- a/Source/cmBootstrapCommands.cxx +++ b/Source/cmBootstrapCommands.cxx @@ -89,6 +89,7 @@ #include cmStringCommand.cxx #include cmSubdirCommand.cxx #include cmTargetLinkLibrariesCommand.cxx +#include cmTimestamp.cxx #include cmTryCompileCommand.cxx #include cmTryRunCommand.cxx #include cmUnsetCommand.cxx After amending this, I'll push to next later today unless somebody objects to this?? Thanks, David On Fri, Oct 5, 2012 at 4:16 PM, Nils Gladitz glad...@sci-vis.de wrote: I've updated the patch (attached) to return empty string on failure. I also tried to use the time definitions from global namespace rather than std::. Nils On 10/05/2012 09:17 PM, Brad King wrote: On 10/05/2012 02:53 PM, Nils Gladitz wrote: My initial thought was that NOTFOUND would be a good idea since it evaluates to false and the get_*_property commands also seem to use it. I wrote the more general get_property command to replace those and the newer command uses empty string rather than NOTFOUND. It is more useful when computing pieces of a string to put together, perhaps when appending to a property value. Looking at the documentation for if() again only -NOTFOUND as a suffix should evaluate to false though (I assume the documentation is incomplete here?). Yes, thanks for pointing it out. Fixed: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f63304d9 On second though relying on timestamps to evaluate to false on failure is probably a bad idea since I could have a format string of e.g. %w (day of the week) which might produce a valid timestamp 0 which would also evaluate to false. Yes, so a comparison against would be more reliable. Thanks, -Brad -- Nils Gladitz, B.Sc. DICOM, Konnektivität und Entwicklung Scivis wissenschaftliche Bildverarbeitung GmbH Bertha-von-Suttner-Str. 5 D-37085 Göttingen GERMANY Handelsregister Nr. / Trade Register No. B3100 Göttingen Geschäftsführer / Managing Directors Dr. Gernot Ebel, Dr. Uwe Engeland Tel: 0049 (0)551 634181-28 E-Mail: glad...@scivis.de Web: www.scivis.de -- 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 -- Nils Gladitz, B.Sc. DICOM, Konnektivität und Entwicklung Scivis wissenschaftliche Bildverarbeitung GmbH Bertha-von-Suttner-Str. 5 D-37085 Göttingen GERMANY Handelsregister Nr. / Trade Register No. B3100 Göttingen Geschäftsführer / Managing Directors Dr. Gernot Ebel, Dr. Uwe Engeland Tel: 0049 (0)551 634181-28 E-Mail: glad...@scivis.de Web: www.scivis.de -- 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] Best practices questions
Hi, I tried submitting my first patch recently (Issue 0013587) and I have a few follow-up questions regarding best practices: 1) Looking at the dashboard, I apparently forgot to quote a path somewhere in the test and it failed on spaces. What is the preferred way for me to provide a fix for the tests? A new commit normally continuing history of the patch as I submitted it? Somehow incorporating changes which were done (by Brad in this case) when merging to next? Something else? 2) Is there a code style document I could read somewhere? I now understand line width is preferred at 79 columns max. and I believe I've figured out brace indenting; anything else I should follow? 3) If I have an idea for a feature I'd like to add, how should I start? Bring it up for discussion here, raise an issue in Mantis, just code the patch and send it in, ...? Thanks. Petr -- 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] Best practices questions
On 10/16/2012 10:36 AM, Petr Kmoch wrote: 1) Looking at the dashboard, I apparently forgot to quote a path somewhere in the test and it failed on spaces. What is the preferred way for me to provide a fix for the tests? A new commit normally continuing history of the patch as I submitted it? Somehow incorporating changes which were done (by Brad in this case) when merging to next? Something else? Once a developer with push access takes the patch then it becomes his/her responsibility to follow up with dashboard trouble. We'll contact the author if we need further help. I tested it locally on VS 6, 7.1, 8, 9, 10, and 11 all with spaces in the path. I need to investigate the failures on the dashboard to identify the problem. 2) Is there a code style document I could read somewhere? I now understand line width is preferred at 79 columns max. and I believe I've figured out brace indenting; anything else I should follow? It is basically: - Copy existing brace style - 79 column limit in C++ sources - Use this- to access members - Use CamelCase names for members - Local variables start in lower-case letters but there is no style convention otherwise 3) If I have an idea for a feature I'd like to add, how should I start? Bring it up for discussion here, raise an issue in Mantis, just code the patch and send it in, ...? Discussion here, please. If you have an initial patch to include in your post to the list that is fine. Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] EXCLUDE_FROM_DEFAULT_BUILD testing
On 10/16/2012 11:04 AM, Brad King wrote: I tested it locally on VS 6, 7.1, 8, 9, 10, and 11 all with spaces in the path. I need to investigate the failures on the dashboard to identify the problem. Since we're trying to keep the dashboard as clean as possible right now (to more directly test any changes meant to fix any regressions in 2.8.10-rc1) I'm reverting the change: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=69e305f2 until after the final 2.8.10 release and when we've resolved these failures. We can restore the topic later. The problem is that MSBuild may be used as the build tool instead of devenv, especially for VS Express editions. The MSBuild tool doesn't even read the .sln so this property does not make sense. One option is to run the test only when the build tool is devenv. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] patch for cmake that adds a new timestamp command
On Tue, Oct 16, 2012 at 10:12 AM, Nils Gladitz glad...@sci-vis.de wrote: I certainly wouldn't mind though I'm not sure what that means. Do the changes in next still potentially make it into 2.8.10? Going into 'next' is how stuff gets tested on the dashboards, and then later Brad and I merge things to 'master' when they're ready. After something is merged to 'master' it will be in the CMake release that follows that. Brad mentioned this would be on the TODO list for after 2.8.10. We can put it in 'next' to vet it and correct any dashboard issues that show up (errors/warnings on other platforms, other platform test failures) at any time. But it will probably not go into 'master' until after 2.8.10. We don't typically add significant features or take risky changes after we start doing release candidates. I've tried to run all tests successfully before submitting but I can't tell if any of those were called BootstrapTest. Is there anything special required to run it? The BootstrapTest test only runs on Unix Makefiles based builds, so if you're using a different generator, it does not get added as a test. Nils On 10/16/2012 02:49 PM, David Cole wrote: I had to do this to get the bootstrap version of CMake to work (and the BootstrapTest to pass): $ git diff diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt index 9d46355..8bf6c40 100644 --- a/Source/CMakeLists.txt +++ b/Source/CMakeLists.txt @@ -264,8 +264,6 @@ set(SRCS cmTarget.cxx cmTarget.h cmTargetExport.h - cmTimestamp.h - cmTimestamp.cxx cmTest.cxx cmTest.h cmTestGenerator.cxx diff --git a/Source/cmBootstrapCommands.cxx b/Source/cmBootstrapCommands.cxx index 9097a74..e3a2ad4 100644 --- a/Source/cmBootstrapCommands.cxx +++ b/Source/cmBootstrapCommands.cxx @@ -89,6 +89,7 @@ #include cmStringCommand.cxx #include cmSubdirCommand.cxx #include cmTargetLinkLibrariesCommand.cxx +#include cmTimestamp.cxx #include cmTryCompileCommand.cxx #include cmTryRunCommand.cxx #include cmUnsetCommand.cxx After amending this, I'll push to next later today unless somebody objects to this?? Thanks, David On Fri, Oct 5, 2012 at 4:16 PM, Nils Gladitz glad...@sci-vis.de wrote: I've updated the patch (attached) to return empty string on failure. I also tried to use the time definitions from global namespace rather than std::. Nils On 10/05/2012 09:17 PM, Brad King wrote: On 10/05/2012 02:53 PM, Nils Gladitz wrote: My initial thought was that NOTFOUND would be a good idea since it evaluates to false and the get_*_property commands also seem to use it. I wrote the more general get_property command to replace those and the newer command uses empty string rather than NOTFOUND. It is more useful when computing pieces of a string to put together, perhaps when appending to a property value. Looking at the documentation for if() again only -NOTFOUND as a suffix should evaluate to false though (I assume the documentation is incomplete here?). Yes, thanks for pointing it out. Fixed: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f63304d9 On second though relying on timestamps to evaluate to false on failure is probably a bad idea since I could have a format string of e.g. %w (day of the week) which might produce a valid timestamp 0 which would also evaluate to false. Yes, so a comparison against would be more reliable. Thanks, -Brad -- Nils Gladitz, B.Sc. DICOM, Konnektivität und Entwicklung Scivis wissenschaftliche Bildverarbeitung GmbH Bertha-von-Suttner-Str. 5 D-37085 Göttingen GERMANY Handelsregister Nr. / Trade Register No. B3100 Göttingen Geschäftsführer / Managing Directors Dr. Gernot Ebel, Dr. Uwe Engeland Tel: 0049 (0)551 634181-28 E-Mail: glad...@scivis.de Web: www.scivis.de -- 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 -- Nils Gladitz, B.Sc. DICOM, Konnektivität und Entwicklung Scivis wissenschaftliche Bildverarbeitung GmbH Bertha-von-Suttner-Str. 5 D-37085 Göttingen GERMANY Handelsregister Nr. / Trade Register No. B3100 Göttingen Geschäftsführer / Managing Directors Dr. Gernot Ebel, Dr. Uwe Engeland Tel: 0049 (0)551 634181-28 E-Mail: glad...@scivis.de Web: www.scivis.de -- 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] patch for cmake that adds a new timestamp command
Ah that might explain it ... I may have been using nmake on Windows and ninja on linux. Thanks! Nils On 10/16/2012 05:27 PM, David Cole wrote: On Tue, Oct 16, 2012 at 10:12 AM, Nils Gladitz glad...@sci-vis.de wrote: I certainly wouldn't mind though I'm not sure what that means. Do the changes in next still potentially make it into 2.8.10? Going into 'next' is how stuff gets tested on the dashboards, and then later Brad and I merge things to 'master' when they're ready. After something is merged to 'master' it will be in the CMake release that follows that. Brad mentioned this would be on the TODO list for after 2.8.10. We can put it in 'next' to vet it and correct any dashboard issues that show up (errors/warnings on other platforms, other platform test failures) at any time. But it will probably not go into 'master' until after 2.8.10. We don't typically add significant features or take risky changes after we start doing release candidates. I've tried to run all tests successfully before submitting but I can't tell if any of those were called BootstrapTest. Is there anything special required to run it? The BootstrapTest test only runs on Unix Makefiles based builds, so if you're using a different generator, it does not get added as a test. Nils On 10/16/2012 02:49 PM, David Cole wrote: I had to do this to get the bootstrap version of CMake to work (and the BootstrapTest to pass): $ git diff diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt index 9d46355..8bf6c40 100644 --- a/Source/CMakeLists.txt +++ b/Source/CMakeLists.txt @@ -264,8 +264,6 @@ set(SRCS cmTarget.cxx cmTarget.h cmTargetExport.h - cmTimestamp.h - cmTimestamp.cxx cmTest.cxx cmTest.h cmTestGenerator.cxx diff --git a/Source/cmBootstrapCommands.cxx b/Source/cmBootstrapCommands.cxx index 9097a74..e3a2ad4 100644 --- a/Source/cmBootstrapCommands.cxx +++ b/Source/cmBootstrapCommands.cxx @@ -89,6 +89,7 @@ #include cmStringCommand.cxx #include cmSubdirCommand.cxx #include cmTargetLinkLibrariesCommand.cxx +#include cmTimestamp.cxx #include cmTryCompileCommand.cxx #include cmTryRunCommand.cxx #include cmUnsetCommand.cxx After amending this, I'll push to next later today unless somebody objects to this?? Thanks, David On Fri, Oct 5, 2012 at 4:16 PM, Nils Gladitz glad...@sci-vis.de wrote: I've updated the patch (attached) to return empty string on failure. I also tried to use the time definitions from global namespace rather than std::. Nils On 10/05/2012 09:17 PM, Brad King wrote: On 10/05/2012 02:53 PM, Nils Gladitz wrote: My initial thought was that NOTFOUND would be a good idea since it evaluates to false and the get_*_property commands also seem to use it. I wrote the more general get_property command to replace those and the newer command uses empty string rather than NOTFOUND. It is more useful when computing pieces of a string to put together, perhaps when appending to a property value. Looking at the documentation for if() again only -NOTFOUND as a suffix should evaluate to false though (I assume the documentation is incomplete here?). Yes, thanks for pointing it out. Fixed: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f63304d9 On second though relying on timestamps to evaluate to false on failure is probably a bad idea since I could have a format string of e.g. %w (day of the week) which might produce a valid timestamp 0 which would also evaluate to false. Yes, so a comparison against would be more reliable. Thanks, -Brad -- Nils Gladitz, B.Sc. DICOM, Konnektivität und Entwicklung Scivis wissenschaftliche Bildverarbeitung GmbH Bertha-von-Suttner-Str. 5 D-37085 Göttingen GERMANY Handelsregister Nr. / Trade Register No. B3100 Göttingen Geschäftsführer / Managing Directors Dr. Gernot Ebel, Dr. Uwe Engeland Tel: 0049 (0)551 634181-28 E-Mail: glad...@scivis.de Web: www.scivis.de -- 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 -- Nils Gladitz, B.Sc. DICOM, Konnektivität und Entwicklung Scivis wissenschaftliche Bildverarbeitung GmbH Bertha-von-Suttner-Str. 5 D-37085 Göttingen GERMANY Handelsregister Nr. / Trade Register No. B3100 Göttingen Geschäftsführer / Managing Directors Dr. Gernot Ebel, Dr. Uwe Engeland Tel: 0049 (0)551 634181-28 E-Mail: glad...@scivis.de Web: www.scivis.de -- Nils Gladitz, B.Sc. DICOM, Konnektivität und Entwicklung Scivis wissenschaftliche Bildverarbeitung GmbH Bertha-von-Suttner-Str. 5 D-37085 Göttingen GERMANY Handelsregister Nr. / Trade Register No. B3100 Göttingen Geschäftsführer / Managing Directors Dr. Gernot Ebel, Dr. Uwe Engeland Tel: 0049 (0)551 634181-28 E-Mail: glad...@scivis.de Web: www.scivis.de
[cmake-developers] [CMake 0013593]: CMake mistakenly says what is newer
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13593 == Reported By:Vadim Zhukov Assigned To: == Project:CMake Issue ID: 13593 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-10-16 12:37 EDT Last Modified: 2012-10-16 12:37 EDT == Summary:CMake mistakenly says what is newer Description: I'm building KDE 4.9.2 localization packages and have a problem that looks like having its root in CMake. Configure stage runs fine, but no Gettext files got processed. For each corrseponding target CMake says the following: Dependee /usr/ports/pobj/kde-l10n-vi-4.9.2/build-i386/messages/qt/CMakeFiles/pofiles_20.dir/DependInfo.cmake is newer than depender /usr/ports/pobj/kde-l10n-vi-4.9.2/build-i386/messages/qt/CMakeFiles/pofiles_20.dir/depend.internal. But... -rw-r--r-- 1 pers wheel 596 Oct 16 20:12:08 2012 /usr/ports/pobj/kde-l10n-vi-4.9.2/build-i386/messages/qt/CMakeFiles/pofiles_20.dir/DependInfo.cmake -rw-r--r-- 1 pers wheel 99 Oct 16 20:12:21 2012 /usr/ports/pobj/kde-l10n-vi-4.9.2/build-i386/messages/qt/CMakeFiles/pofiles_20.dir/depend.internal The full output for one of the targets, with OpenBSD's make debug output includes, placed below. All other localization targets build fine. I attach FindGettext.cmake from my system in case of interest. Steps to Reproduce: Running that command for configuring port (standard one from OpenBSD ports): /usr/bin/env -i CC=cc CFLAGS=-O2 -pipe CXX=c++ CXXFLAGS=-O2 -pipe CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib -liconv -lintl HOME=/usr/ports/pobj/kde-l10n-vi-4.9.2 MODJAVA_VER= MODLUA_VERSION= MODLUA_BIN= MODLUA_INCL_DIR= MODPY_VERSION= MODPY_BIN= MODPY_INCDIR= MODPY_LIBDIR= MODTCL_VERSION= MODTK_VERSION= MODTCL_INCDIR= MODTK_INCDIR= MODTCL_LIBDIR= MODTK_LIBDIR= MODTCL_LIB= MODTK_LIB= PATH=/usr/ports/pobj/kde-l10n-vi-4.9.2/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/bin:/usr/X11R6/bin /usr/local/bin/cmake -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY:Bool=True -DKDE4_BUILD_TESTS:Bool=Yes -DKDE4_INCLUDE_INSTALL_DIR:String=/usr/local/include -DKDE4_INSTALL_DIR:String=/usr/local -DKDE4_LIB_INSTALL_DIR:String=/usr/local/lib -DKDE4_LIBEXEC_INSTALL_DIR:String=/usr/local/libexec -DKDE4_INFO_INSTALL_DIR:String=/usr/local/info -DKDE4_MAN_INSTALL_DIR:String=/usr/local/man -DKDE4_SYSCONF_INSTALL_DIR:String=/etc /usr/ports/pobj/kde-l10n-vi-4.9.2/kde-l10n-vi-4.9.2 Then the following for actual build: VERBOSE=1 PATH='/usr/ports/pobj/kde-l10n-vi-4.9.2/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/bin:/usr/X11R6/bin' PREFIX='/usr/local' LOCALBASE='/usr/local' DEPBASE='/usr/local' X11BASE='/usr/X11R6' CFLAGS='-O2 -pipe' TRUEPREFIX='/usr/local' DESTDIR='' HOME='/usr/ports/pobj/kde-l10n-vi-4.9.2' ELF_TOOLCHAIN=yes COMPILER_VERSION=gcc4 PICFLAG=-fpic ASPICFLAG= BINGRP=bin BINOWN=root BINMODE=555 NONBINMODE=444 DIRMODE=755 INSTALL_COPY=-c INSTALL_STRIP=-s MANGRP=bin MANOWN=root MANMODE=444 BSD_INSTALL_PROGRAM=install -c -s -o root -g bin -m 555 BSD_INSTALL_SCRIPT=install -c -o root -g bin -m 555 BSD_INSTALL_DATA=install -c -o root -g bin -m 444 BSD_INSTALL_MAN=install -c -o root -g bin -m 444 BSD_INSTALL_PROGRAM_DIR=install -d -o root -g bin -m 755 BSD_INSTALL_SCRIPT_DIR=install -d -o root -g bin -m 755 BSD_INSTALL_DATA_DIR=install -d -o root -g bin -m 755 BSD_INSTALL_MAN_DIR=install -d -o root -g bin -m 755 make -d m SHARED_LIBS_LOG=/usr/ports/pobj/kde-l10n-vi-4.9.2/build-i386/shared_libs.log -f Makefile all This produces the following output (with some debugging in local system make(1) included) for each Gettext target: Built target pofiles_19 update time: 20:12:21 Oct 16, 2012 CompatMake(all, messages/qt/CMakeFiles/pofiles_20.dir/all) Examining messages/qt/CMakeFiles/pofiles_20.dir/allPHONY node...out-of-date. make -f messages/qt/CMakeFiles/pofiles_20.dir/build.make messages/qt/CMakeFiles/pofiles_20.dir/depend CompatMake(NULL, messages/qt/CMakeFiles/pofiles_20.dir/depend) Examining messages/qt/CMakeFiles/pofiles_20.dir/dependPHONY node...out-of-date. cd /usr/ports/pobj/kde-l10n-vi-4.9.2/build-i386 /usr/local/bin/cmake -E cmake_depends Unix Makefiles /usr/ports/pobj/kde -l10n-vi-4.9.2/kde-l10n-vi-4.9.2 /usr/ports/pobj/kde-l10n-vi-4.9.2/kde-l10n-vi-4.9.2/messages/qt /usr/ports/pobj/kde-l10n-vi-4.9.2/build-i386 /usr/ports/pobj/kde-l10n-vi-4.9.2/build-i386/messages/qt
Re: [cmake-developers] Best practices questions
Hello, Am Dienstag, 16. Oktober 2012 um 16:36:49 schrieb Petr Kmoch: 2) Is there a code style document I could read somewhere? I now understand line width is preferred at 79 columns max. and I believe I've figured out brace indenting; anything else I should follow? for writing CMake code I have created a configuration file for Uncrustify [1]. I have attached it to this e-mail. It was created for my personal use and is not official. But maybe it is helpful to someone. If there is going to be some interest, one could think about putting it in a repository somewhere. Kind regards Benjamin [1] http://uncrustify.sourceforge.net/ tok_split_gte=false utf8_byte=false utf8_force=false indent_cmt_with_tabs=false indent_align_string=false indent_braces=true indent_braces_no_func=true indent_braces_no_class=true indent_braces_no_struct=true indent_brace_parent=false indent_namespace=false indent_extern=false indent_class=false indent_class_colon=false indent_else_if=false indent_var_def_cont=false indent_func_call_param=false indent_func_def_param=false indent_func_proto_param=false indent_func_class_param=false indent_func_ctor_var_param=false indent_template_param=false indent_func_param_double=false indent_relative_single_line_comments=false indent_col1_comment=false indent_access_spec_body=true indent_paren_nl=false indent_comma_paren=false indent_bool_paren=false indent_first_bool_expr=false indent_square_nl=false indent_preserve_sql=false indent_align_assign=true sp_balance_nested_parens=false align_keep_tabs=false align_with_tabs=false align_on_tabstop=false align_number_left=false align_func_params=false align_same_func_call_params=false align_var_def_colon=false align_var_def_attribute=false align_var_def_inline=false align_right_cmt_mix=false align_on_operator=false align_mix_var_proto=false align_single_line_func=false align_single_line_brace=false align_nl_cont=false align_left_shift=true align_oc_decl_colon=false nl_collapse_empty_body=false nl_assign_leave_one_liners=false nl_class_leave_one_liners=false nl_enum_leave_one_liners=false nl_getset_leave_one_liners=false nl_func_leave_one_liners=false nl_if_leave_one_liners=false nl_multi_line_cond=false nl_multi_line_define=false nl_before_case=false nl_after_case=false nl_after_return=false nl_after_semicolon=true nl_after_brace_open=false nl_after_brace_open_cmt=false nl_after_vbrace_open=false nl_after_vbrace_open_empty=false nl_after_brace_close=false nl_after_vbrace_close=false nl_define_macro=false nl_squeeze_ifdef=false nl_ds_struct_enum_cmt=false nl_ds_struct_enum_close_brace=false nl_create_if_one_liner=false nl_create_for_one_liner=false nl_create_while_one_liner=false ls_for_split_full=false ls_func_split_full=false nl_after_multiline_comment=false eat_blanks_after_open_brace=false eat_blanks_before_close_brace=false mod_full_brace_if_chain=false mod_pawn_semicolon=false mod_full_paren_if_bool=false mod_remove_extra_semicolon=true mod_sort_import=false mod_sort_using=false mod_sort_include=false mod_move_case_break=false mod_remove_empty_return=true cmt_indent_multi=false cmt_c_group=false cmt_c_nl_start=false cmt_c_nl_end=false cmt_cpp_group=false cmt_cpp_nl_start=false cmt_cpp_nl_end=false cmt_cpp_to_c=false cmt_star_cont=true cmt_multi_check_last=false cmt_insert_before_preproc=false pp_indent_at_level=false pp_region_indent_code=false pp_if_indent_code=false pp_define_at_level=false output_tab_size=2 indent_columns=2 indent_switch_case=2 nl_end_of_file_min=1 code_width=79 indent_with_tabs=0 sp_arith=force sp_assign=force sp_bool=force sp_compare=force sp_inside_paren=remove sp_paren_paren=remove sp_paren_brace=force sp_before_ptr_star=add sp_before_unnamed_ptr_star=add sp_between_ptr_star=force sp_after_ptr_star=force sp_before_byref=force sp_before_unnamed_byref=remove sp_after_byref=force sp_after_type=force sp_template_angle=remove sp_before_angle=remove sp_inside_angle=remove sp_after_angle=remove sp_angle_paren=remove sp_angle_word=force sp_before_sparen=force sp_inside_sparen=remove sp_sparen_brace=force sp_before_semi_for=remove sp_before_semi_for_empty=remove sp_after_semi_for_empty=remove sp_before_square=remove sp_before_squares=remove sp_inside_square=remove sp_after_comma=force sp_before_comma=remove sp_after_class_colon=force sp_before_class_colon=force sp_before_case_colon=remove sp_after_operator=remove sp_after_operator_sym=remove sp_sizeof_paren=remove sp_inside_braces_enum=remove sp_inside_braces_struct=remove sp_inside_braces=remove sp_inside_braces_empty=remove sp_type_func=force sp_func_def_paren=remove sp_inside_fparens=remove sp_inside_fparen=remove sp_square_fparen=remove sp_fparen_brace=force sp_func_call_paren=remove sp_func_class_paren=remove sp_return_paren=force sp_defined_paren=force sp_throw_paren=force sp_macro=force sp_else_brace=force sp_brace_else=force sp_brace_typedef=force sp_catch_brace=force sp_brace_catch=force sp_finally_brace=force sp_brace_finally=force sp_try_brace=force
Re: [cmake-developers] [CMake] Random behavior of CTEST_USE_LAUNCHERS
On 10/16/2012 03:09 PM, Nils Gladitz wrote: Well what would be awesome is having the launcher extract individual diagnostic messages. Limitations of that kind of log scraping was precisely the reason we created CTEST_USE_LAUNCHERS in the first place. At most CTest should add markup CDash can use to highlight unsuppressed warnings. That way failure does not drop anything, messages are just less prominent. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] Random behavior of CTEST_USE_LAUNCHERS
Well, the mixing of lines of output from parallel compiles was the main reason log scraping didn't work well. At least with the launchers, we'd be able to scrape from a single output stream associated with a single build step and we wouldn't have the mixing of lines problem anymore. Nils has a point in that we are already analyzing the output line-by-line in order to do custom warning suppression. It would be awesome to make it better. (But would also probably require some corresponding CDash changes...) It's not going to be an easy do it in a day kind of thing, but this is a good idea to keep on the back burner. (Nils's main challenge at the moment, if I understand correctly, is to find the ONE or TWO unsuppressed warnings in an output stream that contains 100's of warnings... so that he can then suppress those as well) David On Tue, Oct 16, 2012 at 3:27 PM, Brad King brad.k...@kitware.com wrote: On 10/16/2012 03:09 PM, Nils Gladitz wrote: Well what would be awesome is having the launcher extract individual diagnostic messages. Limitations of that kind of log scraping was precisely the reason we created CTEST_USE_LAUNCHERS in the first place. At most CTest should add markup CDash can use to highlight unsuppressed warnings. That way failure does not drop anything, messages are just less prominent. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Bugs on the roadmap
The following bugs are on the roadmap (still in the 2.8.10 section), even though they are unassigned: http://public.kitware.com/Bug/view.php?id=8170 http://public.kitware.com/Bug/view.php?id=9905 http://public.kitware.com/Bug/view.php?id=11536 http://public.kitware.com/Bug/view.php?id=11785 http://public.kitware.com/Bug/view.php?id=12264 http://public.kitware.com/Bug/view.php?id=12309 http://public.kitware.com/Bug/view.php?id=12373 http://public.kitware.com/Bug/view.php?id=12951 http://public.kitware.com/Bug/view.php?id=12998 http://public.kitware.com/Bug/view.php?id=13162 http://public.kitware.com/Bug/view.php?id=13204 http://public.kitware.com/Bug/view.php?id=13511 http://public.kitware.com/Bug/view.php?id=13532 0008170: [CMake] Visual Studio 9 generator does not output Custom Build Tool command line for assembler sources - new. 0009905: [CMake] Support for .asm files in the Visual Studio generators - new. 0011536: [CMake] Can't use assembler files with Visual Studio 10 generator - new. 0011785: [CPack] CPack no stripping with MinGW and NSIS - new. 0012264: [CMake] CMake nmake generated makefiles don't consider .ilk and .rsp files when cleaning - new. 0012309: Support raw replacements in IMPLICIT_DEPENDS_INCLUDE_TRANSFORM - new. 0012373: [Documentation] Specify version changes with each commands/variables - new. 0012951: [CMake] The DEFINE variable doesn't expand with VS generators but expands correctly with the nmake one - new. 0012998: [CMake] rc-File support for MinGW: FLAGS incompatibilities between GCC and windres - new. 0013162: [CMake] create_symlink command portability - new. 0013204: Docs don't say what happens to symlinks in copy_directory - new. 0013511: [CMake] Cannot use with VS 2012 RTM for ARM platform - backlog. 0013532: [CMake] kitware-provided CMake installer/executables should be codesigned with 'Developer ID' for GateKeeper on OS X - new. Is anybody working on any of them? If not, I propose that we move them to the CMake 2.8.11 roadmap and see if anybody picks them up for the next release. Also, if you personally have bugs assigned to you that are on the 2.8.10 roadmap, but will not actually have a fix in 2.8.10 (I think you should probably know by now) then please move it to 2.8.11, or send it to the backlog if you're not actually working on it. Thanks, David -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Bugs on the roadmap
Thanks, Eike. Note that I am not asking *who* should be looking at these bugs. I am asking if anyone is *actually* looking at them at all If you are not looking at them, no need for a response. If you are looking at them, please assign them to yourself. If nobody replies or claims these before end of day tomorrow, I'll move them to the 2.8.11 roadmap and re-beg for claimers again later. Thx, David On Tue, Oct 16, 2012 at 5:48 PM, Rolf Eike Beer e...@sf-mail.de wrote: David Cole wrote: The following bugs are on the roadmap (still in the 2.8.10 section), even though they are unassigned: 0008170: [CMake] Visual Studio 9 generator does not output Custom Build Tool command line for assembler sources - new. 0009905: [CMake] Support for .asm files in the Visual Studio generators - new. 0011536: [CMake] Can't use assembler files with Visual Studio 10 generator - new. Those sound like Alex should have a look. Pretty sure Alex doesn't want to do Visual Studio related stuff based on his comment in this related bug: http://public.kitware.com/Bug/view.php?id=11536#c26579 0011785: [CPack] CPack no stripping with MinGW and NSIS - new. Probably Eric. 0012264: [CMake] CMake nmake generated makefiles don't consider .ilk and .rsp files when cleaning - new. 0012309: Support raw replacements in IMPLICIT_DEPENDS_INCLUDE_TRANSFORM - new. No idea. 0012373: [Documentation] Specify version changes with each commands/variables - new. This could be done by everyone that is bored I think. How do we want to have it? I found (since 2.8.x) and [Since 2.8.x], but only for variables in Find*.cmake modules. 0012951: [CMake] The DEFINE variable doesn't expand with VS generators but expands correctly with the nmake one - new. 0012998: [CMake] rc-File support for MinGW: FLAGS incompatibilities between GCC and windres - new. 0013162: [CMake] create_symlink command portability - new. No idea. 0013204: Docs don't say what happens to symlinks in copy_directory - new. Sounds like it is pretty trivial, but it should include some testing (e.g. copying from ext[234] to ext[234] and from ext[234] to vfat or so). 0013511: [CMake] Cannot use with VS 2012 RTM for ARM platform - backlog. 0013532: [CMake] kitware-provided CMake installer/executables should be codesigned with 'Developer ID' for GateKeeper on OS X - new. No idea. Eike -- -- 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
