Stephen Kelly wrote:
Hi there,
I've just pushed tid-system-argument to my clone. It doesn't include unit
tests yet, but I wonder if I can get it into 2.8.11?
I looked into this a bit. The way SYSTEM include directories are marked is
makefile-local, not target-local.
That means that
Alexander Neundorf wrote:
The CONFIGURE_PACKAGE_CONFIG_FILE() macro could check its
INSTALL_DESTINATION argument, whether it is /lib[64]/ or /usr/lib[64]/
and use full paths in that case.
I'll play around a bit with the macro.
There is now the PackageConfigHelper_UsrMove branch on stage.
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13878
==
Reported By:Alan Hourihane
Assigned To:
On 01/25/2013 05:14 AM, Stephen Kelly wrote:
Alexander Neundorf wrote:
The CONFIGURE_PACKAGE_CONFIG_FILE() macro could check its
INSTALL_DESTINATION argument, whether it is /lib[64]/ or /usr/lib[64]/
and use full paths in that case.
I'll play around a bit with the macro.
There is now the
On 01/24/2013 03:39 PM, David Cole wrote:
It's not only that target_link_libraries would be doing more
than linking, it's also that you want to change the behavior of
something that has existed for 12+ years without this behavior.
If you do re-use target_link_libraries for your glorious one
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13880
==
Reported By:David Rosen
Assigned To:
On Friday 25 January 2013, Brad King wrote:
On 01/25/2013 05:14 AM, Stephen Kelly wrote:
Alexander Neundorf wrote:
The CONFIGURE_PACKAGE_CONFIG_FILE() macro could check its
INSTALL_DESTINATION argument, whether it is /lib[64]/ or /usr/lib[64]/
and use full paths in that case.
I'll
On 01/25/2013 03:24 PM, Alexander Neundorf wrote:
On Friday 25 January 2013, Brad King wrote:
On 01/25/2013 05:14 AM, Stephen Kelly wrote:
Are INSTALL(EXPORT)ed files affected at all by this? Do they need to be?
Yes, since they compute paths relative to their location in order
to be
On Friday 25 January 2013, Brad King wrote:
On 01/25/2013 03:24 PM, Alexander Neundorf wrote:
On Friday 25 January 2013, Brad King wrote:
On 01/25/2013 05:14 AM, Stephen Kelly wrote:
Are INSTALL(EXPORT)ed files affected at all by this? Do they need to
be?
Yes, since they compute
On Thursday 24 January 2013, Brad King wrote:
On 01/24/2013 03:40 PM, Alexander Neundorf wrote:
There is now the PackageConfigHelper_UsrMove branch on stage.
If the Config.cmake will be installed to /lib(64) or /usr/lib(64), it
will use full absolute paths.
I like that approach. It
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13881
==
Reported By:Rodolfo Schulz de Lima
Assigned To:
From: xantare...@hotmail.com
To: cmake@cmake.org
Date: Thu, 24 Jan 2013 08:12:49 +
Subject: [CMake] find_packge behavior regarding enabled languages
Hi,
I noticed that when all languages are disabled through the project command:
project ( Foo NONE )
... then a dependent Bar
xantares 09 wrote:
From: xantare...@hotmail.com
To: cmake@cmake.org
Date: Thu, 24 Jan 2013 08:12:49 +
Subject: [CMake] find_packge behavior regarding enabled languages
I noticed that when all languages are disabled through the project command:
project ( Foo NONE )
... then a
From: e...@sf-mail.de
To: cmake@cmake.org
Date: Fri, 25 Jan 2013 19:00:56 +0100
Subject: Re: [CMake] find_packge behavior regarding enabled languages
xantares 09 wrote:
From: xantare...@hotmail.com
To: cmake@cmake.org
Date: Thu, 24 Jan 2013 08:12:49 +
Subject: [CMake] find_packge
I am testing a ITK patch I'm working on in Windows. That involves entering
a path in cmake-gui or ccmake. The first time I tried it, I entered the
path 'windows-wise' with backslashes as path separators.
That caused a syntax error at the point where that variable is used. When
I re-entered the
Am Freitag, 25. Januar 2013, 12:52:07 schrieb Kent Williams:
I am testing a ITK patch I'm working on in Windows. That involves entering
a path in cmake-gui or ccmake. The first time I tried it, I entered the
path 'windows-wise' with backslashes as path separators.
That caused a syntax
Hi,
I'm trying to convince CMake to do my bidding with regard to setting the RPATH
on one of my executables, and it doesn't seem to be working as I think it should
be (according to my understanding of the documentation).
I'm running CMake 2.8.10.2 on OS X 10.8.2, and using the Xcode generator.
I'm trying to write a Findpackage.cmake file for a library that doesn't
generate a proper packageConfig.cmake file.
The problem I'm trying to solve is how to build against a build tree
instead of an install tree. On OS X and Windows (well, probably any
Makefile generator) CMake helpfully adds
Hi Kent,
On all the platform, the build tree contains a CMakeCache.txt that will
systematically contain the following text:
FOO_SOURCE_DIR:STATIC=/path/to/foosource
where FOO is the name of the project.
You could simply check for the existence of CMakeCache.txt, and extact
the value using
Kent,
I have a CMake function that may be of interest to you (see attached file).
For your purposes, use it as follows:
GetCMakeCacheValue( ${ABC_BUILD_DIR} ABC_SOURCE_DIR )
where the project against which you want to build is named ABC.
The first argument must always be the build directory
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 83da29e8e2f6fe09c05222aba668caafcaa4a137 (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, master has been updated
via 2046de2a39e993d0f892f2f38f0ba7543f8505a6 (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, master has been updated
via c29dd4fa76c77830eb2b001867b8e2fcab87e829 (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, master has been updated
via aa6ad9c903c95f7e1112d52925d217d8cb54b62f (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, master has been updated
via 48ab5050de1b60309744f894fd0e96b2db75b76f (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 4da12dd0b5bd9712237198cf8df94a9de12ea59b (commit)
via
26 matches
Mail list logo
