[webkit-dev] Build system update

[Eric Seidel]

On Tue, Mar 22, 2011 at 8:14 PM, Mark Rowe <mrowe at apple.com> wrote:
>
> On 2011-03-22, at 19:16, Adam Barth wrote:
>
>> WebKit-folk,
>>
>> With a bunch of help from Dimitri and Eric, we now have a functioning
>> GYP-based build for the Apple Mac port.  There are still a couple bugs
>> we need to fix before this build system is ready for production
>> (they're filed as blocking Bug 55018, if you're curious).  If you'd
>> like to try out the GYP-based build, you can invoke it (on a Mac) as
>> follows:
>>
>> ./Tools/Scripts/build-webkit --gyp
>
> Is this expected to work?  Running the command quoted above results in a build failure in JavaScriptCore for me (jsc is unable to find UString.h).

Interesting.  I just did a clean build (rm -rf WebKitBuild) with ToT
and was unable to reproduce.  But I'd *love* to see the logs if you
still have them.

Given that this all started working a couple hours ago, I would expect
it's all pretty broken yet.

>> If you just want to look at the generated project files, you can
>> generate them using this command:
>>
>> ./Tools/Scripts/generate-project-files
>>
>> That script will create
>> Source/JavaScriptCore/gyp/JavaScriptCore.xcodeproj and
>> Source/WebCore/gyp/WebCore.xcodeproj (as well as a JavaScriptGlue
>> project file, which you should feel free to ignore).
>
> Is it useful for me to file bugs about these generated projects?

Eventually we will need to file bugs to fix all the issues folks find,
but for now it's probably easiest for Adam or I to file them as we go
based on your email just now.  Of course you should feel welcome to
file any bugs and block https://bugs.webkit.org/show_bug.cgi?id=55018
when you do.

> A few issues I noticed while skimming the Xcode project files…
> The source is all hidden two levels deep in the hierarchy (inside a group named ".."?).
> There's an oddly-named BUILT_PRODUCTS_DIR group.
> There's a mysterious ForwardingHeaders group.
> The .xcconfig files are in the Source group.
> The script build phases are unnecessarily verbose ('Action "…"' or 'Postbuild "…"' where only '…' is meaningful).
> Product names for targets are redundantly declared in the Xcode project when they're already defined in the .xcconfig files.
> There are mysterious extra settings in the Xcode project that serve no apparent purpose (EXECUTABLE_PREFIX, INTERMEDIATE_DIR, SHARED_INTERMEDIATE_DIR, WRAPPER_PREFIX, ALWAYS_SEARCH_USER_PATHS?)
> The default configuration is Debug rather than Production.
> Updating Info.plist is done via a separate aggregate target rather than simply being a script phase.

I'll let Adam reply to these inline.

>> The main advantage of this build system over the existing Apple Mac
>> build system is that the list of files is shared between this build
>> system and the Chromium build system.  That means one fewer location
>> to update when adding, removing, or renaming a file.  Over time, we
>> should be able to share more between the build systems (because they
>> are written in a common language) and to share the list of files
>> between more ports.
>>
>> One area that I could use some help from one or more Apple folks is
>> making sure that this build system integrates properly with Apple's
>> internal build system.  Based on my (incomplete!) understanding of
>> Apple's internal build system, there are at least two options:
>>
>> 1) Apple's internal build system consumes Source in its entirety and
>> builds a master WebKit.xcodeproj (or a Makefile), which abstracts
>> further details about the build, such as how subsequent xcodeproj are
>> created or how many libraries WebKit is factored into (e.g., letting
>> us extract WTF from JavaScriptCore).
>
> Making that particular change is completely unrelated to GYP.
>
>> 2) For each submission to Apple's internal build system, we create a
>> branch, generate xcodeproj files, and check them into the branch.
>> Apple's internal build system can then "svn export" the branch and see
>> xcodeproj files, as today.
>
> While this is certainly technically feasible, it would add a huge amount of overhead to the process of performing a submission.

Thanks for your feedback!