On 08/22/2012 11:19 PM, Mike Hommey wrote:
On Wed, Aug 22, 2012 at 01:38:22PM -0700, Gregory Szorc wrote:
On 8/22/12 1:00 PM, Ben Hearsum wrote:
On 08/22/12 12:43 PM, Jeff Hammel wrote:
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.
A million times this. Putting our configs in Python has let to terrible,
terrible hacks - to the point where we don't even know how to do things
like "turn off leopard tests for some branches" anymore
(https://bugzilla.mozilla.org/show_bug.cgi?id=773120). I strongly
discourage using Python when you don't need a fully featured language.
You will do bad things. You will regret it.
There are a lot of bullets in "batteries included" languages. The
Python foot gun worries me greatly. We even have this problem in
make, and that is a much simpler language!
As I said on irc, i think the "language" for build manifests should be
something between .ini and jar.mn. Because they're simple,
straightforward, and are well known. And simple.
I understand why people are eager to use python or lua, or other
scripting languages. But the fact is you really only need scripting in
very rare cases. The vast majority of our build is "take this file, put
it there", "take this file, preprocess it, put it there", "compile this"
or "link that". And occasionally, we need to add flags for specific files.
The build manifests should make defining those extremely simple.
There's also the case of conditionals. But i think the vast majority of
the conditionals we use are of the type "do this only on windows", or
"do this only on arm"
The few remaining things can have python scripts, but let's worry about
them later.
Mike
Maybe the thing to do is to stub this out for a few existing cases in
various formats and see how they look. It seems like the consensus is
that the format should be
- as simple as possible
- self-evident: easy to write, easy to edit, preferably something
Mozillians are familiar with
- able to do the simple things simply
- able to handle complex specialization for the cases that require it
But its hard (for me, anyway) to visualize what this would look like
without seeing more concrete proposals.
If .ini suffices, I am all for it.
Jeff
P.S. In the past, I was quite fond of buildit:
http://agendaless.com/Members/chrism/software/buildit . AFAIK, it is not
actively maintained, but it could be a source of inspiration.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
