On 8/22/12 11:48 PM, Dirkjan Ochtman wrote:
On Wed, Aug 22, 2012 at 1:36 AM, Gregory Szorc <g...@mozilla.com> wrote:
Up until now, the focus has been on making Makefile.in's themselves generic
and data-driven [1]. We would use pymake's API to parse, load, and extract
data from Makefile.in's to construct the build definition. In the long run,
we'd realize that using make files for data definition was silly (and a
large foot gun) and thus we would switch to something else.
Can you expand on that? From the discussion so far, JSON is not
expressive enough and Python is too expressive. There are some very
understandable reservations about inventing a new language, as well as
the desire for a "clean slate" (admittedly attractive). Why doesn't it
make sense to use a very-restricted dialect of Makefiles? pymake
already has a parser, the dumbing down of which to disallow arbitrary
shell expressions would supposedly be fairly straightforward. No one
would have to learn a new language, and you can start with the current
files, duplicate the parser inside pymake, then start to dumb it down
as you weed the complexity out of the Makefile.ins.
Yes, we could use a subset of make to define things. On the surface, the
functionality is just what you want: simple conditionals, built-in
functions, simple appends, well-understood (more or less). Using make
*is* very tempting. And, we could probably use pymake as-is: we could
validate the parser's "statement list" output for conformance with our
limited make dialect. We should seriously consider using make files,
albeit in a restricted form to make parsing easier.
That being said, there are a few cons:
* Everything is a string. There is no null, false, true, or arrays. "if"
is "ifneq (,$(foo))" or even "ifneq (,$(strip $(foo)))" in case some
extra whitespace snuck in there. Arrays are strings delimited by
whitespace. This results in lots of ugly and hard-to-read code. Maps
don't exist at all. So, you have to normalize everything down to
key-value pairs. This results in weird foo like the library/module or
EXPORTS boilerplate.
* Syntax for complex behavior is hard to read. You inevitably need to
call functions for more advanced behavior. This results in code like
https://hg.mozilla.org/mozilla-central/file/ad7963c93bd8/config/rules.mk#l1623.
That's just as bad as poorly-written Perl. And, unlike Perl, it *has* to
be that way. Fortunately, this complexity *should* be hidden to everyone
but build system people. But, we need to maintain it and that's no fun.
* Performance issues. = in make is deferred assignment. There's a lot of
overhead in resolving values (although bsmedberg proposed a solution for
pymake that may combat this).
* Might require stapling some new features onto pymake. Not a deal breaker.
Individually, they aren't too bad. A lot are superficial. But, when you
combine them, it gets ugly.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
