Hi,
I've had a look at the CMAKE_GENERATOR_TOOLSET option now. I think the
correct approach for WP8 is to hardcode v110_wp80 as it's the only option
that will properly give a working WP8 project. Thanks Brad for pointing this
out though - this might be useful for targeting versions in future
Brad King wrote:
Steve,
Thanks for working on this. Please update the documentation
of tll() to mention this behavior.
Also, the use of CollapseFullPath to evaluate /.. seems more
complicated than necessary. A single CollapseFullPath of the
original input followed by a check against a
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14302
==
Reported By:Jason Spiro
Assigned To:
On 07/19/2013 06:32 AM, Daniele E. Domenichelli wrote:
On 18/07/13 21:54, Brad King wrote:
Please update your topic to fix this and make sure tests pass
locally before publishing.
Done! Sorry about that!
Great, thanks.
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source
On 07/19/2013 05:42 AM, Paul Annetts wrote:
I think the first (and largest) stage of this is to support Windows Store
apps for Win32/ARM multiple architecture. Am I right in thinking this is
what Visual Studio 11 ARM generates?
That generates for the ARM architecture. It was a contributed
On 07/19/2013 12:02 AM, clin...@elemtech.com wrote:
- Original Message -
It looks to me like CMAKE_SYSROOT and CMAKE_OSX_SYSROOT are
pretty much identical other than the logical name mapping.
At a minimum we need to make them mutually exclusive (at most
one can be set in a single
Sorry wrong ML :(.
On Fri, Jul 19, 2013 at 4:36 PM, Nicolas Desprès
nicolas.desp...@gmail.comwrote:
Hi,
In Unix shell we can do that:
$ VAR=foo cmd in out
This way the environment variable is only set in the environment of the
process of the command and not the in current shell like when
Hi,
In Unix shell we can do that:
$ VAR=foo cmd in out
This way the environment variable is only set in the environment of the
process of the command and not the in current shell like when using the
export built-in.
I would like to be able to do the same for a custom command in CMake.
Ideally I
On 07/19/2013 10:36 AM, Nicolas Desprès wrote:
Hi,
In Unix shell we can do that:
$ VAR=foo cmd in out
This way the environment variable is only set in the environment of the
process of the command and not the in current shell like when using the
export built-in.
I would like to be
On 2013-07-19 10:36, Nicolas Desprès wrote:
In Unix shell we can do that:
$ VAR=foo cmd in out
This way the environment variable is only set in the environment of the
process of the command and not the in current shell like when using the
export built-in.
I would like to be able to do the same
On 2013-07-19 12:35-0400 Matthew Woehlke wrote:
On 2013-07-19 10:36, Nicolas Desprès wrote:
In Unix shell we can do that:
$ VAR=foo cmd in out
This way the environment variable is only set in the environment of the
process of the command and not the in current shell like when using the
export
Alexander Neundorf wrote:
On Monday 29 April 2013, Rolf Eike Beer wrote:
Alexander Neundorf wrote:
On Sunday 28 April 2013, Rolf Eike Beer wrote:
One question I see increasingly often is how do I test for C++11
support or for specific parts of that. For 2.8.12 I plan to include
Hello.
I have a strange issue when cross compiling with CMake.
When i compile for host, in the resulting binary i have:
readelf -d ./test
...
0x0001 (NEEDED) Shared library: [libfoo.so]
0x000f (RPATH) Library rpath: [$ORIGIN/../../lib/]
...
When i use CMake
Does /home/mgh/proj/test/lib/libfoo.so not have a SONAME while your
native libfoo.so does?
The linker may use the SONAME when available and might fall back to the
path as seen on the command line (/home/mgh/proj/test/lib/libfoo.so)
otherwise?
Nils
On 07/19/2013 10:41 AM, Дмитрий Дороговцев
2013/7/19 Nils Gladitz nilsglad...@gmail.com
Does /home/mgh/proj/test/lib/libfoo.so not have a SONAME while your
native libfoo.so does?
The linker may use the SONAME when available and might fall back to the
path as seen on the command line (/home/mgh/proj/test/lib/libfoo.so)
otherwise?
When the library is being created by CMake itself I would have expected
a SONAME by default:
Default is to set soname on all shared libraries and modules as long
as the platform supports it.
Is armLinux a valid value for CMAKE_SYSTEM_NAME?
Quick glimpse at some documentation suggests you may
Hi,
I'm currently in the process of setting up automatic builds using CMake,
CTest and CDash
So far I've got builds working, and subprojects seem to be successfully
implemented, but there are a few things it would be useful to know.
1) Is there a way to quickly remove multiple builds from the
2013/7/19 Nils Gladitz nilsglad...@gmail.com
When the library is being created by CMake itself I would have expected
a SONAME by default:
Default is to set soname on all shared libraries and modules as long as
the platform supports it.
Is armLinux a valid value for CMAKE_SYSTEM_NAME?
4) Submission times are an hour out. Daylight savings time is not being
applied somewhere... any clues where I should look?
Add
'ini_set('date.timezone', 'CEST');'
to your
cdash/config.local.php
and fill in your local timezone abbreviation string or 'UTC+-x'(here
CEST ≘ Central European
4) Submission times are an hour out. Daylight savings time is not being
applied somewhere... any clues where I should look?
Add
'ini_set('date.timezone', 'CEST');'
to your
cdash/config.local.php
and fill in your local timezone abbreviation string or 'UTC+-x'(here
CEST ≘ Central European
Hi,
In Unix shell we can do that:
$ VAR=foo cmd in out
This way the environment variable is only set in the environment of the
process of the command and not the in current shell like when using the
export built-in.
I would like to be able to do the same for a custom command in CMake.
Ideally I
Hi,
On Fri, Jul 19, 2013 at 4:37 PM, Nicolas Desprès
nicolas.desp...@gmail.comwrote:
Hi,
In Unix shell we can do that:
$ VAR=foo cmd in out
This way the environment variable is only set in the environment of the
process of the command and not the in current shell like when using the
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 2d0d2138bd1ed05a6b3522f7cb0739b2c71b190e (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 82e110fc1b16ec6dd3c7e31dc95638fd36e66f14 (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 ee4b951bd45a68c5f81715d33b4139bde4932fe8 (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 55de65e7179782b252ea803b3087d6df59da9d28 (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 3f5d8ca1a663d1ad4142944a668080ff452a5788 (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 f4e1a8b164d7f732037dff909d70602106a3b21a (commit)
via
Stamp
diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 3a519b0..5150a8e 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 11)
-set(CMake_VERSION_TWEAK 20130719
29 matches
Mail list logo
