Missing such dependencies shouldn't impair running configure itself
after local modifications, but they are currently required for
(mostly) documentation purpose. Which means they are better done in
the linter.
--HG--
extra : rebase_source : 6bfff2342cda2ed1351f561c9eb9623f1fb4e4c4
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
These config options can be defined in ~/.mozbuild/machrc or topsrcdir/machrc.
Aliases work similar to the identically named option in an hgrc.
For example:
[alias]
browser-test = mochitest -f browser
mochitest = mochitest -f plain
MozReview-Commit-ID: CnOocEslRUI
--HG--
extra : rebase_source : 2a6fa154aca7fea8f159ed840728951a37bc52ec
A few notes:
* This doesn't accommodate general OMNIJAR_NAME definitions. The
current name (assets/omni.ja) is baked into the product in a few
places, and is very unlikely to change, so we just error out if this
isn't true.
* This makes the package-manifest.in file authoritative for what goes
into assets/, libs/, and the APK root. Previously,
package-manifest.in wrote into assets/ and libs/ but
upload-files-APK.mk also had a convoluted DIST_FILES filtering
process to work through before a file actually made it into the APK.
* This is intentional about repackaging. It simplifies the repackage
step rather than trying to make unpackage-then-repackage the same as
just package. I pretty much never get repackaging correct the first
time; this should help. (I've manually tested it.)
* The ALREADY_SZIPPED during repackaging is subsumed by the previous
check if UNPACKAGE is set. The custom linker expects stored, not
deflated, libraries, so there's some small legwork to accommodate
that in mozjar.
MozReview-Commit-ID: JvVtIUSX685
--HG--
extra : rebase_source : fd8a9cfe3dc364d23b1065995db599f99e676e38
This change adds a `Version` type to moz.configure which is a small
wrapper around `distutils.version.Version`. It's suitable for wrapping
version numbers in configure checks and doing equality or greater-than
less-than comparisons in a sensible way.
MozReview-Commit-ID: BOL6yvemulG
--HG--
extra : rebase_source : 3b463eac0499086f8acffda0d01418b6ab17f3d6
extra : amend_source : aebd6e40c408d9f868623b2f53fcdf7455e2fff5
We have many unit tests in the tree for some small parts of the build system
pipeline, but we don't have anything that resembles an end to end test, and we
kind of rely on the resulting Firefox not being broken by our changes.
With the Faster make backend growing, I want to ensure it produces the same
thing as the recursive make backend, at least for the parts it supports.
This adds some kind of test that allows to check that.
mach has restructured text documentation. Let's expose it to the in-tree
Sphinx config so we can increase visibility of the documentation.
--HG--
rename : python/mach/README.rst => python/mach/docs/index.rst
extra : rebase_source : 68a08bebaa5b99ca39e250fa1ed60ca4d7d0af68
extra : histedit_source : 6afda2fece486547192c1c8eba97a2474e3d99c1
This patch add a line at the end of the build like follows:
ccache (direct) hit rate: 98.7%; (preprocessed) hit rate: 0.5%; miss rate: 0.8%
--HG--
extra : rebase_source : 9c814745516d7b8b0db2056a1fa0df540a5a239a
As a first step, this moves PYTHON_UNIT_TESTS to moz.build as a passthru
variable. In the future, we could hook it up to |mach test|.
The __init__.py files may not need to be in the list, but I don't want to
change the list here.