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

[Patrick Gansterer]

Am 31.01.2013 um 17:17 schrieb Maciej Stachowiak:

> 
> On Jan 31, 2013, at 1:56 AM, Patrick Gansterer <paroga at paroga.com> wrote:
> 
>> Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa:
>> 
>>> On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger <jochen at chromium.org> wrote:
>>> Another option is to add a webkit-patch command for modifying the build files. That way, the syntax doesn't need to be overly human friendly. There was also some attempt to write a tool to add files automatically: https://bugs.webkit.org/show_bug.cgi?id=61772  I would expect that such a tool becomes easier if it would only modify one source of truth and generates all other artifacts such as Xcode projects from it.
>>> 
>>> I don't want build file's syntax to be so human unfriendly that I need a tool for it.
>>> 
>>> Often times, these syntax problems can be improved dramatically by simple changes. e.g. we had a similar discussion about TestExpectation syntax, and I'm much happier with the new syntax even though the new syntax is functionally equivalent to the old one, and two syntaxes are very similar.
>>> 
>>> On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe <mrowe at apple.com> wrote:
>>> I’ve experimented with this in the past and you’re right that it shouldn’t be particularly difficult to do. However, I suspect that the task would be similar in scope to defining an improved syntax for gyp. And if the syntax is the primary sticking point with gyp then it’d seem preferable to tackle initially.
>>> 
>>> Yeah. In fact, we can just come up with whatever syntax we like and convert it to the existing gyp format if the syntax was the biggest issue.
>> 
>> Do we want to define the whole build system (including information how to invoke the generators) with the new system, or is a "simple" list for the input files sufficient? IMHO adding a new generator build step happens very rarely. So maybe we can spit the "input file list" (mainly *.cpp and *.idl) into new files.
>> Then GYP and CMake can read them and generate the build system out of them directly (like they to already today) instead of listing the files in the *.gpyi and *.cmake. This might work for other systems like qmake too.
>> For XCode we can maybe have a "template XCode project" and generate the "work XCode project" with a script. This script then only need to fill in the files from the "input file list" into the "template XCode project".
>> Defining the feature flags can be done like Maciej suggested with "Port.h" files.
> 
> I think it would be better to adapt an existing meta build system to our needs than to make one from scratch, unless we find that completely impractical.
> 
> In particular, gyp and cmake both know how to handle generated sources, and while it may not be super common to make a new type of generated source, it's bad for hackability of the project of doing so is super hard. We get a lot of hackability benefits from using various kinds of generated sources, many first introduced in the days when we had a lot fewer build systems. So in my mind, they are already ahead of a hypothetical "simple" system.


Do you want to kick the requirements of the smaller ports from trunk or do you think that e.g. a qmake generate for GYP makes sense?
AFAIK e.g. QtWebKit is shipped with Qt, which uses qmake as build system, where CMake/GYP is not an option.

I completely agree that creating a new meta meta build system isn't a good idea, but sharing the common parts (which reduce the daily productivity) might be a step in the right direction. Using simple text files which contain the list of files (like the gpyi files already do today) isn't a new build system. It only offers the existing meta build systems (CMake, GYP, autotools, qmake) to use a common base.

The remaining build systems can be ported to one of these systems or be adopted to use this file lists too.

-- Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130131/27d86206/attachment.html>