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

[Maciej Stachowiak]

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