[cmake-developers] [CMake 0013450]: FindCuda: nvcc chockes on -std=c++11
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13450
==
Reported By:Jan Rüegg
Assigned To:
==
Project:CMake
Issue ID: 13450
Category: Modules
Reproducibility:always
Severity: minor
Priority: high
Status: new
==
Date Submitted: 2012-08-02 09:47 EDT
Last Modified: 2012-08-02 09:47 EDT
==
Summary:FindCuda: nvcc chockes on -std=c++11
Description:
When adding a library with
CUDA_ADD_LIBRARY
and CUDA_PROPAGATE_HOST_FLAGS is set (as is the default) and -std=c++11 then
making the project crashes since nvcc cannot handle it. Errors like this appear:
Building NVCC (Device) object
AVTLibraries/FutureVideoLibs/CudaPack/CMakeFiles/CudaPack.dir/src/./CudaPack_generated_convolutionSeparable_kernel.cu.o
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/x86_64-unknown-linux-gnu/bits/c++config.h(177):
error: identifier nullptr is undefined
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/x86_64-unknown-linux-gnu/bits/c++config.h(177):
error: expected a ;
Additional Information:
Checking if -std=c++11 is enabled and removing it from the flags forwarded to
nvcc should solve the problem. (Something like this:
if(CMAKE_COMPILER_IS_GNUCC)
string(REPLACE -std=c++11 CUDA_HOST_FLAGS ${CUDA_HOST_FLAGS})
string(REPLACE -std=c++0x CUDA_HOST_FLAGS ${CUDA_HOST_FLAGS})
endif()
in CUDA_WRAP_SRC)
==
Issue History
Date ModifiedUsername FieldChange
==
2012-08-02 09:47 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] [CMake 0013451]: RPMs created with CPackRPM.cmake should not include non-empty directories in their contents-list
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13451
==
Reported By:Andy Piper
Assigned To:
==
Project:CMake
Issue ID: 13451
Category: Modules
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2012-08-02 12:03 EDT
Last Modified: 2012-08-02 12:03 EDT
==
Summary:RPMs created with CPackRPM.cmake should not include
non-empty directories in their contents-list
Description:
I am building RPM packages using the CPackRPM.cmake module. The RPMs have a
default install prefix of /opt/mycompany and have been made relocatable like
so:
set(CPACK_PACKAGING_INSTALL_PREFIX /opt/mycompany)
set(CPACK_PACKAGE_RELOCATABLE TRUE)
The RPMs are relocatable because they are being installed into custom locations
(using the --prefix option) by non-root users who have private RPM databases
(see section 4 of http://www.nordugrid.org/documents/rpm_for_everybody.html).
This setup will allow us to install different versions of our components for
development and maintenance work on a single machine, as required.
When attempting to install our RPMs to custom locations as a non-root user using
a command like this:
rpm -ivh --prefix=/home/andy/workspace/myproject/contrib \
--dbpath=/home/andy/workspace/myproject/contrib/rpmdb \
mypackage-1.0.rpm
...the following error was reported:
error: unpacking of archive failed on file /opt: cpio: chmod failed -
Operation not permitted
But I wasn't installing the RPM to /opt! So I looked at the content-list of the
RPM created using CPackRPM.cmake (using less rpm-package), and saw that it
began with:
/opt
/opt/mycompany
/opt/mycompany/lib64
/opt/mycompany/lib64/libcomponent_one.so
...etc...
(FYI, The path /opt/mycompany will be replaced by the --prefix option in the
rpm command above)
I then looked at at the content-list of another relocatable RPM with the same
default install prefix, but this package had been created by hand using the
rpmbuild command and a normal .spec file. The content-list in this RPM began
with:
/opt/mycompany/lib64/libcomponent_two.so
...etc...
There were no entries to explicitly create non-empty directories, and this RPM
*could* be installed to non-default locations by non-root users (with their
fancy private RPM databases). This told me that the entries to create non-empty
directories should not be present in the content-list: the RPM package-manager
will handle these directories for you.
This led me towards the EXECUTE_PROCESS(COMMAND find . -type f ...) call in
CPackRPM.cmake which populates the content-list for the RPM being built. This
command was searching from the build root directory (.) and was including
non-empty directories in its output. After changing the search to start at the
install-prefix directory (./${CPACK_PACKAGING_INSTALL_PREFIX}) and ignoring
non-empty directories, the RPM-installation issue was resolved.
So the fix is to change the find command from this:
find . -type f -o -type l -o (-type d -a -not -name .)
to this:
find ./${CPACK_PACKAGING_INSTALL_PREFIX} -type f -o -type l -o (-type d -a
-not -name . -a -empty)
I have attached a patch with this fix.
Steps to Reproduce:
Build any RPM using CPackRPM.cmake and examine the file-list using less
rpm-package. The content-list will begin with a series of one or more
non-empty directories, when it should begin with the first file (or
intentionally empty directory)
Additional Information:
Fix has been tested on SLES 11.2 and OpenSUSE 12.1
==
Issue History
Date ModifiedUsername FieldChange
==
2012-08-02 12:03 Andy Piper New Issue
2012-08-02 12:03 Andy Piper File Added: CPackRPM.cmake.patch
==
--
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] lua bindings?
I'm quite curious about the possibility of writing a lua binding for cmake. There are two possible ways to go: 1) Create a set of discrete lua bindings which actually invoke cmake itself. 2) Integrate lua into cmake itself. Before I go and do anything, has any effort been made to do either of these? From the lua mailing list I get the impression that some discussion of (2) has been done before, and broadly speaking, no one is really interested in re-writing cmake to support lua scripts as first class citizens. However, (1) interests me, because it'd be reasonably trivial to implement a lua binding of commands like: cmake:execute_process cmake:add_library cmake:target_link_library That cached the requests internally and actually generated a cmakelists.txt from it. There are some difficulties with this approach, for example, some actions require an immediate response that can't be cached; eg. file(GLOB) - filtering that list to invoke add_library()... but I think it wouldn't be impossible to generate temporary 'working' cmake files and invoke cmake on them directly, read the response and pipe it back into the lua script. This would be effectively a zero-impact wrapper around cmake, and make supporting more complex programming constructs (poor support for closures, hashes and lists specifically being my pet dislike with the cmake language). So, like I said, before I start down the road of messing around with this, has anyone got any thoughts about it, past experience and suggestions? Cheers, Doug. -- 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 0013452]: Invalid path generated to .o files in an object library with Xcode Generator
The following issue has been SUBMITTED. == http://cmake.org/Bug/view.php?id=13452 == Reported By:Grant Limberg Assigned To: == Project:CMake Issue ID: 13452 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-08-03 00:25 EDT Last Modified: 2012-08-03 00:25 EDT == Summary:Invalid path generated to .o files in an object library with Xcode Generator Description: When linking an executable to a library built using the new object library format for add_library(), the path to the .o files is invalid when linking the final executable. I've attached a sample project: CMakeLists.txt - project(CMAKE-BUG) | | - liba/CMakeLists.txt - project(A) | | - exec1/CMakeLists.txt - project(exec1) | | - exec2/CMakeLists.txt - project(exec2) When Xcode goes to link the .o file from liba, the path given to the linker is: /Users/grant/Development/CMakeBug/build/liba/exec2.build/Debug/A.build/Objects-normal/x86_64/a.o' However, the actual path to the .o file is: clang: error: no such file or directory: '/Users/grant/Development/CMakeBug/build/liba/CMAKE-BUG.build/Debug/A.build/Objects-normal/x86_64/a.o' Somehow the folder that should be named CMAKE-BUG.build, after the top level project name, is being replaced with the name of the last executable project name that was loaded. In this case, exec2.build. Steps to Reproduce: See attached minimal sample. Build on OS X with arguments -G Xcode == Issue History Date ModifiedUsername FieldChange == 2012-08-03 00:25 Grant Limberg 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
