On 12-08-23 12:46 AM, Nicholas Nethercote wrote:
So...
Data-only formats such as JSON are too weak -- no comments, no conditionals.
Full languages (e.g. Python, Lua) are too powerful, which means it's
too tempting to use the full language features.
Should you invent something new? If it's just lists, maps, comments
and conditionals, that should be easy. And looking at Gregory's
initial list of eight requirements, it sounds like they could be
satisfied nicely.
Unfortunately inventing something new is only appealing on paper. Let
me give you a concrete example of what is wrong with one of the new
formats we invented (xpcshell tests manifest). [1] I recently had to
disable a test which was failing very often in order to make the tree
green. So, thinking that the manifest files are regular ini files, I
just commented it out [2] and... boom! The build system blew up when
trying to use the manifest file to figure out what tests are run. Then,
puzzled by why comments do not do what they would normally do in ini
files, I removed the commented out line [3] (surely if the test name is
not mentioned, it won't run, right?). Wrong. We check to make sure
that all xpcshell js files *are* mentioned in the manifest file.
Frustrated to find this out on the Tinderbox machines, I cried for help
on IRC. And then people pointed me to this blatantly unfamiliar syntax
which needs to be used if you want to disable a test. [4]
I think Gregory's suggestion of using the python's ast module to limit
the sorts of syntax constructs that we accept in the build manifest
files is a great one. That would let us make python powerful enough for
our needs, but not more powerful. And we can easily advertize the build
scripts as "python files that only allow variable assignments and
conditionals, etc." The advantage of not inventing a new language is
too high for us to give up, IMO.
Cheers,
Ehsan
[1] Don't be tricked by its looks. xpcshell.ini's are _not_ normal ini
files. They have semantics built on top of ini, because ini was not
powerful enough for our needs there.
[2] http://hg.mozilla.org/mozilla-central/rev/1ff862485759
[3] http://hg.mozilla.org/mozilla-central/rev/39b384528de3
[4] http://hg.mozilla.org/mozilla-central/rev/d88590f8a245
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
