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

[Ryosuke Niwa]

See
https://bugs.webkit.org/show_bug.cgi?id=61773
https://bugs.webkit.org/show_bug.cgi?id=64149


On Thu, Jan 31, 2013 at 12:36 PM, Nico Weber <thakis at chromium.org> wrote:

> 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
> - R. 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
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130131/4eb4e9a9/attachment.html>