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.

Cheers,
Maciej

_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to