[webkit-dev] Common build system (was Re: WebKit Wishes)
Mark Mentovai
mark at chromium.org
Tue Feb 5 13:36:50 PST 2013
The run time comparisons were based on actual comparison with available
Python modules at the time. JSON was substantially slower than having the
Python interpreter slurp it up on its own. In fact, GYP started out reading
JSON input and we switched it to Python once we learned this. It was four
years ago, and I don’t have the numbers handy anymore.
In the end, I don’t think that the actual syntax (as opposed to the
structured data that it contains) is all that important. GYP input files
are fairly simple structured data consisting of very few types: dicts,
lists, strings, and infrequent bools and ints. Any extant or nascent format
that can handle these is a candidate. If there’s some kind of convergence
on a beautiful one that’s easy to maintain and quick to parse, there’s no
reason GYP can’t be taught to read it, even alongside the existing
JSON-esque format that’s fed to the Python interpreter. If this is the only
thing standing between a project and its adopting GYP, then it’s a really
easy one to get over.
On Tue, Feb 5, 2013 at 3:59 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Feb 5, 2013, at 6:09 AM, Mark Mentovai <mark at chromium.org> wrote:
>
> > The parser (and the grammar) works the way it does because it’s just
> Python—the whole thing can be slurped in quickly by the interpreter and
> made available to GYP as data. It’s faster than a parser written in Python
> for a similar language would be, and it’d likely take a binary Python
> module to approach or exceed this speed. Developers don’t like waiting for
> tools.
>
> Is that a result based on testing, or just a projectiom? My guess would be
> that most incremental builds do not add or remove any files, and therefore
> do not need to regenerate the project files at all, so the speed of parsing
> GYP files is unlikely to have a major impact, unless it's a truly massive
> difference.
>
> I have to say that the syntax weight of gyp files (quotes, commas, braces,
> brackets) makes them feel harder to read and edit than other build file
> formats designed for human consumption (obviously Xcode is worse).
>
> Compare this bit of gyp for generating a derived source file:
>
> >> {
> >> 'action_name': 'XMLNames',
> >> 'inputs': [
> >> '../dom/make_names.pl',
> >> '../xml/xmlattrs.in',
> >> ],
> >> 'outputs': [
> >> '<(SHARED_INTERMEDIATE_DIR)/webkit/XMLNames.cpp',
> >> '<(SHARED_INTERMEDIATE_DIR)/webkit/XMLNames.h',
> >> ],
> >> 'action': [
> >> 'python',
> >> 'scripts/action_makenames.py',
> >> '<@(_outputs)',
> >> '--',
> >> '<@(_inputs)',
> >> '--',
> >> '--extraDefines', '<(feature_defines)'
> >> ],
> >> 'msvs_cygwin_shell': 1,
> >> },
>
> vs the equivalent bit of DerivedSources.make:
>
> >> XMLNames.cpp : dom/make_names.pl xml/xmlattrs.in
> >> perl -I $(WebCore)/bindings/scripts $< --attrs $(WebCore)/xml/
> xmlattrs.in
>
> Or GNUMakefile.am:
>
> >> DerivedSources/WebCore/XMLNames.cpp DerivedSources/WebCore/XMLNames.h:
> $(WebCore)/dom/make_names.pl $(WebCore)/xml/xmlattrs.in
> >> $(AM_V_GEN)$(PERL) -I$(WebCore)/bindings/scripts $< --attrs
> $(WebCore)/xml/xmlattrs.in --outputDir "$(GENSOURCES_WEBCORE)"
>
> Or DerivedSources.pri:
>
> >> xmlnames.output = XMLNames.cpp
> >> xmlnames.input = XML_NAMES
> >> xmlnames.script = $$PWD/dom/make_names.pl
> >> xmlnames.commands = perl -I$$PWD/bindings/scripts $$xmlnames.script
> --attrs $$PWD/xml/xmlattrs.in --preprocessor \"$${QMAKE_MOC} -E\"
> --outputDir ${QMAKE_FUNC_FILE_OUT_PATH}
> >> GENERATORS += xmlnames
>
> Gyp kind of seems like an outlier in heaviness of the syntax compared to
> the other build systems.The irony is that Python itself doesn't use a lot
> of punctuation in its syntax, so actual Python code looks much cleaner. I
> like to read Python code, but I can't say I enjoy reading the Gyp syntax.
> This makes me wonder if a Python DSL might be more legible than simply
> using a dictionary.
>
> Alternately, maybe it turns out that parsing a custom language is not that
> huge a hit in practice.
>
> Regards,
> Maciej
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130205/631a73d1/attachment.html>
More information about the webkit-dev
mailing list