Similarly find_program already looks in /usr/local/bin.
I suspect the patch without the above hunks is sufficient. Can anyone
on OpenBSD verify this please?
Confirmed. /usr/local hunks are not needed.
Thanks,
David
Ok. Attached is the modified set of patches for OpenBSD qt3/qt4
On 12/06/2012 07:48 AM, Amit Kulkarni wrote:
Ok. Attached is the modified set of patches for OpenBSD qt3/qt4 handling.
Commit message: Handle OpenBSD specific paths in Qt3/Qt4, allowing concurrent
building and installation. Some common programs to both qt3/qt4 are renamed
with suffixes of
Brad King wrote:
Anyway, I think once the LINK_PUBLIC part of the policy is worked
out then I'll perform one final review pass through the topic.
I'd also like to have the CMP0019 test added to it covering the
current form of the policy (since it's changed since you wrote the
test before).
Brad,
Is it possible for you to accept this chunk from
http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/devel/cmake/patches/patch-Modules_Platform_OpenBSD_cmake
$OpenBSD: patch-Modules_Platform_OpenBSD_cmake,v 1.9 2012/12/05
11:32:04 dcoppa Exp $
--- Modules/Platform/OpenBSD.cmake.orig Tue
Sorry please forget this message.
On Thu, Dec 6, 2012 at 7:10 AM, Amit Kulkarni amitk...@gmail.com wrote:
Brad,
Is it possible for you to accept this chunk from
http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/devel/cmake/patches/patch-Modules_Platform_OpenBSD_cmake
$OpenBSD:
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13778
==
Reported By:David Imhoff
Assigned To:
On 11/29/2012 02:48 PM, Stephen Kelly wrote:
So maybe I should only do the expansion if containsVariable is true?
+//
+static bool containsVariable(const std::string lib)
+{
+ const std::string::size_type openpos =
Brad King wrote:
On 11/29/2012 02:48 PM, Stephen Kelly wrote:
So maybe I should only do the expansion if containsVariable is true?
+//
+static bool containsVariable(const std::string lib)
+{
+ const
On 12/06/2012 08:08 AM, Stephen Kelly wrote:
There is another twist in the tail here. The existing topic on next is not
taking account of the case where the link implementation is the link
interface when exporting.
Yes, of course :(
How can we ever stop exporting the old interface when it
Hi,
I haven't followed the long thread between Brad and Stephen about importing
and exporting targets closely...
So, if I understand correctly, in the future the following cmake code
find_package(Foo)
add_executable(hello main.cpp)
target_link_libraries(hello ${Foo_LIBRARIES})
may also set
On Tuesday 04 December 2012, Stephen Kelly wrote:
Alexander Neundorf wrote:
All install variables which are at cmake time somewhere below
CMAKE_INSTALL_PREFIX are treated as relative to CMAKE_INSTALL_PREFIX.
This is what the @PAKCAGE_INIT@ macro together with the @PACKAGE_FOO_DIR@
Alexander Neundorf wrote:
Let's assume /opt/foo/lib/ is a symlink to /usr/local/lib/.
The package has been installed to /opt/foo/ and is found via
CMAKE_PREFIX_PATH in /opt/foo/lib/cmake/Foo/FooConfig.cmake.
Now when going up to the prefix, we will come across /opt/foo/lib/, which
is a
On 12/06/2012 08:08 AM, Stephen Kelly wrote:
There is another twist in the tail here. The existing topic on next is not
taking account of the case where the link implementation is the link
interface when exporting.
After considering this issue and the concerns Alex raised in the new
Setting
On Thursday 06 December 2012, Stephen Kelly wrote:
Alexander Neundorf wrote:
Let's assume /opt/foo/lib/ is a symlink to /usr/local/lib/.
The package has been installed to /opt/foo/ and is found via
CMAKE_PREFIX_PATH in /opt/foo/lib/cmake/Foo/FooConfig.cmake.
Now when going up to the
On Thursday 06 December 2012, Alexander Neundorf wrote:
...
I'd much prefer the following:
find_package(Foo NO_MODULE)
add_executable(hello main.cpp)
target_use_targets(hello Foo::FooLibrary)
which could even warn if a used library doesn't have include directory
properties set, etc.
Alexander Neundorf wrote:
Hi,
I haven't followed the long thread between Brad and Stephen about
importing and exporting targets closely...
So, if I understand correctly, in the future the following cmake code
find_package(Foo)
add_executable(hello main.cpp)
Alexander Neundorf wrote:
On Thursday 06 December 2012, Stephen Kelly wrote:
Alexander Neundorf wrote:
Let's assume /opt/foo/lib/ is a symlink to /usr/local/lib/.
The package has been installed to /opt/foo/ and is found via
CMAKE_PREFIX_PATH in /opt/foo/lib/cmake/Foo/FooConfig.cmake.
On Thursday 06 December 2012, Stephen Kelly wrote:
Alexander Neundorf wrote:
On Thursday 06 December 2012, Stephen Kelly wrote:
Alexander Neundorf wrote:
Let's assume /opt/foo/lib/ is a symlink to /usr/local/lib/.
The package has been installed to /opt/foo/ and is found via
Brad King wrote:
On 12/06/2012 08:08 AM, Stephen Kelly wrote:
There is another twist in the tail here. The existing topic on next is
not taking account of the case where the link implementation is the link
interface when exporting.
After considering this issue and the concerns Alex raised
On 12/06/2012 03:55 PM, Stephen Kelly wrote:
Brad King wrote:
Let's keep the proposed changes in your Gitorious clone at
https://gitorious.org/~steveire/cmake/steveires-cmake
for now. If I need to push commits I'll publish them somewhere similar.
So what are the next steps? Should I
On 12/06/2012 03:53 PM, Stephen Kelly wrote:
Brad King wrote:
How can we ever stop exporting the old interface when it comes from the
link implementation?
The approach I was thinking was to deal with it the same way we deal with
LINK_PUBLIC and LINK_PRIVATE - Make it depend on the policy.
Alexander Neundorf wrote:
I also think it's a very bad idea to install into a prefix where one of
the directories below it is a symlink to somewhere else. I think that
also deserves a warning.
See below, you can get the same problem if you install into a prefix where
there is no symlink,
On Thursday 06 December 2012, Stephen Kelly wrote:
...
I don't fully follow (too much 'the example' etc :)), but I guess it's not
too important. I think the two cases we're talking about are clear
* Installing to a location where one or more locations below
${CMAKE_INSTALL_PREFIX} are
On Thu, Dec 6, 2012 at 3:37 PM, Stephen Kelly steve...@gmail.com wrote:
Alexander Neundorf wrote:
Hi,
I haven't followed the long thread between Brad and Stephen about
importing and exporting targets closely...
So, if I understand correctly, in the future the following cmake code
Brad King wrote:
I'm picturing this as just a simple reStructuredText document in a branch
of your repo. If anyone (like Alex) wants to join the discussion there
will be one place to look for the current status.
I don't like the idea of using a branch in a repo. It would require checking
Alexander Neundorf wrote:
On Thursday 06 December 2012, Stephen Kelly wrote:
...
I don't fully follow (too much 'the example' etc :)), but I guess it's
not too important. I think the two cases we're talking about are clear
* Installing to a location where one or more locations below
David Cole wrote:
On Thu, Dec 6, 2012 at 3:37 PM, Stephen Kelly
steve...@gmail.com wrote:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3615/focus=5111
I'm not sure what has changed since then.
What's changed since then is that we've seen how much change is needed for
Moving this to the developer list where I meant it to be, rather than on
the cmake users list. Sorry for anyone who gets it twice.
I am looking for a way to set global flags for the librarian when creating
static libraries, similar to CMAKE_SHARED_LINKER_FLAGS
or CMAKE_EXE_LINKER_FLAGS. This
Hi,
The CMake 2.8.10 manual includes the following statement in the paragraph
about link_directories() command:
Library locations returned by find_package() and find_library() are
absolute paths.
Would it be possible to include similar clarification in the sections for
find_package() and
I am using cmake/cpack 2.8.9. We have cmake wrapped in Makefile.
CMAKE and CPACK are defined in the Makefile as the full path to the
respective executables. Cmake is expanding the cmake definition to
the full path but cpack doesn't include the full path. This is the
relevant section of
Hi all,
I have two CMakeFile.txt's for a C++ project where one includes the
other. In both cases, I'm searching for Boost.
So, to make this easier, suppose I call one project parent and the
other child such that parent's CMakefile.txt has:
INCLUDE_DIRECTORIES (child)
where child is a
Does anyone have any code that can detect if a given configuration (by
name) is a debug or release configuration? This should work in both
single-configuration and multi-configuration generators.
For example, in Visual Studio:
Release - Release
MinSizeRel - Release
RelWithDebInfo - Release
Debug
Hi,
On Thu, Dec 6, 2012 at 5:13 PM, Mateusz Loskot mate...@loskot.net wrote:
The CMake 2.8.10 manual includes the following statement in the paragraph
about link_directories() command:
Library locations returned by find_package() and find_library() are
absolute paths.
Would it be possible
Hi,
I compiled cmake itself on SunOS/x86
I want to compile my apps in 64 bit mode, however linking with X11 does not work
as cmake finds /usr/lib/libX11.so which is the 32bit version, and the 64 bit
version
is in /usr/lib/64/libX11.so
SunOS/x86 is a 64 bit OS, but the stupid Sun CC compiler
On 6 December 2012 18:45, Andreas Pakulat ap...@gmx.de wrote:
On Thu, Dec 6, 2012 at 5:13 PM, Mateusz Loskot mate...@loskot.net wrote:
The CMake 2.8.10 manual includes the following statement in the paragraph
about link_directories() command:
Library locations returned by find_package() and
On Thursday 06 December 2012 20:27:27 Koller, Martin wrote:
Hi,
I compiled cmake itself on SunOS/x86
I want to compile my apps in 64 bit mode, however linking with X11 does not
work
as cmake finds /usr/lib/libX11.so which is the 32bit version, and the 64 bit
version
is in
Martin Koller wrote:
On Thursday 06 December 2012 20:27:27 Koller, Martin wrote:
Hi,
I compiled cmake itself on SunOS/x86
I want to compile my apps in 64 bit mode, however linking with X11 does
not work as cmake finds /usr/lib/libX11.so which is the 32bit version,
and the 64 bit
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 3587b972b651ecc4fc14a55b13b00e97997f2d33 (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 4c654ef46b1e13e8a08e6e17070d95a247152143 (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 8373fab93a51952fadd8d965905ce0eabf22f2a4 (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 687834d31aab938a884e85885e34cdd9d5a506b7 (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 9b0207a1d3b08d938509ac1b3f3368c0e0eaf137 (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 d02456cb18822f74e2c67e7e080ffdff486e815b (commit)
via
Stamp
diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 5c77993..fe2b1f3 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 20121206
44 matches
Mail list logo
