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

[Ryosuke Niwa]

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 think making Autotools and Qmake use GYP will be a huge win even if we
couldn't make Xcodeproj and CMake use GYP at the end. Having GYP + CMake +
Xcodeproj is much better than having Autotools and Qmake on top of that.

I don't think we need to necessarily unify all build systems. Reducing the
number of build systems is a worthwhile goal on its own merit.

- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130131/db9e1260/attachment.html>