Brad King wrote:
Any project-specific place that needs to know the on-target path
can use a project-specific variable.
Yes, I suppose. What I was suggesting was to standardise that.
Okay, but I'd rather keep CMAKE_INSTALL_PREFIX to mean where on the
host it will be installed since that's
On 7/11/2013 6:56 AM, Stephen Kelly wrote:
As CMAKE_SYSROOT is new, there's no breakage either way.
I'd much prefer to use configure_file with a file containing
#define CMAKE_INSTALL_PREFIX
and have it be always correct when using the sysroot
I've already disagreed with having
Brad King wrote:
If that problem manifests in practice we can add a special hook to
enable the workaround.
If I understand you, this doesn't sound like an attractive solution to
me.
If we go with CMAKE_TARGET_INSTALL_PREFIX as I describe above
then we can simply use that to activate the
On 07/11/2013 08:07 AM, Stephen Kelly wrote:
Brad King wrote:
If we go with CMAKE_TARGET_INSTALL_PREFIX as I describe above
then we can simply use that to activate the workaround logic
instead of CMAKE_INSTALL_PREFIX. On host-only builds the two
values will be the same and it will just work
Steve,
Our discussions recently have been divided between two general
areas of enhancement:
* Usage requirements and interface libraries
* Cross-compiling
I think we should set the priority on the former for 2.8.12
since it is the culmination of your work for over a year.
After
Brad King wrote:
Both roles are already widely used. There is user code that:
* Sets CMAKE_INSTALL_PREFIX to change the install dest (role 1).
* Uses CMAKE_INSTALL_PREFIX as the target install dest (role 2).
Moving one role into a separate variable will require user code for
at least one
On 07/11/2013 09:06 AM, Stephen Kelly wrote:
Role 2 is probably more common.
In cmake code you mean?
Yes.
I imagine there are lots of bash scripts or aliases
which invoke cmake with -DCMAKE_INSTALL_PREFIX (I use an alias).
Yes, and this makes role 1 even more common. [smacks forehead]
On 07/11/2013 09:21 AM, Stephen Kelly wrote:
Yes, apart from tll-new-signatures, I'd like to try to get the export-policy
and target-LOCATION-policy topics from my clone into 2.8.12.
Okay, that sounds like a good dividing point. Once we get those in
we'll see how the timing looks to decide on
- Original Message -
On 7/3/2013 11:43 AM, Stephen Kelly wrote:
To choose an SDK, you use the -isysroot option with the compiler and the -
syslibroot option with the linker.
[snip]
Modules/Platform/Darwin-Clang.cmake: set(CMAKE_${lang}_SYSROOT_FLAG
-isysroot)
[snip]
I'm
On 07/11/2013 10:41 AM, clin...@elemtech.com wrote:
They also appear similar to me, so I would start with the
assumption that they should be unified.
I just dug into this a bit.
One difference is that CMAKE_OSX_SYSROOT can be set to a logical
SDK name rather than a path. In Darwin.cmake there
On 07/11/2013 11:08 AM, Brad King wrote:
Can anyone else think of complications?
Side note: If we cannot resolve this soon we should revert
CMAKE_SYSROOT before 2.8.12 to leave room for the two to
be combined later.
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14286
==
Reported By:Christian Bühler
Assigned To:
- Original Message -
Stephen Kelly steveire@... writes:
We could also probably add a runtime warning if enabled. You need to enable
deprecation warnings with your compiler, so it would make sense to have to
enable them with a cmake script too. CMAKE_ENABLE_DEPRECATION_WARNINGS
The following simple test case works (for CMake-2.8.10.1)
cmake_policy(SET CMP0007 NEW)
set(lines a;;)
list(GET lines 0 package1)
list(GET lines 1 package2)
list(GET lines 1 package3)
message(${package1})
message(${package2})
message(${package3})
list(REMOVE_AT lines 0 1 2)
e.g.,
The following issue has been SUBMITTED.
==
http://cmake.org/Bug/view.php?id=14287
==
Reported By:Rolf Eike Beer
Assigned To:
Hello,
Related to this, I implemented an EXTRACT_COMMAND option to
ExternalProject_Add which would enable to download anything, provided that
an EXTRACT_COMMAND is also passed so that CMake knows how to extract what
it downloaded. It is specially useful for Windows, where NSIS,
InstallShield, etc
Hello,
Sorry, the example was wrong (copy paste from a bad revision). This is
the right one:
ExternalProject_Add( graphicsmagick
DOWNLOAD_NAME graphicsmagick.exe
DOWNLOAD_DIR ${WINST_BASEDIR}/downloads
URL ${graphicsmagick_URL}
URL_MD5
17 matches
Mail list logo
