After a little more looking around in the bug tracker I see there is already an
open issue for this. http://www.cmake.org/Bug/view.php?id=14782
Removing the PROTECTED_AT change to CPackRPM.cmake provides a work around for
now.
Thanks
Matt
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf
If you leave off a doublequote somewhere, you will get confusing messages like
"CMake Warning (dev) in CMakeLists.txt:
Syntax Warning in cmake code at
/home/joe/foo/CMakeLists.txt:66:79
Argument not separated from preceding token by whitespace.
This warning is for project developers. Us
>
> The next major release will likely be CMake 3.1 -- and the fix you've
> found will be in that release automatically, as it will be based on
> 'master' when it is created.
>
>
Related, it should also include support for extended length paths at the
cmake level. This converts paths to the specia
No need to add a bug for this... it's fixed already in 'master' -- that
means it will automatically appear in the next major release of CMake.
The current release is 3.0.1, and any critical bug fixes going into
CMake for a patch release will appear in 3.0.2, 3.0.3, and so on. (This
particular
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm a little bit annoyed by the following lines in CPack.cmake (2.8.12):
macro(cpack_check_file_exists file description)
if(NOT EXISTS "${file}")
message(SEND_ERROR "CPack ${description} file: \"${file}\" could
not be found.")
endif()
endmacr
Hi CMakers,
I was running into a "using to long path" issue with CMake.
Here some short notes about my setup:
OS: Windows 7
Dev: MS Visual Studio 10
CMake: 2.8.12 (tested it also with 3.0.1)
In our project (it is based on the CIAO/TAO framework) some files will be
generated automatically thro
Hello cmake users,
I'm trying to convert a big project from make to cmake, and I'm seeing
paths like
/home/lode/prj/test/cmake/ext/build/lib1/CMakeFiles/lib1.dir/home/lode/prj/test/cmake/ext/prj2/src
where I would want to see
/home/lode/prj/test/cmake/ext/build/lib1/CMakeFiles/lib1.dir/prj2/
