Re: [cmake-developers] [CMake] xcode project and static library dependencies
Nick,
We are using a modification on your patch internally.
Few things
1) It breaks projects that have resources. Fix is to attach the Executable
to only the 'copy to cmake build dir' phase. Even after the mailinglist
discussion I'm unsure of the need for this?
XCode basically claims it is a recursive dependency as the executable file
is added as a depenency on the Copy Files phase.
2) POST_BUILD targets stopped working. Re-added the code that uses those
(Before the copy-files target, maybe it should be after? I Really don't
understand the copy to cmake build dir phase.
Attached the original Patch from Nick modified to work with lastest git
master + two fixes mentioned above.
/Johan
On Sun, Feb 20, 2011 at 2:43 PM, Johan Björk p...@spotify.com wrote:
Hi Nick,
Any updates on this patch?
Cheers
/Johan
On Thu, Jan 20, 2011 at 2:08 AM, Nick Kledzik kled...@apple.com wrote:
BTW, it might make more sense to move this to the cmake-developers
mailing list.
I've transfered this thread to the developer list. See below for
continuation..
On Jan 18, 2011, at 12:42 PM, Bill Hoffman wrote:
On 1/18/2011 2:40 PM, Brad King wrote:
On 1/18/2011 2:12 PM, Nick Kledzik wrote:
When I use cmake to create a Makefile, the resulting main executable
is placed in the build directory tree next to the Makefile.
This is where CMake puts files in single-configuration generators.
When I use cmake to create a xcode project, the resulting main
executable is placed in a subdirectory named Debug of the build
directory tree.
This is where CMake puts files in multi-configuration generators.
Both of the above are expected default behaviors. Both can be
changed by CMake properties like RUNTIME_OUTPUT_DIRECTORY and
its per-configuration equivalent. All CMake generators must
honor these.
None of these locations are the native location
where Xcode would put a build result.
Xcode has settings like CONFIGURATION_BUILD_DIR to control
where the build outputs go. This already works. Is there
some reason your changes cannot use these?
My understanding is that the main problem with the current generator
is all the extra build phases and OTHER_LDFLAGS stuff used to deal
with link line ordering and static libraries. This is what Bill
summarized:
On 1/13/2011 3:41 PM, Bill Hoffman wrote:
- have a static library show up more than once on a link line
- be able to specify the order of static libraries on the link line
- be able to relink and executable when a static library that it
depends on is rebuilt.
I'm more interested in a solution to implementation issues like these
than in interface details like where output files go.
-Brad
So, for Xcode and VS IDE, CMake will place things in directories like
Debug, Release.
For example, you should get something like this:
${RUNTIME_OUTPUT_DIRECTORY}/Debug/myexe
Xcode does support building multiple configurations like Debug, Release,
etc. Where is the native location for those files?
As I said, it is per-user xcode settings. You cannot infer the location
from source tree cmake has access to.
At build time, the location is known within xcode. So, I added a
copy-file phase to have xocde copy the resulting binary from the native
location to the standard location the cmake expects. There is little
overhead for this.
I've now have a patch which:
1) preserves link order
2) builds libraries into the xcode native location
4) removes pre and post shell script phases previously used to fix
dependency problems
3) xcode projects now have proper dependencies
WIth this cmake patch, I can build CMake.xcodeproject, open it in xcode,
build-all, set the current target to be cmake, make a source change, hit
build, and have xcode just compile that one file, re-archive the library,
then re-link cmake tool. I also debugged all this in Xcode by setting
arguments for the cmake tool and hitting the build-and-debug within xcode!
Attached is the patch from cmake-2.8.3 sources:
This cmake also creates an xcode project that builds LLVM. It is still
not quite optimal because there are a bunch of cases where custom rules
cause a custom make file to be generated which is executed from within xcode
via a shell script phase. Xcode does not now which files the script might
modify, so xcode has to be conservative and re-check all timestamps. There
are ways to add custom scripts with specified input and output files in
xcode. I may get to fixing that someday...
How does one run the test suite? I saw the instructions about building
cmake for make, then executing make Experimental. I did that and all 184
or 184 tests passed. But it looks like this is running the cmake generated
makefiles - not cmake generated xcode projects.
-Nick
___
cmake-developers mailing list
cmake-developers@cmake.org
Re: [cmake-developers] [CMake] xcode project and static library dependencies
and wow, the patch I just sent is broken because cmXCodeObject-Print() has
sideffects! :(
Will send a patch that fixes -Print() when I have some extra time.
/Johan
On Mon, Mar 7, 2011 at 1:33 PM, Johan Björk p...@spotify.com wrote:
Nick,
We are using a modification on your patch internally.
Few things
1) It breaks projects that have resources. Fix is to attach the Executable
to only the 'copy to cmake build dir' phase. Even after the mailinglist
discussion I'm unsure of the need for this?
XCode basically claims it is a recursive dependency as the executable file
is added as a depenency on the Copy Files phase.
2) POST_BUILD targets stopped working. Re-added the code that uses those
(Before the copy-files target, maybe it should be after? I Really don't
understand the copy to cmake build dir phase.
Attached the original Patch from Nick modified to work with lastest git
master + two fixes mentioned above.
/Johan
On Sun, Feb 20, 2011 at 2:43 PM, Johan Björk p...@spotify.com wrote:
Hi Nick,
Any updates on this patch?
Cheers
/Johan
On Thu, Jan 20, 2011 at 2:08 AM, Nick Kledzik kled...@apple.com wrote:
BTW, it might make more sense to move this to the cmake-developers
mailing list.
I've transfered this thread to the developer list. See below for
continuation..
On Jan 18, 2011, at 12:42 PM, Bill Hoffman wrote:
On 1/18/2011 2:40 PM, Brad King wrote:
On 1/18/2011 2:12 PM, Nick Kledzik wrote:
When I use cmake to create a Makefile, the resulting main executable
is placed in the build directory tree next to the Makefile.
This is where CMake puts files in single-configuration generators.
When I use cmake to create a xcode project, the resulting main
executable is placed in a subdirectory named Debug of the build
directory tree.
This is where CMake puts files in multi-configuration generators.
Both of the above are expected default behaviors. Both can be
changed by CMake properties like RUNTIME_OUTPUT_DIRECTORY and
its per-configuration equivalent. All CMake generators must
honor these.
None of these locations are the native location
where Xcode would put a build result.
Xcode has settings like CONFIGURATION_BUILD_DIR to control
where the build outputs go. This already works. Is there
some reason your changes cannot use these?
My understanding is that the main problem with the current generator
is all the extra build phases and OTHER_LDFLAGS stuff used to deal
with link line ordering and static libraries. This is what Bill
summarized:
On 1/13/2011 3:41 PM, Bill Hoffman wrote:
- have a static library show up more than once on a link line
- be able to specify the order of static libraries on the link line
- be able to relink and executable when a static library that it
depends on is rebuilt.
I'm more interested in a solution to implementation issues like these
than in interface details like where output files go.
-Brad
So, for Xcode and VS IDE, CMake will place things in directories like
Debug, Release.
For example, you should get something like this:
${RUNTIME_OUTPUT_DIRECTORY}/Debug/myexe
Xcode does support building multiple configurations like Debug,
Release, etc. Where is the native location for those files?
As I said, it is per-user xcode settings. You cannot infer the location
from source tree cmake has access to.
At build time, the location is known within xcode. So, I added a
copy-file phase to have xocde copy the resulting binary from the native
location to the standard location the cmake expects. There is little
overhead for this.
I've now have a patch which:
1) preserves link order
2) builds libraries into the xcode native location
4) removes pre and post shell script phases previously used to fix
dependency problems
3) xcode projects now have proper dependencies
WIth this cmake patch, I can build CMake.xcodeproject, open it in xcode,
build-all, set the current target to be cmake, make a source change, hit
build, and have xcode just compile that one file, re-archive the library,
then re-link cmake tool. I also debugged all this in Xcode by setting
arguments for the cmake tool and hitting the build-and-debug within xcode!
Attached is the patch from cmake-2.8.3 sources:
This cmake also creates an xcode project that builds LLVM. It is still
not quite optimal because there are a bunch of cases where custom rules
cause a custom make file to be generated which is executed from within xcode
via a shell script phase. Xcode does not now which files the script might
modify, so xcode has to be conservative and re-check all timestamps. There
are ways to add custom scripts with specified input and output files in
xcode. I may get to fixing that someday...
How does one run the test suite? I saw the instructions about building
cmake for make, then executing make Experimental. I did that and all 184
or 184 tests passed. But it
Re: [cmake-developers] [CMake] xcode project and static library dependencies
Hi Nick,
Any updates on this patch?
Cheers
/Johan
On Thu, Jan 20, 2011 at 2:08 AM, Nick Kledzik kled...@apple.com wrote:
BTW, it might make more sense to move this to the cmake-developers
mailing list.
I've transfered this thread to the developer list. See below for
continuation..
On Jan 18, 2011, at 12:42 PM, Bill Hoffman wrote:
On 1/18/2011 2:40 PM, Brad King wrote:
On 1/18/2011 2:12 PM, Nick Kledzik wrote:
When I use cmake to create a Makefile, the resulting main executable
is placed in the build directory tree next to the Makefile.
This is where CMake puts files in single-configuration generators.
When I use cmake to create a xcode project, the resulting main
executable is placed in a subdirectory named Debug of the build
directory tree.
This is where CMake puts files in multi-configuration generators.
Both of the above are expected default behaviors. Both can be
changed by CMake properties like RUNTIME_OUTPUT_DIRECTORY and
its per-configuration equivalent. All CMake generators must
honor these.
None of these locations are the native location
where Xcode would put a build result.
Xcode has settings like CONFIGURATION_BUILD_DIR to control
where the build outputs go. This already works. Is there
some reason your changes cannot use these?
My understanding is that the main problem with the current generator
is all the extra build phases and OTHER_LDFLAGS stuff used to deal
with link line ordering and static libraries. This is what Bill
summarized:
On 1/13/2011 3:41 PM, Bill Hoffman wrote:
- have a static library show up more than once on a link line
- be able to specify the order of static libraries on the link line
- be able to relink and executable when a static library that it
depends on is rebuilt.
I'm more interested in a solution to implementation issues like these
than in interface details like where output files go.
-Brad
So, for Xcode and VS IDE, CMake will place things in directories like
Debug, Release.
For example, you should get something like this:
${RUNTIME_OUTPUT_DIRECTORY}/Debug/myexe
Xcode does support building multiple configurations like Debug, Release,
etc. Where is the native location for those files?
As I said, it is per-user xcode settings. You cannot infer the location
from source tree cmake has access to.
At build time, the location is known within xcode. So, I added a copy-file
phase to have xocde copy the resulting binary from the native location to
the standard location the cmake expects. There is little overhead for this.
I've now have a patch which:
1) preserves link order
2) builds libraries into the xcode native location
4) removes pre and post shell script phases previously used to fix
dependency problems
3) xcode projects now have proper dependencies
WIth this cmake patch, I can build CMake.xcodeproject, open it in xcode,
build-all, set the current target to be cmake, make a source change, hit
build, and have xcode just compile that one file, re-archive the library,
then re-link cmake tool. I also debugged all this in Xcode by setting
arguments for the cmake tool and hitting the build-and-debug within xcode!
Attached is the patch from cmake-2.8.3 sources:
This cmake also creates an xcode project that builds LLVM. It is still not
quite optimal because there are a bunch of cases where custom rules cause a
custom make file to be generated which is executed from within xcode via a
shell script phase. Xcode does not now which files the script might modify,
so xcode has to be conservative and re-check all timestamps. There are ways
to add custom scripts with specified input and output files in xcode. I may
get to fixing that someday...
How does one run the test suite? I saw the instructions about building
cmake for make, then executing make Experimental. I did that and all 184
or 184 tests passed. But it looks like this is running the cmake generated
makefiles - not cmake generated xcode projects.
-Nick
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] xcode project and static library dependencies
BTW, it might make more sense to move this to the cmake-developers mailing
list.
I've transfered this thread to the developer list. See below for continuation..
On Jan 18, 2011, at 12:42 PM, Bill Hoffman wrote:
On 1/18/2011 2:40 PM, Brad King wrote:
On 1/18/2011 2:12 PM, Nick Kledzik wrote:
When I use cmake to create a Makefile, the resulting main executable
is placed in the build directory tree next to the Makefile.
This is where CMake puts files in single-configuration generators.
When I use cmake to create a xcode project, the resulting main
executable is placed in a subdirectory named Debug of the build
directory tree.
This is where CMake puts files in multi-configuration generators.
Both of the above are expected default behaviors. Both can be
changed by CMake properties like RUNTIME_OUTPUT_DIRECTORY and
its per-configuration equivalent. All CMake generators must
honor these.
None of these locations are the native location
where Xcode would put a build result.
Xcode has settings like CONFIGURATION_BUILD_DIR to control
where the build outputs go. This already works. Is there
some reason your changes cannot use these?
My understanding is that the main problem with the current generator
is all the extra build phases and OTHER_LDFLAGS stuff used to deal
with link line ordering and static libraries. This is what Bill
summarized:
On 1/13/2011 3:41 PM, Bill Hoffman wrote:
- have a static library show up more than once on a link line
- be able to specify the order of static libraries on the link line
- be able to relink and executable when a static library that it
depends on is rebuilt.
I'm more interested in a solution to implementation issues like these
than in interface details like where output files go.
-Brad
So, for Xcode and VS IDE, CMake will place things in directories like Debug,
Release.
For example, you should get something like this:
${RUNTIME_OUTPUT_DIRECTORY}/Debug/myexe
Xcode does support building multiple configurations like Debug, Release, etc.
Where is the native location for those files?
As I said, it is per-user xcode settings. You cannot infer the location from
source tree cmake has access to.
At build time, the location is known within xcode. So, I added a copy-file
phase to have xocde copy the resulting binary from the native location to the
standard location the cmake expects. There is little overhead for this.
I've now have a patch which:
1) preserves link order
2) builds libraries into the xcode native location
4) removes pre and post shell script phases previously used to fix dependency
problems
3) xcode projects now have proper dependencies
WIth this cmake patch, I can build CMake.xcodeproject, open it in xcode,
build-all, set the current target to be cmake, make a source change, hit
build, and have xcode just compile that one file, re-archive the library, then
re-link cmake tool. I also debugged all this in Xcode by setting arguments for
the cmake tool and hitting the build-and-debug within xcode!
Attached is the patch from cmake-2.8.3 sources:
cmake-xcode.patch
Description: Binary data
This cmake also creates an xcode project that builds LLVM. It is still not
quite optimal because there are a bunch of cases where custom rules cause a
custom make file to be generated which is executed from within xcode via a
shell script phase. Xcode does not now which files the script might modify, so
xcode has to be conservative and re-check all timestamps. There are ways to
add custom scripts with specified input and output files in xcode. I may get
to fixing that someday...
How does one run the test suite? I saw the instructions about building cmake
for make, then executing make Experimental. I did that and all 184 or 184
tests passed. But it looks like this is running the cmake generated makefiles
- not cmake generated xcode projects.
-Nick
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] xcode project and static library dependencies
On Wed, Jan 19, 2011 at 8:08 PM, Nick Kledzik kled...@apple.com wrote:
BTW, it might make more sense to move this to the cmake-developers mailing
list.
I've transfered this thread to the developer list. See below for
continuation..
On Jan 18, 2011, at 12:42 PM, Bill Hoffman wrote:
On 1/18/2011 2:40 PM, Brad King wrote:
On 1/18/2011 2:12 PM, Nick Kledzik wrote:
When I use cmake to create a Makefile, the resulting main executable
is placed in the build directory tree next to the Makefile.
This is where CMake puts files in single-configuration generators.
When I use cmake to create a xcode project, the resulting main
executable is placed in a subdirectory named Debug of the build
directory tree.
This is where CMake puts files in multi-configuration generators.
Both of the above are expected default behaviors. Both can be
changed by CMake properties like RUNTIME_OUTPUT_DIRECTORY and
its per-configuration equivalent. All CMake generators must
honor these.
None of these locations are the native location
where Xcode would put a build result.
Xcode has settings like CONFIGURATION_BUILD_DIR to control
where the build outputs go. This already works. Is there
some reason your changes cannot use these?
My understanding is that the main problem with the current generator
is all the extra build phases and OTHER_LDFLAGS stuff used to deal
with link line ordering and static libraries. This is what Bill
summarized:
On 1/13/2011 3:41 PM, Bill Hoffman wrote:
- have a static library show up more than once on a link line
- be able to specify the order of static libraries on the link line
- be able to relink and executable when a static library that it
depends on is rebuilt.
I'm more interested in a solution to implementation issues like these
than in interface details like where output files go.
-Brad
So, for Xcode and VS IDE, CMake will place things in directories like Debug,
Release.
For example, you should get something like this:
${RUNTIME_OUTPUT_DIRECTORY}/Debug/myexe
Xcode does support building multiple configurations like Debug, Release,
etc. Where is the native location for those files?
As I said, it is per-user xcode settings. You cannot infer the location from
source tree cmake has access to.
At build time, the location is known within xcode. So, I added a copy-file
phase to have xocde copy the resulting binary from the native location to
the standard location the cmake expects. There is little overhead for this.
I am still not sure why you need the extra copy. That is a concern.
If Xcode were to put things in a predictable place, we could just
have CMake look there, just like in VS when we look in the Debug,
Release, etc, directories.
I've now have a patch which:
1) preserves link order
2) builds libraries into the xcode native location
4) removes pre and post shell script phases previously used to fix dependency
problems
3) xcode projects now have proper dependencies
That sounds great.
WIth this cmake patch, I can build CMake.xcodeproject, open it in xcode,
build-all, set the current target to be cmake, make a source change, hit
build, and have xcode just compile that one file, re-archive the library,
then re-link cmake tool. I also debugged all this in Xcode by setting
arguments for the cmake tool and hitting the build-and-debug within xcode!
Attached is the patch from cmake-2.8.3 sources:
This cmake also creates an xcode project that builds LLVM. It is still not
quite optimal because there are a bunch of cases where custom rules cause a
custom make file to be generated which is executed from within xcode via a
shell script phase. Xcode does not now which files the script might modify,
so xcode has to be conservative and re-check all timestamps. There are ways
to add custom scripts with specified input and output files in xcode. I may
get to fixing that someday...
How does one run the test suite? I saw the instructions about building cmake
for make, then executing make Experimental. I did that and all 184 or 184
tests passed. But it looks like this is running the cmake generated
makefiles - not cmake generated xcode projects.
To run the tests, do this:
1. build your modified CMake
2. build a second CMake with the one from step 1, with -GXcode
3. run ./bin/Release/ctest -C Release from the binary tree of CMake.
That will use the Xcode generator for the tests, also will verify that
CMake itself can be built with your modified CMake.
So, something like this:
mkdir CMakeTest; cd CMakeTest
/path/to/your/modified/cmake/bin/cmake -GXcode ../CMake
/path/to/your/modified/cmake/bin/cmake --build . --config Release
./bin/Release/ctest
-Bill
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] xcode project and static library dependencies
On Mon, Jan 17, 2011 at 9:02 PM, Nick Kledzik kled...@apple.com wrote: On Jan 13, 2011, at 1:57 PM, Bill Hoffman wrote: On 1/13/2011 4:49 PM, Nick Kledzik wrote: On Jan 13, 2011, at 12:41 PM, Bill Hoffman wrote: This is because Xcode provides no way to order static libraries as far as I can tell, or to repeat them. Also, no way to depend on a static library or a file directly, forcing the makefile usage. This may have changed, so, if you can so native Xcode projects that can do the following we can change cmake: - have a static library show up more than once on a link line This is unnecessary. Unlike most unix linkers, the Xcode linker repeatedly iterators over all archives on the command line. You never need to add the same archive more than once on the command line. That was not true when I implemented this the first time. We have a test in CMake that counts on library ordering and it failed. - be able to specify the order of static libraries on the link line The order that the libraries appear in the PBXFrameworksBuildPhase is the order that they are passed to the linker. OK, sounds good... - be able to relink an executable when a static library that it depends on is rebuilt. This is normal behavior for the Xccde build system. If one target depends on the product of another target, the build system follows the chain and builds everything needed for the target requested to be built. If you can get all the CMake tests to pass with these changes, I would be very happy to get rid of the extra stuff. It may have changed, but when I first did the implementation, it was required to do it the way it is. That said, I have not revisited this stuff since Xcode 1.5, so things may have changed for the better. I have changes that cause cmake to produce an Xcode project in which the targets do not have the extra phases, and the dependencies are set up such that incremental builds work efficiently! But I'm having some impedance mismatches between where Xcode want the build results to be and where cmake wants them. Xcode (like many makefiles) has the concept of a normal build and an install build. But when cmake runs it builds some test programs using the xcodebuild command line, but does not specify the install action but then expects to find the resulting executable in the install location. I'm sure I could change TryCompileCode() to add install to the xcodebuild line, but it seems like lots of other cmake scripts will have the same expectations. I playing with trying to get Xcode to always do an install. I tried creating xcode projects with the initial (not install) locations being where cmake wants them, but xcode seems to not do the internal dependency analysis properly when the intermediate results are not within BUILD_PRODUCTS_DIR. What is the cmake model for where the results of a build go? Putting the results where the native tool expects them is fine. CMake makes no guarantees about where build products go. If a native tool has no expectations, we try to hide build results underneath the CMakeFiles/ directories in the build tree to avoid cluttering a developer's view of the build tree with stuff they mostly don't need to see... I don't think there are any hard requirements w.r.t. build products locations. Although where libraries and executables end up is important for the CMake generated install rules to work. Feel free to change things around experimentally if that makes it easy to work with newer Xcode versions. The test suite will very likely tell us if things have gone awry. Thanks for your effort on this, David Cole Kitware, Inc. -Nick ___ 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 subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ 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 subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] xcode project and static library dependencies
I have changes that cause cmake to produce an Xcode project in which the targets do not have the extra phases, and the dependencies are set up such that incremental builds work efficiently! But I'm having some impedance mismatches between where Xcode want the build results to be and where cmake wants them. Xcode (like many makefiles) has the concept of a normal build and an install build. But when cmake runs it builds some test programs using the xcodebuild command line, but does not specify the install action but then expects to find the resulting executable in the install location. I'm sure I could change TryCompileCode() to add install to the xcodebuild line, but it seems like lots of other cmake scripts will have the same expectations. I playing with trying to get Xcode to always do an install. I tried creating xcode projects with the initial (not install) locations being where cmake wants them, but xcode seems to not do the internal dependency analysis properly when the intermediate results are not within BUILD_PRODUCTS_DIR. What is the cmake model for where the results of a build go? Putting the results where the native tool expects them is fine. CMake makes no guarantees about where build products go. If a native tool has no expectations, we try to hide build results underneath the CMakeFiles/ directories in the build tree to avoid cluttering a developer's view of the build tree with stuff they mostly don't need to see... I don't think there are any hard requirements w.r.t. build products locations. Although where libraries and executables end up is important for the CMake generated install rules to work. Feel free to change things around experimentally if that makes it easy to work with newer Xcode versions. The test suite will very likely tell us if things have gone awry. That is not entirely true Things like EXECUTABLE_OUTPUT_PATH and target location properties have to work without an extra install step. What do you mean CMake expects to find things in install locations? CMake does need to be able to find executables after the build is run. It also needs to be able to place them via location properties. -Bill ___ 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 subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] xcode project and static library dependencies
Clarification: I was referring to intermediate build product files, not final libraries and executables. For the most part, nobody should care where their intermediate files are as long as everything works. Sorry for the mis-communication. On Tue, Jan 18, 2011 at 8:30 AM, Bill Hoffman bill.hoff...@kitware.comwrote: I have changes that cause cmake to produce an Xcode project in which the targets do not have the extra phases, and the dependencies are set up such that incremental builds work efficiently! But I'm having some impedance mismatches between where Xcode want the build results to be and where cmake wants them. Xcode (like many makefiles) has the concept of a normal build and an install build. But when cmake runs it builds some test programs using the xcodebuild command line, but does not specify the install action but then expects to find the resulting executable in the install location. I'm sure I could change TryCompileCode() to add install to the xcodebuild line, but it seems like lots of other cmake scripts will have the same expectations. I playing with trying to get Xcode to always do an install. I tried creating xcode projects with the initial (not install) locations being where cmake wants them, but xcode seems to not do the internal dependency analysis properly when the intermediate results are not within BUILD_PRODUCTS_DIR. What is the cmake model for where the results of a build go? Putting the results where the native tool expects them is fine. CMake makes no guarantees about where build products go. If a native tool has no expectations, we try to hide build results underneath the CMakeFiles/ directories in the build tree to avoid cluttering a developer's view of the build tree with stuff they mostly don't need to see... I don't think there are any hard requirements w.r.t. build products locations. Although where libraries and executables end up is important for the CMake generated install rules to work. Feel free to change things around experimentally if that makes it easy to work with newer Xcode versions. The test suite will very likely tell us if things have gone awry. That is not entirely true Things like EXECUTABLE_OUTPUT_PATH and target location properties have to work without an extra install step. What do you mean CMake expects to find things in install locations? CMake does need to be able to find executables after the build is run. It also needs to be able to place them via location properties. -Bill ___ 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 subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] xcode project and static library dependencies
On Jan 18, 2011, at 5:30 AM, Bill Hoffman wrote: I have changes that cause cmake to produce an Xcode project in which the targets do not have the extra phases, and the dependencies are set up such that incremental builds work efficiently! But I'm having some impedance mismatches between where Xcode want the build results to be and where cmake wants them. Xcode (like many makefiles) has the concept of a normal build and an install build. But when cmake runs it builds some test programs using the xcodebuild command line, but does not specify the install action but then expects to find the resulting executable in the install location. I'm sure I could change TryCompileCode() to add install to the xcodebuild line, but it seems like lots of other cmake scripts will have the same expectations. I playing with trying to get Xcode to always do an install. I tried creating xcode projects with the initial (not install) locations being where cmake wants them, but xcode seems to not do the internal dependency analysis properly when the intermediate results are not within BUILD_PRODUCTS_DIR. What is the cmake model for where the results of a build go? Putting the results where the native tool expects them is fine. CMake makes no guarantees about where build products go. If a native tool has no expectations, we try to hide build results underneath the CMakeFiles/ directories in the build tree to avoid cluttering a developer's view of the build tree with stuff they mostly don't need to see... I don't think there are any hard requirements w.r.t. build products locations. Although where libraries and executables end up is important for the CMake generated install rules to work. Feel free to change things around experimentally if that makes it easy to work with newer Xcode versions. The test suite will very likely tell us if things have gone awry. That is not entirely true Things like EXECUTABLE_OUTPUT_PATH and target location properties have to work without an extra install step. What do you mean CMake expects to find things in install locations? CMake does need to be able to find executables after the build is run. It also needs to be able to place them via location properties. Take for example a simple test case that just builds one source file into an executable via ADD_EXECUTABLE(main main.c) When I use cmake to create a Makefile, the resulting main executable is placed in the build directory tree next to the Makefile. When I use cmake to create a xcode project, the resulting main executable is placed in a subdirectory named Debug of the build directory tree. The method cmCoreTryCompile::FindOutputFile() seems to know about this because it looks for executables in the build directory then in build directory/Debug and build directory/Release. None of these locations are the native location where Xcode would put a build result. So, I need to create xcode projects that place/copy the resulting executables somewhere that cmake universe expects. Now I am wondering if I should add a copy-files-phase in the executable target to copy the resulting binary to the build directory. That would make xcode output be like Makefile output. -Nick ___ 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 subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] xcode project and static library dependencies
On Tue, Jan 18, 2011 at 2:12 PM, Nick Kledzik kled...@apple.com wrote: On Jan 18, 2011, at 5:30 AM, Bill Hoffman wrote: I have changes that cause cmake to produce an Xcode project in which the targets do not have the extra phases, and the dependencies are set up such that incremental builds work efficiently! But I'm having some impedance mismatches between where Xcode want the build results to be and where cmake wants them. Xcode (like many makefiles) has the concept of a normal build and an install build. But when cmake runs it builds some test programs using the xcodebuild command line, but does not specify the install action but then expects to find the resulting executable in the install location. I'm sure I could change TryCompileCode() to add install to the xcodebuild line, but it seems like lots of other cmake scripts will have the same expectations. I playing with trying to get Xcode to always do an install. I tried creating xcode projects with the initial (not install) locations being where cmake wants them, but xcode seems to not do the internal dependency analysis properly when the intermediate results are not within BUILD_PRODUCTS_DIR. What is the cmake model for where the results of a build go? Putting the results where the native tool expects them is fine. CMake makes no guarantees about where build products go. If a native tool has no expectations, we try to hide build results underneath the CMakeFiles/ directories in the build tree to avoid cluttering a developer's view of the build tree with stuff they mostly don't need to see... I don't think there are any hard requirements w.r.t. build products locations. Although where libraries and executables end up is important for the CMake generated install rules to work. Feel free to change things around experimentally if that makes it easy to work with newer Xcode versions. The test suite will very likely tell us if things have gone awry. That is not entirely true Things like EXECUTABLE_OUTPUT_PATH and target location properties have to work without an extra install step. What do you mean CMake expects to find things in install locations? CMake does need to be able to find executables after the build is run. It also needs to be able to place them via location properties. Take for example a simple test case that just builds one source file into an executable via ADD_EXECUTABLE(main main.c) When I use cmake to create a Makefile, the resulting main executable is placed in the build directory tree next to the Makefile. When I use cmake to create a xcode project, the resulting main executable is placed in a subdirectory named Debug of the build directory tree. The method cmCoreTryCompile::FindOutputFile() seems to know about this because it looks for executables in the build directory then in build directory/Debug and build directory/Release. None of these locations are the native location where Xcode would put a build result. So, I need to create xcode projects that place/copy the resulting executables somewhere that cmake universe expects. Now I am wondering if I should add a copy-files-phase in the executable target to copy the resulting binary to the build directory. That would make xcode output be like Makefile output. -Nick Where does the Xcode equivalent of add_executable(main main.c) naturally go? ___ 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 subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] xcode project and static library dependencies
On Jan 18, 2011, at 11:23 AM, David Cole wrote: That is not entirely true Things like EXECUTABLE_OUTPUT_PATH and target location properties have to work without an extra install step. What do you mean CMake expects to find things in install locations? CMake does need to be able to find executables after the build is run. It also needs to be able to place them via location properties. Take for example a simple test case that just builds one source file into an executable via ADD_EXECUTABLE(main main.c) When I use cmake to create a Makefile, the resulting main executable is placed in the build directory tree next to the Makefile. When I use cmake to create a xcode project, the resulting main executable is placed in a subdirectory named Debug of the build directory tree. The method cmCoreTryCompile::FindOutputFile() seems to know about this because it looks for executables in the build directory then in build directory/Debug and build directory/Release. None of these locations are the native location where Xcode would put a build result. So, I need to create xcode projects that place/copy the resulting executables somewhere that cmake universe expects. Now I am wondering if I should add a copy-files-phase in the executable target to copy the resulting binary to the build directory. That would make xcode output be like Makefile output. -Nick Where does the Xcode equivalent of add_executable(main main.c) naturally go? It depends on some global xcode settings. Some users have a one location in which all projects put their final projects. Some users have a build/Debug and build/Release directory next to the xcode project file. That is why I'm thinking that if cmake's model is to have the final executable put into cmakes build directory, that I should just let xcode build it where the user wants, then copy it to where cmake wants. That way both models are happy. -Nick ___ 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 subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] xcode project and static library dependencies
On Tue, Jan 18, 2011 at 2:30 PM, Nick Kledzik kled...@apple.com wrote: On Jan 18, 2011, at 11:23 AM, David Cole wrote: That is not entirely true Things like EXECUTABLE_OUTPUT_PATH and target location properties have to work without an extra install step. What do you mean CMake expects to find things in install locations? CMake does need to be able to find executables after the build is run. It also needs to be able to place them via location properties. Take for example a simple test case that just builds one source file into an executable via ADD_EXECUTABLE(main main.c) When I use cmake to create a Makefile, the resulting main executable is placed in the build directory tree next to the Makefile. When I use cmake to create a xcode project, the resulting main executable is placed in a subdirectory named Debug of the build directory tree. The method cmCoreTryCompile::FindOutputFile() seems to know about this because it looks for executables in the build directory then in build directory/Debug and build directory/Release. None of these locations are the native location where Xcode would put a build result. So, I need to create xcode projects that place/copy the resulting executables somewhere that cmake universe expects. Now I am wondering if I should add a copy-files-phase in the executable target to copy the resulting binary to the build directory. That would make xcode output be like Makefile output. -Nick Where does the Xcode equivalent of add_executable(main main.c) naturally go? It depends on some global xcode settings. Some users have a one location in which all projects put their final projects. Some users have a build/Debug and build/Release directory next to the xcode project file. That is why I'm thinking that if cmake's model is to have the final executable put into cmakes build directory, that I should just let xcode build it where the user wants, then copy it to where cmake wants. That way both models are happy. -Nick CMake, unless told otherwise, should produce an identical build tree to the native tool when possible. I think the way we do it now (by default) is a direct reflection of the fact that Xcode used to do it that way back in the day... when the Xcode generator was first produced. I don't think changing the default value of the output location is a problem for people. But we do have to honor EXECUTABLE_OUTPUT_PATH and the new CMAKE_RUNTIME_OUTPUT_DIRECTORY and all of the variants thereof that people might be setting in their CMakeLists files. ___ 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 subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] xcode project and static library dependencies
On 1/18/2011 2:12 PM, Nick Kledzik wrote: When I use cmake to create a Makefile, the resulting main executable is placed in the build directory tree next to the Makefile. This is where CMake puts files in single-configuration generators. When I use cmake to create a xcode project, the resulting main executable is placed in a subdirectory named Debug of the build directory tree. This is where CMake puts files in multi-configuration generators. Both of the above are expected default behaviors. Both can be changed by CMake properties like RUNTIME_OUTPUT_DIRECTORY and its per-configuration equivalent. All CMake generators must honor these. None of these locations are the native location where Xcode would put a build result. Xcode has settings like CONFIGURATION_BUILD_DIR to control where the build outputs go. This already works. Is there some reason your changes cannot use these? My understanding is that the main problem with the current generator is all the extra build phases and OTHER_LDFLAGS stuff used to deal with link line ordering and static libraries. This is what Bill summarized: On 1/13/2011 3:41 PM, Bill Hoffman wrote: - have a static library show up more than once on a link line - be able to specify the order of static libraries on the link line - be able to relink and executable when a static library that it depends on is rebuilt. I'm more interested in a solution to implementation issues like these than in interface details like where output files go. -Brad ___ 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 subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] xcode project and static library dependencies
On 1/18/2011 2:40 PM, Brad King wrote:
On 1/18/2011 2:12 PM, Nick Kledzik wrote:
When I use cmake to create a Makefile, the resulting main executable
is placed in the build directory tree next to the Makefile.
This is where CMake puts files in single-configuration generators.
When I use cmake to create a xcode project, the resulting main
executable is placed in a subdirectory named Debug of the build
directory tree.
This is where CMake puts files in multi-configuration generators.
Both of the above are expected default behaviors. Both can be
changed by CMake properties like RUNTIME_OUTPUT_DIRECTORY and
its per-configuration equivalent. All CMake generators must
honor these.
None of these locations are the native location
where Xcode would put a build result.
Xcode has settings like CONFIGURATION_BUILD_DIR to control
where the build outputs go. This already works. Is there
some reason your changes cannot use these?
My understanding is that the main problem with the current generator
is all the extra build phases and OTHER_LDFLAGS stuff used to deal
with link line ordering and static libraries. This is what Bill
summarized:
On 1/13/2011 3:41 PM, Bill Hoffman wrote:
- have a static library show up more than once on a link line
- be able to specify the order of static libraries on the link line
- be able to relink and executable when a static library that it
depends on is rebuilt.
I'm more interested in a solution to implementation issues like these
than in interface details like where output files go.
-Brad
So, for Xcode and VS IDE, CMake will place things in directories like
Debug, Release.
For example, you should get something like this:
${RUNTIME_OUTPUT_DIRECTORY}/Debug/myexe
Xcode does support building multiple configurations like Debug, Release,
etc. Where is the native location for those files?
I don't think we want an extra copy stage.
BTW, it might make more sense to move this to the cmake-developers
mailing list.
http://www.cmake.org/cmake/help/mailing.html
-Bill
___
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 subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] xcode project and static library dependencies
On Jan 13, 2011, at 1:57 PM, Bill Hoffman wrote: On 1/13/2011 4:49 PM, Nick Kledzik wrote: On Jan 13, 2011, at 12:41 PM, Bill Hoffman wrote: This is because Xcode provides no way to order static libraries as far as I can tell, or to repeat them. Also, no way to depend on a static library or a file directly, forcing the makefile usage. This may have changed, so, if you can so native Xcode projects that can do the following we can change cmake: - have a static library show up more than once on a link line This is unnecessary. Unlike most unix linkers, the Xcode linker repeatedly iterators over all archives on the command line. You never need to add the same archive more than once on the command line. That was not true when I implemented this the first time. We have a test in CMake that counts on library ordering and it failed. - be able to specify the order of static libraries on the link line The order that the libraries appear in the PBXFrameworksBuildPhase is the order that they are passed to the linker. OK, sounds good... - be able to relink an executable when a static library that it depends on is rebuilt. This is normal behavior for the Xccde build system. If one target depends on the product of another target, the build system follows the chain and builds everything needed for the target requested to be built. If you can get all the CMake tests to pass with these changes, I would be very happy to get rid of the extra stuff. It may have changed, but when I first did the implementation, it was required to do it the way it is. That said, I have not revisited this stuff since Xcode 1.5, so things may have changed for the better. I have changes that cause cmake to produce an Xcode project in which the targets do not have the extra phases, and the dependencies are set up such that incremental builds work efficiently! But I'm having some impedance mismatches between where Xcode want the build results to be and where cmake wants them. Xcode (like many makefiles) has the concept of a normal build and an install build. But when cmake runs it builds some test programs using the xcodebuild command line, but does not specify the install action but then expects to find the resulting executable in the install location. I'm sure I could change TryCompileCode() to add install to the xcodebuild line, but it seems like lots of other cmake scripts will have the same expectations. I playing with trying to get Xcode to always do an install. I tried creating xcode projects with the initial (not install) locations being where cmake wants them, but xcode seems to not do the internal dependency analysis properly when the intermediate results are not within BUILD_PRODUCTS_DIR. What is the cmake model for where the results of a build go? -Nick ___ 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 subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] xcode project and static library dependencies
I'm a long time Xcode user and recently used cmake to create an Xcode project for LLVM. I really like the idea the CMake can produce native projects for different platforms, but in my case, the resulting xcode project was very slow to use. To investigate, I created a small cmake example project with a static library and a main executable that uses the library. The generated Xcode project does not encode the static library as a link library of the main executable. Instead the static library is slipped in via OTHER_LDFLAGS. Thus, Xcode does not know that if a source file of the static library is changed, that the main executable needs to be relinked. The generated Xcode project also has extra shell script phases (CMake ReRun, and CMAKE PostBuild Rules). I'm not sure why they are there, but they slow down large builds (like llvm). But they do have the side effect of causing Xcode to re-evaluate the mod times of files, which in a way, compensates for missing static library dependency. I'd like to contribute to making the xcode project generator better, but would like to understand why the current implementation works as it does. -Nick ___ 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 subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] xcode project and static library dependencies
On 1/13/2011 3:16 PM, Nick Kledzik wrote: I'm a long time Xcode user and recently used cmake to create an Xcode project for LLVM. I really like the idea the CMake can produce native projects for different platforms, but in my case, the resulting xcode project was very slow to use. To investigate, I created a small cmake example project with a static library and a main executable that uses the library. The generated Xcode project does not encode the static library as a link library of the main executable. Instead the static library is slipped in via OTHER_LDFLAGS. Thus, Xcode does not know that if a source file of the static library is changed, that the main executable needs to be relinked. The generated Xcode project also has extra shell script phases (CMake ReRun, and CMAKE PostBuild Rules). I'm not sure why they are there, but they slow down large builds (like llvm). But they do have the side effect of causing Xcode to re-evaluate the mod times of files, which in a way, compensates for missing static library dependency. I'd like to contribute to making the xcode project generator better, but would like to understand why the current implementation works as it does. This is because Xcode provides no way to order static libraries as far as I can tell, or to repeat them. Also, no way to depend on a static library or a file directly, forcing the makefile usage. This may have changed, so, if you can so native Xcode projects that can do the following we can change cmake: - have a static library show up more than once on a link line - be able to specify the order of static libraries on the link line - be able to relink and executable when a static library that it depends on is rebuilt. -Bill ___ 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 subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] xcode project and static library dependencies
On 1/13/2011 4:49 PM, Nick Kledzik wrote: On Jan 13, 2011, at 12:41 PM, Bill Hoffman wrote: This is because Xcode provides no way to order static libraries as far as I can tell, or to repeat them. Also, no way to depend on a static library or a file directly, forcing the makefile usage. This may have changed, so, if you can so native Xcode projects that can do the following we can change cmake: - have a static library show up more than once on a link line This is unnecessary. Unlike most unix linkers, the Xcode linker repeatedly iterators over all archives on the command line. You never need to add the same archive more than once on the command line. That was not true when I implemented this the first time. We have a test in CMake that counts on library ordering and it failed. - be able to specify the order of static libraries on the link line The order that the libraries appear in the PBXFrameworksBuildPhase is the order that they are passed to the linker. OK, sounds good... - be able to relink an executable when a static library that it depends on is rebuilt. This is normal behavior for the Xccde build system. If one target depends on the product of another target, the build system follows the chain and builds everything needed for the target requested to be built. If you can get all the CMake tests to pass with these changes, I would be very happy to get rid of the extra stuff. It may have changed, but when I first did the implementation, it was required to do it the way it is. That said, I have not revisited this stuff since Xcode 1.5, so things may have changed for the better. -Bill ___ 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 subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
