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

[Alexis Menard]

On Thu, Jan 31, 2013 at 6: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.

My 2 cents.

One advantage CMake has over other proposals is that it's already
working for 2 ports (and potentially 4). It is an open source project
so we could potentially contribute to it to add or fix what is needed.
One other good point for CMake is that it's widely used in the
industry and it is backed by a company. When KDE switched over CMake
the guys behind CMake were very very responsive, I believe they will
be too if we plan to switch to CMake. The more famous projects they
have running CMake, the better it is for them. So if we need to
improve the Xcode support then I bet we can count on them. CMake has
also some support in various IDE, and if not then the native solution
is a fallback.

Sure the syntax is maybe not the best but it no worst than Gyp, Xcode,
Makefiles, qmake or some perl script. We already live with all these
syntax and people are also used to edit the CMake related project.

Perfect build system do not exist it's a fact.

On the other hand I don't want to loose the native support like Xcode.
I don't know if many are using it but I find incredibly convenient to
open the Xcode workspace of WebKit, setup the two little things
instructed in the wiki and press cmd+b and it just works, it builds,
it integrate with Xcode (so you get the neat features of pretty output
compiles errors with jumping, ...) and I press cmd+r and it launch
MiniBrowser or something else to debug from within the IDE. This is
what makes the Mac port a very great port to work on.

>
> -- Patrick
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>



-- 
Software Engineer @
Intel Open Source Technology Center