Re: OBJROOT and SYMROOT in Xcode 4?
Re: OBJROOT and SYMROOT in Xcode 4?
- Subject: Re: OBJROOT and SYMROOT in Xcode 4?
- From: Kai Brüning <email@hidden>
- Date: Mon, 04 Apr 2011 23:14:16 +0200
On 4.4.2011, at 20:28, Quincey Morris wrote:
> On Apr 4, 2011, at 10:14, Christiaan Hofman wrote:
>
>> Thanks, I was not aware of that. Though it's still weird that the project/workspace itself does point to it anywhere, even though it's using it.
>
> I think it's consistent with a trend to make the intermediate derived products more private to Xcode, and less interesting to the developer.
>
>> And it is still true that the build settings do NOT point to the actual location that is used (in contradiction to your description.)
>
> I found that the *macros* pointed to the correct places, so that (e.g.) script phases referencing $SYMROOT do the right thing. At least, I think that's what I saw -- I didn't investigate very deeply.
Yes, they indeed do. Thanks a lot for the hint, I didn’t even check after seeing the wrong values in the build settings panel.
>
> You just won't see the actual macro values in the build settings editor. Again, that's consistent with such things having become more private to Xcode -- in a sense, those build settings don't exist any more (with default preferences), although the macros do still exist. Aren't there a lot of other macros that, similarly, have some relationship to build settings but aren't actually *in* the build settings?
I strongly disagree with the claim that this could be "consistent". Check for instance the build setting "Build Products Path". Quick Help reveals that this is nothing else but SYMROOT. In a newly created Xcode 4 project the build settings panel will show the value "build", which is the relative path to a build directory alongside the project file. But if you echo ${SYMROOT} from a script phase, it does indeed contain the location used by Xcode 4 inside the user’s library. Hard to reason that the display in build settings is not a bug.
I also disagree that it might be the right direction to make these location more and more private to Xcode. I don’t care too much about the intermediates location (at least not currently), but it is absolutely necessary to have access to the build products location for a variety of reasons. One example is the need to inject a library for unit testing.
>
>> Moreover, I cannot confirm what you say about incomplete build products in these DerivedData folders. For me they're always complete, including for Debug builds. So if you're really getting incomplete build products, I think you either have aproblem ion building, or you're running into a bug.
>
> I left out a piece of information that I'd forgotten in my fumbling around.
>
> This situation I described involves embedded private frameworks. There's a Copy Files build phase that copies them into the app bundle. Currently, that build phase is set to run only "when installing".
>
> In that case, the *only* Xcode operation I could find that ran the phase was 'Archive' -- not 'Build For Archive', nothing else. Presumably, that's because in Xcode 4 "build" means "build" and not "build and install".
>
> If I change the build phase to run all the time, my app bundle is (IIRC) complete, but the copying also gets done for Debug builds (and for Release builds where I don't care, like profiling). That's why I chose "when installing".
>
> There could well be a bug there or a deficiency in my understanding.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden