Bug 109248 – [Mac] Experimental gyp-based build system

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebKit Misc.

[Mark Rowe (bdash)]

As discussed on webkit-dev, we should attempt to bring up a gyp-based build system for the Mac. This will help us determine if there are any limitations in gyp that need to be addressed.

[Mark Rowe (bdash)]

I started experimenting with this today by setting up gyp to generate an Xcode project for WTF that matches the structure and configuration of the current Xcode project. This should help minimize any changes in build behavior. I believe I've got things set up in such a way that they work for engineering builds ("xcodebuild -configuration Debug" or "xcodebuild -configuration Release"). I'm struggling to get a project that works for our production builds though, unless I move the .gyp file to the top level of the WTF directory.

[Dirk Pranke]

what setting in xcode controls where the project directory is set? Put differently, what setting in the generated wtf.xcodeproj is wrong, and what is the corresponding setting in the checked-in wtf.xcodeproj?

[Mark Rowe (bdash)]

projectDirPath on the project object gets set to the path containing the .gyp file:
  projectDirPath = WTF.gyp/mac;

This causes SRCROOT to get set to Source/WTF/WTF.gyp/mac, which is bogus. SRCROOT is supposed to point to the top level directory containing the source (Source/WTF).

[Mark Rowe (bdash)]

Maybe I'm invoking gyp wrong? In order to get it to spit the Xcode project out at the right location I'm doing:

  cd WTF.gyp/mac && gyp --generator-output=../.. -f xcode --depth=. WTF.gyp

If I run gyp from the top level directory and specify "." as the output directory then I don't get the bogus projectDirPath value, but the Xcode project ends up in a subdirectory rather than where I wanted it.

[Dirk Pranke]

it's a bit hard to say what's wrong. Can you post the WT.gyp you're using?

[Dirk Pranke]

(WTF.gyp, rather).

[Mark Rowe (bdash)]

Created attachment 187227 [details]
WTF.gyp for Mac

I've attached a patch that shows the gyp file I'm experimenting with for WTF in case anyone wants to take a look. I've tweaked the "Copy WTF Headers" script phase to dump out the value of SRCROOT and gyp's project_dir. This shows that no matter where I generate the .xcodeproj to, gyp tweaks the projects projectDirPath such that SRCROOT is always incorrect.

[Dirk Pranke]

Okay, I have reproduced this. I think what's going on is that GYP uses the location of the .gyp file as the current working directory for any relative paths, and in order for that to translate most easily into the xcodeproject, we set the projectDirPath to match the directory containing the gyp file.

As you say, it does look like projectDirPath/SRCROOT is supposed to be the directory containing the .xcodeproj. When that is not the same as the directory containing the .gyp file, you're gonna have problems.

At this point, I can't say why gyp does this, and we'd probably need to check w/ Mark Mentovai (or maybe Nico), since my knowledge of both xcode and the gyp xcode generator is pretty weak. Perhaps the thing to do is to adjust the xcode gyp generator to make sure the relative paths are based on the directory containing the .xcodeproj, not the directory containing the .gyp . Or, maybe there's a reason it needs to be this way, dunno.

Generally speaking, we always put the .xcodeproj's next to the .gyp files. So, for you to get something to work, you could probably work around this by moving your WTF.gyp from Source/WTF/WTF.gyp/mac/WTF.gyp to just Source/WTF . If we do eventually go down the "everyone uses gyp" route, that seems like the better thing to do anyway.

Hope this helps and I haven't written anything wrong here, but if I have hopefully Mark Mentovai or Nico will correct me.

[Mark Rowe (bdash)]

(In reply to comment #8)
> Generally speaking, we always put the .xcodeproj's next to the .gyp files. So, for you to get something to work, you could probably work around this by moving your WTF.gyp from Source/WTF/WTF.gyp/mac/WTF.gyp to just Source/WTF . If we do eventually go down the "everyone uses gyp" route, that seems like the better thing to do anyway.


This seems like a reasonable workaround while I'm experimenting with this.

[Nico Weber]

Comment on attachment 187227 [details]
WTF.gyp for Mac

View in context: https://bugs.webkit.org/attachment.cgi?id=187227&action=review

> Source/WTF/WTF.gyp/mac/WTF.gyp:7
> +      'xcode_config_file': '<(project_dir)/Configurations/Base.xcconfig',

Just FYI: xcode_config_file works for the xcode backend of gyp, but there's no support for it in the make and ninja generators. There's http://crbug.com/90043 open for adding support, but we ended up not needing it for chromium, so we didn't implement that.

Just copying the contents of the xcconfig into an xcode_settings block doesn't quite work either, because the conditional syntax used in your xcconfig files isn't emulated either: http://crbug.com/122592 We ended up using gyp conditionals instead, so we didn't end up implementing this either.

If you only care about producing xcode files , this is a non-issue for you.

[Mark Rowe (bdash)]

(In reply to comment #10)
> (From update of attachment 187227 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=187227&action=review
> 
> > Source/WTF/WTF.gyp/mac/WTF.gyp:7
> > +      'xcode_config_file': '<(project_dir)/Configurations/Base.xcconfig',
> 
> Just FYI: xcode_config_file works for the xcode backend of gyp, but there's no support for it in the make and ninja generators. There's http://crbug.com/90043 open for adding support, but we ended up not needing it for chromium, so we didn't implement that.
> 
> Just copying the contents of the xcconfig into an xcode_settings block doesn't quite work either, because the conditional syntax used in your xcconfig files isn't emulated either: http://crbug.com/122592 We ended up using gyp conditionals instead, so we didn't end up implementing this either.
> 
> If you only care about producing xcode files , this is a non-issue for you.

Understood. I'm initially trying to match the structure of our existing Xcode projects. Once we get that working, we can evolve towards a less Xcode-specific gyp file.