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
Previously if an Arch Linux user had a different package extension configured
in `/etc/makepkg.conf` building AUR packages during bootstrap would fail.
Forcing the extension by providing it as an environment variable makes sure
building doesn't fail regarding of a user's configuration.
MozReview-Commit-ID: 4aryYS0XVr7
--HG--
extra : rebase_source : 4c466e49f729de625e814a92325c6d38e6d1e0b4
Both BuildMonitor and BuildOutputManager are doing similar things and
wrapping the build with forms of monitoring. These classes are only
used in the `mach build` command.
Since the BuildOutputManager takes an instance of BuildMonitor as an
argument and since BuildOutputManager behaves as a context manager,
it makes sense for BuildOutputManager to control the lifetime of
BuildMonitor's collection.
So, we teach BuildOutputManager's context manager to start the
BuildMonitor and ensure its resource collection is stopped when it
exits.
MozReview-Commit-ID: 3l9Hwz0Xe7o
--HG--
extra : rebase_source : 600b0231fce050465bdccb2bc11680f77bbc35d9
r?gps for the build changes and ochameau for the rest.
This results in about a 28% speed-up for Jetpack mochitest runs, for me.
MozReview-Commit-ID: K30q7BfvTLs
--HG--
extra : rebase_source : 8074947062c73a329f1d8a255a9601147ba1ba0c
For devtools-html, devtools will progressively stop using DTD files and will use only properties
files. To avoid retranslating already localized strings in every locale, this script can be used
by localization teams to automatically migrate strings moved in the scope of the devtools-html
project.
MozReview-Commit-ID: KNDfCoPXOM9
--HG--
extra : rebase_source : 48fbf2ae3daab89891262e460c979b6c141a2caa
ccache 3.3 added two fields in the status.
1. "cache hit rate"
https://github.com/ccache/ccache/issues/94
2. "cleanups performed"
0769ea3630
We just teach the parser the two fields. Nothing else.
MozReview-Commit-ID: 9kZrDrpCopd
--HG--
extra : rebase_source : ecb55fa9187abb37e668f0d25b40afd41597f7f8
If a linter returns a status code instead of a list of results, mozlint will throw away
that status code and move on to the next linter. We should make sure that status code
bubbles all the way up to the cli.
MozReview-Commit-ID: 9fXpmtlUUT1
--HG--
extra : rebase_source : 84c80d1b24d7233d0c4c6e38b23e775110776d1f
In our current Rust world, we have the following dependency structure:
xul.so --------------------------+
|
xul-gtest.so -+--> xul.a --------+-> gkrust
|
+--> gkrust-gtest
This structure results in link errors with multiply-defined symbols
between gkrust-gtest and gkrust with newer Rust releases when linking
xul-gtest.so. So we have to do something different.
Our new structure is:
xul.so --------------------------+
|
xul-gtest.so -+--> xul.a --------+-> gkrust --+-> gkrust-shared
| |
+--> gkrust-gtest --------------+
and we enforce that a given shared library can only have at most one
Rust library that it depends on. Said Rust library is assumed to
include all significant Rust dependencies of the dependent static
libraries as well. (In the above structure, gkrust is simply a wrapper
around gkrust-shared, so gkrust-gtest doesn't have to include gkrust as
a dependency.)
This moves reading of gyp files to a separate process from the main
reader/emitter pipeline, causing gyp contexts to be consumed after other
contexts.
MozReview-Commit-ID: CevPcpe5cFI
Due to an apparent bug, DIRS are being ouptut inconsistently for directories
with code built by gyp files (as of this writing, they are output for child
directories of media/webrtc but not for some other directories). The DIRS
variable no longer drives compilation, so this was essentially a no-op.
MozReview-Commit-ID: IMfjyrcsWyv
This generalizes the monkey-patching of the main module added
in bug 914563 to allow multiprocessing to be used from config.status
(which triggers the same bug as when it's used with `mach` as main).
MozReview-Commit-ID: AdOdpKzmbsp
This patch allows specifying an objdir path in `SYMBOLS_FILE`, with the
requirement that the file is also listed in `GENERATED_FILES`. This is used
for handling NSS' .def files with their special processing.
I added tests for the existing `SYMBOLS_FILE` case as well as the new case
and a test for the error if the file is not listed in `GENERATED_FILES`.
MozReview-Commit-ID: 3cVbKplltfb
--HG--
extra : rebase_source : 0ae4180dbe9383b09f14554bfda8aec20d7cc094
Now that we access WPT related files from a source checkout, we no
longer need the web-platform tests zip file produced or consumed by
automation. So stop producing it.
MozReview-Commit-ID: Ea8KjKZJ5Yx
--HG--
extra : rebase_source : f22506a02fdd5e78434cdc5d1c1f274db1cd04e2
When attempting to run mach from a make target, there were failures on OSX due to an objdir
mismatch:
https://dxr.mozilla.org/mozilla-central/rev/7c576fe3279d87543f0a03b844eba7bc215e17f1/python/mozbuild/mozbuild/base.py#656
The two detected objdirs were "<objdir>" and "<objdir>/x86_64". I believe this should not
count as a mismatch, otherwise it would not be possible to run a mach command from the
x86_64 directory.
MozReview-Commit-ID: CXDEABNWX8L
--HG--
extra : rebase_source : 9daeaf372d872921e7b2854eee0313b5adc0e707
This command is mostly just a wrapper around `cargo vendor`, but it runs
it the right way and will install the cargo-vendor tool if necessary.
Additionally, the mach command will by default error if there are uncommited
changes to files other than Cargo.{toml,lock} in your working copy, and it
will stage changes to the vendored crates in your VCS after the update.
MozReview-Commit-ID: 2fMDBawNUMO
--HG--
extra : rebase_source : fe72f26aec795eb663c554933432e700ac5089c3
I wanted to be able to do some VCS interaction from a mach command, and we
didn't have anything suitable, so I tore up mozversioncontrol and replaced
it with a framework to hang new features off of. I've only implemented
the bits I need currently (get_modified_files and add_remove_files),
but it should be straightforward to add more functionality there.
This patch also adds a `repository` property to `MozbuildObject`, which will
return a `Repository` object for the topsrcdir to make using these helpers
even easier for `MozbuildObject`-derived classes.
MozReview-Commit-ID: Gw6Ixp1ltiN
--HG--
extra : rebase_source : e619d6642eb86c3f96e679ac22a3e561dfdbb56a
This is a little tricky since tup expects rules in a single Tupfile to
be topologically sorted, and the emitter emits the GeneratedFile object
before it emits the FinalTargetPreprocessedFile object. We work around
this by delaying when we process the application.ini.h GeneratedFile
object, but it's a hack.
MozReview-Commit-ID: 8nVm76nZOKb
--HG--
extra : rebase_source : a82cfbeef739aac791998fb6d45cf88eb7116e32
Now that we access WPT related files from a source checkout, we no
longer need the web-platform tests zip file produced or consumed by
automation. So stop producing it.
MozReview-Commit-ID: Ea8KjKZJ5Yx
--HG--
extra : rebase_source : ee6ec00689696a710faf390d3dec5c5d02d8ec74
Move packaging for Marionette from make to test_archiver by using root manifest files.
MozReview-Commit-ID: 1cxEBYQeJ2Z
**
--HG--
extra : rebase_source : 372a407d9207bfbccbfb88c689df60b8cc1abcaf
It turns out the entry count is not the same as the capacity. This turns out
badly when your hashtable is a hashtable and not an array. Which is most of
them. If you were using this pretty printer prior to this fix, you may have
seen anywhere between 0% and 100% of the actual entries in the table.
Apologies!
Note that this change has no bearing on any in-tree tests at this point. We
still want to add unit tests so this is not the case. (The JS pretty printers
have them.)
This avoids printing harmless (but confusing) errors to the log. For instance, git users
will see a '.hg not found!' error in the output even though not finding an hg repo is
expected in that case.
MozReview-Commit-ID: DBPOabcV7PA
--HG--
extra : rebase_source : a40de185cd4bf0c58917065d1331e0e663b92b94
This patch also reworks how we set all the boolean flags in mozinfo.py.
MozReview-Commit-ID: IhjXCFsx5J1
--HG--
extra : rebase_source : d984d9ecaed765126600c8d85847a82585ab3e67
This patch solves 3 problems on Fedora when trying to bootstrap Firefox for Android:
1) Installs java
2) Adds a call to android.ensure_android_packages()
3) Uses build-tools-23.0.1 which seems to be the latest on Fedora
I'm not sure why the Android specific packages are only being installed on Fedora
and not CentOS, but as I don't have CentOS distribution to play around with figured
it was best to leave that for another bug.
MozReview-Commit-ID: 19sD6tYj4V
--HG--
extra : rebase_source : eaf17bc05d606d3010b11927f27a482680266992
Versions of mercurial older than 3.0 don't support the -T shorthand for
the --template option. While most people should be using something
newer, it can still happen that some run an older version, and it's
still trivial to support them by using the long option.
--HG--
extra : rebase_source : 1507aea436779495045df48b044a58f4af1382be
This is mostly to maintain backwards compatibility with the |mach eslint| command. But it's also going to be used in
automation. The 'mozlint-eslint' task will need to pass in --quiet to eslint.
Maybe in the future we should remove this ability and only allow well-defined arguments in mozlint. But for now it's
convenient and allows us to land the eslint->mozlint patch series quicker.
MozReview-Commit-ID: KYhC6SEySC3
--HG--
extra : rebase_source : ad7f0cdeb57ed8a99becb90d761d73ef45ce853a
Some linters, such as flake8, will lint invalid file extensions if you explicitly pass them in. E.g,
|flake8 foobar.js| will result in flake8 attempting to lint a JS file. This is a problem because passing
in files explicitly is exactly what the --rev/--workdir options do. If a developer modifies a JS file
then runs |mach lint -l flake8 -w|, that JS file will get linted.
To prevent this, mozlint needs to handle file extensions instead of relying on the underlying linter to
do it. This patch adds an "extensions" config option to the LINTER dict, and will filter these files out
as part of the 'filterpaths' steps.
MozReview-Commit-ID: KYhC6SEySC3
--HG--
extra : rebase_source : 6fea2942b2db1bea7deca1d6738546362b6ebd65
This will make specifying terminal colours cleaner and provide fallbacks for terminals
with only 8 colours. It also tweaks the 'grey' color to match an update to the eslint
stylish formatter.
MozReview-Commit-ID: KYhC6SEySC3
--HG--
extra : rebase_source : 8d3242edc54bf6505aa2e60cdb08cb0dd9743dd3
.mozbuild/last_log.json is opened by the process doing the deleting.
On Windows, you can't delete an opened file.
So stop clobbering the .mozbuild directory.
This directory only holds non-essential artifacts from mach/build
invocations. I don't think keeping it around will break anything.
MozReview-Commit-ID: 9b0AC2ywAAZ
--HG--
extra : rebase_source : 9236e3e282d1db2595e8b36353008bc98e2ae6cf
Some substs values are lists, and some CONFIGURE_SUBST_FILES use them,
and don't expect the substitution to use a pythonic expression of the
value. So serialize those lists.
--HG--
extra : rebase_source : 848962c326236607609bca2b92180c8f6f4ad079
It's important to use absolute paths so lint errors for the same files don't show up in two
different places. For example, eslint will absolutize a relative path, whereas flake8 will
not.
This patch also makes sure all include/exclude paths are joined to the mozlint 'root' that
was previously calculated from vcs.
MozReview-Commit-ID: KYhC6SEySC3
--HG--
extra : rebase_source : 9b88ee70a997d3f7b6cc0eb849e47931d5726f20
Previously, vcs related stuff was resolved in the cli.py module. But it's possible
for consumers to bypass the cli and instantiate a LintRoller directly. In fact this
is what the mozlint tests do.
Now that we always try to find the vcs root, calling into vcs is no longer optional.
This patch moves the VCSFiles class to a new vcs.py module and makes LintRoller
responsible for instantiating it instead of cli.py.
MozReview-Commit-ID: 5yA3gDZ1UGM
--HG--
extra : rebase_source : 96adc0ca01e8220b0432b64c96c478fc526db756
extra : source : 709c1e521ad3eb466c3434000aed7f71ebf37365
This makes sure we return absolute paths from the VCSFiles class. This is done so we don't accidentally normalize
the relative paths onto $CWD in the event the relative path is valid in both places.
MozReview-Commit-ID: 2QIuR2YqFos
--HG--
extra : rebase_source : 2e82b4a5cf9a18856bbcb8d04fdc916ff7e72deb
This makes it easier to pass configuration to the filterpaths method. In
the future, 'root' and 'extensions' will both be used here.
MozReview-Commit-ID: KYhC6SEySC3
--HG--
extra : rebase_source : 19ddf511ebd24a1a6c21f7c06b67ab64e78e7903
This required implementing a utility function to resolve the binary
type. I used GetBinaryTypeW via ctypes because this seems the fastest.
I arbitrarily limited the function to testing 32-bit and 64-bit Windows
executables because hopefully those are the only executables we'll
ever encounter. We can expand the binary detection later, if needed.
This includes support for running on non-Windows platforms.
MozReview-Commit-ID: CYwyDWQrePc
--HG--
extra : rebase_source : 8fd7ca7f253d9e9e18d64784652a5ff934ad2272
And with indentation so it is easier for humans to read.
MozReview-Commit-ID: Kkd6vmfLNUf
--HG--
extra : rebase_source : 9f2b4ad2223f361dd6dd1ec9cdda71bd5a8560e3
Also, is a ConEmu preferences file which automatically points a newly installed ConEmu to the newly installed MSYS2.
MozReview-Commit-ID: FBeMat4SYjK
--HG--
extra : rebase_source : 83d8f03a6cc011215fe58745c93afdf90162dc58
The "remove_objdir" method has been rewritten to support partial
clobber. It still defaults to full clobber. But the "full" argument
can be passed as False to limit to a partial clobber where currently
the "msvc" directory (contains Visual Studio files) is not clobbered.
On Windows, there might be a regression with this change because
we'll be invoking N winrm.exe processes and new processes have
a non-trivial overhead on Windows. However, it is hopefully unlikely
that new processes are more overhead than deleting hundreds of thousands
of files.
MozReview-Commit-ID: 7yeMttztwic
--HG--
extra : rebase_source : 646992be199e1059f0b09cf8bed3334085293fe0
My Python editor told me rmtree has been marked as deprecated. Use
mozfile.remove instead.
MozReview-Commit-ID: FYkXk1fnxvC
--HG--
extra : rebase_source : df392e8832e52501950f09acda208943c9e3d707
As of Python 3, decimal notations of octal values for permission modes
are no longer permitted and will result in a `SyntaxError` exception
(`invalid token`).
Using the proper octal notation which is also Python 2.7 compatible will
fix this issue.
--HG--
extra : rebase_source : 2e897c51f04ad0ee69071f84b98df224f3af72d3
Contains a few sentences copied from MDN.
MozReview-Commit-ID: 2wgcCNiWkWw
--HG--
extra : transplant_source : %7B%A2%10%88%83k%AC%AE%D3%A4H/pL%E6%B9%BE-9%5E
The base compiler check in python configure does some preprocessing,
which ensures the compiler works to some extent. Autoconf used to have
a more complete test, doing a compile/link. We do have plenty of tests
afterwards that do that anyways, but it's better if we fail early if
the toolchain fails somehow.
This refactors try_compile such that the *_compiler variable themselves
can be used to trigger compiler tests. Eventually, we'll want something
similar for preprocessing and possibly other invocations.
This also removes similar tests from build/autoconf/toolchain.m4.
--HG--
extra : rebase_source : c60d1d6e39b6bd2a377516687affd9b8932ebc12
While on automation, there is no MSVC to find through the registry, the
story is different on local builds, and that can interfere with tests.
Specifically, it breaks test_toolchain_configure.py because it's not
expecting the registry to provide a valid path to an almost valid
compiler, and then fails because that compiler doesn't match the
expected target CPU.
And because build/moz.configure/toolchain.configure also affects the PATH
environment variable, subsequent tests end up failing even earlier
because executing the empty mozconfig with the modified environment then
fails because of the unicode value of PATH.
This change implements enough of _winreg to make the get_registry_values
function return nothing.
--HG--
extra : rebase_source : f70e40ddabaed1197f6cddce67832bb112f1969d
Back when it was added, it was used, but it is not anymore, outside
test_base.py.
--HG--
extra : rebase_source : f0b9a4dab2985e89e9950eda774ae853c7de764c
We've been reading the mozconfig in MozbuildObject.from_environment to
check whether the mozconfig topobjdir matches the detected topobjdir.
Since bug 1278415, everything using the buildconfig python module now
calls MozbuildObject.from_environment, which reads the mozconfig. A lot
of things to that during the build. But none of them actually need the
data from the mozconfig, and the topobjdir match test has been breaking
things randomly on multiple occasions.
The topobjdir match test, however, really only needs to happen once:
when a mach command starts. So we can move the test to MachCommandBase,
where it belongs, and anything actively using MozbuildObject.mozconfig
will have the mozconfig read, but everything else won't.
On a Linux64 opt build, this brings down the number of times the
mozconfig is read during `mach build` from 979 to 9.
--HG--
extra : rebase_source : 6b340f1fcf73a3c3987033c37f8f14ef06a44f04
The base compiler check in python configure does some preprocessing,
which ensures the compiler works to some extent. Autoconf used to have
a more complete test, doing a compile/link. We do have plenty of tests
afterwards that do that anyways, but it's better if we fail early if
the toolchain fails somehow.
This refactors try_compile such that the *_compiler variable themselves
can be used to trigger compiler tests. Eventually, we'll want something
similar for preprocessing and possibly other invocations.
This also removes similar tests from build/autoconf/toolchain.m4 and
old-configure.in.
--HG--
extra : rebase_source : 4f6f84e5ad220386e9edf82d19cc2cd6c1f4c43e
This patch is really two separate changes.
The first change is that rust crates are large, standalone entities that
may contain multitudes of source files. It therefore doesn't make sense
to keep them in SOURCES, as we have been doing. Moving to use cargo
will require a higher-level approach, which suggests that we need a
different, higher-level representation for Rust sources in the build
system.
The representation here is to have the build system refer to things
defined in Cargo.toml files as the entities dealt with in the build
system, and let Cargo deal with the details of actually building things.
This approach means that adding a new crate to an existing library just
requires editing Rust and Cargo.toml files, rather than dealing with
moz.build, which seems more natural to Rust programmers. By having the
source files for libraries (and binaries in subsequent iterations of
this support) checked in to the tree, we can also take advantage of
Cargo.lock files.
The second is that we switch the core build system over to building via
cargo, rather than invoking rustc directly.
We also clean up a number of leftover things from the Old Way of doing
things. A number of tests are added to confirm that we'll only permit
crates to be built that have dependencies in-tree.
rlibs are going to be less important once we start building with cargo:
the focus will move to crates instead, so that's what we should call the
moz.build object.
Through an oversight, we listed librul.a twice when linking libxul: once
as part of the "objects" we were linking, and once as a static library.
This duplication is unnecessary and would cause problems later when we
try to generate librul.a via cargo, as cargo will put it someplace
different from where we expect and the two names will conflict. Let's
have rules.mk be the single source of truth for how librul.a is named,
and then the code to link libxul can simply refer to that name.
This patch is really two separate changes.
The first change is that rust crates are large, standalone entities that
may contain multitudes of source files. It therefore doesn't make sense
to keep them in SOURCES, as we have been doing. Moving to use cargo
will require a higher-level approach, which suggests that we need a
different, higher-level representation for Rust sources in the build
system.
The representation here is to have the build system refer to things
defined in Cargo.toml files as the entities dealt with in the build
system, and let Cargo deal with the details of actually building things.
This approach means that adding a new crate to an existing library just
requires editing Rust and Cargo.toml files, rather than dealing with
moz.build, which seems more natural to Rust programmers. By having the
source files for libraries (and binaries in subsequent iterations of
this support) checked in to the tree, we can also take advantage of
Cargo.lock files.
The second is that we switch the core build system over to building via
cargo, rather than invoking rustc directly.
We also clean up a number of leftover things from the Old Way of doing
things. A number of tests are added to confirm that we'll only permit
crates to be built that have dependencies in-tree.
rlibs are going to be less important once we start building with cargo:
the focus will move to crates instead, so that's what we should call the
moz.build object.
Through an oversight, we listed librul.a twice when linking libxul: once
as part of the "objects" we were linking, and once as a static library.
This duplication is unnecessary and would cause problems later when we
try to generate librul.a via cargo, as cargo will put it someplace
different from where we expect and the two names will conflict. Let's
have rules.mk be the single source of truth for how librul.a is named,
and then the code to link libxul can simply refer to that name.
