Fallback to '.tbd' for system missing '.dylib'.

Fallback to '.tbd' for system missing '.dylib'.

With Xcode 7 the '.dylib' for system libraries are no longer present
but instead only '.tbd' are shipped maybe in an effort to reduce the
size of the SDK download.

Change XcodeSettings._AdjustLibrary() to look for a '.tbd' file for
system libraries (those whose path starts by "$(SDKROOT)"). Only do
the substitution if the '.dylib' cannot be found and a '.tbd' file
with the same path exists.

BUG=517914
R=justincohen@chromium.org, mark@chromium.org

Committed: https://chromium.googlesource.com/external/gyp/+/01528c7244837168a1c80f06ff60fa5a9793c824

[sdefresne, 2015-08-10 18:35:57]

sdefresne@chromium.org changed reviewers:
+ mark@chromium.org

[sdefresne, 2015-08-10 18:35:57]

Please take a look.

I've tried this change and I'm able to build Chromium with Xcode 7 beta 4.

[Mark Mentovai, 2015-08-10 18:41:44]

mark@chromium.org changed reviewers:
+ thakis@chromium.org

[Mark Mentovai, 2015-08-10 18:41:44]

I think Nico should review this. I had comparatively little to do with
xcode_emulation.py.

It seems reasonable to me, except I’ll note that Xcode hasn’t yet solved this
problem, and we should look at their solution if they do come up with one before
Xcode 7 becomes final. Because of that, you may want to leave a TODO comment and
a bug behind.

https://codereview.chromium.org/1275133004/diff/1/pylib/gyp/xcode_emulation.py
File pylib/gyp/xcode_emulation.py (right):

https://codereview.chromium.org/1275133004/diff/1/pylib/gyp/xcode_emulation.p...
pylib/gyp/xcode_emulation.py:1042: l = l.replace('$(SDKROOT)', sdk_root)
I don’t like the double-replace of SDKROOT.

[sdefresne, 2015-08-11 07:43:00]

https://codereview.chromium.org/1275133004/diff/1/pylib/gyp/xcode_emulation.py
File pylib/gyp/xcode_emulation.py (right):

https://codereview.chromium.org/1275133004/diff/1/pylib/gyp/xcode_emulation.p...
pylib/gyp/xcode_emulation.py:1042: l = l.replace('$(SDKROOT)', sdk_root)
On 2015/08/10 at 18:41:44, Mark Mentovai - out til August wrote:
> I don’t like the double-replace of SDKROOT.

Fixed (with the double os.path.exists(library) too).

[Mark Mentovai, 2015-08-11 21:54:11]

LGTM, but again, I think Nico should see this too.

[Nico, 2015-08-11 21:57:51]

Do we have to support building with Xcode beta versions? Or can we wait and see
what they end up doing?

[justincohen, 2015-08-12 02:58:02]

justincohen@chromium.org changed reviewers:
+ justincohen@chromium.org

[justincohen, 2015-08-12 02:58:02]

Do we have to refer to dylib at all?  If I recall, we worked around this problem
by changing references to libsomething.dylib to -lsomething, e.g.
https://codereview.chromium.org/1179573004

[Mark Mentovai, 2015-08-12 03:11:59]

That’s kind of a hackaround.

Again, this is a known problem in the Xcode beta. Why are we in such a rush to
use a broken toolchain instead of waiting (or pushing) to see that the toolchain
is fixed?

Since Xcode created this problem and Xcode will need to fix this problem, if
possible, gyp should wait to see what Xcode does and follow its lead.

[sdefresne, 2015-08-12 06:19:23]

On 2015/08/12 at 03:11:59, mark wrote:
> That’s kind of a hackaround.
> 
> Again, this is a known problem in the Xcode beta. Why are we in such a rush to
use a broken toolchain instead of waiting (or pushing) to see that the toolchain
is fixed?
> 
> Since Xcode created this problem and Xcode will need to fix this problem, if
possible, gyp should wait to see what Xcode does and follow its lead.

Chrome for iOS wants to be ready to uses Xcode 7 as soon as it is made official.
Currently Chrome for iOS developers are strongly encouraged to only use Xcode 7
beta. Which make it hard to also work on Mac (it's possible, you just have to
use "xcode-select" but if you forget to do it, you are going to suffer a full
rebuild, painful).

Since you think we should not land this, I'm closing this issue, but I'll leave
the reference in the bug so that people interested in using Xcode 7 beta can
still patch it locally.

[sdefresne, 2015-09-10 10:16:18]

On 2015/08/12 at 06:19:23, sdefresne wrote:
> On 2015/08/12 at 03:11:59, mark wrote:
> > That’s kind of a hackaround.
> > 
> > Again, this is a known problem in the Xcode beta. Why are we in such a rush
to use a broken toolchain instead of waiting (or pushing) to see that the
toolchain is fixed?
> > 
> > Since Xcode created this problem and Xcode will need to fix this problem, if
possible, gyp should wait to see what Xcode does and follow its lead.
> 
> Chrome for iOS wants to be ready to uses Xcode 7 as soon as it is made
official. Currently Chrome for iOS developers are strongly encouraged to only
use Xcode 7 beta. Which make it hard to also work on Mac (it's possible, you
just have to use "xcode-select" but if you forget to do it, you are going to
suffer a full rebuild, painful).
> 
> Since you think we should not land this, I'm closing this issue, but I'll
leave the reference in the bug so that people interested in using Xcode 7 beta
can still patch it locally.

Has anyone tested how Xcode 7 GM does fix this issue?

[Mark Mentovai, 2015-09-10 12:54:10]

It doesn’t fix it. What it does, for /usr/lib libraries, is do -L/usr/lib
-lname. I don’t want to do that because it makes things dependent on the library
search path, and we do wind up with name collisions in the output directory.

At this point, I think we should take this patch.

LGTM.

[sdefresne, 2015-09-10 14:53:48]

On 2015/09/10 at 12:54:10, mark wrote:
> It doesn’t fix it. What it does, for /usr/lib libraries, is do -L/usr/lib
-lname. I don’t want to do that because it makes things dependent on the library
search path, and we do wind up with name collisions in the output directory.
> 
> At this point, I think we should take this patch.
> 
> LGTM.

OK. Re-opening an sending to the CQ (let's see if it pass without rebasing).

[sdefresne, 2015-09-10 14:54:35]

On 2015/09/10 at 14:53:48, sdefresne wrote:
> On 2015/09/10 at 12:54:10, mark wrote:
> > It doesn’t fix it. What it does, for /usr/lib libraries, is do -L/usr/lib
-lname. I don’t want to do that because it makes things dependent on the library
search path, and we do wind up with name collisions in the output directory.
> > 
> > At this point, I think we should take this patch.
> > 
> > LGTM.
> 
> OK. Re-opening an sending to the CQ (let's see if it pass without rebasing).

Shoot, forgot gyp has no CQ. And I re-installed my desktop so I need to checkout
gyp.
Let's wait a moment.

[sdefresne, 2015-09-10 15:13:19]

I've updated the comment at the recommendation of justincohen (offline). mark,
does this comment looks good to you?

[justincohen, 2015-09-10 15:21:53]

lgtm

[sdefresne, 2015-09-10 15:22:42]

thakis: ping?

[Mark Mentovai, 2015-09-18 22:19:04]

Committed patchset #6 (id:100001) manually as
01528c7244837168a1c80f06ff60fa5a9793c824 (presubmit successful).

[Mark Mentovai, 2015-09-18 22:19:35]

I talked to Nico and he wasn’t against this. Now that Xcode 7 has been released,
I landed it.