canmove, Confirmed users
409
edits
Build config/Projects: Difference between revisions
Jump to navigation
Jump to search
m
fix grouping
(initial - content from https://etherpad.mozilla.org/build-system-goals) |
m (fix grouping) |
||
| Line 90: | Line 90: | ||
The nose package has solved many of these problems and integrating it into the tree would make a lot of the issues go away. | The nose package has solved many of these problems and integrating it into the tree would make a lot of the issues go away. | ||
This will likely involve defining Python unit tests in moz.build files somehow. We can probably define things as a directory containing test files plus an optional regex used to discover them. Generally speaking, nose's algorithm for finding tests is pretty robust. Worst case, we can adapt our existing tests that don't conform to its expectations. This is probably a good idea anyway. | This will likely involve defining Python unit tests in moz.build files somehow. We can probably define things as a directory containing test files plus an optional regex used to discover them. Generally speaking, nose's algorithm for finding tests is pretty robust. Worst case, we can adapt our existing tests that don't conform to its expectations. This is probably a good idea anyway. | ||
=== Kill client.mk === | === Kill client.mk === | ||
| Line 134: | Line 116: | ||
Another big question is what should mach config files look like? .ini is a popular choice. There are even dialects of .ini that support variable interpolation. We have configobj (http://www.voidspace.org.uk/python/configobj.html) in the tree for a reason. Another option is sandboxed Python. Traditionally, config files are static, so .ini seems like the better fit. However, if we were to put the mozconfig equivalent in mach config files, people tend to utilize the power of shell scripts for branching, etc, so a static .ini format would have hard to support. Perhaps the mach.ini file contains a "[build] config_file =" entry that points to a script to execute. | Another big question is what should mach config files look like? .ini is a popular choice. There are even dialects of .ini that support variable interpolation. We have configobj (http://www.voidspace.org.uk/python/configobj.html) in the tree for a reason. Another option is sandboxed Python. Traditionally, config files are static, so .ini seems like the better fit. However, if we were to put the mozconfig equivalent in mach config files, people tend to utilize the power of shell scripts for branching, etc, so a static .ini format would have hard to support. Perhaps the mach.ini file contains a "[build] config_file =" entry that points to a script to execute. | ||
As you can tell, there's lots of thinking and bikeshedding involved in this goal. It shouldn't be undertaken lightly. That being said, simple mach.ini files without regard for build config/mozconfigs can probably be done with little thought as long as we have an escape plan. | As you can tell, there's lots of thinking and bikeshedding involved in this goal. It shouldn't be undertaken lightly. That being said, simple mach.ini files without regard for build config/mozconfigs can probably be done with little thought as long as we have an escape plan. | ||
== mach == | |||
=== Config file support === | |||
There are many options being landed in mach commands that are effectively user preferences. There is no good way to define sticky defaults for those options. mach needs config files so people can tailor their environments to their liking. We should add config file support to mach. | |||
=== Faster startup === | |||
Mach has become slower as more commands are added. We should look at making it faster. | |||
=== More robust available command support === | |||
Support for detecting what commands are runnable at run-time has been added recently. When you run |mach help| it even prunes the list to commands that should work. We should hook up most of the commands to this mechanism so people can't do things like attempt to run tests when the tree isn't built. | |||
=== Improve comm-central and fxos integration === | |||
Mach integration with comm-central and b2g is fragile. We should make that work so we don't have to continue supporting legacy interfaces and so developers there don't complain so much about not being able to use mach. This is more important than ever since functionality like test running is starting to require mach. | |||
== Developer workflow == | == Developer workflow == | ||