Look for strip in DT_TOOLCHAIN_DIR

Run strip via xcrun.

In Xcode 5, strip is no longer in SYSTEM_DEVELOPER_BIN_DIR. It is only in
DT_TOOLCHAIN_DIR. I also checked Xcode 4.6.1 and found that DT_TOOLCHAIN_DIR
was also set there, and strip is in both SYSTEM_DEVELOPER_BIN_DIR and
DT_TOOLCHAIN_DIR in that version.

Environment variables as set when Xcode is installed at /Applications/Xcode.app:

SYSTEM_DEVELOPER_BIN_DIR=/Applications/Xcode.app/Contents/Developer/usr/bin
DT_TOOLCHAIN_DIR=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefa
ult.xctoolchain

xcrun should be able to find strip without having to resort to manual
environment interpretation.

R=thakis@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=227787

[Nico, 2013-09-24 18:44:04]

Is it better to run `xcrun strip` instead?

[Mark Mentovai, 2013-09-24 18:49:16]

I’m still worried about finding xcrun, but it appears that in Xcode 5, that’s at
least still in SYSTEM_DEVELOPER_BIN_DIR.

[Nico, 2013-09-24 18:50:23]

On Tue, Sep 24, 2013 at 11:49 AM, <mark@chromium.org> wrote:

> I’m still worried about finding xcrun, but it appears that in Xcode 5,
> that’s at
> least still in SYSTEM_DEVELOPER_BIN_DIR.
>

I thought the point of xcrun is that one can rely on it just being in the
path / /usr/bin? (Might not with with 4.2 which the bots use tho?)


>
>
https://codereview.chromium.**org/24352006/<https://codereview.chromium.org/2...
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Mark Mentovai, 2013-09-24 18:51:50]

Even if there are no command-line tools installed?

[Nico, 2013-09-24 18:56:39]

On Tue, Sep 24, 2013 at 11:51 AM, <mark@chromium.org> wrote:

> Even if there are no command-line tools installed?
>

I thought so. I thought I read that xcrun was the way to call command-line
tools when they aren't installed (clang -> xcrun clang, etc) (the thinking
here seems to be changing again in xcode5, but xcrun should still be
around.)

I don't have a system without command-line tools around tho


>
>
https://codereview.chromium.**org/24352006/<https://codereview.chromium.org/2...
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Mark Mentovai, 2013-09-24 19:04:24]

Me neither, that’s perhaps why I assumed that xcrun was part of the command-line
tools installation.

[Mark Mentovai, 2013-09-24 19:08:22]

And this might be the thing we’ve seen where xcrun doesn’t actually work until
you’ve run xcode-select. I don’t have any virgin systems handy at the moment,
though.

I can put this on ice pending investigation if you’d prefer. As long as people
don’t upgrade to Xcode 5 and try building with Xcode, it’s probably not urgent.
Upgrading to Xcode 5 and building with ninja should be fine.

[Mark Mentovai, 2013-10-07 20:11:24]

Installing the 10.9 GM was a chance to look at this on a virgin machine. At
least there, xcrun exists prior to installing any Xcode or command-line tools,
and once Xcode is installed, even in the absence of tools, xcrun strip does
work. (And I didn’t even need to xcode-select to point it to /Applications.) So
on the theory that it works similarly in previous OS releases, I’ve simplified
this change.

[Nico, 2013-10-07 20:12:32]

lgtm

[Mark Mentovai, 2013-10-08 16:37:23]

