[cmake-developers] [CMake 0015476]: WiX packages not created with files that contain special characters.
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15476 == Reported By:Richard Ulrich Assigned To: == Project:CMake Issue ID: 15476 Category: CPack Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2015-03-26 05:30 EDT Last Modified: 2015-03-26 05:30 EDT == Summary:WiX packages not created with files that contain special characters. Description: After upgrading to cmake 3.2.1, WiX packages can no longer be created that contain files with special characters in their name. Steps to Reproduce: Use the attached minimal project, and try to generate a WiX installer. Additional Information: error LGHT0103 : The system cannot find the file '... garbled chars.txt' If I open files.wxs, instead of the special chars, it displays garbage characters. == Issue History Date ModifiedUsername FieldChange == 2015-03-26 05:30 Richard Ulrich New Issue 2015-03-26 05:30 Richard Ulrich File Added: wix_utf8.zip == -- 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] [CMake 0015477]: FindMFC.cmake warning due to POLICY CMP0054
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15477 == Reported By:j.kreuzberger Assigned To: == Project:CMake Issue ID: 15477 Category: Modules Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-03-26 06:11 EDT Last Modified: 2015-03-26 06:11 EDT == Summary:FindMFC.cmake warning due to POLICY CMP0054 Description: cmake_required_version is 3.0.0 during migration to 3.2.1 the POLICY CMP0054 gives a warning in FindMFC.cmake line 39 Question is if i set the policy to NEW, does this affect the FindMFC.cmake behaviour on FindMFC? Steps to Reproduce: cmake configure step Additional Information: Cannot clearly check the behaviour for FindMFC.cmake cause i am on a linux machine and currently have no environment with cmake 3.2, mfc installed and visual studio professional == Issue History Date ModifiedUsername FieldChange == 2015-03-26 06:11 j.kreuzberger New Issue == -- 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] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support
On 03/25/2015 11:39 AM, Brad King wrote: http://cmake.org/gitweb?p=cmake.git;a=commit;h=8f547be5 We can still add more fixup commits as needed for nightly testing. Please base further work, if any, on that commit for now. Two GHS tests still fail: https://open.cdash.org/viewTest.php?onlyfailedbuildid=3744753 with output like: Run Clean Command:gbuild -clean The system cannot find the file specified Generator: execution of make clean failed. The FindGhsBuildCommand method currently just searches the PATH for gbuild. Shouldn't it be able to locate gbuild through similar means to finding GHS_COMP_ROOT? Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015479]: Support depfiles from add_custom_command
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15479 == Reported By:Ben Boeckel Assigned To: == Project:CMake Issue ID: 15479 Category: CMake Reproducibility:have not tried Severity: feature Priority: normal Status: new == Date Submitted: 2015-03-26 16:05 EDT Last Modified: 2015-03-26 16:05 EDT == Summary:Support depfiles from add_custom_command Description: It would be nice to be able to have custom commands be able to generate their own depfiles for Make and Ninja. Probably a DEPFILE argument to `add_custom_command`. == Issue History Date ModifiedUsername FieldChange == 2015-03-26 16:05 Ben BoeckelNew Issue == -- 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] [CMake 0015478]: As of CMake 3.1 Properties cannot be set to
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15478
==
Reported By:Walter Gray
Assigned To:
==
Project:CMake
Issue ID: 15478
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2015-03-26 15:25 EDT
Last Modified: 2015-03-26 15:25 EDT
==
Summary:As of CMake 3.1 Properties cannot be set to
Description:
As of CMake 3.0.2, it was completely legal to set a target property to . This
was in fact a very helpful feature for me in some cases since it meant that if I
knew I'd set a property to a list (even an empty one), when I read it back later
and passed it into a foreach I didn't have to also use an if to check if it
existed. This functionality was broken in 3.1, and there is neither a policy
setting about it, nor any documentation I can find that indicates this was an
intended change.
Steps to Reproduce:
Run the following cmake script. In CMake = 3.0.2, prop1 will be an empty
string. In CMake = 3.1, it will be prop1-NOTFOUND
cmake_minimum_required(VERSION 3.0)
cmake_policy(VERSION 3.0.2)
project(cmaketestproject)
add_executable(testexe test.cpp)
set(emptylist )
set_target_properties(testexe PROPERTIES INTERFACE_PROP_1 ${emptylist}
INTERFACE_PROP_2 thing)
get_target_property(prop1 testexe INTERFACE_PROP_1)
get_target_property(prop2 testexe INTERFACE_PROP_2)
get_target_property(prop3 testexe INTERFACE_PROP_3)
message(prop1=${prop1})
message(prop2=${prop2})
message(prop3=${prop3})
==
Issue History
Date ModifiedUsername FieldChange
==
2015-03-26 15:25 Walter GrayNew Issue
==
--
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] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support
On 03/26/2015 01:50 PM, Geoffrey Viola wrote:
Do you have Green Hills MULTI installed? If so which version is installed?
No. The failures I'm linking are on /your/ nightly build. Remember
that does
set(ENV{PATH} c:\\Windows\\system32;c:\\Windows)
so nothing is in the path. The purpose of FindGhsBuildCommand is to
use any knowledge possible to find gbuild. The equivalent method
in the VS generators uses the registry to find msbuild for example.
Thanks,
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] UseSWIG warns about CMP0057
I have a library and use the UseSWIG-module to generate bindings for different
scripting languages from an interface file (ltt.i in the example below).
To get the bindings for more than one language, my CMakeLists.txt looks
somehow like
add_library(ltt sources)
include(UseSWIG)
foreach(_lang ruby python)
if(_lang STREQUAL ruby)
set(_modulename rltt)
else()
set(_modulename pltt)
endif()
swig_add_module(${_modulename} ${_lang} ltt.i)
swig_link_libraries(${_modulename} ltt)
endif()
Running this with cmake built from master (version 3.2.20150326-g5d1d99) now
gives
the warning about
Policy CMP0057 is not set: Disallow multiple MAIN_DEPENDENCY specifications
Is this a bug in UseSWIG or is my use case invalid?
If the latter, who can I workaround it?
The warning comes from UseSWIG in line 193; the interface file is added as
a MAIN_DEPENDENCY to the swig-generated wrapper file, and because of the loop,
it is added twice, to the lttPYTHON_warp.cxx and lttRUBY_warp.cxx,
the two swig-generated files.
Fixing this would be simple by adding the interface file as a normal dependency
to the wrapper-files, the only drawback is backward compatibility.
regards
Felix
--
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
