Am 31.01.2013 um 17:17 schrieb Maciej Stachowiak:
>
> On Jan 31, 2013, at 1:56 AM, Patrick Gansterer <par...@paroga.com> wrote:
>
>> Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa:
>>
>>> On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger <joc...@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 <mr...@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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
