The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13895
==
Reported By:Sylwester Arabas
Assigned To:
On 02/06/2013 08:27 PM, Stephen Kelly wrote:
I've pushed a branch with some addtional fixes for various issues in
generator expressions.
Thanks, those all look good. I presume you're finding these by
trying to use the new features for Qt5, KDE, and Boost? How else?
One of the issues
Brad King wrote:
On 02/06/2013 08:27 PM, Stephen Kelly wrote:
I've pushed a branch with some addtional fixes for various issues in
generator expressions.
Thanks, those all look good. I presume you're finding these by
trying to use the new features for Qt5, KDE, and Boost? How else?
Yes.
On 02/07/2013 09:02 AM, Stephen Kelly wrote:
A concern though is this in CMakeExpandImportedTargets.cmake:
get_target_property(_linkInterfaceLibs ${_CURRENT_LIB}
IMPORTED_LINK_INTERFACE_LIBRARIES_${_importedConfigToUse} )
That macro won't work if the
This is interesting...
The intent of FindQt4.cmake is to find the Qt installation so it can be used.
But in that bug report, the QT_IMPORTS_DIR variable is being used to determine
the qt_dir/imports directory to install their qml plugins - which is into
the Qt installation. Its a problem for
Brad King wrote:
The full solution is to refactor things enough that a new kind of
try_compile can be implemented. It should push the configuration
process state on a stack, run more CMake code in the isolated state
to add some targets, and then generate the build system for them
directly
Brad King wrote:
The full solution is to refactor things enough that a new kind of
try_compile can be implemented. It should push the configuration
process state on a stack, run more CMake code in the isolated state
to add some targets, and then generate the build system for them
directly
On 02/07/2013 11:42 AM, Stephen Kelly wrote:
Are you sure?
Well, my proposal would be sufficient but may not be necessary
(i.e. overkill).
It seems to me it would be much easier and less duplicative to
add a way to specify TARGETS in try_compile, and in cmCoreTryCompile,
generate the
Clinton Stimpson wrote:
This is interesting...
The intent of FindQt4.cmake is to find the Qt installation so it can be
used. But in that bug report, the QT_IMPORTS_DIR variable is being used to
determine the qt_dir/imports directory to install their qml plugins -
which is into
the Qt
On Thursday, February 07, 2013 05:51:59 PM Stephen Kelly wrote:
Clinton Stimpson wrote:
This is interesting...
The intent of FindQt4.cmake is to find the Qt installation so it can be
used. But in that bug report, the QT_IMPORTS_DIR variable is being used to
determine the qt_dir/imports
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13896
==
Reported By:Leszek Swirski
Assigned To:
Clinton Stimpson wrote:
That said, the reported problem in the bug report, that qmake reports the
path, but cmake does not make it available, seems like something to look
into.
Do you have something in mind when you say it should be looked into?
qmake is reporting a non-existant
Brad King wrote:
On 02/07/2013 01:40 PM, Stephen Kelly wrote:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fecede0d9012f78470778cb049b2ab0231b4dcb7
+ If this variable is enabled, CMake automatically adds for each
shared
+ library target, module target and executable target,
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13897
==
Reported By:Eric Gross
Assigned To:
On 02/07/2013 04:15 PM, Stephen Kelly wrote:
What about OBJECT_LIBRARYs ? I have no experience with them.
Do you add any interface properties to any object libraries currently?
Do the new tcd() and tid() work for them, at least for the impl
properties (COMPILE_DEFINITIONS and
Brad King wrote:
On 02/07/2013 04:15 PM, Stephen Kelly wrote:
What about OBJECT_LIBRARYs ? I have no experience with them.
Do you add any interface properties to any object libraries currently?
Nope. The only places where cmake populates interface properties are with
the
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13898
==
Reported By:Jonathan M Davis
Assigned To:
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13899
==
Reported By:Jonathan M Davis
Assigned To:
Did you try to create two targets and add per-target compile flags?
Something along the lines of
add_library(mylib_rel ${sources})
add_library(mylib_dbg ${sources})
set_target_properties(mylib_rel PROPERTIES COMPILE_FLAGS -O3)
set_target_properties(mylib_dbg PROPERTIES COMPILE_FLAGS -O0 -g)
Not
On Thu, Feb 7, 2013 at 3:12 AM, Yngve Inntjore Levinsen
yngve.levin...@gmail.com wrote:
Did you try to create two targets and add per-target compile flags?
What you suggest is replacing configurations with targets. That may be
possible, but runs counter to how CMake natively works. I feel
How about something like this:
if(${CMAKE_BUILD_TYPE STREQUAL DebugAndRelease)
include(ExternalProject)
ExternalProject_Add(MEDEBUG
CMAKE_FLAGS -DCMAKE_BUILD_TYPE Debug)
ExternalProject_Add(MERELEASE
CMAKE_FLAGS -DCMAKE_BUILD_TYPE Release)
install(FILES ...)
Hi,
I think you are fighting the tool in any case, because you are asking to
build multiple configurations in one build folder (?). Normally you
would create one build folder per configuration.. Which I guess is what
you are doing today.
Instead of specifying the compile flags manually you can
On 2/6/2013 6:00 PM, Theo Berkau wrote:
Hello,
I've been trying to setup a cross-compiled project using cmake and so
far everything's working fine using Unix Makefiles generator, etc. Now
I know generating for visual studio generally doesn't work under a cross
compiling setup, but I was
The approach suggested by Ansis looks interesting. Instead of using
install(FILES ...), you could use CPACK_INSTALL_CMAKE_PROJECTS [1][2]. For
an example, see [3] and [4]
[1]
http://www.cmake.org/cmake/help/v2.8.8/cpack.html#variable:CPACK_INSTALL_CMAKE_PROJECTS
[2]
On Thu, Feb 7, 2013 at 12:41 PM, Yngve Inntjore Levinsen
yngve.levin...@gmail.com wrote:
I think you are fighting the tool in any case, because you are asking to
build multiple configurations in one build folder (?). Normally you would
create one build folder per configuration.. Which I guess
On Wednesday, February 06, 2013 01:09:20 PM Patrick Johnmeyer wrote:
I have looked through the CMake wikis and several mailing list threads that
the following google search returned, and I have not found a definitive
answer to my question.
[site:www.cmake.org/pipermail/cmake CPack multiple
Hello:
I am trying to build an app to be compatible with Mac OSX systems 10.6, 10.7,
and 10.8 using the command line with cmake. I have successfully built it for
10.7.5, now I would like to expand this app to be compatible with 10.6 and 10.8
is this possible?
This is the command I am issuing
On Thu, 7 Feb 2013 17:05:55 -0800, Ed said:
I am trying to build an app to be compatible with Mac OSX systems 10.6,
10.7, and 10.8 using the command line with cmake. I have successfully
built it for 10.7.5, now I would like to expand this app to be
compatible with 10.6 and 10.8 is this possible?
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 b6947b77d5109c192cb2c64b061fb0cb771882f8 (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 ac37dfb6628e9c43da6912885c255e3bef216257 (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 03df039502924398fe51ccd492ef4a5c93c86b71 (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 c53d0f18a8fb38c2d38c113c7341b2e95691eba6 (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 910ad89f3c556f8902e3206a620b9c867b6dcb39 (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 3efc38828749d34c1f2e3c87a031db3b85dece14 (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 5f456ded1e6426c57f82306f36a517875898a68a (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 37bdf11cce238f61210da0cf9e1ccd57a17bef3a (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 5948a987e8633f6be2aa140051a3d8e8954e3bb0 (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 623f04a71ceb2687b2b2b7cb961f45a848902a3e (commit)
via
Stamp
diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 0be7d05..1b33cde 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -2,5 +2,5 @@
set(CMake_VERSION_MAJOR 2)
set(CMake_VERSION_MINOR 8)
set(CMake_VERSION_PATCH 10)
-set(CMake_VERSION_TWEAK 20130207
39 matches
Mail list logo
