Added uninstalled products header search path to iOS. #5

Merged
merged 2 commits into from Feb 18, 2013

Projects

None yet

3 participants

@Coneko
Collaborator
Coneko commented Feb 9, 2013

Since the iOS configs set SKIP_INSTALL they should include the workaround for the Xcode being silly because of it.

@diederich
Collaborator

I have $(OBJROOT)/UninstalledProducts/include set in my Archive configs. IMHO this looks a bit less fragile than the $(BUILD_ROOT)/../IntermediateBuildFilesPath/ part.

I've also opened a bug a while ago rdar://2694401. It's still open and no comments so far :/

Besides that, I'm not sure if this should be set for all configurations. E.g. if you do an Archive build in the Release or Debug config, the headers of static libs get copied to the above path.
Afer that you continue with the default development cycle, CMD-R and such, so a normal build. While headers in the above directory won't get updated, they can still be reached via a normal include statement, possibly including non-existent or outdated headers.

My current solution to this is to have 2 more configurations, AdHoc and AppStore, which are basically the same as the Release-config. Those are only used for Archive builds and have only some minor adjustments. One is the additional include path given above. (the other is adjusting the bundle-identifier, so I can have beta, development and appstore versions installed in parallel).

@Coneko
Collaborator
Coneko commented Feb 9, 2013

@diederich I agree using OBJROOT is nicer.

Did you every trip in the situation you describe? OBJROOT points to the root Intermediates directory for the workspace in non-archive builds, and that one doesn't have an UninstalledProducts subdirectory on my machine.

@diederich
Collaborator

@Coneko Good call :-)
I actually don't remember I tripped in that situation and indeed, there's no UninstalledProducts subdirectory. So this should be safe.
I wondered if this will introduce a warning about the non-existent include directory, but at least for me it doesn't.
+1 for merging.

@Coneko
Collaborator
Coneko commented Feb 9, 2013

I was also surprised when it didn't trigger a warning, because I definitely saw warning for something similar to that (maybe it was only for -L and not -I). I'm glad it wasn't something wrong on my side.

@jspahrsummers
Owner

Thanks! 💥

@jspahrsummers jspahrsummers merged commit 39e464b into jspahrsummers:master Feb 18, 2013
@Coneko Coneko deleted the EnthusiasticCode:fix-archive-builds branch Feb 19, 2013
@diederich
Collaborator

FYI: I just had my rdar updated:
http://openradar.appspot.com/radar?id=2694401

@Coneko
Collaborator
Coneko commented Feb 21, 2013

Headers do not belong in the UninstalledProducts directory; only products belong there. We recommend that static libraries install their headers using a Copy Files build phase putting them in the Products Directory with a subpath of "include".

I guess Copy Headers is only meant for frameworks. It's weird because if I remember right it used to be enabled only on frameworks, but they changed that at some point.

I'd rather keep the same setup for OSX and iOS targets and add the uninstalled products headers search path though, even if it's unintended it seems cleaner this way.

@diederich
Collaborator

Yeah, that might be it.

http://cl.ly/image/3f2E0O3n3d1d seems to be what they suggest, and indeed, this works for Archive and normal builds. I guess I'll also leave my libs as they are, at least until it breaks again :-)


<rant>
It's quite frustrating. It somehow feels like this is a totally obscure problem to solve, but c'mon, static libraries :/ And it's not like we're alone running into those problems.
The interwebs is full of tutorials on how to do static libraries. Even dependency-management solutions think they can do a better job at configuring the build than to teach devs on how to create a proper xcode project. I'm not sure this is the right direction... (and, ofc, by ignoring the advice from the bug-report, we're part of the problem :-))
</rant>

@Coneko
Collaborator
Coneko commented Feb 21, 2013

It just occured to me that the advice is incomplete: you should copy the headers to $(PUBLIC_HEADERS_FOLDER_PATH) so it can be changed in the target's settings instead of hardcoding it.

@diederich
Collaborator

yeah, that probably makes sense.
To make this work, PUBLIC_HEADERS_FOLDER_PATH needs to be adjusted as well. The default /usr/local/include is not added to the default-header search paths so it should again be set to include or include/$(PRODUCT_NAME)

Another difference I just found is that headers copied via the "Copy Headers" build phase are removed on a clean-build, while those copied via "Copy Files" are not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment