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

[Dirk Pranke]

On Thu, Jan 31, 2013 at 12:10 PM, Patrick Gansterer <paroga at paroga.com> wrote:
>
> Am 31.01.2013 um 21:07 schrieb Dirk Pranke:
>
>> On Thu, Jan 31, 2013 at 11:48 AM, Hugo Parente Lima
>> <hugo.lima at openbossa.org> wrote:
>>> On Wednesday, January 30, 2013 04:15:48 PM Maciej Stachowiak 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.
>>>
>>> I have a patch trying to solve this issue for CMake based ports[1], the patch
>>> still on going, but even a change affecting just 2-3 ports using the same build
>>> system is a bit hard to get a consensus, so you can imagine how hard will be
>>> to get a consensus over all WebKit ports.
>>>
>>> [1] https://bugs.webkit.org/show_bug.cgi?id=103162
>>>
>>
>> This is slightly off-topic, but I had thought that no one was actually
>> using CMake; maybe I was mistaken and just none of the ports that
>> build on webkit.org are? It looks like Blackberry and maybe a WinCE
>> port uses CMake? Anyone else?
>
> EFL uses CMake too.
> 4 EFL bots @ http://build.webkit.org
> 1 WinCE bot @ http://build.webkit.org
> 1 EFL bot as EWS
>

Ah, I thought EFL was using Autotools. Thanks for the correction.

-- Dirk