Hi
-Original Message-
From: cmake-developers [mailto:cmake-developers-boun...@cmake.org]
On Behalf Of Bill Hoffman
Sent: Freitag, 29. August 2014 17:35
To: cmake-developers@cmake.org
Subject: Re: [cmake-developers] Cross compile tests on open.cdash.org
On 8/29/2014 9:47 AM, Bach,
Am 29.08.2014 17:35, schrieb Bill Hoffman:
On 8/29/2014 9:47 AM, Bach, Pascal wrote:
Hi Everybody
I'm interested in cross compilation, and am already using it
extensively for Linux and Embedded Linux.
But now I ran into some problems cross compiling for Windows Compact
Embedded 2013 using
On Fri, Aug 29, 2014 at 4:20 AM, Aleix Pol aleix...@kde.org wrote:
Dear cmake'rs,
I'm rewriting the KDevelop plugin from scratch to fetch the information
from the build directory.
Now in the first implementation I'm using the compile_commands.json file
that cmake already can generate for
Hi Guys
This is a good idea. There has been some recent work on the windows
phone support: Tests/VSWinStorePhone/. However, I would think what
you would want would be a more comprehensive test of CMake. Most of
the tests run executables that are built. We would either have to not
Back on topic...
Solaris 10 + SolarisStudio
http://open.cdash.org/buildSummary.php?buildid=3470493
No build failures, 4 test failures
Solaris 10 + GCC (from OpenCSW)
http://open.cdash.org/buildSummary.php?buildid=3470687
No build failures, 5 test failures
I dug more into the test
The approach looks reasonable, but having it unconditionally spit out a
file in cmGlobalGenerator regardless of generator is probably not what
we want. Seems like it should be based on a variable, or be in a
specific generator, or somehow have a limited scope.
HTH,
David C.
--
Powered by
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15121
==
Reported By:Hartmut Seichter
Assigned To:
On Monday, September 01, 2014 15:26:12 David Cole via cmake-developers wrote:
The approach looks reasonable, but having it unconditionally spit out a
file in cmGlobalGenerator regardless of generator is probably not what
we want. Seems like it should be based on a variable, or be in a
specific
On Mon, Sep 1, 2014 at 9:26 PM, David Cole dlrd...@aol.com wrote:
The approach looks reasonable, but having it unconditionally spit out a
file in cmGlobalGenerator regardless of generator is probably not what we
want. Seems like it should be based on a variable, or be in a specific
generator,
Am Montag, 1. September 2014, 14:35:41 schrieb Chuck Atkins:
Back on topic...
Solaris 10 + SolarisStudio
http://open.cdash.org/buildSummary.php?buildid=3470493
No build failures, 4 test failures
Solaris 10 + GCC (from OpenCSW)
http://open.cdash.org/buildSummary.php?buildid=3470687
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
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
-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()
endmacro()
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
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 special
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.
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
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 496d0357f9273304bfe6d706ca6a42e8f80f2bf0 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 19b17e61df12fd21bae28b53b1c1231edb9c0e00 (commit)
via
20140901)
+set(CMake_VERSION_PATCH 20140902)
#set(CMake_VERSION_RC 1)
---
Summary of changes:
Source/CMakeVersion.cmake |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
hooks/post-receive
--
CMake
20 matches
Mail list logo
