gecko/python
Gregory Szorc 8e72b6e44d Bug 848530 - Check for moz.build traversal at top of build; r=glandium
One of the first actions an invoked Makefile now does is check to see if
*any* moz.build file or Makefile.in is out of date. If so, config.status
is executed to rebuild the build backend.

Since we always perform this check as part of a build, we no longer need
special handling for out of date moz.build files during traversals. This
results in the removal of a significant amount of code!

Another upside of the change is that if a moz.build file is modified
during building, we don't (potentially) modify the build backend from
under the in-progress build. Thus the only race condition that remains
is if a moz.build is mutated during moz.build reading. This window (a
few seconds) is significantly shorter than the time of a full build
(minutes).

This patch should also enable us to remove empty Makefile.in files
without requiring a clobber.
2013-05-17 10:54:56 -07:00
..
blessings
codegen Bug 462463 - Stop using mddepend.pl. r=ted 2013-04-09 15:10:25 -07:00
mach Bug 799680 - Add a bash completion script for mach [r=gps] 2013-05-15 17:00:01 -07:00
mock-1.0.0
mozboot Bug 856392 - Categorize mach commands; r=jhammel 2013-05-08 17:56:30 -07:00
mozbuild Bug 848530 - Check for moz.build traversal at top of build; r=glandium 2013-05-17 10:54:56 -07:00
psutil Bug 870575 - Upgrade psutil to 0.7.1; rs=me 2013-05-09 15:39:30 -07:00
simplejson-2.1.1
virtualenv Bug 837631 - Refresh virtualenv.py to pick up the changes from 661f7866da20. r=gps 2013-02-06 16:58:09 -05:00
which
Makefile.in Bug 677452 - Add smartmake-like functionality to |mach build DIR|. r=gps 2013-05-01 15:36:05 -07:00
moz.build Bug 855465 - Add emacs python mode comments to moz.build files; r=gps 2013-04-01 11:36:59 -07:00
README

This directory contains common Python code.

The basic rule is that if Python code is cross-module (that's "module" in the
Mozilla meaning - as in "module ownership") and is MPL-compatible, it should
go here.

What should not go here:

* Python that is not MPL-compatible (see other-licenses/)
* Python that has good reason to remain close to its "owning" (Mozilla)
  module (e.g. it is only being consumed from there).

Historical information can be found at
https://bugzilla.mozilla.org/show_bug.cgi?id=775243