Brad King wrote:
Part of the value of COMPILE_OPTIONS is supposed to be that it
takes a ;-list of options and escapes each one appropriately.
You'll have to go back and fix up the generators or cmTarget's
GetCompileOptions method to use lg-EscapeForShell when appending
each flag.
I did
On 06/27/2013 03:35 AM, Stephen Kelly wrote:
Brad King wrote:
On 6/26/2013 12:24 PM, Stephen Kelly wrote:
I think the generated targets file will need to bump its
minimum required version of CMake if the policy is NEW
and the compatibility export option is not used. Otherwise
consuming
On 06/27/2013 05:28 AM, Stephen Kelly wrote:
Please post a snippet of cmake code showing the problems you are seeing so
that I can easily understand them.
Consider this code using CMake 2.8.11:
cmake_minimum_required(VERSION 2.8.11)
#...
add_library(foo SHARED foo.c)
Brad King wrote:
On 06/27/2013 05:28 AM, Stephen Kelly wrote:
Please post a snippet of cmake code showing the problems you are seeing
so that I can easily understand them.
Consider this code using CMake 2.8.11:
cmake_minimum_required(VERSION 2.8.11)
#...
add_library(foo SHARED
Brad King wrote:
though it may be sporadic.
One dashboard that passed after I changed it to use a SHARED library now
fails again.
http://open.cdash.org/buildSummary.php?buildid=2948465
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
On 06/27/2013 03:27 AM, Stephen Kelly wrote:
Brad King wrote:
Part of the value of COMPILE_OPTIONS is supposed to be that it
takes a ;-list of options and escapes each one appropriately.
You'll have to go back and fix up the generators or cmTarget's
GetCompileOptions method to use
On 6/27/2013 10:18 AM, Stephen Kelly wrote:
I went with the option of setting the INTERFACE_LINK_LIBRARIES
unconditionally in tll.
That's fine with me. It keeps things simpler internally.
Strictly speaking we should make it conditional on the
policy not being set to OLD, but it doesn't matter
Steve,
On 6/27/2013 10:34 AM, Brad King wrote:
Okay, this problem is a bit deeper than I thought.
I'm working on a topic to resolve it.
For now I reverted the compiler-version-genex topic to make room.
I will try to get my topic ready today.
I've merged a 'refactor-compile-options' to next
Hi,
there is a bug here: http://public.kitware.com/Bug/view.php?id=14123 , which
says that under Windows when using mingw .dll.a files should not be stripped
during install.
A patch is also attached, which keeps import libraries from being stripped
during install:
diff --git
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14250
==
Reported By:John Ralls
Assigned To:
On Wed, 26 Jun 2013 09:14:51 -0400, Brad King said:
though it may be sporadic. I cannot reproduce it on my OS X 10.8
machine. In the above-linked output one can see that Xcode does
not build the excludedFromAll target prior to the failure. In
my local build it does. Something is tricking your
On 06/27/2013 03:30 PM, Alexander Neundorf wrote:
- if(this-Target-GetType() == cmTarget::STATIC_LIBRARY)
+ if(this-Target-GetType() == cmTarget::STATIC_LIBRARY ||
this-ImportLibrary)
This looks reasonable to me, still I'd like to get some advice whether this
is
the right thing to do,
On 06/27/2013 03:57 PM, Sean McBride wrote:
So I opened the .xcodeproj with Xcode.app and I don't see any
excludedFromAll item in the 'scheme' popup. Do you?
In Xcode 4.5.2 on OS X 10.8 the test passes for me and I do
see excludedFromAll in the list of targets in the GUI.
Please send me your
Brad King wrote:
Steve,
On 6/27/2013 10:34 AM, Brad King wrote:
Okay, this problem is a bit deeper than I thought.
I'm working on a topic to resolve it.
For now I reverted the compiler-version-genex topic to make room.
I will try to get my topic ready today.
I've merged a
Brad King wrote:
On 6/27/2013 10:18 AM, Stephen Kelly wrote:
I went with the option of setting the INTERFACE_LINK_LIBRARIES
unconditionally in tll.
That's fine with me. It keeps things simpler internally.
Strictly speaking we should make it conditional on the
policy not being set to OLD,
Hei hei,
On Mon, May 13, 2013 at 06:17:58PM -0400, Matthew Woehlke wrote:
Another option to consider is keeping the file in an external
repository and using your VCS's external-repo support to bring it
into your other projects. This way the file exists in your source
tree, but your VCS is
Hei hei,
On Fri, May 17, 2013 at 11:09:11AM -0400, Robert Maynard wrote:
- target_link_libraries(myexe yourlib) can now build myexe sources
with requirements specified
Does this mean transitive linking between separate projects is possible?
Greets
Alex
--
»With the first link, the chain
Hi all,
I've setup a new build configuration called ReleaseLowOpt for a set of
projects we're developing. Currently I have all the linker / compiler
options being set, my problem comes when I'm determining the set of
libraries to specify on the link line and which directory to pull them
from.
I see that this CMake variable is not case-sensitive at it and defaults to
DEBUG.
I'm afraid this is incorrect; the default build type is empty. When you
build with Release, the flag NDEBUG is set; when you build with Debug the
DEBUG flag is set.
--
Powered by www.kitware.com
Visit other
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 268f97a02a305e63df46187b2210c0a764052498 (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 4dcab11e53b843fc01ad0d1ecc267e949292603e (commit)
via
21 matches
Mail list logo
