[webkit-dev] Towards a unified build system

[Mark Rowe]

On 2011-03-01, at 14:06, Adam Barth wrote:

> On Tue, Mar 1, 2011 at 1:57 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>> On Mar 1, 2011, at 11:07 AM, Adam Barth wrote:
>>> On Tue, Mar 1, 2011 at 9:33 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>>>> Another consequence of step 3 is it would break submissions to Apple's central build system, since those pull from the repository with vanilla SVN and do not run special scripts afterwards.
>>> 
>>> I don't fully understand the constraints of Apple's central build
>>> system.  It might be worthwhile talking over the constraints with
>>> someone who's an expert.
>>> 
>>> If the requirements are that the entry point to the build system is an
>>> xcodeproj, we can create an xcodeproj with an action that creates the
>>> other xcodeproj files and then defers to the generated projects as
>>> dependencies.  I haven't tested this approach, but I suspect we'll
>>> find something that satisfies the Apple-internal constraints.
>> 
>> It needs to be either an xcodeproj or a Makefile. Also, all tools required for building have to be either be part of the OS, or part of what is submitted for the given project. So if gyp scripts need to execute at build time, they'd either have to be checked in to the WebKit repository, or get added to Mac OS X.
> 
> We can certainly use a Makefile to kick off the build.  The GYP system
> itself is just a handful of BSD-licensed Python scripts, so I wouldn't
> expect any trouble with checking them into svn.webkit.org.

I don't think driving the build via a Makefile is a desirable option.  XBS (what Maciej has been referring to as Apple's central build system) knows how to override Xcode configuration settings for projects that build using Xcode. This ability is useful and sometimes necessary.  It's also not possible to use if a project builds using Make as Makefiles vary so much from project to project.

>> I asked Mark Rowe about this and he says the current gyp-generated Xcode projects would not build in Apple's central build system at all, so I guess that hurdle would need to be cleared before we even replace the existing checked-in xcodeproj files. Mark is probably our top expert on how Apple's build system works.
> 
> It would be helpful to understand why that's the case.  We can certain
> improve the xcodeproj backend until it generates project files that
> work with Apple's internal build system.  The current xcode backend is
> only 1000 lines of Python.  We could re-write it from scratch if
> needed.

The initial issues that I observed when looking at JavaScriptCore was the Xcode project is generated in to a subdirectory.  This prevents "xcodebuild installsrc" from working correctly (only the files in directories below the Xcode project appear to be installed).  I made some quick hacks to work around that and then ran in to the issue that the configurations in the generated JavaScriptCore.xcodeproj are not set up correctly (Production is no longer the default configuration, Production is based on DebugRelease.xcconfig rather than Base.xcconfig, etc.).  There's also the fact that the generated Xcode project doesn't build the same content as the existing Xcode project (No jsc, testapi, minidom). At this point I gave up and stopped looking at it.

- Mark