Re: [cmake-developers] [PATCH 3/6] Resolve replace @rpath placeholders
After that change is dropped, I give a +1 for the patch set. Done, both in attached 3/5 patch and GitHub branch of mine. --Adam -- 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] [PATCH 3/5] Resolve replace @rpath placeholders
This is done by gathering LC_RPATH commands for main bundle executable and
using it for @rpath lookup in dependent frameworks.
All functions that need to carry rpaths to now take optional rpaths argument.
This enabled apps using @rpath to be bundled correctly, which will be necessary
for upcoming Qt 5.4 that will use @rpath for all frameworks.
---
Modules/BundleUtilities.cmake | 93 ++
Modules/GetPrerequisites.cmake | 23 +++
2 files changed, 90 insertions(+), 26 deletions(-)
diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake
index 7e2b173..cc27310 100644
--- a/Modules/BundleUtilities.cmake
+++ b/Modules/BundleUtilities.cmake
@@ -19,6 +19,7 @@
#get_bundle_and_executable
#get_bundle_all_executables
#get_item_key
+#get_item_rpaths
#clear_bundle_keys
#set_bundle_key_values
#get_bundle_keys
@@ -124,7 +125,7 @@
# ::
#
# SET_BUNDLE_KEY_VALUES(keys_var context item exepath dirs
-# copyflag)
+# copyflag [rpaths])
#
# Add a key to the list (if necessary) for the given item. If added,
# also set all the variables associated with that key.
@@ -407,6 +408,29 @@ function(get_bundle_all_executables bundle exes_var)
endfunction()
+function(get_item_rpaths item rpaths_var)
+ if(APPLE)
+find_program(otool_cmd otool)
+mark_as_advanced(otool_cmd)
+ endif()
+
+ if(otool_cmd)
+execute_process(
+ COMMAND ${otool_cmd} -l ${item}
+ OUTPUT_VARIABLE load_cmds_ov
+ )
+string(REGEX REPLACE [^\n]+cmd LC_RPATH\n[^\n]+\n[^\n]+path ([^\n]+)
\\(offset[^\n]+\n rpath \\1\n load_cmds_ov ${load_cmds_ov})
+string(REGEX MATCHALL rpath [^\n]+ load_cmds_ov ${load_cmds_ov})
+string(REGEX REPLACE rpath load_cmds_ov ${load_cmds_ov})
+if(load_cmds_ov)
+ gp_append_unique(${rpaths_var} ${load_cmds_ov})
+endif()
+ endif()
+
+ set(${rpaths_var} ${${rpaths_var}} PARENT_SCOPE)
+endfunction()
+
+
function(get_item_key item key_var)
get_filename_component(item_name ${item} NAME)
if(WIN32)
@@ -425,12 +449,14 @@ function(clear_bundle_keys keys_var)
set(${key}_EMBEDDED_ITEM PARENT_SCOPE)
set(${key}_RESOLVED_EMBEDDED_ITEM PARENT_SCOPE)
set(${key}_COPYFLAG PARENT_SCOPE)
+set(${key}_RPATHS PARENT_SCOPE)
endforeach()
set(${keys_var} PARENT_SCOPE)
endfunction()
function(set_bundle_key_values keys_var context item exepath dirs copyflag)
+ set(rpaths ${ARGV6})
get_filename_component(item_name ${item} NAME)
get_item_key(${item} key)
@@ -440,10 +466,12 @@ function(set_bundle_key_values keys_var context item
exepath dirs copyflag)
list(LENGTH ${keys_var} length_after)
if(NOT length_before EQUAL length_after)
-gp_resolve_item(${context} ${item} ${exepath} ${dirs}
resolved_item)
+gp_resolve_item(${context} ${item} ${exepath} ${dirs}
resolved_item ${rpaths})
gp_item_default_embedded_path(${item} default_embedded_path)
+get_item_rpaths(${resolved_item} item_rpaths)
+
if(item MATCHES [^/]+\\.framework/)
# For frameworks, construct the name under the embedded path from the
# opening ${item_name}.framework/ to the closing /${item_name}:
@@ -479,6 +507,8 @@ function(set_bundle_key_values keys_var context item
exepath dirs copyflag)
set(${key}_EMBEDDED_ITEM ${embedded_item} PARENT_SCOPE)
set(${key}_RESOLVED_EMBEDDED_ITEM ${resolved_embedded_item} PARENT_SCOPE)
set(${key}_COPYFLAG ${copyflag} PARENT_SCOPE)
+set(${key}_RPATHS ${item_rpaths} PARENT_SCOPE)
+set(${key}_RDEP_RPATHS ${rpaths} PARENT_SCOPE)
else()
#message(warning: item key '${key}' already in the list, subsequent
references assumed identical to first)
endif()
@@ -499,18 +529,27 @@ function(get_bundle_keys app libs dirs keys_var)
#
get_bundle_all_executables(${bundle} exes)
+# Set keys for main executable first:
+#
+set_bundle_key_values(${keys_var} ${executable} ${executable}
${exepath} ${dirs} 0)
+
+# Get rpaths specified by main executable:
+#
+get_item_key(${executable} executable_key)
+set(main_rpaths ${${executable_key}_RPATHS})
+
# For each extra lib, accumulate a key as well and then also accumulate
# any of its prerequisites. (Extra libs are typically dynamically loaded
# plugins: libraries that are prerequisites for full runtime functionality
# but that do not show up in otool -L output...)
#
foreach(lib ${libs})
- set_bundle_key_values(${keys_var} ${lib} ${lib} ${exepath}
${dirs} 0)
+ set_bundle_key_values(${keys_var} ${lib} ${lib} ${exepath}
${dirs} 0 ${main_rpaths})
set(prereqs )
- get_prerequisites(${lib} prereqs 1 1 ${exepath} ${dirs})
+ get_prerequisites(${lib} prereqs 1 1 ${exepath} ${dirs}
${main_rpaths})
foreach(pr ${prereqs})
-set_bundle_key_values(${keys_var} ${lib} ${pr} ${exepath}
${dirs} 1)
+
Re: [cmake-developers] Suggest to not add libosgUI-NOTFOUND to OSG_INCLUDE_DIR if it wasn't required
On 09/17/2014 02:42 AM, Mattias Helsing wrote: If I'm not requiring osgUI it shouldn't break my build. Applied, thanks: FindOpenSceneGraph: Do not add unfound OSG libs if not required http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b683da3e -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
Re: [cmake-developers] policies in CMake builtin modules (was: FindCUDA: Wrap keyword in if() string comparison)
On 09/17/2014 02:25 PM, Nils Gladitz wrote: I pushed root-modules-set-policies-new to stage which sets all policies to NEW for modules from cmake's own Modules directory if NO_POLICY_SCOPE is not used. A minor comment on the impl: use cmSystemTools::GetCMakeRoot instead of looking up CMAKE_ROOT. However, I do not think this approach will work well in general. We do not have extensive testing covering all functionality of the builtin modules. We do not actually know that all the modules will work with every policy set to NEW right away. Typically authors of projects that use the modules will report bugs if things break when the projects set policies to NEW. Meanwhile at least existing projects keep building with the OLD policy behavior. Modules on an individual basis could use cmake_policy(PUSH/POP) and cmake_policy(SET) to get NEW behavior for specific policies that they trigger. -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
Re: [cmake-developers] policies in CMake builtin modules
On 09/18/2014 04:05 PM, Brad King wrote: On 09/17/2014 02:25 PM, Nils Gladitz wrote: I pushed root-modules-set-policies-new to stage which sets all policies to NEW for modules from cmake's own Modules directory if NO_POLICY_SCOPE is not used. A minor comment on the impl: use cmSystemTools::GetCMakeRoot instead of looking up CMAKE_ROOT. Thanks, I'll try to remember that for next time. I copied the use of CMAKE_ROOT from cmMakefile::GetModulesFile(). However, I do not think this approach will work well in general. We do not have extensive testing covering all functionality of the builtin modules. We do not actually know that all the modules will work with every policy set to NEW right away. Typically authors of projects that use the modules will report bugs if things break when the projects set policies to NEW. Meanwhile at least existing projects keep building with the OLD policy behavior. OK, thanks. I unstaged the topic. Nils -- 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 0015163]: wrong permissions on base files with nonstandard umask setting
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15163 == Reported By:Ilya Rusyanov Assigned To: == Project:CMake Issue ID: 15163 Category: (No Category) Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2014-09-18 11:44 EDT Last Modified: 2014-09-18 11:44 EDT == Summary:wrong permissions on base files with nonstandard umask setting Description: If umask is different from 022, CPack will generate wrong permission on base directories. Steps to Reproduce: umask 027 cmake ../src make cpack -G DEB dpkg -c test.deb drwxr-x--- root/root 0 2014-09-18 19:40 ./usr/ drwxr-x--- root/root 0 2014-09-18 19:40 ./usr/share/ drwxr-x--- root/root 0 2014-09-18 19:40 ./usr/share/testproj/ drwxr-x--- root/root 0 2014-09-18 19:40 ./usr/share/testproj/data/ drwxr-xr-x root/root 0 2014-09-18 19:40 ./usr/share/testproj/data/180-188-189/ -rw-r--r-- root/root16 2014-09-18 15:22 ./usr/share/testproj/data/180-188-189/general.ini Additional Information: Please notice directory permissions on /usr, /usr/share, /usr/share/testproj, /usr/share/testproj/data. Everything is fine with supplied inner directories and files. INSTALL command is not given any PERMISSIONS options, and, as documentation says they should be default: 755 for directories and 644 for regular files. == Issue History Date ModifiedUsername FieldChange == 2014-09-18 11:44 Ilya Rusyanov 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
[cmake-developers] [PATCH] WINCE: Add toolchain documentation for Windows CE
--- Help/manual/cmake-toolchains.7.rst | 20 1 file changed, 20 insertions(+) diff --git a/Help/manual/cmake-toolchains.7.rst b/Help/manual/cmake-toolchains.7.rst index f36a43c..095a43f 100644 --- a/Help/manual/cmake-toolchains.7.rst +++ b/Help/manual/cmake-toolchains.7.rst @@ -174,5 +174,25 @@ toolchain which will be used by the compiler driver. The :variable:`CMAKE_LANG_COMPILER_EXTERNAL_TOOLCHAIN` variable can be set in a toolchain file to pass the path to the compiler driver. +Cross compiling for Windows CE requires the corresponding SDK being installed on +your system. These SDKs are usually installed under: `C:\\Program Files (x86)\\Windows CE Tools\\SDKs` + +The :variable:`CMAKE_GENERATOR_PLATFORM` tells the generator which SDK to use. +Further :variable:`CMAKE_SYSTEM_VERSION` tells the generator what version of Windows CE to use. +Currently version 8.0 (Windows Embedded Compact 2013) is supported out of the box. Other versions +my require to set :variable:`CMAKE_GENERATOR_TOOLSET` to the correct value. + +A toolchain file for Windows CE may look like this: + +.. code-block:: cmake + + set(CMAKE_SYSTEM_NAME WindowsCE) + + set(CMAKE_SYSTEM_VERSION 8.0) + set(CMAKE_SYSTEM_PROCESSOR arm ) + + set(CMAKE_GENERATOR_TOOLSET CE800) # Can be omitted for 8.0 + set(CMAKE_GENERATOR_PLATFORM SDK_AM335X_SK_WEC2013_V310) + The :variable:`CMAKE_CROSSCOMPILING` variable is set to true when CMake is cross-compiling. -- 1.7.10.4 -- 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] [PATCH 3/6] Resolve replace @rpath placeholders
FYI I pushed stage/fix-OSX-bundle-rpaths-and-Qt5 topic for final review. Regards, -- Adam -- 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] policies in CMake builtin modules
If I understand correctly all modules included via include/find_package have
implicit POLICY PUSH and POP at the EOF. Wouldn't it be reasonable to require
all internal .cmake files to begin with:
cmake_policy(VERSION 3.1) # or whatever version the module was tested
against
Then before next release all of these should be checked against new policies
and upgraded to:
cmake_policy(VERSION 3.2) # next release version
Then we can safely drop all these fancy if(x${var} STREQUAL xVALUE) in
favor of if(var STREQUAL VALUE) and improve scripts readability, rather that
do PUSHes and POPs in various places. Of course I am aware that such task needs
lot of work, however I think this should be consequence of introducing CMP0054.
--Adam
--
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] [PATCH 3/6] Resolve replace @rpath placeholders
On Thursday, September 18, 2014 06:15:51 PM Adam Strzelecki wrote: FYI I pushed stage/fix-OSX-bundle-rpaths-and-Qt5 topic for final review. Regards, Does the functionality you add allow us to modify CMake/Tests/BundleUtilities/CMakeLists.txt such that the last part in the tests where @rpath is used can be changed to separate the binaries into bin/ and lib/ directories instead of everything in one directory. I assume so since you added the the ability to extract rpaths from a binary. Then eventually, someone can add the same capability for Linux. I'm hoping the parameter you added to functions in GetPrerequisite.cmake is not OS X specific (at the moment, it appears so). Thanks, - Clint -- 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] policies in CMake builtin modules
On 09/18/2014 01:00 PM, Adam Strzelecki wrote:
If I understand correctly all modules included via
include/find_package have implicit POLICY PUSH and POP
Yes.
at the EOF. Wouldn't it be reasonable to require all
internal .cmake files to begin with:
cmake_policy(VERSION 3.1) # or whatever version the module was tested
against
Then before next release all of these should be checked
against new policies and upgraded to:
cmake_policy(VERSION 3.2) # next release version
Like Nils' proposal, this will not be reliable without full coverage
of module functionality in the test suite (which is very hard to do
because every find module depends on another external package). It
could be done manually on a per-module basis.
Then we can safely drop all these fancy
if(x${var} STREQUAL xVALUE) in favor of if(var STREQUAL VALUE)
This can be done with just
cmake_policy(SET CMP0054 NEW)
at the top of any module that has been ported accordingly.
Most policies do not affect CMake syntax, but several have come
before this one and there are very few modules that make any
explicit mention of cmake_policy. In most cases the module
code can be written to work with any policy settings.
On 09/17/2014 08:37 AM, Rolf Eike Beer wrote:
Wait, what? This is actually the opposite of what that policy is for,
This is true, but will only affect modules that come with CMake
that must work regardless of the cmake_minimum_required(VERSION)
used in the project. Once a release of CMake contains this policy,
project code can require that version of CMake when it is ready
and then use the nicer if() tests.
-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
Re: [cmake-developers] [PATCH] WINCE: Add toolchain documentation for Windows CE
On 09/18/2014 12:03 PM, Pascal Bach wrote: diff --git a/Help/manual/cmake-toolchains.7.rst b/Help/manual/cmake-toolchains.7.rst index f36a43c..095a43f 100644 --- a/Help/manual/cmake-toolchains.7.rst +++ b/Help/manual/cmake-toolchains.7.rst @@ -174,5 +174,25 @@ toolchain which will be used by the compiler driver. The :variable:`CMAKE_LANG_COMPILER_EXTERNAL_TOOLCHAIN` variable can be set in a toolchain file to pass the path to the compiler driver. +Cross compiling for Windows CE requires the corresponding SDK being installed on +your system. These SDKs are usually installed under: `C:\\Program Files (x86)\\Windows CE Tools\\SDKs` Over time the Cross Compiling section of this manual will gain information about various target platforms. We should add a subsection header for each platform, e.g. Cross Compiling to Windows CE - If you don't mind, please precede this patch with a change that adds such subsection headers for the Clang and QCC cases. 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
Re: [cmake-developers] Extracting target metadata, IDE integration
On Mon, Sep 8, 2014 at 2:51 PM, Brad King brad.k...@kitware.com wrote: On 09/03/2014 12:12 PM, Aleix Pol wrote: On Wed, Sep 3, 2014 at 5:48 PM, Alexander Neundorf wrote: I still don't understand why this shouldn't be an additional ExtraGenerator. Because it's not possible to change the generator of a build directory once it's set up. You need to nuke it and re-create it. [snip] On 09/01/2014 07:27 PM, Aleix Pol wrote: Ok, how does it sound if we have a variable, such as CMAKE_EXPORT_COMPILE_COMMANDS? Let's say, CMAKE_EXPORT_TARGETS_INFORMATION. A control variable like that sounds good to me. The purpose looks very similar to CMAKE_EXPORT_COMPILE_COMMANDS, but is distinct enough to have its own control. 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 I added a CMAKE_OUTPUT_PROJECT_TARGETS variable that can be used to enable the generation of the file. I also renamed the file to ProjectTargets.json. http://www.proli.net/meu/kdevelop/cmake-targetsdata.patch Does it look better like this? Aleix -- 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 0015164]: Relative Value for CMAKE_TOOLCHAIN_FILE Does Not Work Under PowerShell
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15164 == Reported By:Janne Rönkkö Assigned To: == Project:CMake Issue ID: 15164 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2014-09-19 01:10 EDT Last Modified: 2014-09-19 01:10 EDT == Summary:Relative Value for CMAKE_TOOLCHAIN_FILE Does Not Work Under PowerShell Description: The toolchain file is not handled properly under PowerShell if the toolchain file path is relative. The issues (I have noticed so far): - CMAKE_SYSTEM_NAME is not set properly - There is warnings about include with empty file name (this seems to be the reason that at least CMAKE_SYSTEM_NAME is not set correctly) The issue is present at least in versions 3.0.0-3.0.2 (these are the version I tested). Steps to Reproduce: In PowerShell: unzip project.zip cd project mkdir build cmake -DCMAKE_TOOLCHAIN_FILE=../../toolchain.cmake -G Ninja .. Additional Information: On PowerShell with relative path: = PS C:\Users\janne\project\build cmake -DCMAKE_TOOLCHAIN_FILE=../../toolchain.cmake -G Ninja .. CMake Warning (dev) at build/CMakeFiles/3.0.2/CMakeSystem.cmake:6 (include): include() given empty file name (ignored). Call Stack (most recent call first): CMakeLists.txt:3 (project) This warning is for project developers. Use -Wno-dev to suppress it. -- The C compiler identification is GNU 4.7.3 -- The CXX compiler identification is GNU 4.7.3 -- Check for working C compiler using: Ninja CMake Warning (dev) at C:/Users/janne/project/build/CMakeFiles/3.0.2/CMakeSystem.cmake:6 (include): include() given empty file name (ignored). Call Stack (most recent call first): CMakeLists.txt:2 (project) This warning is for project developers. Use -Wno-dev to suppress it. -- Check for working C compiler using: Ninja -- works -- Detecting C compiler ABI info CMake Warning (dev) at C:/Users/janne/project/build/CMakeFiles/3.0.2/CMakeSystem.cmake:6 (include): include() given empty file name (ignored). Call Stack (most recent call first): CMakeLists.txt:2 (project) This warning is for project developers. Use -Wno-dev to suppress it. -- Detecting C compiler ABI info - done -- Check for working CXX compiler using: Ninja CMake Warning (dev) at C:/Users/janne/project/build/CMakeFiles/3.0.2/CMakeSystem.cmake:6 (include): include() given empty file name (ignored). Call Stack (most recent call first): CMakeLists.txt:2 (project) This warning is for project developers. Use -Wno-dev to suppress it. -- Check for working CXX compiler using: Ninja -- works -- Detecting CXX compiler ABI info CMake Warning (dev) at C:/Users/janne/project/build/CMakeFiles/3.0.2/CMakeSystem.cmake:6 (include): include() given empty file name (ignored). Call Stack (most recent call first): CMakeLists.txt:2 (project) This warning is for project developers. Use -Wno-dev to suppress it. -- Detecting CXX compiler ABI info - done CMake system name: Windows -- Configuring done -- Generating done -- Build files have been written to: C:/Users/janne/project/build ## Note the line CMake system name: Windows On PowerShell with absolute path: = PS C:\Users\janne\project\build cmake -DCMAKE_TOOLCHAIN_FILE=C:/users/janne/toolchain.cmake -G Ninja .. -- The C compiler identification is GNU 4.7.3 -- The CXX compiler identification is GNU 4.7.3 -- 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 -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done CMake system name: Linux -- Configuring done -- Generating done -- Build files have been written to: C:/Users/janne/project/build On cmd.exe with relative path: == C:\Users\janne\project\buildcmake -DCMAKE_TOOLCHAIN_FILE=../../toolchain.cmake -G Ninja .. -- The C compiler identification is GNU 4.7.3 -- The CXX compiler identification is GNU 4.7.3 -- 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 -- works --
Re: [cmake-developers] [PATCH] FindCUDA: Wrap keyword in if() string comparison
Could someone please explain to me why we need to change all the if
statements to look super ugly?
Expanding WIN32 to dereference the value is just a recipe for confusion.
Honestly I would prefer if there was a policy to never deference variables
in if statements and replace the if's with:
if (${arg} STREQAL WIN32)
This way there isn't any trickery involved with whether WIN32 is string
or a variable.
By the way creating a variable that has the same string as arguments to
command (see add_executable) is an unfortunate dirtying of the language
(WIN32 is a variable here, but over here it's an argument e.g. string).
James
On Wed, Sep 17, 2014 at 5:54 AM, Adam Strzelecki o...@java.pl wrote:
This silents possible CMP0054 related warnings.
---
Modules/FindCUDA.cmake | 14 +++---
Modules/FindCUDA/run_nvcc.cmake | 2 +-
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/Modules/FindCUDA.cmake b/Modules/FindCUDA.cmake
index 9348aa5..2e2b21c 100644
--- a/Modules/FindCUDA.cmake
+++ b/Modules/FindCUDA.cmake
@@ -894,15 +894,15 @@ macro(CUDA_GET_SOURCES_AND_OPTIONS _sources
_cmake_options _options)
set( ${_options} )
set( _found_options FALSE )
foreach(arg ${ARGN})
-if(arg STREQUAL OPTIONS)
+if(x${arg} STREQUAL xOPTIONS)
set( _found_options TRUE )
elseif(
-arg STREQUAL WIN32 OR
-arg STREQUAL MACOSX_BUNDLE OR
-arg STREQUAL EXCLUDE_FROM_ALL OR
-arg STREQUAL STATIC OR
-arg STREQUAL SHARED OR
-arg STREQUAL MODULE
+x${arg} STREQUAL xWIN32 OR
+x${arg} STREQUAL xMACOSX_BUNDLE OR
+x${arg} STREQUAL xEXCLUDE_FROM_ALL OR
+x${arg} STREQUAL xSTATIC OR
+x${arg} STREQUAL xSHARED OR
+x${arg} STREQUAL xMODULE
)
list(APPEND ${_cmake_options} ${arg})
else()
diff --git a/Modules/FindCUDA/run_nvcc.cmake
b/Modules/FindCUDA/run_nvcc.cmake
index 58e0d31..abdd307 100644
--- a/Modules/FindCUDA/run_nvcc.cmake
+++ b/Modules/FindCUDA/run_nvcc.cmake
@@ -126,7 +126,7 @@ endif()
# and other return variables are present after executing the process.
macro(cuda_execute_process status command)
set(_command ${command})
- if(NOT _command STREQUAL COMMAND)
+ if(NOT x${_command} STREQUAL xCOMMAND)
message(FATAL_ERROR Malformed call to cuda_execute_process. Missing
COMMAND as second argument. (command = ${command}))
endif()
if(verbose)
--
1.9.3 (Apple Git-50)
--
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
--
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
