[cmake-developers] [CMake 0014570]: Intel + Ninja regression: unable to compile a simple test program
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14570 == Reported By:Nils Gladitz Assigned To: == Project:CMake Issue ID: 14570 Category: (No Category) Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2013-11-15 03:26 EST Last Modified: 2013-11-15 03:26 EST == Summary:Intel + Ninja regression: unable to compile a simple test program Description: I tried the current master (958367e10cee44d2dbce72f9393168746099ebd1) with Ninja and the Intel compiler on Window which results in: -- The C compiler identification is Intel 12.1.0.20120612 -- The CXX compiler identification is Intel 12.1.0.20120612 -- Check for working C compiler using: Ninja -- Check for working C compiler using: Ninja -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler using: Ninja -- Check for working CXX compiler using: Ninja -- broken CMake Error at C:/opt/cmake-git/share/cmake-2.8.12/Modules/CMakeTestCXXCompiler.cmake:54 (message): The C++ compiler "C:/Program Files (x86)/Intel/Composer XE 2011 SP1/bin/intel64/icl.exe" is not able to compile a simple test program. It fails with the following output: Change Dir: C:/cdash/086b772-bin/CMakeFiles/CMakeTmp Run Build Command:c:/Tools/ninja.exe cmTryCompileExec983296435 [1/2] Building CXX object CMakeFiles\cmTryCompileExec983296435.dir\testCXXCompiler.cxx.obj FAILED: C:\PROGRA~2\Intel\COMPOS~1\bin\intel64\icl.exe /nologo /TP /DWIN32 /D_WINDOWS /W3 /GR /EHsc /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 -MMD -MT CMakeFiles\cmTryCompileExec983296435.dir\testCXXCompiler.cxx.obj -MF CMakeFiles/cmTryCompileExec983296435.dir/testCXXCompiler.cxx.obj.d /FoCMakeFiles\cmTryCompileExec983296435.dir\testCXXCompiler.cxx.obj /FdCMakeFiles\cmTryCompileExec983296435.dir/ -c testCXXCompiler.cxx icl: command line warning http://www.cmake.org/Bug/view.php?id=10006: ignoring unknown option '/MMD' icl: command line warning http://www.cmake.org/Bug/view.php?id=10121: overriding '/MDd' with '/MT' icl: command line warning http://www.cmake.org/Bug/view.php?id=10006: ignoring unknown option '/MF' icl: command line error: multiple sources; obj output option must specify dir ninja: build stopped: subcommand failed. [...] The "NMake Makefiles" generator still works. == Issue History Date ModifiedUsername FieldChange == 2013-11-15 03:26 Nils Gladitz 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] Weird behaviour of arguments in macro
On 14/11/13 20:39, Brad King wrote: > On 11/14/2013 12:09 PM, Daniele E. Domenichelli wrote: >> Is this a wanted behaviour? If it is, perhaps it should be documented in >> macro() command documentation. > > The "macro" command documentation says: > > http://www.cmake.org/cmake/help/v2.8.12/cmake.html#command:macro > Note that the parameters to a macro ... are not variables > > The "if" command documentation says: > > http://www.cmake.org/cmake/help/v2.8.12/cmake.html#command:if > Note macro arguments are not variables. Ok there is some documentation, but perhaps it is not very clear what you cannot do with a macro parameter: * it's not a variable but it isn't either a list (the list() documentation says "A list in cmake is a ; separated group of strings", and doesn't mention macro arguments). Therefore you cannot use the list() command. * foreach(IN LISTS), does not mention that it won't work with macro parameters. * The if() command mentions that in the documentation of the if(var) form, but not in the if(DEFINED var). Also the problem that gave me more issues is that I was using ARGN like this: macro(_BAR) foreach(arg IN LISTS ARGN) [...] endforeach() endmacro() function(_FOO) _bar(x y z) endfunction() _foo(a b c) And it took a lot of time to realize that I was using the list from the current scope, not from the macro. So I believe that some more documentation would be helpful... If you agree, I can write it... Cheers, Daniele -- 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] Invalid/Reserved target names
I would like to hijack/extend Stephen's changes in 05f5fde0eb83c0e49aab3214f28a098861aa3313 to also disallow target names that have been implicitly reserved by some of the generators. This list might not be complete but I assume it would be at least: all, help, clean, edit_cache, rebuild_cache, test, package, package_source, PACKAGE, ZERO_CHECK Would anyone be opposed to this? Could I extend the existing policy, should I create a new one or would it be ok without any policy even? Nils -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014571]: CMake does not validate cache entries given on the command line
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14571 == Reported By:Magnus Johansson Assigned To: == Project:CMake Issue ID: 14571 Category: CMake Reproducibility:random Severity: minor Priority: normal Status: new == Date Submitted: 2013-11-15 08:19 EST Last Modified: 2013-11-15 08:19 EST == Summary:CMake does not validate cache entries given on the command line Description: Typically you set a cache entry like this: cmake -DMYFLAG:string=ON However, cmake also accepts this degenerate case: cmake -D:string=ON When called like this I got very strange build failures: [ 32%] Building C object progs/bkz/prog/CMakeFiles/bkz.dir/bkz.c.o cd /import/build/magnus/rembuild/boks/redhat-6.0/progs/bkz/prog && /usr/bin/cc -I/import/build/magnus/rembuild/boks/redhat-6.0/BUILD/include-o CMakeFiles/bkz.dir/bkz.c.o -c /import/build/mj/boks-sources/boks/progs/bkz/prog/bkz.c Linking C executable ONbkz Note that when linking, bkz had received the prefix "ON" which shouldn't be there, and caused subsequent errors. (CMake got called with bad input like this due to a bug in our build scripts, where a variable was sometimes not set. This was very hard to track down. If CMake had validated the input, this would have been much easier to find.) == Issue History Date ModifiedUsername FieldChange == 2013-11-15 08:19 Magnus JohanssonNew 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] Invalid/Reserved target names
On 2013-11-15 04:05, Nils Gladitz wrote: I would like to hijack/extend Stephen's changes in 05f5fde0eb83c0e49aab3214f28a098861aa3313 to also disallow target names that have been implicitly reserved by some of the generators. This list might not be complete but I assume it would be at least: all, help, clean, edit_cache, rebuild_cache, test, package, package_source, PACKAGE, ZERO_CHECK Would anyone be opposed to this? Could I extend the existing policy, should I create a new one or would it be ok without any policy even? I haven't done so yet, but I've considered once or twice creating a 'clean' target in case the generator is ninja. Possibly someone has already done that. Maybe only disallow target names that the generator actually uses? (Or should we teach CMake to make a 'clean' target for ninja? :-) That could probably be done separately, but if 'clean' is disallowed unconditionally it feels like that should be "on the radar" of things to do.) -- Matthew -- 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] Invalid/Reserved target names
On 11/15/2013 04:05 AM, Nils Gladitz wrote: > This list might not be complete but I assume it would be at least: > all, help, clean, edit_cache, rebuild_cache, test, package, > package_source, PACKAGE, ZERO_CHECK > > Would anyone be opposed to this? > Could I extend the existing policy, should I create a new one or would > it be ok without any policy even? The policy has not been released yet so I think it would be fine to extend it to cover this. Please include documentation and test cases. Also look through all generators to find all reserved target names. In addition to those you listed there is also at least ALL_BUILD. 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] Weird behaviour of arguments in macro
On 11/15/2013 03:27 AM, Daniele E. Domenichelli wrote: > So I believe that some more documentation would be helpful... If you > agree, I can write it... Fine with me! One reason we changed to the rst-formatted documentation is to make it easier to write and for contributors to modify. Please push it through the topic stage like any other change. 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] Invalid/Reserved target names
On 15.11.2013 17:24, Matthew Woehlke wrote: I haven't done so yet, but I've considered once or twice creating a 'clean' target in case the generator is ninja. Possibly someone has already done that. Maybe only disallow target names that the generator actually uses? (Or should we teach CMake to make a 'clean' target for ninja? :-) That could probably be done separately, but if 'clean' is disallowed unconditionally it feels like that should be "on the radar" of things to do.) I would prefer to forbid them regardless of generator. This would prevent someone using a target that happens to be free for his generator but inadvertently breaking something for someone else working on the same project with a different generator. Defining a custom "clean" target would also break if the Ninja generator did start defining a custom clean target ... which obviously can happen for any target name not currently used but is more likely with the currently "reserved" names. Projects that already use these names should still work if I make this dependant on the existing policy. Nils -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Invalid/Reserved target names
Am Freitag, 15. November 2013, 10:05:13 schrieb Nils Gladitz: > I would like to hijack/extend Stephen's changes in > 05f5fde0eb83c0e49aab3214f28a098861aa3313 > to also disallow target names that have been implicitly reserved by some > of the generators. > > This list might not be complete but I assume it would be at least: > all, help, clean, edit_cache, rebuild_cache, test, package, > package_source, PACKAGE, ZERO_CHECK Anything ending in "/fast"? Eike signature.asc Description: This is a digitally signed message part. -- 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] Invalid/Reserved target names
On 11/15/2013 03:19 PM, Rolf Eike Beer wrote: > Anything ending in "/fast"? The policy-introduced restrictions already disallow "/" in names. -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
