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 directory>/Debug and /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 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 /Debug and /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 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
Re: [CMake] xcode project and static library dependencies
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. > - 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. > - 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. -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
