View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0014768 | CMake | CMake | public | 2014-02-20 15:48 | 2016-06-10 14:31 | ||||
Reporter | Paul Smith | ||||||||
Assigned To | Kitware Robot | ||||||||
Priority | high | Severity | major | Reproducibility | always | ||||
Status | closed | Resolution | moved | ||||||
Platform | Apple | OS | Mac OS X | OS Version | 10.9.1 | ||||
Product Version | CMake 2.8.12.2 | ||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0014768: Using OBJECT libraries with Xcode causes incorrect builds | ||||||||
Description | I wanted to use an OBJECT library in order to build both a static and shared library from the same set of objects, across multiple directories. This works great with Makefiles and Visual Studio but fails with Xcode: the initial build works fine but if I then change a file and re-run the build it compiles the object file but does NOT update the libraries and executables that depend on it. | ||||||||
Steps To Reproduce | CMakeLists.txt: #---------- cmake_minimum_required(VERSION 2.8.12) project(CMTEST CXX) add_library(foo_OBJECTS OBJECT foo.cpp foo.h) add_library(foo SHARED dummy.cpp $<TARGET_OBJECTS:foo_OBJECTS>) add_dependencies(foo foo_OBJECTS) add_executable(hello hello.cpp) target_link_libraries(hello foo) #---------- Then create a trivial foo.cpp, foo.h, and hello.cpp. Run "cmake -G Xcode ." Run "xcodebuild build -configuration RelWithDebInfo" (or use "cmake -build" if you prefer). All builds and is fine. Now modify foo.cpp. Run "xcodebuild build -configuration RelWithDebInfo" again (or "cmake -build") Note that Xcode recompiles foo.o and updates libfoo_OBJECTS.a, _BUT_ it does NOT recreate libfoo.a and it does not re-link the hello program. | ||||||||
Additional Information | I've tried this with Xcode 4.6 and Xcode 5.0. I've tried it with CMake 2.8.12.2 and also with the latest CMake 3.0.0-rc1 from Git master; same behavior in all situations. | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | cmtest.tar.gz [^] (1,030 bytes) 2014-02-21 15:01 | ||||||||
Relationships | |
Relationships |
Notes | |
(0035163) Brad King (manager) 2014-02-20 16:05 |
I cannot reproduce this: $ cmake --version cmake version 2.8.12.1 $ sw_vers ProductName: Mac OS X ProductVersion: 10.9.1 BuildVersion: 13B42 $ xcodebuild -version Xcode 5.0.2 Build version 5A3005 $ mkdir b && cd b $ cmake .. -GXcode $ xcodebuild -configuration Debug ... Ld b/Debug/hello normal x86_64 ... $ xcodebuild -configuration Debug (nothing builds) $ touch ../foo.cpp $ xcodebuild -configuration Debug ... Ld b/Debug/hello normal x86_64 ... |
(0035165) Paul Smith (reporter) 2014-02-21 11:59 edited on: 2014-02-21 12:09 |
Wow, you're right it seems to work if you use a subdirectory!! Crazy. If I run this (mirroring what you did) it works for me: (rm -rf b && mkdir b && cd b \ && cmake .. -GXcode && xcodebuild -configuration Debug \ && sleep 2 && touch ../foo.cpp && echo "----------" \ && xcodebuild -configuration Debug 2>&1 | tee b.out | grep Ld) and I see the "Ld" linking "hello". But, if I change it to: (pwd=`pwd`; rm -rf ../b && mkdir ../b && cd ../b \ && cmake "$pwd" -GXcode && xcodebuild -configuration Debug \ && sleep 2 && touch ../foo.cpp && echo "----------" \ && xcodebuild -configuration Debug 2>&1 | tee b.out | grep Ld) then it fails as I describe above (no "Ld" output is seen and "hello" is not rebuilt). |
(0035166) Paul Smith (reporter) 2014-02-21 12:00 |
It actually also will fail if you build in the source directory itself, not using a separate binary directory (which is actually how our real setup works, for most people). |
(0035167) Brad King (manager) 2014-02-21 14:33 |
Re 0014768:0035165: It also works correctly for me in an in-source build or with a sibling build directory outside the source. Please attach a tarball of the exact source tree and build scripts you use to reproduce this. |
(0035168) Paul Smith (reporter) 2014-02-21 15:02 |
I've attached a tarball. You unpack and cd into it and run "./runtest". I've included the output of a sample run on my system ("./runtest > run.log 2>&1"): ---------- cmake version 2.8.12.1 ProductName: Mac OS X ProductVersion: 10.9.1 BuildVersion: 13B42 Xcode 5.0.2 Build version 5A3005 ---------- -- The CXX compiler identification is Clang 5.0.0 -- Check for working CXX compiler using: Xcode -- Check for working CXX compiler using: Xcode -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Configuring done -- Generating done -- Build files have been written to: /Users/psmith/src/cmake/b ---------- Ld /Users/psmith/src/cmake/b/Debug/libfoo.dylib normal x86_64 Ld /Users/psmith/src/cmake/b/Debug/hello normal x86_64 ---------- ---------- Note the empty content for the second run. |
(0035169) Paul Smith (reporter) 2014-02-21 15:05 |
Here's another run from another, older system: $ ./runtest ---------- cmake version 2.8.12.1 ProductName: Mac OS X ProductVersion: 10.7.4 BuildVersion: 11E53 Xcode 4.6 Build version 4H127 ---------- -- The CXX compiler identification is Clang 4.2.0 -- Check for working CXX compiler using: Xcode -- Check for working CXX compiler using: Xcode -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Configuring done -- Generating done -- Build files have been written to: /Users/build/pds/b ---------- Ld /Users/build/pds/b/Debug/libfoo.dylib normal x86_64 Ld /Users/build/pds/b/Debug/hello normal x86_64 ---------- ---------- |
(0035170) Paul Smith (reporter) 2014-02-21 15:06 |
Here's a run if I change the script to use a subdirectory "b" instead of "../b": $ ./runtest ---------- cmake version 2.8.12.1 ProductName: Mac OS X ProductVersion: 10.9.1 BuildVersion: 13B42 Xcode 5.0.2 Build version 5A3005 ---------- -- The CXX compiler identification is Clang 5.0.0 -- Check for working CXX compiler using: Xcode -- Check for working CXX compiler using: Xcode -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Configuring done -- Generating done -- Build files have been written to: /Users/psmith/src/cmake/objtest/b ---------- Ld b/Debug/libfoo.dylib normal x86_64 Ld b/Debug/hello normal x86_64 ---------- Ld b/Debug/libfoo.dylib normal x86_64 Ld b/Debug/hello normal x86_64 ---------- |
(0035171) Paul Smith (reporter) 2014-02-21 15:17 |
FWIW, here's a run using the latest master HEAD from a day or two ago: $ ./runtest ---------- cmake version 3.0.0-rc1 CMake suite maintained by Kitware, Inc. (kitware.com). ProductName: Mac OS X ProductVersion: 10.9.1 BuildVersion: 13B42 Xcode 5.0.2 Build version 5A3005 ---------- -- The CXX compiler identification is AppleClang 5.0.0.5000279 -- Check for working CXX compiler using: Xcode -- Check for working CXX compiler using: Xcode -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done CMake Warning (dev) at CMakeLists.txt:2 (project): Policy CMP0025 is not set: Compiler id for Apple Clang is now AppleClang. Run "cmake --help-policy CMP0025" for policy details. Use the cmake_policy command to set the policy and suppress this warning. Converting CXX compiler id "AppleClang" to "Clang" for compatibility. This warning is for project developers. Use -Wno-dev to suppress it. -- Configuring done CMake Warning (dev): Policy CMP0042 is not set: MACOSX_RPATH is enabled by default. Run "cmake --help-policy CMP0042" for policy details. Use the cmake_policy command to set the policy and suppress this warning. MACOSX_RPATH is not specified for the following targets: foo This warning is for project developers. Use -Wno-dev to suppress it. -- Generating done -- Build files have been written to: /Users/psmith/src/cmake/b ---------- Ld /Users/psmith/src/cmake/b/Debug/libfoo.dylib normal x86_64 Ld /Users/psmith/src/cmake/b/Debug/hello normal x86_64 ---------- ---------- |
(0035172) Brad King (manager) 2014-02-21 15:20 |
It works for me after I fix your runtest script to touch the proper file: - && sleep 2 && touch ../foo.cpp && echo "----------" \ + && sleep 2 && touch "$pwd/foo.cpp" && echo "----------" \ |
(0035173) Paul Smith (reporter) 2014-02-21 17:37 |
Bah. Hard to believe I was doing that the entire time but I can't seem to repro this with my example. Nevertheless, in my real environment this still fails: $ touch Foo/Index.cpp $ xcodebuild build -configuration RelWithDebInfo ... === BUILD TARGET Foo_OBJECTS OF PROJECT Proj WITH CONFIGURATION RelWithDebInfo === Check dependencies CompileC Foo/Proj.build/RelWithDebInfo/Foo_OBJECTS.build/Objects-normal/x86_64/Index.o Foo/Index.cpp normal x86_64 c++ com.apple.compilers.llvm.clang.1_0.compiler ... === BUILD TARGET Foo OF PROJECT Proj WITH CONFIGURATION RelWithDebInfo === Check dependencies === BUILD TARGET Bar OF PROJECT Proj WITH CONFIGURATION RelWithDebInfo === Check dependencies so it doesn't rebuild libFoo.a (apparently decides there's nothing to do) or anything that depends on libFoo.a. However, obviously something about my translation of my complex build system into the simple example here is flawed, I'll have to figure out how to get the repro case to fail. |
(0042492) Kitware Robot (administrator) 2016-06-10 14:29 |
Resolving issue as `moved`. This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page. |
Notes |
Issue History | |||
Date Modified | Username | Field | Change |
2014-02-20 15:48 | Paul Smith | New Issue | |
2014-02-20 16:05 | Brad King | Note Added: 0035163 | |
2014-02-21 11:59 | Paul Smith | Note Added: 0035165 | |
2014-02-21 12:00 | Paul Smith | Note Added: 0035166 | |
2014-02-21 12:09 | Paul Smith | Note Edited: 0035165 | |
2014-02-21 14:33 | Brad King | Note Added: 0035167 | |
2014-02-21 15:01 | Paul Smith | File Added: cmtest.tar.gz | |
2014-02-21 15:02 | Paul Smith | Note Added: 0035168 | |
2014-02-21 15:05 | Paul Smith | Note Added: 0035169 | |
2014-02-21 15:06 | Paul Smith | Note Added: 0035170 | |
2014-02-21 15:17 | Paul Smith | Note Added: 0035171 | |
2014-02-21 15:20 | Brad King | Note Added: 0035172 | |
2014-02-21 17:37 | Paul Smith | Note Added: 0035173 | |
2016-06-10 14:29 | Kitware Robot | Note Added: 0042492 | |
2016-06-10 14:29 | Kitware Robot | Status | new => resolved |
2016-06-10 14:29 | Kitware Robot | Resolution | open => moved |
2016-06-10 14:29 | Kitware Robot | Assigned To | => Kitware Robot |
2016-06-10 14:31 | Kitware Robot | Status | resolved => closed |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |