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

[Hugo Parente Lima]

On Thursday, January 31, 2013 06:14:20 PM Patrick Gansterer 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.
> 
> 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.

I agree, common build system on WebKit is an utopia, create a new meta build 
system isn't a good idea, so the only plausible option is to unify way we 
add/remove/modify files from the build. Create a script to do this on all build 
system is yet another utopia, so again, the only option is to have plain text 
files.

Going a bit further on this idea, would be nice to also have conditionals on 
these plain text files to cover the use case of e.g. "add foo.cpp to the build 
when ENABLE_FOO or WTF_USE_FOO is on" would be even better, a script would be 
called passing all ENABLE, USE, HAVE, etc.. flags and returning a list of files, 
the only question is if all current build system would support such "dynamic" 
source file list, CMake does :-)
 
> The remaining build systems can be ported to one of these systems or be
> adopted to use this file lists too.
> 
> -- Patrick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130131/8965f197/attachment.sig>