This marks **/docs/** as exclusively docs, and code that is autodoc'd as
inclusively docs.
That means that a change that purely modifies documentation files will *only*
run `docs` tasks, while a change that modifies autodoc'd source code will
*additionaly* run `docs` tasks. The tasks do not run by default.
MozReview-Commit-ID: G9tOK0AwtrI
--HG--
extra : rebase_source : 8dd971e5c9b0eb5f47895664a4ea49442f303ecb
extra : source : 0881de9b2b5e36ec37cc866f1d4af109da57a919
This marks **/docs/** as exclusively docs, and code that is autodoc'd as
inclusively docs.
That means that a change that purely modifies documentation files will *only*
run `docs` tasks, while a change that modifies autodoc'd source code will
*additionaly* run `docs` tasks. The tasks do not run by default.
MozReview-Commit-ID: G9tOK0AwtrI
--HG--
extra : rebase_source : 8dd971e5c9b0eb5f47895664a4ea49442f303ecb
extra : source : 0881de9b2b5e36ec37cc866f1d4af109da57a919
This marks **/docs/** as exclusively docs, and code that is autodoc'd as
inclusively docs.
That means that a change that purely modifies documentation files will *only*
run `docs` tasks, while a change that modifies autodoc'd source code will
*additionaly* run `docs` tasks. The tasks do not run by default.
MozReview-Commit-ID: G9tOK0AwtrI
--HG--
extra : rebase_source : 8dd971e5c9b0eb5f47895664a4ea49442f303ecb
extra : source : 0881de9b2b5e36ec37cc866f1d4af109da57a919
We currently use a 32-bit Rust toolchain for win32 builds, but this can lead
to OOM situations. This patch makes win32 builds use a 64-bit Rust toolchain,
which requires a little bit of extra configuration because rustc needs to
be able to find a link.exe that produces 64-bit binaries for building
things like build scripts, which are host binaries.
We will now generate a batch file that sets LIB to the paths to 64-bit
libraries and invokes the x64-targeting link.exe, and add a section to the
.cargo/config file to instruct cargo to use that batch file as the linker
when producing 64-bit binaries.
MozReview-Commit-ID: 9vKBbm7Gvra
--HG--
extra : rebase_source : 599b3b661c7a8a5db1f32a2a9732fc202fb55e1e
We add a simple cram test that `configure --help` works.
I added the test to build/tests because I'm not sure where else it should go.
This test uncovers a few interesting things:
1) piping `./configure --help` to `head` directly causes a Python
traceback (presumably due to the pipe disappearing once N lines
have been read)
2) "checking for vcs source checkout" is printed for --help
3) It is printed twice (!!)
These will be addressed later. Establishing test coverage is
more important.
MozReview-Commit-ID: 9zQ5X8ulTkc
--HG--
extra : rebase_source : aaf660152cdfe37580f559976bca13ea9bf14c49
The current way they are generated makes it so that it's not trivial for
the backends to figure that one depends on the other. While we should
eventually make things such that using FINAL_TARGET_PP_FILES works for
that, it's currently simpler to just use GENERATED_FILES.
--HG--
rename : build/application.ini => build/application.ini.in
extra : rebase_source : cad3460b65d99bdae3e6f1d9dd611e0a602ebfed
This deprecates PYTHON_UNIT_TESTS and replaces it with PYTHON_UNITTEST_MANIFESTS.
In the build system, this means python unittests will be treated the same as all
other test suites that use manifestparser. New manifests called 'python.ini' have
been created for all test directories containing python unittests.
MozReview-Commit-ID: IBHG7Thif2D
--HG--
extra : rebase_source : 11a92a2bc544d067946bbd774975140147458caa
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
B2g came with its own version of 'libgabi++' in its toolchain. Gecko
on b2g isn't build any longer with this toolchain. With this patch
applied, Gecko's internal version of 'libgabi++' is used for building.
MozReview-Commit-ID: KU4OBYQ6cAW
The lone remaining INSTALL_TARGETS is for moztt, which relies on
including a Makefile from that repository. We could potentially add a
mozbuild file there instead.
MozReview-Commit-ID: FXJDg3xPW1x
This makes it clearer that really it's the same thing as FINAL_TARGET,
with preprocessing.
We still keep DIST_FILES in backend.mk because it's shorter and doesn't
really matter.
This builds the Robocop tests with |mach build mobile/android|, making
it easier for developers to build Fennec and the tests at the same
time.
--HG--
rename : build/mobile/robocop/AndroidManifest.xml.in => mobile/android/tests/browser/robocop/AndroidManifest.xml.in
rename : build/mobile/robocop/Makefile.in => mobile/android/tests/browser/robocop/Makefile.in
rename : build/mobile/robocop/README => mobile/android/tests/browser/robocop/README
rename : build/mobile/robocop/moz.build => mobile/android/tests/browser/robocop/moz.build
rename : build/mobile/robocop/res/values/strings.xml => mobile/android/tests/browser/robocop/res/values/strings.xml
rename : build/mobile/robocop/robotium-solo-4.3.1.jar => mobile/android/tests/browser/robocop/robotium-solo-4.3.1.jar
extra : commitid : BuNBjgXdm1d
extra : rebase_source : c36b8bf0183d8f5821b7f7839668ca963065d894
extra : histedit_source : a86fef3b834420ea496a9c2644ca72786a2d7da9
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.
