Marcus D. Hanwell wrote:
But if you are advising just updating docs, then go for it.
I entirely echo Dave's words here - I thought you meant more of an
active warning against using it at runtime/producing errors.
Well, actually I did mean runtime warnings. The documentation changes
Hi,
I think I saw somewhere in one of the threads something about being able to
set target properties before the target has been defined.
Is this the case or did I misunderstand something ?
If it's the case, then I have a few questions regarding this.
Is this scheduled for 2.8.11 ?
What
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13926
==
Reported By:Greg Sharp
Assigned To:
On 02/15/2013 03:03 PM, Alexander Neundorf wrote:
I think I saw somewhere in one of the threads something about being able to
set target properties before the target has been defined.
Is this the case or did I misunderstand something ?
I don't remember that coming up. You may be mixing it
On Friday 15 February 2013, Brad King wrote:
On 02/15/2013 03:03 PM, Alexander Neundorf wrote:
I think I saw somewhere in one of the threads something about being able
to set target properties before the target has been defined.
Is this the case or did I misunderstand something ?
I
On 02/15/2013 04:37 PM, Alexander Neundorf wrote:
So is it possible to refer to not-yet-defined targets from tll(), and what
happens if they get not defined later on ?
This works at it always has. If the named item does not resolve to a
target name at generate time it is treated as a raw
On Friday 15 February 2013, Brad King wrote:
On 02/15/2013 04:37 PM, Alexander Neundorf wrote:
So is it possible to refer to not-yet-defined targets from tll(), and
what happens if they get not defined later on ?
This works at it always has. If the named item does not resolve to a
target
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13927
==
Reported By:Christopher Mullins
Assigned To:
Hi all,
for the question above I found different answers on the web, so I'm puzzled
and wanted to know an authoritative answer from the cmake gurus.
What I found:
http://www.vtk.org/Wiki/CMake_Cross_Compiling#Information_how_to_set_up_various_cross_compiling_toolchains
= On mixed 32/64 bit Linux
The *easiest* way is to use a virtual machine.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to
Can you share a bit more context? I suspect there may be no single
correct answer, as it depends on your situation what the best way is. If
you are using a toolchain file you will have to put the decision of
using that file outside of your cmake file. You can also opt to put a
check inside your
On Friday 15 February 2013 12:11:27 m. hergarden wrote:
Can you share a bit more context? I suspect there may be no single
correct answer, as it depends on your situation what the best way is.
I have a 64bit Linux server (RHEL5), which automatically builds our software
every night
(triggered
Does that result in building the code 3 times?
And why would you need to repeat the install directives?
I've attached a CMakeLists.txt file for an example project that works for me
without repeating install directives.
Clint
- Original Message -
Here's a follow-up.
I was unable
Hello,
On 15/02/13 15:41, Martin Koller wrote:
I'm just not sure if it is enough to change the compiler flags or if
there is more to change (paths etc.)
This is why I prefer toolchain files over adding an option inside the
CMakeLists.txt files. On some systems you probably also want to change
Or simply specify -m32 at the first configure
CFLAGS=-m32 CXXFLAGS=-m32 cmake ../src
find_library() works correctly if you do that, and it automatically detects if
the 32 bit libraries are in /usr/lib32 or /usr/lib.
Clint
- Original Message -
Hello,
On 15/02/13 15:41, Martin
What I have done in the past is the -m32 flag to the CMAKE_CXX_FLAGS and all of
the search paths were updated automatically. You just need to add the flag
when you CMake for the first time. I did this on CentOS 5.8 x64 without any
problems.
Keith
-Original Message-
From:
Hi guys,
I am trying to install the CMake Nightly
*
http://www.cmake.org/files/dev/cmake-2.8.10.20130213-g7665b-Darwin-universal.dmg
*
*
*
But it fails saying that a newer version of CMake exists (CMake 2.8.10
stable). I deleted the application bundle and the cmake links in /usr/bin/
but it still
Hi Folks,
For reference: A similar issue regarding XCode 4.5.X as been submitted and
resolved - See http://cmake.org/Bug/view.php?id=13765
May be something change with XCode 4.6
Jc
On Fri, Feb 15, 2013 at 10:39 AM, Daniel Haehn
daniel.ha...@childrens.harvard.edu wrote:
Hi guys,
I am
Are FindTIFF.cmake and FindJPEG.cmake really old and neglected?
Neither seems to bother looking at TIFF_DIR or JPEG_DIR -- you have to set
TIFF_LIBRARY and TIFF_INCLUDE_DIR (or JPEG_LIBRARY and JPEG_INCLUDE_DIR).
find_package is a great facility but I find myself having to look at the
actual
It is true, I actually never had problems just adding -m32 on my
machines, but I assumed some systems are more difficult than others..
But what do I know? :)
Cheers,
Yngve
On 15/02/13 16:33, clin...@elemtech.com wrote:
Or simply specify -m32 at the first configure
CFLAGS=-m32 CXXFLAGS=-m32
On Thursday 14 February 2013, Shaun Williams wrote:
I'm slowly realizing the gravity of this behavior:
if(build_system STREQUAL windows)
...
endif()
If someone creates a variable named windows, then this code will not work
as intended.
I'm starting to convert our scripts to use this
Hi Daniel,
The issue has been re-opened. Can you reproduce the problem using the toy
project referenced here: http://www.cmake.org/Bug/view.php?id=13765#c32292
Thanks
Jc
On Fri, Feb 15, 2013 at 10:56 AM, Jean-Christophe Fillion-Robin
jchris.filli...@kitware.com wrote:
Hi Folks,
For
Hi JC,
well - right now I don't have CMake at all due to the installation issue :/
Cheers,
Daniel
On Fri, Feb 15, 2013 at 1:36 PM, Jean-Christophe Fillion-Robin
jchris.filli...@kitware.com wrote:
Hi Daniel,
The issue has been re-opened. Can you reproduce the problem using the
toy
Hi Daniel,
Simply get the latest tar.gz
For example:
curl -O
http://www.cmake.org/files/dev/cmake-2.8.10.20130105-ga4e06-Darwin64-universal.tar.gz
tar -xzvf cmake-2.8.10.20130105-ga4e06-Darwin64-universal.tar.gz
Hth
Jc
On Fri, Feb 15, 2013 at 1:50 PM, Daniel Haehn
We have an existing deployment of a large amount of internal software on
Linux using custom build and link tools that expect a certain naming
layout. We're porting it over to OS X and to be consistent we want to
name shared libraries with the Linux style, that is, libOpenImageIO.so.32.
On 02/15/2013 01:02 PM, Blair Zajac wrote:
We have an existing deployment of a large amount of internal software on
Linux using custom build and link tools that expect a certain naming
layout. We're porting it over to OS X and to be consistent we want to
name shared libraries with the Linux
Hi,
I'm sure I just overlooked something, but I can not get shared libraries (at a
non system location) to load properly at runtime after having had them linked
properly.
If I run otool -L the library is listed without any path or loader reference:
dylibLinkTest:
libiomp5.dylib
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 c1dc80749440febf41c24329e0276e733a7220f2 (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 3a393cb2da1b744598da23bc01592a910c728c18 (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 bc6b0326b3016f6ffb10f7d9f5e6b8608f28c77e (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 ffdf57d9f5f0fc6c64e3c4ec32cc7630576770ab (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 e85f1c28d4e709bf468cd1d146f71d528f408582 (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 5698d9b86549d1252d5748e818dec1530c7a4296 (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 4c9003b32c4755519b054b2e84c396c13528c04a (commit)
via
Stamp
diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 99e87ea..b45d7d3 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 20130215
35 matches
Mail list logo
