Alexander Neundorf wrote:
The point is that you get targets from one installed Config.cmake file,
and other information from a different installed Config.cmake file, due to
different required version or search paths.
Should we guard the whole Config.cmake file ?
A Config file author
On 12/19/2012 07:31 AM, Stephen Kelly wrote:
I think this idea gets complex quickly.
Yes, we're bikeshedding it.
The cmPropertyMap would need to hold cmProperty* and new them. cmPropertyMap
and cmProperties are currently copied but that would have to be made
impossible as it introduces
Brad King wrote:
Okay. Since this is purely internal it can be factored into a generalized
approach later.
Great. I mentioned this before:
Note that the branch is work in progress. Currently the backtrace is not
always initialized correctly when include_directories() is used. What do
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13803
==
Reported By:Michael Rolnik
Assigned To:
The following issue has been SUBMITTED.
==
http://www.itk.org/Bug/view.php?id=13804
==
Reported By:Andreas Mohr
Assigned To:
On 12/19/2012 09:49 AM, Stephen Kelly wrote:
The problem is that in this code:
include_directories(foo/bar)
add_library(the_lib ...)
the INCLUDE_DIRECTORIES target property is seeded by the directory property
of the same name. The backtrace then leads to the add_library invokation
On 12/18/2012 12:00 PM, Stephen Kelly wrote:
3. There is no change in behavior for existing use cases because the
new behavior comes only from new interfaces.
A new command and INTERFACE_LINK_LIBRARIES would have the same effect.
But, maybe a property which is only responsible for
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13805
==
Reported By:Andrew Bott
Assigned To:
Op 18-12-12 13:46, David Cole schreef:
On Mon, Dec 17, 2012 at 11:57 AM, Alexander Neundorf
a.neundorf-w...@gmx.net mailto:a.neundorf-w...@gmx.net wrote:
On Monday 17 December 2012, David Cole wrote:
I thought we wanted them to switch to the new behavior... Isn't
that the
Hi David,
I need to set a policy to OLD, because I have wrapped a few existing
Find*.cmake files to overcome some bugs or shortcomings. However, since
CMake 2.8.4 (or 2.8.3, I'm not sure), this triggers a policy warning
CMP0017 with newer versions of CMake, because some macros are now
Stephen Kelly wrote:
Note that an RC1 was released in the mean-time:
http://qt-project.org/downloads
That does not change anything with regard to the CMake files however.
Qt 5.0 final has now been released :).
http://blog.qt.digia.com/blog/2012/12/19/qt-5-0/
It also does not change
No need for specific examples. Just wanted to understand the context better.
One good way to avoid this warning would be to get your Find* script
changes into CMake itself, and then eliminate your need for the custom
copies of them when using a new-enough CMake.
Is it feasible for you to propose
On Wednesday 19 December 2012, Marcel Loose wrote:
Hi David,
I need to set a policy to OLD, because I have wrapped a few existing
Find*.cmake files to overcome some bugs or shortcomings. However, since
CMake 2.8.4 (or 2.8.3, I'm not sure), this triggers a policy warning
CMP0017 with newer
I think the safest/wisest thing to do in this case is to update your
minimum required version to CMake 2.8.4, and then adjust your custom code
to eliminate the warning if it still occurs.
2.8.4 is more than 18 months old at this point. Is there a reason why 2.6.2
is still required for some?
On
I'm using the shipped UseSWIG package to add a swig module to my project (cmake
2.8). For those that don't know, swig works by running the swig command on an
input file (a .i) and then building the files that it produces. The input file
tells swig to scan certain header files and the output
On Wednesday, December 19, 2012 01:18:47 PM Daniel Russel wrote:
I'm using the shipped UseSWIG package to add a swig module to my project
(cmake 2.8). For those that don't know, swig works by running the swig
command on an input file (a .i) and then building the files that it
produces. The
On 19/12/12 17:56, David Cole wrote:
I think the safest/wisest thing to do in this case is to update your
minimum required version to CMake 2.8.4, and then adjust your custom
code to eliminate the warning if it still occurs.
2.8.4 is more than 18 months old at this point. Is there a reason
On 19/12/12 16:21, David Cole wrote:
No need for specific examples. Just wanted to understand the context
better.
One good way to avoid this warning would be to get your Find* script
changes into CMake itself, and then eliminate your need for the custom
copies of them when using a new-enough
Stamp
diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 84ed368..66ae4c6 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 20121219
19 matches
Mail list logo
