[webkit-dev] Common build system (was Re: WebKit Wishes)

Mon Feb 4 10:46:15 PST 2013

GYP was written in Python to address point (b). Python was already part of
the baseline requirements on all platforms, so we already had Python
available everywhere we needed it. There are no dependencies on external
binaries, and no compiled code needs to be checked in anywhere or
maintained as part of a base image.

As for point (a), you can easily have a top-level Makefile not generated by
GYP that says “run GYP to produce the build files for whatever environment
you like and then pass control to that build system to do the rest of the
build. Developers who like it can use ninja for their own builds, and your
bots can use Xcode or make if that’s a requirement (or if ninja doesn’t
meet your requirements given point (b)).

I’d be happy to discuss this further with anyone who’s interested in moving
in this direction.

On Mon, Feb 4, 2013 at 12:20 AM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Feb 3, 2013, at 8:18 PM, Mike Lawther <mikelawther at chromium.org> wrote:
>
> Hi Maciej!
>
> On 31 January 2013 11:15, Maciej Stachowiak <mjs at apple.com> wrote:
>
>> It's far simplest for us if:
>> (a) There is an Xcode project (or a Makefile) that builds the Mac port
>> checked in to source control.
>> (b) The generated project invokes only tools that are part of the default
>> Mac OS X install.
>>
>
> For b), does 'default' include an Xcode install? From my memory of setting
> up a Mac dev box Xcode was needed to compile.
>
>
> The limitation in (a) is all about how the build fleet is managed, and
> yes, the machines in question have the Mac OS X user install as well as
> developer tools installed, and it is ok to rely on that.
>
> To clarify: the things that are not kosher are submitting a binary tool as
> part of the module, downloading things as part of the build, or relying on
> something to be installed out of band before building. It is ok for the
> build to rely on scripts, so long as the relevant interpreter is part of
> the default install. Any such script would have to be in each directory
> under Source/ since these build separately without access to the source of
> the others.
>
> I should mention that there's a lot of interest right now at Apple in the
> possibility of switching to Gyp. We think it's likely closer to what we
> need than CMake, and we suspect there is probably somewhat better
> probability of modifying it if necessary. If we find someone at Apple who
> is able to work on such a project in the short term (not completely
> impossible), would any Google folks be interested in collaborating? Ideally
> we could use assistance from someone who (a) understands how the Chromium
> WebKit Gyp-based build works; and (b) is willing and able to change Gyp if
> necessary.
>
> Regards,
> Maciej
>
>
>     mike
>
>
> On 31 January 2013 11:15, Maciej Stachowiak <mjs at apple.com> wrote:
>
>>
>> On Jan 30, 2013, at 3:24 PM, Dirk Pranke <dpranke at chromium.org> wrote:
>>
>> > On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo <fpizlo at apple.com> wrote:
>> >> Thanks for sharing this.
>> >>
>> >> On Jan 30, 2013, at 1:28 PM, Eric Seidel <eric at webkit.org> wrote:
>> >>
>> >> I wish we only had one build system (it were easy to add/remove/move
>> files).
>> >>
>> >> I believe changes like http://trac.webkit.org/changeset/74849 are an
>> >> unhealthy sign for the project.  Adam is not the only person who has
>> chosen
>> >> to empty files instead of removing them.  The pain of updating 8 build
>> >> system is so great, we jump through hoops to avoid it.  Which means it
>> took
>> >> us months to move JavaScriptCore/wtf to WTF, and will take us years to
>> kill
>> >> WebCore/platform.
>> >>
>> >>
>> >> +1
>> >>
>> >> This is a hard problem.  It is a problem worth solving.
>> >>
>> >> Do you have more thoughts on this, particularly since you know quite
>> well
>> >> how both Xcode and gyp work?
>> >>
>> >> I suspect this is one of those things that it would be hard to achieve
>> >> consensus on since there are so many stakeholders.  But it may be
>> fruitful
>> >> to have a "what if" discussion about what this might look like.
>> >>
>> >
>> > I think we can solve this problem if we agree that we want to. I think
>> > we haven't in the past mostly because we couldn't reach a consensus
>> > that it was worth solving enough to really try.
>> >
>> > I would love to see this fixed and would be glad to work on it. I
>> > think we should at least pursue this far enough to fully understand
>> > what our options are and what the costs and tradeoffs might be; does
>> > anyone disagree, and is anyone else willing to help pitch in?
>> >
>> > I think there are several possible ways we could solve this. One would
>> > be to switch to a common meta-build system. My understanding is that
>> > Apple's internal production build processes impose certain constraints
>> > here that I don't fully understand, but I know we've discussed the
>> > possibility of checking in generated project files as a workaround.
>> > Maybe there are other options as well to those constraints? I would
>> > love to discuss this further w/ someone from Apple ...
>>
>> It's far simplest for us if:
>> (a) There is an Xcode project (or a Makefile) that builds the Mac port
>> checked in to source control.
>> (b) The generated project invokes only tools that are part of the default
>> Mac OS X install.
>>
>> It may not be completely impossible to violate these requirements but it
>> will require a lot of bureaucracy.
>>
>> > (Also, just to get this out of the way, I don't think gyp needs to be
>> > the solution).
>> >
>> > Another alternative would be to write a script that did support at
>> > least the common use cases (add/move/delete files). There have been
>> > attempts in the past, but they have foundered on at least some
>> > perceived skepticism over how well this would work w/ XCode. That
>> > said, I don't think we've really pushed this to see. At some point
>> > this script might turn into a meta-meta-build system, which might be
>> > silly but also be the shortest path to the finish line.
>> >
>> > I suggest if there is interest in this we can start a new thread to
>> > discuss further ...
>>
>> My preference would be to use a common meta-build system with a
>> comfortably human-readable and human-editable syntax, and checked in
>> generated project files for those ports that need them.
>>
>> I think a key to making this work is to get Chromium and the Apple Mac
>> port onto a common build system, which will probably require both Google
>> and Apple ponying up at least one person to work on this project for a
>> reasonable period of time.
>>
>> I think the plausible meta-build-systems to use would be CMake and Gyp,
>> but in both cases it may be necessary to modify them to work well for
>> everyone.
>>
>> I'd also like to add that I think a key related issue to common build
>> system is common feature configuration. The many different ways ports
>> control their feature flags is super confusing. I've long wanted to
>> implement common configuration management, but have not had time.
>>
>> Cheers,
>> Maciej
>>
>>
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130204/6c6f250d/attachment-0001.html>