I had to back the xcrun version out (https://codereview.chromium.org/26235007/)
because xcrun is influenced badly by SDKROOT, and fails when SDKROOT is set to
something Xcode doesn’t understand.

mark@cougar bash$ xcrun strip
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip:
no files specified
mark@cougar bash$ SDKROOT=/SDKs/MacOSX10.6.sdk xcrun strip
xcodebuild: error: SDK "/SDKs/MacOSX10.6.sdk" cannot be located.
xcrun: error: unable to find utility "strip", not a developer tool or in PATH

So I’m going back to checking the environment variables.

[Nico, 2013-10-08 16:39:23]

On Tue, Oct 8, 2013 at 9:37 AM, <mark@chromium.org> wrote:

> I had to back the xcrun version out (https://codereview.chromium.**
> org/26235007/ <https://codereview.chromium.org/26235007/>)
> because xcrun is influenced badly by SDKROOT, and fails when SDKROOT is
> set to
> something Xcode doesn’t understand.
>
> mark@cougar bash$ xcrun strip
> /Applications/Xcode.app/**Contents/Developer/Toolchains/**
> XcodeDefault.xctoolchain/usr/**bin/strip:
> no files specified
> mark@cougar bash$ SDKROOT=/SDKs/MacOSX10.6.sdk xcrun strip
> xcodebuild: error: SDK "/SDKs/MacOSX10.6.sdk" cannot be located.
> xcrun: error: unable to find utility "strip", not a developer tool or in
> PATH
>
> So I’m going back to checking the environment variables.
>

Since several tools get confused when SDKROOT is set to a path I guess we
should just stop doing that?


>
>
https://codereview.chromium.**org/24352006/<https://codereview.chromium.org/2...
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Mark Mentovai, 2013-10-08 16:40:58]

That’s hairy: we set SDKROOT because Xcode does it.

[Nico, 2013-10-08 16:43:59]

Xcode sets it to a path?


On Tue, Oct 8, 2013 at 9:40 AM, <mark@chromium.org> wrote:

> That’s hairy: we set SDKROOT because Xcode does it.
>
>
https://codereview.chromium.**org/24352006/<https://codereview.chromium.org/2...
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Mark Mentovai, 2013-10-08 16:47:26]

Yes, always.

[Mark Mentovai, 2013-10-08 16:49:48]

This is how all of our framework links work. We always say something like

  'link_settings': {
    'libraries': [
      '$(SDKROOT)/System/Library/Frameworks/AppKit.framework',
    ],
  },

When you tell Xcode to set SDKROOT to something like macosx10.7, it will
special-case expand it to a real path before exporting it to the environment.
Isn’t that what ninja does too?

[Nico, 2013-10-08 16:53:19]

Ah, I guess I confused SDKROOT-the-xcode-setting and
SDKROOT-the-envvar-set-by-the-build-system.

From what I understand, the user is supposed to set SDKROOT to 'macosx' or
similar, and then the build system sets it to a path when exporting the env
var to its inferiors (?)


On Tue, Oct 8, 2013 at 9:49 AM, <mark@chromium.org> wrote:

> This is how all of our framework links work. We always say something like
>
>   'link_settings': {
>     'libraries': [
>       '$(SDKROOT)/System/Library/**Frameworks/AppKit.framework',
>     ],
>   },
>
> When you tell Xcode to set SDKROOT to something like macosx10.7, it will
> special-case expand it to a real path before exporting it to the
> environment.
> Isn’t that what ninja does too?
>
>
https://codereview.chromium.**org/24352006/<https://codereview.chromium.org/2...
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Mark Mentovai, 2013-10-08 16:57:20]

Correct. But it also works to set SDKROOT to a path, even in Xcode. It gets
carried through as-is to the environment in that case.

The problem with tools like xcrun (and mig, as I recall, and a few others) isn’t
that SDKROOT isn’t that SDKROOT is set to a path, it’s that they don’t grok the
10.6 SDK. This SDK didn’t come with the Xcode that tools came with, and they
don’t know anything about it.

[Nico, 2013-10-08 16:58:43]

Does xcrun work with a path to the 10.7 (or 10.8) sdk?


On Tue, Oct 8, 2013 at 9:57 AM, <mark@chromium.org> wrote:

> Correct. But it also works to set SDKROOT to a path, even in Xcode. It gets
> carried through as-is to the environment in that case.
>
> The problem with tools like xcrun (and mig, as I recall, and a few others)
> isn’t
> that SDKROOT isn’t that SDKROOT is set to a path, it’s that they don’t
> grok the
> 10.6 SDK. This SDK didn’t come with the Xcode that tools came with, and
> they
> don’t know anything about it.
>
>
https://codereview.chromium.**org/24352006/<https://codereview.chromium.org/2...
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Mark Mentovai, 2013-10-08 17:42:15]

Yup.

[Nico, 2013-10-08 17:54:28]

Ok, cool. Then lgtm with a comment with a TODO to use xcrun once we're off
the 10.6 sdk.


On Tue, Oct 8, 2013 at 10:42 AM, <mark@chromium.org> wrote:

> Yup.
>
>
https://codereview.chromium.**org/24352006/<https://codereview.chromium.org/2...
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Mark Mentovai, 2013-10-08 18:12:51]

No can do. By the time we move off of the 10.6 SDK, we’ll probably be on Xcode
5, which doesn’t come with the 10.7 SDK.

mark@cougar bash$ xcodebuild -version
Xcode 5.0
Build version 5A1413
mark@cougar bash$ SDKROOT=/SDKs/MacOSX10.7.sdk xcrun strip
xcodebuild: error: SDK "/SDKs/MacOSX10.7.sdk" cannot be located.
xcrun: error: unable to find utility "strip", not a developer tool or in PATH

In other words, the problem isn’t a property of the SDK itself, it’s a property
of the Xcode that xcrun is a part of. If that Xcode didn’t come with a given
SDK, then it won’t know anything about that SDK, and its xcrun won’t work when
SDKROOT is set to that SDK.

[Nico, 2013-10-09 01:51:38]

On 2013/10/08 18:12:51, Mark Mentovai wrote:
> No can do. By the time we move off of the 10.6 SDK, we’ll probably be on Xcode
> 5, which doesn’t come with the 10.7 SDK.
> 
> mark@cougar bash$ xcodebuild -version
> Xcode 5.0
> Build version 5A1413
> mark@cougar bash$ SDKROOT=/SDKs/MacOSX10.7.sdk xcrun strip
> xcodebuild: error: SDK "/SDKs/MacOSX10.7.sdk" cannot be located.
> xcrun: error: unable to find utility "strip", not a developer tool or in PATH
> 
> In other words, the problem isn’t a property of the SDK itself, it’s a
property
> of the Xcode that xcrun is a part of. If that Xcode didn’t come with a given
> SDK, then it won’t know anything about that SDK, and its xcrun won’t work when
> SDKROOT is set to that SDK.

And there isn't a way to install the 10.7 sdk so that just "SDKROOT=macosx10.7"
works with xcode 5?

[Mark Mentovai, 2013-10-09 13:31:15]

It works if the SDK lives inside Xcode
(/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs),
symlink OK, but I didn’t think that’s how we installed the SDKs on the bots.
I’ll have to check. If that’s the approach we’re going to use, it works just as
well for the 10.6 SDK.

I’m generally wary of doing stuff inside someone else’s bundle, though. In this
case, it doesn’t seem to break the code signature (on Xcode 5, anyway).

[Nico, 2013-10-09 16:18:10]

On Wed, Oct 9, 2013 at 6:31 AM, <mark@chromium.org> wrote:

> It works if the SDK lives inside Xcode
> (/Applications/Xcode.app/**Contents/Developer/Platforms/**
> MacOSX.platform/Developer/**SDKs),
> symlink OK, but I didn’t think that’s how we installed the SDKs on the
> bots.
> I’ll have to check. If that’s the approach we’re going to use, it works
> just as
> well for the 10.6 SDK.
>

I feel we might run into fewer problems down the road with that approach as
it's less surprising to Xcode.


> I’m generally wary of doing stuff inside someone else’s bundle, though. In
> this
> case, it doesn’t seem to break the code signature (on Xcode 5, anyway).
>

Signatures are a good point. It seems like at least Xcode 4 and 5 exclude
the SDKs folder from the bundle signature.

Anyway, we don't need to decide that now. This CL lgtm with some
explanation why it's not using xcrun (worst case, "see discussion on
<review url>")


>
>
https://codereview.chromium.**org/24352006/<https://codereview.chromium.org/2...
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Mark Mentovai, 2013-10-09 19:28:11]

I stuck that in patch set 4, then I checked the bot slave setup scripts and
found that they currently do stick the SDKs inside the right place in Xcode.app
for this to work, so xcrun should be OK. Patch set 5 just goes back to using
xcrun again, which is what had been backed out.

This has been instructive!

So assuming that this “trys” OK, we’ll just go with xcrun now, and if any
individual developer builds break, we can tell them to put their SDK inside the
right location in Xcode.app. That probably won’t actually happen to anyone,
because most developers are just using the 10.7 SDK or whatever their Xcode.app
has in it via the SDK finder logic you added, since they aren’t doing official
builds that require a specific SDK version.

[Nico, 2013-10-09 19:30:10]

On 2013/10/09 19:28:11, Mark Mentovai wrote:
> I stuck that in patch set 4, then I checked the bot slave setup scripts and
> found that they currently do stick the SDKs inside the right place in
Xcode.app
> for this to work, so xcrun should be OK. Patch set 5 just goes back to using
> xcrun again, which is what had been backed out.
> 
> This has been instructive!
> 
> So assuming that this “trys” OK, we’ll just go with xcrun now, and if any
> individual developer builds break, we can tell them to put their SDK inside
the
> right location in Xcode.app. That probably won’t actually happen to anyone,
> because most developers are just using the 10.7 SDK or whatever their
Xcode.app
> has in it via the SDK finder logic you added, since they aren’t doing official
> builds that require a specific SDK version.

Cool! Maybe tweak the Cl description before landing then.