This also migrates the vcs.py test to mozversioncontrol and adds a new task for
it.
MozReview-Commit-ID: 9jTRkjNupVA
--HG--
extra : rebase_source : 400f27498e00ea45234ad7c951770b098e916b8e
Sometimes commands return non-zero even though everything is ok. For example,
'hg outgoing' returns 1 if there are no outgoing files. This adds a way for
specific function calls not to abort if something goes wrong. Instead, stderr
will be printed (if any) and an empty string is returned.
MozReview-Commit-ID: E089djeHrmr
--HG--
extra : rebase_source : be351f357705e09c3fe876cecefa7ddd9c48987e
This adds 'get_outgoing_files'. First it automatically attempts to find the
upstream remote the current change is based on, then returns all files changed
in the local branch.
If an upstream remote can't be detected, it raises MissingUpstreamRepo
MozReview-Commit-ID: 9zSB9EdwVU8
--HG--
extra : rebase_source : e352d6d471644ef9eda76b972b789d6b54449471
There's currently a function for getting added files (A) and modified files
(M). We'll also eventually need the ability to get deleted files (D) and any
combination of the above, e.g (AM). Rather than creating a new function for
each possible case, let's have a single function where you can pass in which
modifiers you are interested in. With this patch, if you want all modified and
added files, you can do:
get_changed_files('AM')
By default 'ADM' is used.
This also adds a 'mode' option for git. This allows consumers to return staged
files, unstaged files or both. The default ('unstaged') keeps the current
behaviour in tact.
MozReview-Commit-ID: 9IA1bxaJS80
--HG--
extra : rebase_source : 160f650220ca9a35b4b116bc9fa13f28d84419fa
Technically this turns on gnu++14. I encountered a few errors when using c++14:
1) _USE_MATH_DEFINES needed to be defined for MinGW
2) MinGW did not define _finite under c++14
3) MinGW's float.h did not define Microsoft specific float functions under c++14
All of these were because c++14 defines _STRICT_ANSI_ which MinGW obeys and
avoids defining certain functions. The first two could be patched around, but
the third was a blocker, so we switched to gnu++14
MozReview-Commit-ID: 6Y7gEQgApYp
--HG--
extra : rebase_source : dabbd40c049c36e780b585e0bef0a8e25887d089
Unfortunately this also needs to be kept in Makefile.in to handle
other consumers of INCLUDES while we transition them.
MozReview-Commit-ID: 9OYlu6Jv1XZ
--HG--
extra : rebase_source : 719200501a93e836a03a64b5e1cd950a8f2e696a
GCC isn't safe to use on architectures that switched to Clang because
libstdc++ and libc++ aren't very compatible. Newer LLVM and Clang are
often already installed as a dependency for Mesa packages. So, always
require llvm* package.
MozReview-Commit-ID: 8651mz5tiIp
--HG--
extra : rebase_source : 7713e167b34f14a18fd5bf9c5ec33e926b2b929c
Currently line linters (linters that open a file and process it line by line,
by applying a regex for example), don't handle directories. If a directory is
passed in, it will try to 'open' it, which fails. Directories can get hit if
the linter has a directory in its include directive or if the user passes in
--no-filter.
This patch modifies LineLinters so that if a directory is detected, we search
for all relevant files under that directory. If 'extensions' is used, we'll
look for only files with appropriate extensions. Otherwise we assume the
linter wants every file.
MozReview-Commit-ID: D9lzTNuQTob
--HG--
extra : rebase_source : 0b952c06eae28b67b687813ff7e75b231b2dd4d3
The MozillaBuildBootstrapper specific rust install code in not needed as
mozbase already includes genertic code to achieve the same outcome. The
mozilla-build specific code also leads to issues where it tries to add already
existing targets and fails the bootstrap. This changeset removes the
mozilla-build specific step.
MozReview-Commit-ID: G0BqKZrF40A
--HG--
extra : rebase_source : 60e9638afff744c937a9665d6fd5830187835ea4
The code for obtaining a BuildReader for evaluating moz.build files
is generic and non-trivial. We already had a custom implementation
for `mach file-info` that implemented support for Mercurial
integration. Bug 1383880 will introduce a second consumer.
So this commit factors out the "obtain a BuildReader" logic into
a reusable function on our base MozbuildObject class. This makes
it easily available to various parts of the build system and mach
commands.
As part of the change, we detect when ``.`` is being used as the
revision and verify the working directory is clean. This behavior
can be disabled via argument if unwanted. But it's useful by default
to ensure consumers aren't expecting to read uncommitted changes.
MozReview-Commit-ID: LeYFqAb3HAe
--HG--
extra : rebase_source : d5ed4e4f5570a58a68853188de2225cd4e64ab3a
This is generally useful functionality to have. A consume will be
introduced in an upcoming commit.
MozReview-Commit-ID: 4arTMfJSiEC
--HG--
extra : rebase_source : 4bcf70f58b57b79b8dcb7a6eed633e1c7e42aca3
It seems reasonable to expose this outside of the BuildReader.
MozReview-Commit-ID: 4paDbYl9dEd
--HG--
extra : rebase_source : 86bb559500952a40fc9afbf958be5706dd9f858e
This also passes the '--noreplace' option to all the emerge invocations thus
preventing already installed packages from being rebuilt from scratch.
MozReview-Commit-ID: 4JBuptmgS3Y
--HG--
extra : rebase_source : e581607d4a2e997e7d79c7c4496d13b8e9b10e50
