Re: [cmake-developers] CMakeParseArguments: Do not skip empty arguments
On 11/8/2013 4:19 PM, Alexander Neundorf wrote:
> On Friday 08 November 2013, Daniele E. Domenichelli wrote:
>> So it looks like that "set(FOO "" PARENT_SCOPE)" instead of setting an
>> empty FOO value, unsets it in the parent scope, and the behaviour is
>> definitely different from set for the current scope.
>
> How about adding one new policy "modify handling of empty variables" which is
> used by both ?
At most the policy should affect PARENT_SCOPE. One can see the
difference right in cmSetCommand, where parentScope was added:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fc8ce174#patch6
For parentScope it does
if (value.empty())
{
this->Makefile->RaiseScope(variable, 0);
}
else
{
this->Makefile->RaiseScope(variable, value.c_str());
}
while for normal scope it does just
this->Makefile->AddDefinition(variable, value.c_str());
-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] CMakeParseArguments: Do not skip empty arguments
On Friday 08 November 2013, Daniele E. Domenichelli wrote:
> Hello,
>
> I updated the CMakeParseArguments_EmptyArgs topic, the new behaviour is
> now decided as follows:
>
> * If CMAKE_MINIMUM_REQUIRED_VERSION < 2.8.13, the default behaviour is
> to skip empty arguments, otherwise the default behaviour is to keep
> them.
> * Using the CMAKE_PARSE_ARGUMENTS_DEFAULT_SKIP_EMPTY directory
> property the user can explicitly set the default behaviour for a
> folder and its subfolders.
> * Using CMAKE_PARSE_ARGUMENTS_(SKIP|KEEP)_EMPTY or as the first
> argument of the call after the mandatory ones, the user can specify
> whether to keep or to skip the empty arguments, regardless of the
> default behaviour for that cmake_parse_arguments() call.
>
> Therefore the new syntax is:
>
> cmake_parse_arguments(
>
>
>
>
> [CMAKE_PARSE_ARGUMENTS_(SKIP|KEEP)_EMPTY]
> args...
> )
>
> Does it look better now?
>
>
> Unfortunately there still a big problem, that is probably in the c++
> source code, because "set( "" PARENT_SCOPE)" still fails if
> is empty. This is a small example that shows the problem:
>
> ---
>
> function(_foo)
> set(FOO "" PARENT_SCOPE)
> endfunction()
>
> foo(FOO "foo")
> _foo()
> if(DEFINED FOO)
> message("FOO DEFINED")
> else()
> message("FOO NOT DEFINED")
> endif()
>
> set(BAR "")
> if(DEFINED BAR)
> message("BAR DEFINED")
> else()
> message("BAR NOT DEFINED")
> endif()
>
> ---
>
> The output of this is:
>
> FOO NOT DEFINED
> BAR DEFINED
>
> So it looks like that "set(FOO "" PARENT_SCOPE)" instead of setting an
> empty FOO value, unsets it in the parent scope, and the behaviour is
> definitely different from set for the current scope.
>
> This looks like a bug to me... How should I handle this?
the implementation in set() doesn't differentiate whether it was set to empty
or whether there was no value at all.
In most cases it doesn't matter much whether a variable is empty or not
defined, if it is dereferenced it gives an empty string in both cases, if()
also interprets both as false.
It's more or less only if(DEFINED) which detects the difference, right ?
How about adding one new policy "modify handling of empty variables" which is
used by both ?
Then you don't need the directory property and the extra argument.
Having two separate policies would be cleaner, but it seems a bit overkill to
me, since most probably both changes won't break many, if any, builds.
Alex
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] CMake 2.8.12.1 Released
Some serious problems were reported with the 2.8.12 release. Thanks to the swift work of Brad King, Stephen Kelly, Modestas Vainius and Vladislav Vinogradov, those problems have been fixed. We've prepared a 2.8.12.1 bug fix release to address those issues. Some of the notable changes in this patch release are: - The implementation of new CMake Policy CMP0022 was corrected to preserve default transitive linking by the target_link_libraries plain signature when the policy is set to NEW. As a result, CMake 2.8.12.1 may produce CMP0022 warnings that 2.8.12.0 did not. - The Makefile and Ninja generators, when using MSVC from Visual Studio 2013, now pass to "cl" the "/FS" option to support parallel builds. - FindCUDA learned of CUDA 5.5's divided NPP libraries The complete list of changes in 2.12.1 can be found at: http://www.cmake.org/Wiki/CMake/ChangeLog -- 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] CMakeParseArguments: Do not skip empty arguments
On 08/11/13 17:54, Daniele E. Domenichelli wrote: > foo(FOO "foo") Obviously it was supposed to be set(FOO "foo") Sorry... 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
Re: [cmake-developers] CMakeParseArguments: Do not skip empty arguments
Hello,
I updated the CMakeParseArguments_EmptyArgs topic, the new behaviour is
now decided as follows:
* If CMAKE_MINIMUM_REQUIRED_VERSION < 2.8.13, the default behaviour is
to skip empty arguments, otherwise the default behaviour is to keep
them.
* Using the CMAKE_PARSE_ARGUMENTS_DEFAULT_SKIP_EMPTY directory
property the user can explicitly set the default behaviour for a
folder and its subfolders.
* Using CMAKE_PARSE_ARGUMENTS_(SKIP|KEEP)_EMPTY or as the first
argument of the call after the mandatory ones, the user can specify
whether to keep or to skip the empty arguments, regardless of the
default behaviour for that cmake_parse_arguments() call.
Therefore the new syntax is:
cmake_parse_arguments(
[CMAKE_PARSE_ARGUMENTS_(SKIP|KEEP)_EMPTY]
args...
)
Does it look better now?
Unfortunately there still a big problem, that is probably in the c++
source code, because "set( "" PARENT_SCOPE)" still fails if
is empty. This is a small example that shows the problem:
---
function(_foo)
set(FOO "" PARENT_SCOPE)
endfunction()
foo(FOO "foo")
_foo()
if(DEFINED FOO)
message("FOO DEFINED")
else()
message("FOO NOT DEFINED")
endif()
set(BAR "")
if(DEFINED BAR)
message("BAR DEFINED")
else()
message("BAR NOT DEFINED")
endif()
---
The output of this is:
FOO NOT DEFINED
BAR DEFINED
So it looks like that "set(FOO "" PARENT_SCOPE)" instead of setting an
empty FOO value, unsets it in the parent scope, and the behaviour is
definitely different from set for the current scope.
This looks like a bug to me... How should I handle this?
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
Re: [cmake-developers] Ninja pools
On 11/05/2013 02:15 PM, Peter Kümmel wrote: > I merged a proposal to next which adds support for Ninja's "pool": > >http://martine.github.io/ninja/manual.html#ref_pool This will be a really nice feature to support. > It adds three new properties, POOLS, LINK_POOL, COMPILE_POOL: > >http://www.cmake.org/cmake/help/git-next/manual/cmake-properties.7.html > > With a "pool" it is possible to limit the number of concurrent > processes of a specific rule. Without context the name "POOL" may not have clear meaning to a reader not already familiar with Ninja's feature. I think a name like JOB_POOL would be clearer. The documentation of these properties all note that they are only for Ninja. While it is possible a future generator will also support them, it is unclear whether the semantics will be exactly the same. Therefore I prefer to use a NINJA_ prefix on the property names for now: NINJA_JOB_POOLS NINJA_JOB_POOL_LINK NINJA_JOB_POOL_COMPILE Also look at cmTarget::SetMakefile for calls to SetPropertyDefault to see how to add variables like CMAKE_NINJA_JOB_POOL_LINK CMAKE_NINJA_JOB_POOL_COMPILE that set a default for the target properties at their creation. This will make it easy for projects to put all targets into the pools. We should also consider a way to allow users to define pools with cache entries when the projects don't. > Current patch adds only the essentials, but maybe there are more > comfortable ways to use pools. The patch also appears to try adding a POOL option to the add_custom_command command but does not provide documentation except in the commit message. In the final version of this topic that goes to master, I'd prefer not to have any docs or examples in the commit messages, just in the actual docs. (Again, I think the option should be named NINJA_JOB_POOL.) Should we have a NINJA_JOB_POOL_CUSTOM property that is used for custom commands within a target that do not explicitly set a job pool? It would of course come with a supporting CMAKE_NINJA_JOB_POOL_CUSTOM variable to initialize the property. This would allow projects to quickly add all their build rules to pools with just a few lines of code. Also please add error messages when the NINJA_JOB_POOLS value does not match the expected format, or when one of the other rules names a pool not on the global list. The add_custom_command option processing: + case doing_pool: + pool = copy; + break; should switch back to doing = doing_nothing so that a second value after the keyword is rejected with an error message. (Some of the other keyword options should be doing this but can't now for compatibility.) The interface should be as strict as possible when first created. It can always be relaxed in the future, but would require a policy to make it more strict. Please add RunCMake test cases that cover these error messages. Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014553]: add_subdirectory fails when using Ninja generator
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14553
==
Reported By:Jan Rüegg
Assigned To:
==
Project:CMake
Issue ID: 14553
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2013-11-08 11:07 EST
Last Modified: 2013-11-08 11:07 EST
==
Summary:add_subdirectory fails when using Ninja generator
Description:
This is the setup:
./folder1/CMakeLists.txt:
cmake_minimum_required(VERSION 2.8)
set(LIBRARY_OUTPUT_PATH "${CMAKE_CURRENT_SOURCE_DIR}/libs/")
add_subdirectory(../folder2 ${CMAKE_CURRENT_BINARY_DIR}/folder2)
./folder2/CMakeLists.txt:
project(foo)
add_library(foo foo.cpp)
./folder2/foo.cpp:
int main() {}
Steps to Reproduce:
When I run cmake with the Unix Makefiles generator, everything works fine:
~/tmp/problem/folder1/build❯ cmake ..
-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
...
-- Configuring done
-- Generating done
-- Build files have been written to: /home/jan/tmp/problem/folder1/build
~/tmp/problem/folder1/build❯ make
Scanning dependencies of target foo
[100%] Building CXX object folder2/CMakeFiles/foo.dir/foo.cpp.o
Linking CXX static library /home/jan/tmp/problem/folder1/libs/libfoo.a
[100%] Built target foo
However, using the Ninja generator doesn't work:
~/tmp/problem/folder1/build❯ cmake -GNinja ..
-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
...
-- Configuring done
-- Generating done
-- Build files have been written to: /home/jan/tmp/problem/folder1/build
~/tmp/problem/folder1/build❯ ninja
ninja: error: '../libs/libfoo.a', needed by 'all', missing and no known rule to
make it
Additional Information:
~/tmp/problem/folder1/build❯ ninja --version
1.4.0
~/tmp/problem/folder1/build❯ cmake --version
cmake version 2.8.12
==
Issue History
Date ModifiedUsername FieldChange
==
2013-11-08 11:07 Jan Rüegg 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
[cmake-developers] Dashboard machine "carrock.dlrsoftware"
Hello, The dashboard machine "carrock.dlrsoftware" is being physically moved, crossing state lines in the process. It will not be submitting its usual Nightly dashboards again until Monday November 18, 2013. I anticipate it will resume its regular schedule at that point. Sorry for the inconvenience. D -- 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] Dashboard machine "mug.neocisinc"
Hello, The dashboard machine "mug.neocisinc" is being physically moved, crossing state lines in the process. It will not be submitting its usual Nightly dashboards again until Monday November 18, 2013. I anticipate it will resume its regular schedule at that point. Sorry for the inconvenience. D -- 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 0014552]: testCCompiler for WinCE ARMV4I and NMake generator fails with linker error
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14552 == Reported By:vzvezda Assigned To: == Project:CMake Issue ID: 14552 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2013-11-08 06:57 EST Last Modified: 2013-11-08 06:57 EST == Summary:testCCompiler for WinCE ARMV4I and NMake generator fails with linker error Description: The "NMake Makefiles" generation fails when building for Windows CE with ARMV4I as system processor. The error is like the conflict in linker options and selected libraries: coredll.lib(COREDLL.dll) : fatal error LNK1112: module machine type 'THUMB' conflicts with target machine type 'ARM' There is no such problem when building for CE x86. Steps to Reproduce: 1. Create a simple project 2. Start generation as described in: http://www.cmake.org/Wiki/CMake_Cross_Compiling#Cross_compilation_for_Windows_CE === Steps h:\temp\HelloWorld>set path=D:\sdk\cmake-2.8.12-win32-x86\bin;%path% h:\temp\HelloWorld>"%VS80COMNTOOLS%vsvars32.bat" Setting environment for using Microsoft Visual Studio 2005 x86 tools. h:\temp\HelloWorld>cmake -E env_vs8_wince "STANDARDSDK_500 (ARMV4I)" >env.bat h:\temp\HelloWorld>env.bat Environment Selection: STANDARDSDK_500 (ARMV4I) h:\temp\HelloWorld>cmake -G "NMake Makefiles" -DCMAKE_SYSTEM_NAME=WindowsCE -DCM AKE_SYSTEM_PROCESSOR=ARMV4I . Additional Information: The output -- The C compiler identification is MSVC 14.0.60131 -- The CXX compiler identification is MSVC 14.0.60131 -- Check for working C compiler: D:/sdk/vc8/ce/bin/x86_arm/cl.exe -- Check for working C compiler: D:/sdk/vc8/ce/bin/x86_arm/cl.exe -- broken CMake Error at D:/sdk/cmake-2.8.12-win32-x86/share/cmake-2.8/Modules/CMakeTestCC ompiler.cmake:61 (message): The C compiler "D:/sdk/vc8/ce/bin/x86_arm/cl.exe" is not able to compile a simple test program. It fails with the following output: Change Dir: H:/temp/HelloWorld/CMakeFiles/CMakeTmp Run Build Command:nmake /NOLOGO "cmTryCompileExec873074925\fast" D:\sdk\vc8\bin\nmake.exe -f CMakeFiles\cmTryCompileExec873074925.dir\build.make /nologo -L CMakeFiles\cmTryCompileExec873074925.dir\build D:\sdk\cmake-2.8.12-win32-x86\bin\cmake.exe -E cmake_progress_report H:\temp\HelloWorld\CMakeFiles\CMakeTmp\CMakeFiles 1 Building C object CMakeFiles/cmTryCompileExec873074925.dir/testCCompiler.c.obj D:\sdk\vc8\ce\bin\x86_arm\cl.exe /D_WIN32_WCE=0x500 /DUNDER_CE /DARM /D_ARM_ /D_WINDOWS /W3 /D_DEBUG /MDd /Zi /Ob0 /Od /FoCMakeFiles\cmTryCompileExec873074925.dir\testCCompiler.c.obj /FdCMakeFiles\cmTryCompileExec873074925.dir/ -c H:\temp\HelloWorld\CMakeFiles\CMakeTmp\testCCompiler.c Microsoft (R) C/C++ Optimizing Compiler Version 14.00.60131 for ARM Copyright (C) Microsoft Corporation. All rights reserved. testCCompiler.c Linking C executable cmTryCompileExec873074925.exe D:\sdk\cmake-2.8.12-win32-x86\bin\cmake.exe -E vs_link_exe D:\sdk\vc8\ce\bin\x86_arm\link.exe @CMakeFiles\cmTryCompileExec873074925.dir\objects1.rsp /out:cmTryCompileExec873074925.exe /implib:cmTryCompileExec873074925.lib /pdb:H:\temp\HelloWorld\CMakeFiles\CMakeTmp\cmTryCompileExec873074925.pdb /version:0.0 /NODEFAULTLIB:libc.lib /NODEFAULTLIB:oldnames.lib /machine:ARM /debug /INCREMENTAL:YES /subsystem:windowsce /entry:mainACRTStartup coredll.lib ole32.lib oleaut32.lib uuid.lib commctrl.lib corelibc.lib Microsoft (R) Incremental Linker Version 8.00.50727.762 Copyright (C) Microsoft Corporation. All rights reserved. CMakeFiles/cmTryCompileExec873074925.dir/testCCompiler.c.obj coredll.lib(COREDLL.dll) : fatal error LNK1112: module machine type 'THUMB' conflicts with target machine type 'ARM' LINK Pass 1 failed. with 1112 NMAKE : fatal error U1077: 'D:\sdk\cmake-2.8.12-win32-x86\bin\cmake.exe' : return code '0x' Stop. NMAKE : fatal error U1077: 'D:\sdk\vc8\bin\nmake.exe' : return code '0x2' == Issue History Date ModifiedUsername FieldChange == 2013-11-08 06:57 vzvezdaNew Issue 2013-11-08 06:57 vzvezdaFile Added: HelloWorldAndOutput.zip ==
