Bug 109248 - [Mac] Experimental gyp-based build system
Summary: [Mac] Experimental gyp-based build system
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-07 19:20 PST by Mark Rowe (bdash)
Modified: 2013-04-05 01:07 PDT (History)
12 users (show)

See Also:


Attachments
WTF.gyp for Mac (2.87 KB, patch)
2013-02-07 20:34 PST, Mark Rowe (bdash)
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Rowe (bdash) 2013-02-07 19:20:38 PST
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.
Comment 1 Mark Rowe (bdash) 2013-02-07 19:29:07 PST
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.
Comment 2 Dirk Pranke 2013-02-07 19:51:57 PST
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?
Comment 3 Mark Rowe (bdash) 2013-02-07 20:12:18 PST
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).
Comment 4 Mark Rowe (bdash) 2013-02-07 20:16:15 PST
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.
Comment 5 Dirk Pranke 2013-02-07 20:32:16 PST
it's a bit hard to say what's wrong. Can you post the WT.gyp you're using?
Comment 6 Dirk Pranke 2013-02-07 20:32:28 PST
(WTF.gyp, rather).
Comment 7 Mark Rowe (bdash) 2013-02-07 20:34:51 PST
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.
Comment 8 Dirk Pranke 2013-02-07 22:42:36 PST
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.
Comment 9 Mark Rowe (bdash) 2013-02-08 02:03:48 PST
(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.
Comment 10 Nico Weber 2013-02-13 14:26:08 PST
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.
Comment 11 Mark Rowe (bdash) 2013-02-13 14:33:51 PST
(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.