Xcode does not rebuild app when source file updated in dependent static library

Originator:rsfinn
Number:rdar://12535282 Date Originated:19-Oct-2012 11:28 AM
Status:Duplicate/8836361 (Closed) Resolved:Closed
Product:Xcode Product Version:4.5.1 (4G1004)
Classification:Serious Bug Reproducible:Yes
 
Summary:
Xcode fails to rebuild an application when a static library on which it depends is rebuilt because its source code is updated.  The expectation is that the implicit dependency tracking should detect this case.  Although the static library does get rebuilt, this does not trigger a relink of the application.

Steps to Reproduce:
The problem is illustrated by the attached sample workspace ("LibraryBug"), which contains an application project ("DepBugApp") and a static library project ("DepBugLib"). The application calls a library function (DBLHelloer::hello()) to obtain the text of a message to display.
1) Open LibraryBug.xcworkspace; build and run the application. Observe that this behaves properly; the application displays the text message that is returned by the library function.
2) In the file LibraryBug/Library/DepBugLib/DBLHelloer.cpp, locate the DBLHelloer::hello() function and edit the string literal (for example, change the word "Hello" to "Goodbye").
3) Build and run the application again.

Expected Results:
The application should now display the modified message.  Xcode should rebuild the library, then relink the application before running it.

Actual Results:
The application displays the previous version of the message.  Examining the build transcript shows that although Xcode has recompiled the modified source file and rebuilt the static library, it has failed to update the application by relinking it with the updated library.

Regression:
Unknown. Anecdotally, I found a mention of a very similar issue in a posting to the xcode-users mailing list in April 2012; the exact version of Xcode is not mentioned, but I would guess it is probably 4.3.2.  I am not aware of an Xcode version which handles this situation properly.

Notes:
I understand this is not a common usage pattern, but it corresponds to the code structure used at my new employer, where I am porting an existing Visual Studio code base to the Mac (hence the use of C++ as well as static libraries). Regardless, it seems that it should work properly, and there is no obvious workaround short of cleaning and rebuilding from scratch.

Comments

Thank you rsfinn for your report.

I actually had to manually update the project.pbxproj, look for the name of my library and update the line where path and sourceTree are present. I set sourceTree to BUILT_PRODUCTS_DIR as you mentioned, and path to the file name of my library.

By philippe.bernery at Nov. 7, 2012, 4:57 p.m. (reply...)

Workaround: Set location of library's file reference to "Relative to Build Products"

I have found a partial workaround, but I still believe there is a bug in Xcode.

When adding the static library to the application target by using the Add button in the Link Binary With Libraries build phase, I find that the library is added to the application's project with its location (in the File Inspector) set to "Relative to Group". Manually changing this setting to "Relative to Build Products" seems to work around the problem: in other words, editing a source file in the library, followed by a Build and Run command with the application project's scheme active, causes Xcode to rebuild the library and then correctly relink the application.

In my investigation of this issue on the Internet, I've now found other references to this issue and potential workaround. Some people believe it is necessary to manually edit the project.pbxproj file and change the "sourceTree" setting in the file references to be BUILT_PRODUCTS_DIR; I have not found this necessary. However, I think the fact that the reference to the static library is not being made relative to the build products library when it is initially added to the application project is a bug in Xcode (since it leads to the incorrect behavior initially reported).


Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!