On Thursday, September 22, 2011 03:00:33 PM Rolf Eike Beer wrote:
On Thursday, September 22, 2011 01:52:51 PM Rolf Eike Beer wrote:
From 3f500a5c655cc4c12ecf6f774602b2a10cae0365 Mon Sep 17 00:00:00
2001
From: Rolf Eike Beer e...@sf-mail.de
Date: Thu, 22 Sep 2011 13:48:15 +0200
Tell
From: Nicolas Despres nicolas.desp...@gmail.com
Make it a static method instead of an array. It is safer for the
type checking and if we add a new target type we will be warned to add
a case to the switch.
+ case cmTarget::UNKNOWN_LIBRARY:
+return UNKNOWN_LIBRARY;
+//
This provides a mechanism for the local generator to override how
library search paths are generated.
---
Source/cmLocalGenerator.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Source/cmLocalGenerator.h b/Source/cmLocalGenerator.h
index 1f5a26e..69e452b 100644
On 09/27/2011 04:00 PM, Rolf Eike Beer wrote:
This provides a mechanism for the local generator to override how
library search paths are generated.
---
Source/cmLocalGenerator.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Source/cmLocalGenerator.h
On 09/27/2011 02:19 PM, Brad King wrote:
On 9/26/2011 11:48 PM, Peter Collingbourne wrote:
Now that the Ninja generator is passing all tests on Linux, I have
decided to start preparing patches, and I am starting with some
refactorings and bug fixes developed in the course of developing the
On 9/27/2011 10:34 AM, Michael Wild wrote:
On 09/27/2011 02:19 PM, Brad King wrote:
Please expand the commit message in patch 7 to
elaborate on the specific problems it fixes. That looks like a real bug
fix rather than just refactoring. I guess no one has been using per-config
link flags.
On Tue, Sep 27, 2011 at 3:55 PM, Rolf Eike Beer e...@sf-mail.de wrote:
From: Nicolas Despres nicolas.desp...@gmail.com
Make it a static method instead of an array. It is safer for the
type checking and if we add a new target type we will be warned to add
a case to the switch.
+ case
Hello everybody,
I would like to use cpack in order to gather a set of executables (built
statically) into a single archive that could be extracted everywhere the
user wants.
My project architecture is the following:
collections\
CMakeLists.txt
prog1\
CMakeLists.txt + source
Second message for the list
2011/9/27 pellegrini pellegr...@ill.fr:
Hello everybody,
I would like to use cpack in order to gather a set of executables (built
statically) into a single archive that could be extracted everywhere the
user wants.
My project architecture is the following:
Eric Noulard a écrit :
2011/9/27 pellegrini pellegr...@ill.fr:
Hi Eric,
thanks for your quick answer.
No, my subprojects do not contains any CPack directives neither include
cpack. Should they ?
Sorry my fingers slipped.
Another message is coming to the list.
You need an INSTALL
Hi,
I'm testing the new feature described in this comment of the ticket in
http://www.cmake.org/Bug/view.php?id=11517
I have pushed a fix for this to next. To test you will have to build CMake
from git next branch source. If you can do that, please let me know if it
works for youheck for working
Hi,
in my project there is a subfolder which SHALL contain sources to
generate a library. The problem is that at startup of the project there
are no source files existing, because they will be generated by a code
generator. This means within the build process the code generator needs
to be
On 09/27/2011 05:59 PM, Martin Kupke wrote:
Hi,
in my project there is a subfolder which SHALL contain sources to
generate a library. The problem is that at startup of the project there
are no source files existing, because they will be generated by a code
generator. This means within the
Using the Xcode generator, the FOLDER property of targets appears to do
nothing. Is this behavior simply a function a Xcode not supporting
groupings of targets or will support be added in 2.8.6?
Thanks,
Steve
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
I've run into a situation where find_library is returning a symlink:
/usr/lib/libblah.so - libblah.so.1
but libblah.so.1 does not actually exist (e.g. the symlink is bad).
Is there an option I can set to have find_library ensure that a found
library file is valid and links?
Cheers,
CY
--
On 09/28/2011 02:44 AM, Clifford Yapp wrote:
I've run into a situation where find_library is returning a symlink:
/usr/lib/libblah.so - libblah.so.1
but libblah.so.1 does not actually exist (e.g. the symlink is bad).
Is there an option I can set to have find_library ensure that a found
On Wed, Sep 28, 2011 at 12:13 AM, Michael Wild them...@gmail.com wrote:
On 09/28/2011 02:44 AM, Clifford Yapp wrote:
I've run into a situation where find_library is returning a symlink:
/usr/lib/libblah.so - libblah.so.1
but libblah.so.1 does not actually exist (e.g. the symlink is
Michael Wild wrote:
On 09/28/2011 02:44 AM, Clifford Yapp wrote:
I've run into a situation where find_library is returning a symlink:
/usr/lib/libblah.so - libblah.so.1
but libblah.so.1 does not actually exist (e.g. the symlink is bad).
Is there an option I can set to have
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 8751cb9bbaa17902a9ffe30b18cfc2f1c7dce25c (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 ef8cc9997cab748098bab52caf1ca038f90ec826 (commit)
from
20 matches
Mail list logo
