I'm trying to use CMake with an admittedly odd toolchain (Adobe's Alchemy
project) and it's failing at configure time while detecting the C/C++ ABI info
with the error CMake Error: Could not COPY_FILE
I'm sure this is a bug in the toolchain and not CMake, but I'm not sure how to
diagnose it.
Run cmake with --debug-trycompile.
Oddly, with --debug-trycompile the problem goes away (!) and CMakeErrors.log
doesn't have any mention of try compile failing.
aaron
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
Oddly, with --debug-trycompile the problem goes away (!) and
CMakeErrors.log doesn't have any mention of try compile failing.
Start with a clean build tree, the problem did not go away. It would
have worked with just a second run.
Actually, I did start with a clean tree (rm -rf *).
Actually, I did start with a clean tree (rm -rf *).
If you start with a clean tree again but without --debug-trycompile it works?
If I start with a clean tree without --debug-trycompile it fails (could not
COPY_FILE). If I start with a clean tree with --debug-trycompile it will
succeed.
I am using swig in cmake to create a JNI wrapper around a C++ library.
Everything is working fine, however I would like to jar up all the
swig-generated java files. I'm not sure how to do it.
My project looks more or less like this:
cmake_minimum_required(VERSION 2.8)
Ah, the bug didn't say that it had been released yet, just that it was in cvs.
Sorry for the trouble. Thanks!
From: David Cole [mailto:david.c...@kitware.com]
Sent: Tuesday, March 30, 2010 7:59
To: Simmons, Aaron
Cc: cmake@cmake.org
Subject: Re: [CMake] working around gcc version bug in xocde
My project requires using gcc 4.0 when compiling on Mac OS X, as it has to
support 10.4. This works fine for the makefile generator, but it breaks with
the XCode generator for Xcode 3.2 as the default gcc is v4.2.
Other posts on this list indicates that it's a bug in the Xcode generator. I
It is a common misconception that one needs to use the 10.4 SDK to
create an executable that is compatible with 10.4. This is not so.
In most cases, you're right. However, we're linking to the iconv library. If
we don't specify the 10.4 SDK via isysroot, it will link to the wrong version
What I don't understand is this: Why do you want to force the SDK? Shouldn't
this be the worry of the person doing the build?
If I download some open-source software and then build it for myself,
I don't want to be forced in using the 10.4 SDK, I wan't to build against the
greatest and latest!
When compiled on Mac OS X, my project links against the 10.4 SDK. This SDK is
often not installed by default on newer systems (10.6, for example). I would
like to put in a check for whether the SDK is present before compiling
(otherwise the developer gets all kinds of hard-to-understand
While it will compile, the resulting binary needs to be compatible with 10.4.
-Original Message-
From: Sean McBride [mailto:s...@rogue-research.com]
Sent: Friday, March 26, 2010 12:35
To: Simmons, Aaron; cmake@cmake.org
Subject: Re: [CMake] find_library and mac os x SDKs
On Fri, 26 Mar
Actually, it's a framework. The docs say find_library will work with
frameworks (which are also folders). E.g., find_library(carbon Carbon) will
work.
From: David Cole [mailto:david.c...@kitware.com]
Sent: Friday, March 26, 2010 13:15
To: Simmons, Aaron
Cc: cmake@cmake.org
Subject: Re: [CMake
Probably not working because the 10.4u SDK is not is any standard
location like /Library/Frameworks or /System/library/Frameworks. You
may have to add the additional argument to add another search path.
Actually, that doesn't work either. I think its because it has an .sdk
extension and not
Is there a problem with just using if(EXISTS like I suggested in my first
reply?
That's what I ended up doing and it works:
macro( set_osx_sysroot)
if (NOT EXISTS ${ARGV0})
message(FATAL_ERROR Could not find ${ARGV0}.)
endif (NOT EXISTS ${ARGV0})
Due to historical development reasons, source file properties
are scoped only in the directory where they are set. Only
targets created by an add_exectuable, add_library, or
add_custom_target commands in the *same* directory (not even
a subdirectory) can see the property of a source file.
Use a full path name instead, and the source file
property will stick to that full path name.
I've changed the CMakeLists to use the full file path as suggested, but it
doesn't work. Am I missing something? The code is below...
Top-level CMakeLists.txt:
I have some flags I need to set for certain builds on a single source file.
For single-configuration generators (make, nmake) it's easy enough to look at
CMAKE_BUILD_TYPE and use set_source_files_properties, like this:
if (CMAKE_BUILD_TYPE STREQUAL Debug)
I'm having trouble using set_source_files_properties from a subdirectory. Say
I have a top-level CMakeLists.txt like this:
cmake_minimum_required(VERSION 2.8)
project(test)
add_subdirectory(subdir)
get_source_file_property( temp subdir/test.c COMPILE_FLAGS )
I am trying to use cmake v2.8.0 on Windows XP to link a library. On Mac OS X
and Linux, it works. But on Windows I get a very strange error:
C:\strawberry\c\bin\ld.exe: /lib: No such file: No such file or
directory
The only thing I can think of is that this is some kind of reference
To: cmake@cmake.org
Subject: Re: [CMake] windows link error
On 04.03.10 17:08:32, Simmons, Aaron wrote:
I am trying to use cmake v2.8.0 on Windows XP to link a library. On Mac OS X
and Linux, it works. But on Windows I get a very strange error:
C:\strawberry\c\bin\ld.exe: /lib: No such file
[mailto:cmake-boun...@cmake.org] On Behalf Of
Andreas Pakulat
Sent: Thursday, March 04, 2010 15:39
To: cmake@cmake.org
Subject: Re: [CMake] windows link error
On 04.03.10 17:27:56, Simmons, Aaron wrote:
You're right-- msvc uses link; I was thinking of gcc's ld. I guess the
question is why
21 matches
Mail list logo
