On 08/22/2012 06:50 AM, Benjamin Smedberg wrote:
On 8/21/2012 7:36 PM, Gregory Szorc wrote:
On the other end of the spectrum, we could have the build manifest
files be Python "scripts." This solves a lot of problems around
needing functionality in the manifest files. But, it would be a
potential foot gun. See requirement #7.
I don't think this would be a big deal. We could just enforce no side
effects at review, or with a small bit of python we could enforce some
basic restraints in code:
* allow imports from only a small whitelist of known-safe modules:
perhaps just 're', or disallow imports altogether (by modifying the
globals in the execution environment) and pre-import the safe modules
* "fix" output variables to ensure that they are the expected
string/list-of-strings/whatever types
I really think that python manifests are the best choice here, since
python is already optimized to parse them efficiently, the control
structures are fairly straightforward, and most people (both regular
engineers and build-sytem hackers) are going to know enough to get
started without confusion.
One thing that wasn't clear to me from the original post is whether we
are planning on automatically transforming some parts of the existing
makefiles (e.g. DIRS, EXPORTS, preprocessor stuff) into the new
manifest format, or whether the plan is to just migrate by hand. Or is
that still TBD?
--BDS
I don't have a magic bullet here. My inclination is to not introduce
new technology/languages/syntax to keep the learning curve lower/comparable.
If we're going to go for a whole language, I am +1 on python. We
already use it...well, all over the place. It is well known, solid, and
not "yet another thing to learn or syntax switch" to. Unless a very
compelling argument argument could be made for the functionality of
other languages vs python for this problem space, python seems a natural
solution and can build on our existing python ecosystem (which likewise
can grow driven by needs here).
My actual inclination is to use a pure data format. I'm not sure if
.ini is sufficient: guessing not. My inclination here is JSON. That
said, it won't have conditionals or logic, so as :gps puts it, these
would have to be shoehorned in. To expand on that a bit, the different
platforms/configurations/states will have to be recorded and the runner
would have to have the logic to decide what to use. I haven't looked at
this problem in depth, so I don't know how good/bad/horrible this would
be in practice.
If we do go with python, it would be nice to keep the configuration
files as much configuration as possible. The reason I question having
any "full" language as a configuration language is that in practice I
see a lot of logic creep in to "configuration" files and then they
become very difficult for a consumer to parse/use as configuration.
While a bit of an unfair example, our buildbot-configs fall into this
category.
TL;DR - python if we want/need a full language, JSON if we can get away
with POD
Jeff
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
