This adds everything to a default output group so we can run `tup upd $objdir/<default>`
during `mach build` and `tup upd $objdir/<gtest>` for instance when running `mach gtest`
as a way to conditionally build parts of the tree.
MozReview-Commit-ID: 8jpkru1EgAC
--HG--
extra : rebase_source : 5a2c4fd0e0b1b62f8bd65dd1a23ba2086ba63eeb
Most HG commands use subprocesses, even if a context manager (and therefore an
hglib client) has been created. There are only two commands that make use of
the client, but they *only* work inside a context manager. I don't think
there are any technical reason these two commands *need* to use the context
manager.
This patch merges the HgRepository._run_in_client function with
HgRepository._run(). If a client exists, that will be used, otherwise a
subprocess will be used.
Differential Revision: https://phabricator.services.mozilla.com/D1809
--HG--
extra : moz-landing-system : lando
This adds just enough host shared library support for this one use case,
but also takes shortcuts, because fully supporting host shared library
is a deep rabbit hole I'm not ready to take just to fix --enable-lto
--enable-clang-plugin on mac builds.
One downside is that one my machine the plugin now takes > 80s to build,
instead of 15s before, thanks to the lack of unified sources.
--HG--
extra : rebase_source : bf52a72a01d4e3eb77cf52b646b19734b9273075
The test checks the modules imported, which means it will fail if we import mozbuild.base to determine the topsrcdir. Rather than include the additional modules, which may change in the future, I have narrowed the scope of the test to the mozbuild/tests module.
MozReview-Commit-ID: GiaPzp19adE
--HG--
extra : rebase_source : 9d79ad79bef2b45e3f62190200bc46f21d57f90d
Because we have no linking configure test in python configure (yet), we
just make old-configure tests use LINKER_LDFLAGS, and make those flags
added to LDFLAGS by old-configure at the same time.
--HG--
extra : rebase_source : 80ab7c5021c7ddd1b53d58ef76cd4372a524d3cb
vendor_rust.py checks all dirs in third_party/rust/ for license information, but it wasn't distinguishing between subdirs and files when listing the contents of that directory, and the script earlier causes macOS to create a .DS_Store file in the directory, which the script then treats as a subdir, causing an IOError "not a directory". This change excludes the .DS_Store file (and other non-dirs) from the list of subdirs of third_party/rust/ to check for license info.
MozReview-Commit-ID: 4CrJH9tZLnG
--HG--
extra : rebase_source : 464ad17f4c9b76303f9024d8eaad475b1fc248f7
Added `./mach python-safety`, distinct from python-test so it doesn't have
to be run on every CI job - its errors may not depend on the area the push has changed.
Added the python/safety directory to ensure a different Pipfile is used, avoiding
conflicts with python-test.
Differential Revision: https://phabricator.services.mozilla.com/D1825
--HG--
extra : moz-landing-system : lando
We're well overdue for an upgrade of the rust compiler requirements.
Now that we're building with 1.28 (albeit a beta, due to be bumped when
it's released), we can bump the requirement away from 1.24 which is now
old. 1.27 is too new, though, so settle for the older 1.26.
--HG--
extra : rebase_source : a17aa496bf3d4af4d1349d69a637c686c6817d0f
This will make sure that when running |mach python-test --python 3| locally,
we only run the tests that also run in CI with python 3 (and therefore pass
presumably).
MozReview-Commit-ID: 3OBr9yLSlSq
--HG--
extra : rebase_source : 456340d0ecdddf1078f2b5b4ebb1eddf3813b26a
By making the archive URL dynamic, we can fetch an old version of the
bootstrap files. This will make it easier to test the bootstrapper in
CI.
Differential Revision: https://phabricator.services.mozilla.com/D1698
--HG--
extra : rebase_source : 9ba582cf3c138dba433e2bb354650f14b3f16aa7
extra : amend_source : 8a515bb755187e7f0d87b90a25a99f3803ea9e0f
extra : source : 1dcd43dd2a7b04e2bb714349033a456ea5158f3e
The previously listed server wasn't working. This has likely been
broken for years (I initially authored this commit in November 2016).
Differential Revision: https://phabricator.services.mozilla.com/D1697
We're well overdue for an upgrade of the rust compiler requirements.
Now that we're building with 1.28 (albeit a beta, due to be bumped when
it's released), we can bump the requirement away from 1.24 which is now
old. 1.27 is too new, though, so settle for the older 1.26.
--HG--
extra : rebase_source : c788ef4f7da9949b81df2f0577af6f6039ea63d8
Overall, this makes the whole setup less fragile, and make it work with
LTO in more situations.
--HG--
extra : rebase_source : de968c61dc4ef337fdc28745c202334ac41763cd
We perform, on the binaries we build, a series of check, that are
implemented as half-baked make commands, invoked after linking them.
- check libstdc++ symbol versions to ensure binary compatibility with
a baseline.
- check glibc symbol versions to ensure binary compatibility with a
baseline.
- check that target binaries don't contain text relocations.
- check that libmozglue is linked before libc on android.
- on libxul, check that NSModules are laid out correctly.
- on libxul, check that there is more than one PT_LOAD segment.
Those checks happen to work where they matter, but their setup is
unreliable. For example, the checks for symbol versions are supposed to
work for libclang-plugin on cross osx builds, but in fact, don't,
because the readelf path doesn't exist, and the command doesn't fail in
that case.
So move them all to a standalone script, performing the checks more
thoroughly (especially the NSModules one, where we now also check that
they are all adjacent), and more verbosely.
--HG--
extra : rebase_source : 7072e622e95f363d4a6c3a8e272d3445d998b592
yaml.load() is unsafe and can lead to arbitrary code execution via
syntax like `!!python/object/apply:os.system`. yaml.safe_load() is
more reasonable.
Differential Revision: https://phabricator.services.mozilla.com/D1738
--HG--
extra : rebase_source : 597c07b3c1538dc27ad6f46e01cdb7f48755d0bc
extra : histedit_source : 131d570f8ac1ee047487cba54822dbf20abf6681
The bitstream is frozen and we're updating to v1.0.0. There is no longer any need
to indicate which revision we're using in the mimetype.
--HG--
extra : rebase_source : 5f5bf8649bd21610ebf04661e8f80bacbb69ca09
Some recently introduced gn-configs contain duplicate flags/includes, which
aren't handled correctly and introduce non-determinism into the gn-moz.build
generation. This patch makes the moz.build generator faithfully reproduce
duplicated flags, usually to no effect, which is unfortunate in these cases,
but a reasonable approach for the moz.build generator in general.
MozReview-Commit-ID: 6PvobD9JRwN
--HG--
extra : rebase_source : 50c9e92bb03400e6b41908de1a1bfadaced1ad91
When we do a './mach build-backend --dry-run', no files in the objdir
should be written or touched. Updating the mtime of the backend file
during dry-run causes a future './mach build' to think that the backend
is up-to-date when it is not, which causes an incorrect build.
MozReview-Commit-ID: 2NA0rcSGrvL
--HG--
extra : amend_source : f694503264dc6275568c453de59b7f13983091f7
This patch allows us to enable Python 3 tests and skip any tests that fail so that we can work on adding support for Python 3 without risking regressing any existing support. It will also eventually allow us to skip tests from running against Python 2, when we decide to drop support for it. To skip a test against Python 3, add "skip-if = python == 3" to the [DEFAULT] or test file section of a manifest file.
MozReview-Commit-ID: KYzjW6PQw2Q
--HG--
extra : rebase_source : 9e0670efe237b8953aab96e95cfa3c9ae678351c
Bug 1467041 changed the default for --enable-release such that it is
affected by the milestone. Test both possible cases for milestones.
--HG--
extra : rebase_source : 5bfeadf4cd1e8c672cf78e4922ebb91bdafecad8
90dca0906337 accidentally broke `mach artifact toolchain --from-build`
because that code is attempting to load toolchain tasks in isolation.
The new "use_fetches" transform added to toolchain tasks requires
that "fetch" tasks are already processed and their references are
available to toolchain tasks.
This commit adds a mechanism to effectively disable the "use_fetches"
transform when called by `mach artifact toolchain`. It is a hack. I
suspect future planned work around artifacts/fetches will necessitate
additional changes to the `mach artifact toolchain` code. But this
can be deferred to a later day: this commit unbusts `mach artifact
toolchain` and isn't super hacky, so it seems more reasonable than
backing out fetch tasks completely.
Differential Revision: https://phabricator.services.mozilla.com/D1588
This populates $OBJDIR/dist/host/bin as part of |mach artifact install|.
Conceptually, the mar and mbsdiff utilities should be grouped (in the
same way that the test-related binaries are grouped). However, it's
difficult to achieve that with the current structure of the code, so
this fetches mar and mbsdiff and produces $HASH-mar.processed.jar and
$HASH-mbsdiff.processed.jar files.
MozReview-Commit-ID: 3ks5xsUEKp5
--HG--
extra : rebase_source : 5fcf186decc95537cbaa90ffedb86774eab050d2
This upgrades sphinx to version 1.7.5, which contained a couple backwards
incompatible changes that needed fixing.
This also leaves sphinx-js at version 2.1 as upgrading that to 2.5 seems to
introduce an intermittent in the Doc task.
MozReview-Commit-ID: FRUTcXs5yzb
--HG--
extra : rebase_source : e874a2e9c637b7cec710203f75f4dd989a5681a1
This patch allows executing |mach python-test| against Python 3 by specifying the optional |--three| command line option. When this option is present, pipenv will be used to manage a virtual environment using Python 3 and attempt to run the tests. When it is not present, pipenv will not be used, and everything will work as it did before this patch.
My original plan was to use pipenv regardless of the target version of Python, however I encountered several issues running some of the tests against our Python packages. Once all tests have been patched to run against Python 3, then we should be able to use pipenv when running them against Python 2.
Note that this patch allows tests to run against Python 3, but there are plenty of issues preventing them from passing. With this patch in place we can start to add Python 3 support to our packages and have the tests running in CI to ensure we don't regress back to just supporting Python 2.
MozReview-Commit-ID: BuU5gZK83hL
IHG: changed taskcluster/ci/source-test/python.yml
--HG--
extra : rebase_source : ca2b15d905f7a5c895a2fd8916144841f5d205de
This patch allows executing |mach python-test| against Python 3 by specifying the optional |--three| command line option. When this option is present, pipenv will be used to manage a virtual environment using Python 3 and attempt to run the tests. When it is not present, pipenv will not be used, and everything will work as it did before this patch.
My original plan was to use pipenv regardless of the target version of Python, however I encountered several issues running some of the tests against our Python packages. Once all tests have been patched to run against Python 3, then we should be able to use pipenv when running them against Python 2.
Note that this patch allows tests to run against Python 3, but there are plenty of issues preventing them from passing. With this patch in place we can start to add Python 3 support to our packages and have the tests running in CI to ensure we don't regress back to just supporting Python 2.
MozReview-Commit-ID: BuU5gZK83hL
IHG: changed taskcluster/ci/source-test/python.yml
--HG--
extra : rebase_source : e1a64c0ffa8fe5cce71a041579601d4a72e37779
