Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
On Monday, February 04, 2013 10:57:46 AM Maciej Stachowiak wrote:
On Feb 4, 2013, at 10:46 AM, Mark Mentovai m...@chromium.org wrote:
GYP was written in Python to address point (b). Python was already part of
the baseline requirements on all platforms, so we already had Python
available everywhere we needed it. There are no dependencies on external
binaries, and no compiled code needs to be checked in anywhere or
maintained as part of a base image.
As for point (a), you can easily have a top-level Makefile not generated
by GYP that says “run GYP to produce the build files for whatever
environment you like and then pass control to that build system to do the
rest of the build. Developers who like it can use ninja for their own
builds, and your bots can use Xcode or make if that’s a requirement (or
if ninja doesn’t meet your requirements given point (b)).
Checking in the generated Xcode projects is another alternative. The
Makefile might be better for the reasons you suggest, though.
I'm reasonably confident at this point that Gyp can meet our hard
requirements. Our remaining issues are finding time to do it and
comprehensibility/readability of the syntax.
On the topic of the Gyp syntax:
I find it pretty readable, but I wonder if you guys are open to the idea of
relaxing the parser a bit to also allow for the omission of quotes and commas
for the dictionary keys. I feel a syntax like
{
includes: [
...
]
variables: [
]
}
is slightly less error prone to type and you could probably still support the
stricter language, too.
Simon
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
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.
With that in mind, I’d be open to experimenting with alternative (probably
optional) formats.
On Tue, Feb 5, 2013 at 7:48 AM, Simon Hausmann simon.hausm...@digia.comwrote:
On Monday, February 04, 2013 10:57:46 AM Maciej Stachowiak wrote:
On Feb 4, 2013, at 10:46 AM, Mark Mentovai m...@chromium.org wrote:
GYP was written in Python to address point (b). Python was already
part of
the baseline requirements on all platforms, so we already had Python
available everywhere we needed it. There are no dependencies on
external
binaries, and no compiled code needs to be checked in anywhere or
maintained as part of a base image.
As for point (a), you can easily have a top-level Makefile not
generated
by GYP that says “run GYP to produce the build files for whatever
environment you like and then pass control to that build system to do
the
rest of the build. Developers who like it can use ninja for their own
builds, and your bots can use Xcode or make if that’s a requirement (or
if ninja doesn’t meet your requirements given point (b)).
Checking in the generated Xcode projects is another alternative. The
Makefile might be better for the reasons you suggest, though.
I'm reasonably confident at this point that Gyp can meet our hard
requirements. Our remaining issues are finding time to do it and
comprehensibility/readability of the syntax.
On the topic of the Gyp syntax:
I find it pretty readable, but I wonder if you guys are open to the idea of
relaxing the parser a bit to also allow for the omission of quotes and
commas
for the dictionary keys. I feel a syntax like
{
includes: [
...
]
variables: [
]
}
is slightly less error prone to type and you could probably still support
the
stricter language, too.
Simon
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Gated trunk, experiences from OpenStack
Do you know how they got rid of flakiness in their tests? We've spent a bunch of effort fixing flaky tests (and in marking the remaining flaky tests as flaky), but there's still a long tail of flakiness. I wonder if that sort of thing might be different for OpenStack if they have a different approach to testing than we do. Adam On Mon, Feb 4, 2013 at 5:14 PM, Tim Ansell mit...@mithis.com wrote: Hey guys, Last week a number of the team here at Google Sydney, including myself attended Linux.conf.au 2013 conference. The conference was a blast and the hot topic this year was OpenStack, an Open Source Cloud layer. The OpenStack project has grown from being a small project to having over 500 active committers and continues to grow at a rapid pace. Both the Continuous Integration Miniconf (http://lca2013.linux.org.au/schedule/30102/view_talk?day=monday) and main conference included talks from OpenStack leaders about how they have tried to handle this growth and I think we can learn from their successes and failures. All of the OpenStack's infrastructure is documented in the following talks http://openstack-ci.github.com/publications/ I pulled the following stats to see how comparable the projects are; OpenStack; (http://openstack-ci.github.com/publications/lca2013-ci/index.html#(3)) Over 500 Active Technical Contributors As many as 200 trunk changes an hour 18 (integrated) projects (and growing) I tried looking these up in WebKit and got the following; ~200 active contributors As many as ~12 trunk changes an hour 1 project, but 7 target platforms One of the most interesting parts of OpenStack was having a gated trunk. From their talk; Before each change to the OpenStack projects is merged into the main tree, unit and integration tests are run on the change, and only if they pass, is the change merged. We call this gating. There is a lot of debate about the value of a gated trunk on the internet; which I'm not going to repeat here. OpenStack's experience has been that it preserves the following properties; http://openstack-ci.github.com/publications/lca2013-ci/index.html#(9) Ensures Code Quality Protects developers Devs always start from working code Protects tree Bad code doesn't land Egalitarian Process is the same for everyone Process is transparent Process is automated These are all things that came up in Eric's WebKit wishes email specially the parts about having an always green tree. The egalitarian nature of the system also helps with trusting people as you *know* they can not break the tree. This system is similar to our commit queue, however nobody has privileges to bypass the queue. OpenStack has 18 projects which are all tightly integrated, for example a change in the API in one project could break another project, for this reason they gate changes on tests runs from all projects before allowing a commit to land to any of them. While WebKit is only a single project, the process of requiring multiple jobs to be green is similar to WebKit needing to support multiple platforms. They do point out that when this system is set up, the system has to be ultra repeatable and reliable; Once everything is automated, the projects stops if the automation does - http://openstack-ci.github.com/publications/lca2013-ci/index.html#(8) To allow this to happen, OpenStack has managed to eliminated all flaky tests in their suite. WebKit is not at this stage and still has a large number tests which are both failing and/or flaky. Luckily, WebKit has much better infrastructure for dealing with and tracking them down. Other things they have done to try and make this process work are; Like WebKit, every patch is required to have code review before being submitted. OpenStack requires two positive reviews before allowing a commit to be submitted, rather than the single one that WebKit needs. Like WebKit, OpenStack has an early warning system which runs all tests as soon as a patch is submitted. The complete OpenStack test suite takes around ~1 hour to run, but as they have more than 1 event per hour their landing system needs pipelining. They have developed a system called Zuul to make this happen. Before they had this pipeline process, committing was taking many hours to land. You can see their currently running system at http://zuul.openstack.org/ and find out more about Zuul at the following locations; Zuul: a Pipelining Trunk Gating System http://amo-probos.org/post/14 http://mirror.linux.org.au/linux.conf.au/2013/ogv/OpenStack_Zuul.ogv I guess this is something we should discuss further. Tim 'mithro' Ansell ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org
Re: [webkit-dev] Gated trunk, experiences from OpenStack
On Tue, Feb 5, 2013 at 9:28 AM, Adam Barth aba...@webkit.org wrote: Do you know how they got rid of flakiness in their tests? We've spent a bunch of effort fixing flaky tests (and in marking the remaining flaky tests as flaky), but there's still a long tail of flakiness. I wonder if that sort of thing might be different for OpenStack if they have a different approach to testing than we do. Another useful thing is to know the number of tests in OpenStack. WebKit has more tests than any other project I've worked on. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
On Tue, Feb 5, 2013 at 6:09 AM, Mark Mentovai m...@chromium.org wrote: The parser (and the grammar) works the way it does because it’s just Python This works great for people who like Python syntax but not for someone like myself who dislikes Python syntax. I also find it particularly annoying that people can use whatever Python constructs they want to use in GYP. It dramatically reduces language portability because you need to support quite a few Python constructs and quirks in order to correctly parse GYP. I personally would have much preferred for it be a simple JSON file. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
You’re not supposed to use arbitrary Python, it’s highly discouraged. We have a linter that keeps you from doing things you’re not supposed to do (like this), but it slows things down, so it’s not part of the “standard” GYP run that developers normally use. It can run as a pre-commit script or test on the bot or something else. Used as we’re using it, GYP basically is simple JSON, except the rules about commas are looser and # introduces comments. On Tue, Feb 5, 2013 at 2:47 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Feb 5, 2013 at 6:09 AM, Mark Mentovai m...@chromium.org wrote: The parser (and the grammar) works the way it does because it’s just Python This works great for people who like Python syntax but not for someone like myself who dislikes Python syntax. I also find it particularly annoying that people can use whatever Python constructs they want to use in GYP. It dramatically reduces language portability because you need to support quite a few Python constructs and quirks in order to correctly parse GYP. I personally would have much preferred for it be a simple JSON file. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
I'm curious if YAML was ever considered? I have very limited experience with YAML, except for Google App Engine config files. It's very python parse-able? :) On Tue, Feb 5, 2013 at 11:55 AM, Mark Mentovai m...@chromium.org wrote: You’re not supposed to use arbitrary Python, it’s highly discouraged. We have a linter that keeps you from doing things you’re not supposed to do (like this), but it slows things down, so it’s not part of the “standard” GYP run that developers normally use. It can run as a pre-commit script or test on the bot or something else. Used as we’re using it, GYP basically is simple JSON, except the rules about commas are looser and # introduces comments. On Tue, Feb 5, 2013 at 2:47 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Feb 5, 2013 at 6:09 AM, Mark Mentovai m...@chromium.org wrote: The parser (and the grammar) works the way it does because it’s just Python This works great for people who like Python syntax but not for someone like myself who dislikes Python syntax. I also find it particularly annoying that people can use whatever Python constructs they want to use in GYP. It dramatically reduces language portability because you need to support quite a few Python constructs and quirks in order to correctly parse GYP. I personally would have much preferred for it be a simple JSON file. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Gated trunk, experiences from OpenStack
On Tue, Feb 5, 2013 at 9:46 AM, Martin Robinson mrobin...@webkit.org wrote: On Tue, Feb 5, 2013 at 9:28 AM, Adam Barth aba...@webkit.org wrote: Do you know how they got rid of flakiness in their tests? We've spent a bunch of effort fixing flaky tests (and in marking the remaining flaky tests as flaky), but there's still a long tail of flakiness. I wonder if that sort of thing might be different for OpenStack if they have a different approach to testing than we do. Another useful thing is to know the number of tests in OpenStack. WebKit has more tests than any other project I've worked on. There are two other related aspects that make our tests flaky: 1) They're very high level integration tests (mostly), which, as they cover large swaths of code in each test, are much more susceptible to flakiness than method-level unit tests. 2) They weren't generally written to be run in parallel, and thus we often have to be concerned with system-level resource contention. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
http://www.haskell.org/haskellwiki/Wadlers_Law On Tue, Feb 5, 2013 at 12:16 PM, Eric Seidel e...@webkit.org wrote: I'm curious if YAML was ever considered? I have very limited experience with YAML, except for Google App Engine config files. It's very python parse-able? :) On Tue, Feb 5, 2013 at 11:55 AM, Mark Mentovai m...@chromium.org wrote: You’re not supposed to use arbitrary Python, it’s highly discouraged. We have a linter that keeps you from doing things you’re not supposed to do (like this), but it slows things down, so it’s not part of the “standard” GYP run that developers normally use. It can run as a pre-commit script or test on the bot or something else. Used as we’re using it, GYP basically is simple JSON, except the rules about commas are looser and # introduces comments. On Tue, Feb 5, 2013 at 2:47 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Feb 5, 2013 at 6:09 AM, Mark Mentovai m...@chromium.org wrote: The parser (and the grammar) works the way it does because it’s just Python This works great for people who like Python syntax but not for someone like myself who dislikes Python syntax. I also find it particularly annoying that people can use whatever Python constructs they want to use in GYP. It dramatically reduces language portability because you need to support quite a few Python constructs and quirks in order to correctly parse GYP. I personally would have much preferred for it be a simple JSON file. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
On Tue, Feb 5, 2013 at 12:20 PM, Nico Weber tha...@chromium.org wrote: http://www.haskell.org/haskellwiki/Wadlers_Law I've started working on an experimental gyp build for GTK+, so I have first-hand experience as a gyp newbie editing .gyp and .gypi files. While the aesthetics of the files haven't bothered me much, I find that it's very easy to introduce syntax errors. I often forget a comma or use the wrong closing parenthesis. Since the files are deeply nested, it's easy to lose track. Most frustratingly the error message from the tool aren't very useful for finding the problem. I usually resort to matching parenthesis with vim's % command and squinting. Other than this, I love it so far. The build file generation is very quick (admittedly I have only a small part of WebKit building) and it seems to handle source generating dependencies really well. This is one of the most painful issues we have with autotools. I also look forward to building with ninja. :) --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Gated trunk, experiences from OpenStack
On Tue, Feb 5, 2013 at 12:17 PM, Dirk Pranke dpra...@chromium.org wrote: There are two other related aspects that make our tests flaky: 1) They're very high level integration tests (mostly), which, as they cover large swaths of code in each test, are much more susceptible to flakiness than method-level unit tests. 2) They weren't generally written to be run in parallel, and thus we often have to be concerned with system-level resource contention. 3) WebKit runs on top of large imperfect platforms. The frameworks we use have bugs too. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
On Feb 5, 2013, at 6:09 AM, Mark Mentovai m...@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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
On Tue, Feb 5, 2013 at 12:59 PM, Maciej Stachowiak m...@apple.com wrote: 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). As much as I don't like Xcode project file, they are not to be edited by hand. It is easy to edit Xcode project file because there is a graphical tool that makes the task easy. There is no such tool for gyp so its syntax is important. TestExpectations is a success story of making unreadable files, readable. We should consider it for gyp if it were to become the standard tool for everyone. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
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 m...@apple.com wrote:
On Feb 5, 2013, at 6:09 AM, Mark Mentovai m...@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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
On 02/05/2013 12:59 PM, Maciej Stachowiak wrote: 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). Ant is pretty verbose as well, partially due to the XML syntax. It is sometimes generated by tools (IDEs) and sometime written by hand. (Because Ant is implemented in Java and primarily aimed at building Java projects, it's not a good match for WebKit, regardless.) -- --Per Bothner per.both...@oracle.com p...@bothner.com http://per.bothner.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Better syntax for GYP (Was Common build system; was Re: WebKit Wishes)
On Tue, Feb 5, 2013 at 1:36 PM, Mark Mentovai m...@chromium.org wrote:
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.
The syntax has always been the biggest problem when it comes to adopting
GYP in WebKit.
Let's take the following as an example as picked by Maciej
{
'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,
},
Using a YAML-like syntax, we can rewrite it as:
XMLName:
inputs:
(SHARED_INTERMEDIATE_DIR)/../dom/make_names.pl
(SHARED_INTERMEDIATE_DIR)/../xml/xmlattrs.in
outputs:
XMLNames.cpp
XMLNames.h
action:
python scripts/action_makenames.py @(_outputs) -- @(_inputs) --
--extraDefines (feature_defines)
msvs_cygwin_shell: True
To me, this YAML-like syntax reads significantly better.
Now, I don't like all the magic strings like (SHARED_INTERMEDIATE_DIR)/../
and @(_outputs) -- @(_inputs) -- --extraDefines (feature_defines).
Can someone with build system knowlede prettify them?
- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Better syntax for GYP (Was Common build system; was Re: WebKit Wishes)
I work on the build system for Firefox and have some experience that
might be worth sharing.
We (Mozilla) evaluated GYP as the replacement for Makefile.in files.
While we generally love the concept of GYP (assemble data structures
then transform them N ways to whatever build backend/tool format you
want), we didn't really care for GYP's frontend file format. A static
file format like JSON, YAML, XML, etc just doesn't feel right,
especially when you need to do things like if X Y then do these things.
After a significant conversation on one of our main developer lists [1]
(many parts relevant to this post), we flirted with ini-like manifests
and Lua (it was invented as a config file language after all) but
eventually chose sandboxed Python. Once we decided to go with a real
programming language, the choice of Python was easy, as that is what
most of our tools are written in.
Instead of Makefile.in or .gyp files, we have what are called
moz.build files. These are actually Python scripts executed in a
highly limited Python environment (no importing, no I/O, etc). We define
special functions and variables. At the end of each file's execution, we
extract values from the symbol table then construct data structures
representing the build configuration. At this point, we essentially have
arrived at the backend portion of GYP.
See [2] for slides with some examples. A technical readme exists at [3].
The main code lives at [4] and [5]. The sandboxing code [4] is the real
bread and butter. With relative ease it can be extracted from the
Firefox source tree (we'd like to eventually have it live on PyPI).
Unfortunately, we haven't yet landed the initial switchover, so I can't
tell you how the experience has been received. Having personally
converted large portions of our source tree to use moz.build files, I
can say that it feels much better writing real code as opposed to
shoehorning procedural logic into something like YAML.
We have aspirations of eventually hooking our moz.build-derived data
structures into GYP (why reinvent the build backend generation wheel).
If that works out well, we speculated we could contribute the Python
sandboxing code to GYP as an alternate frontend file format or at least
make it available as a standalone package. But this is so far out that
it's only wishful thinking. If WebKit or some other large GYP-using
project were interested, I'd love to explore possibilities of unifying
solutions.
I don't actively follow this mailing list, so please CC me on any
replies. You can also find me as gps on irc.mozilla.org (try #build).
Gregory Szorc
gregory.sz...@gmail.com
[1]
https://groups.google.com/d/topic/mozilla.dev.platform/SACOnl-avMs/discussion
[2]
http://gregoryszorc.com/presentations/2012-11-29-firefox-build-system/#41
[3]
https://hg.mozilla.org/mozilla-central/file/1eab3e0d7f53/python/mozbuild/mozbuild/frontend/README.rst
[4]
https://hg.mozilla.org/mozilla-central/file/1eab3e0d7f53/python/mozbuild/mozbuild/frontend/sandbox.py
[5]
https://hg.mozilla.org/mozilla-central/file/1eab3e0d7f53/python/mozbuild/mozbuild/frontend/reader.py
On 2/5/13 2:01 PM, Ryosuke Niwa wrote:
On Tue, Feb 5, 2013 at 1:36 PM, Mark Mentovai m...@chromium.org
mailto:m...@chromium.org wrote:
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.
The syntax has always been the biggest problem when it comes to adopting
GYP in WebKit.
Let's take the following as an example as picked by Maciej
{
'action_name': 'XMLNames',
'inputs': [
'../dom/make_names.pl http://make_names.pl',
'../xml/xmlattrs.in http://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,
},
Using a YAML-like syntax, we can rewrite it as:
XMLName:
inputs:
(SHARED_INTERMEDIATE_DIR)/../dom/make_names.pl
http://make_names.pl
(SHARED_INTERMEDIATE_DIR)/../xml/xmlattrs.in http://xmlattrs.in
outputs:
XMLNames.cpp
XMLNames.h
action:
python scripts/action_makenames.py @(_outputs) --
Re: [webkit-dev] Gated trunk, experiences from OpenStack
On 6 February 2013 07:17, Dirk Pranke dpra...@chromium.org wrote: On Tue, Feb 5, 2013 at 9:46 AM, Martin Robinson mrobin...@webkit.org wrote: On Tue, Feb 5, 2013 at 9:28 AM, Adam Barth aba...@webkit.org wrote: Do you know how they got rid of flakiness in their tests? We've spent a bunch of effort fixing flaky tests (and in marking the remaining flaky tests as flaky), but there's still a long tail of flakiness. I wonder if that sort of thing might be different for OpenStack if they have a different approach to testing than we do. From what I can see they have a pretty similar goal to us. I personally don't know where our test flakyness comes from, so can't really comment on how we could fix it. Another useful thing is to know the number of tests in OpenStack. WebKit has more tests than any other project I've worked on. There are two other related aspects that make our tests flaky: 1) They're very high level integration tests (mostly), which, as they cover large swaths of code in each test, are much more susceptible to flakiness than method-level unit tests. While OpenStack doesn't have anywhere near the number of integration tests WebKit does, it does have large integration tests. Infact, one of their tests brings up a whole cloud stack and checks that you can operate the cluster. 2) They weren't generally written to be run in parallel, and thus we often have to be concerned with system-level resource contention. Neither where OpenStack's originally. They made heavy use of tool called * testr* ( http://pypi.python.org/pypi/testrepository ) which has a mode to automatically find when two tests are interfering with each other. testr also has a bunch of other useful features, like only re-running tests which are currently failing and keeping a database of test runs and allowing stat collection. We too could use testr if our tests output the subunit format. The subunit format was originally developed for python and has excellent python support so I think it should be pretty trivial to add. Tim 'mithro' Ansell ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Better syntax for GYP (Was Common build system; was Re: WebKit Wishes)
On Feb 5, 2013, at 2:01 PM, Ryosuke Niwa rn...@webkit.org wrote: Using a YAML-like syntax, we can rewrite it as: XMLName: inputs: (SHARED_INTERMEDIATE_DIR)/../dom/make_names.pl (SHARED_INTERMEDIATE_DIR)/../xml/xmlattrs.in outputs: XMLNames.cpp XMLNames.h action: python scripts/action_makenames.py @(_outputs) -- @(_inputs) -- --extraDefines (feature_defines) msvs_cygwin_shell: True To me, this YAML-like syntax reads significantly better. It does seem like an improvement. Maybe inputs and outputs could also be space-separated instead of newline separated, like the action. That would still have a bit more overhead than make syntax, but at least it would be meaningful labels, rather than punctuation and newlines. Now, I don't like all the magic strings like (SHARED_INTERMEDIATE_DIR)/../ and @(_outputs) -- @(_inputs) -- --extraDefines (feature_defines). Can someone with build system knowlede prettify them? It's necessary to have some kind of syntax for variable expansion in the action command, and it likely can't be too verbose. Though something involving the $ character might look more obviously like a variable expansion. - Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
I have looked at YAML off and on over the years, and I'm not sure that it would be much of an improvement in this case. I do believe that dropping the strict python syntax could make some things easier to read. I don't have a fully-baked proposal in mind, and I don't know what the perf hit would be. I will also note that -- like in many languages -- it's easy to write hard-to-read files. GYP has never had much of a style guide, and it probably could greatly benefit from one. It is important to make a fair apples-to-apples comparison for whatever we end up looking at. I suspect that given any tool or language, you can find some things that are easy to express and some that are harder. Even the existing chromium gyp files are not necessarily a model of clean code or good style. Also, one thing that's important to realize about GYP's syntax is that it is very set-based; the order things appear in the files is much less important than in many other languages (especially in how they handle conditionals, i.e., if/then/else). This has many advantages, but does also have some disadvantages. -- Dirk On Tue, Feb 5, 2013 at 12:16 PM, Eric Seidel e...@webkit.org wrote: I'm curious if YAML was ever considered? I have very limited experience with YAML, except for Google App Engine config files. It's very python parse-able? :) On Tue, Feb 5, 2013 at 11:55 AM, Mark Mentovai m...@chromium.org wrote: You’re not supposed to use arbitrary Python, it’s highly discouraged. We have a linter that keeps you from doing things you’re not supposed to do (like this), but it slows things down, so it’s not part of the “standard” GYP run that developers normally use. It can run as a pre-commit script or test on the bot or something else. Used as we’re using it, GYP basically is simple JSON, except the rules about commas are looser and # introduces comments. On Tue, Feb 5, 2013 at 2:47 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Feb 5, 2013 at 6:09 AM, Mark Mentovai m...@chromium.org wrote: The parser (and the grammar) works the way it does because it’s just Python This works great for people who like Python syntax but not for someone like myself who dislikes Python syntax. I also find it particularly annoying that people can use whatever Python constructs they want to use in GYP. It dramatically reduces language portability because you need to support quite a few Python constructs and quirks in order to correctly parse GYP. I personally would have much preferred for it be a simple JSON file. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
On Tue, Feb 5, 2013 at 5:33 PM, Dirk Pranke dpra...@chromium.org wrote: I have looked at YAML off and on over the years, and I'm not sure that it would be much of an improvement in this case. I do believe that dropping the strict python syntax could make some things easier to read. I don't have a fully-baked proposal in mind, and I don't know what the perf hit would be. I will also note that -- like in many languages -- it's easy to write hard-to-read files. GYP has never had much of a style guide, and it probably could greatly benefit from one. I'm hopeful that we can come up with a syntax that doesn't require style guide. I'd even go as far as to say we shouldn't adopt a syntax that needs a style guide. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Gated trunk, experiences from OpenStack
On Tue, Feb 5, 2013 at 3:34 PM, Tim Ansell mit...@mithis.com wrote: On 6 February 2013 07:17, Dirk Pranke dpra...@chromium.org wrote: On Tue, Feb 5, 2013 at 9:46 AM, Martin Robinson mrobin...@webkit.org wrote: On Tue, Feb 5, 2013 at 9:28 AM, Adam Barth aba...@webkit.org wrote: Do you know how they got rid of flakiness in their tests? We've spent a bunch of effort fixing flaky tests (and in marking the remaining flaky tests as flaky), but there's still a long tail of flakiness. I wonder if that sort of thing might be different for OpenStack if they have a different approach to testing than we do. From what I can see they have a pretty similar goal to us. I personally don't know where our test flakyness comes from, so can't really comment on how we could fix it. Another useful thing is to know the number of tests in OpenStack. WebKit has more tests than any other project I've worked on. There are two other related aspects that make our tests flaky: 1) They're very high level integration tests (mostly), which, as they cover large swaths of code in each test, are much more susceptible to flakiness than method-level unit tests. While OpenStack doesn't have anywhere near the number of integration tests WebKit does, it does have large integration tests. Infact, one of their tests brings up a whole cloud stack and checks that you can operate the cluster. 2) They weren't generally written to be run in parallel, and thus we often have to be concerned with system-level resource contention. Neither where OpenStack's originally. They made heavy use of tool called testr ( http://pypi.python.org/pypi/testrepository ) which has a mode to automatically find when two tests are interfering with each other. testr also has a bunch of other useful features, like only re-running tests which are currently failing and keeping a database of test runs and allowing stat collection. Ah, the testr isolation bisection does look interesting. I have done a little work along those lines but haven't gotten very far. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Gated trunk, experiences from OpenStack
testr is already a great way to record test runs and collect stats on them. I'd really love it if we could contribute to testr some of our flakyness stuff. Flakyness plagues all projects and having awesome tools would help a lot of people, not just us. Tim On 6 February 2013 12:55, Dirk Pranke dpra...@chromium.org wrote: On Tue, Feb 5, 2013 at 3:34 PM, Tim Ansell mit...@mithis.com wrote: On 6 February 2013 07:17, Dirk Pranke dpra...@chromium.org wrote: On Tue, Feb 5, 2013 at 9:46 AM, Martin Robinson mrobin...@webkit.org wrote: On Tue, Feb 5, 2013 at 9:28 AM, Adam Barth aba...@webkit.org wrote: Do you know how they got rid of flakiness in their tests? We've spent a bunch of effort fixing flaky tests (and in marking the remaining flaky tests as flaky), but there's still a long tail of flakiness. I wonder if that sort of thing might be different for OpenStack if they have a different approach to testing than we do. From what I can see they have a pretty similar goal to us. I personally don't know where our test flakyness comes from, so can't really comment on how we could fix it. Another useful thing is to know the number of tests in OpenStack. WebKit has more tests than any other project I've worked on. There are two other related aspects that make our tests flaky: 1) They're very high level integration tests (mostly), which, as they cover large swaths of code in each test, are much more susceptible to flakiness than method-level unit tests. While OpenStack doesn't have anywhere near the number of integration tests WebKit does, it does have large integration tests. Infact, one of their tests brings up a whole cloud stack and checks that you can operate the cluster. 2) They weren't generally written to be run in parallel, and thus we often have to be concerned with system-level resource contention. Neither where OpenStack's originally. They made heavy use of tool called testr ( http://pypi.python.org/pypi/testrepository ) which has a mode to automatically find when two tests are interfering with each other. testr also has a bunch of other useful features, like only re-running tests which are currently failing and keeping a database of test runs and allowing stat collection. Ah, the testr isolation bisection does look interesting. I have done a little work along those lines but haven't gotten very far. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
