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

[Nico Weber]

This is a lovely discussion to have every now and then :-)

Maybe the file add/move/delete tool that someone wrote could land
without xcode support for now? Then the pain of moving files is
reduced to two systems (xcode and everyone else), and that's something
that's at least tractable.

Nico

On Thu, Jan 31, 2013 at 12:31 PM, Dirk Pranke <dpranke at chromium.org> wrote:
> On Thu, Jan 31, 2013 at 9:14 AM, Patrick Gansterer <paroga at paroga.com> wrote:
>>
>> 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.
>>
>
> It could certainly make sense for us to add Autotools and Qmake
> generators to GYP; I'm less certain if a CMake generator makes much
> sense, but I haven't thought about it as much. I'm not super familiar
> with any of these three tools, so I could be dead wrong.
>
>> 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
>
> I suspect that we would quickly find that we would want some sort of
> support for conditionals and/or file inclusion in our "simple text
> files", at which point you basically get a meta-meta-build system :).
> I don't actually think such a thing is that bad of an idea, but it's
> all in the details.
>
> I would like to find a solution where all of the ports were able to
> retain integration with their "native" build environments one way or
> another.
>
> -- Dirk
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev