Also fix that the default merge dir in the mach command creates a directory
that's the merge make target, and thus keeps that make target from actually
running.
MozReview-Commit-ID: HWZBPxWuHSy
--HG--
extra : rebase_source : a39157ad9eb99f3eef5d149d003e62a235f92fc1
The mozconfig detection logic has bitten us on many occasions in the
past. The following changes are made to tentatively improve the
situation:
- The API is modified such that autodetection of the mozconfig has
to be a conscious decision made by the caller, and not triggered
any time there is no mozconfig given, which could be a conscious
decision of the opposite.
- mozinfo.json now stores the actual mozconfig (or lack thereof) used
during configure.
--HG--
extra : rebase_source : c7a632afd414f25daf7bbe7e1a66c3736c26e039
Per froydnj in bug 1186064 comment #23, "it makes sense to proceed with removing
MSVC 2013 support." This commit does that.
We also go a step further and require VS2015 Update 2 instead of just
update 1. This temporarily brings us down to just 1 officially supported
Visual Studio version. However, VS2015u3 was just released and is
unofficially supported.
Since MOZ_CRT is no longer set, references to it have been removed.
MozReview-Commit-ID: 8MUR6qLzQA5
--HG--
extra : rebase_source : 8f5061080a3d56dd484f9be03649fb65f0145f67
Per froydnj in bug 1186064 comment #23, "it makes sense to proceed with removing
MSVC 2013 support." This commit does that.
We also go a step further and require VS2015 Update 2 instead of just
update 1. This temporarily brings us down to just 1 officially supported
Visual Studio version. However, VS2015u3 was just released and is
unofficially supported.
Since MOZ_CRT is no longer set, references to it have been removed.
MozReview-Commit-ID: 8MUR6qLzQA5
--HG--
extra : rebase_source : 22ab4f47661ead4995d0c5261104abfb02b82aa2
This adds two parameters, --rev and --workdir. Each works both with mercurial and git (though the syntax for
specifying revisions is different between them). The value is simply forwarded to either |hg log| or |git diff|
so syntax like |mach lint -r .~4::.| or |mach lint -r "HEAD~4 HEAD"| will work as expected.
MozReview-Commit-ID: aOGp2Yrncs
--HG--
extra : rebase_source : d2cb834d4cc1a083171a3551af4e72c8a7d14021
There is currently no built-in user interface to mozlint. The only existing interface is the
external cli provided by |mach lint|. However, in the future mozlint may need to be used in a
context where mach isn't readily available (i.e version-control-tools). This patch basically
just moves the cli logic out of mach_commands.py, and into mozlint core. That way it can be
re-used in other places without needing to be re-implemented.
The |mach lint setup| subcommand was removed because apparently subcommands don't work with
the parser attribute. Nothing was using it yet anyway, so I removed it for now. It may get
re-added in some form in the future.
MozReview-Commit-ID: aOGp2Yrncs
--HG--
extra : rebase_source : 8f7530de96e5c131d2ed5bfcdd7a159329401e5b
This matches the implementation from mach_bootstrap.py.
MozReview-Commit-ID: 8kZCKuIsAMQ
--HG--
extra : rebase_source : 59b1f3d595e1663603363bb712da9cb74c3ba0e0
extra : amend_source : e95774ade1c7d28ba1d880b6b9ef1d64eaa618a8
We'll be consolidating code from mach_bootstrap.py and mozboot.
We don't want mach_bootstrap.py to import bootstrap.py because it
imports nearly every module under mozboot. So establish a standalone
module with minimal dependencies to hold utility code. Move
get_state_dir() there.
MozReview-Commit-ID: Hw5VB5OZGCi
--HG--
extra : rebase_source : e083f9a5d2fabea308b7b884e9830f800758ae17
extra : amend_source : 0a7b5f42a937430170fdc16909c559f720085668
This also fixes the issue of processing the artifacts twice in some
situations (bug 1275673). Note that the artifact download no longer
happens when a specific target is passed to 'mach build'.
MozReview-Commit-ID: Ktys6u3r1kG
https://hg.mozilla.org/firefox now exists. It is a unified Firefox
repository containing the heads of all the major Firefox repos
(mozilla-central, inbound, aurora, beta, release, esrs, etc).
Having 1 unified repository is more useful and incurs less overhead
than N separate repos. We want to encourage the use of the unified
repository. So, we start cloning from it.
The unified repo on the server is configured in such a way that
manifest delta chains can become very long - over 30,000 deltas. This
can make manifest reading very slow and slow down many Mercurial
operations. The server compensates for this by setting
format.maxchainlen=10000 to limit the delta chains to 10,000.
Unfortunately, this setting is not preserved when clients do a
traditional clone: the changegroup consists of a single delta chain
and the client will use its own settings (often the default) to
break the chain. This will result in the client re-creating very long
delta chains. So, as part of initializing the new repo we configure
format.maxchainlen in its .hg/hgrc so it doesn't suffer from this
performance issue.
We could achieve the same result by passing the --config option to
`hg clone`. However, the option won't be preserved in the repo's
.hg/hgrc and subsequent `hg pull` operations could result in the
creation of very long delta chains. So we need to write the config
option in the .hg/hgrc. `hg clone` is equivalent to `hg init` +
`hg pull` anyway, so we just separate out the steps and insert a
write to .hg/hgrc in between.
We also set the "default" path (like `hg clone` would do).
DONTBUILD (NPOTB)
MozReview-Commit-ID: Fs4cz9YvdCv
--HG--
extra : rebase_source : 99e8239415f74d078c9a1a903355175cb54a8184
extra : amend_source : ee4bc9ef2b89fabdae6f14d0ab10ca12dc08b15d
I've always been bothered that the one-line bootstrap configures your system
then leaves you on the hook to clone source code and configure the build
system. I'd like the bootstrap wizard to guide you through end-to-end.
This commit addresses part of the disconnect by offering to clone the
Mercurial source repository at the end of bootstrap.
We only offer to clone if we aren't running from a Firefox source checkout
(likely the one-line bootstrap invocation) and if we are in interactive
mode.
I'd like to eventually offer Git support here. Mercurial is the canonical
repo, so it makes sense to start with that.
MozReview-Commit-ID: 6TSZwxB3702
--HG--
extra : rebase_source : 5c35408a4f0e59d681ca28e5b23359c54927b513
extra : amend_source : f980b972e35a17e733e704e47efdd773b3633e45
Without this, we attempt to execute "hg" as a native Win32 program
and get the dreaded "%1 is not a valid Win32 application" error because
"hg" has a shebang and only executes inside a UNIX-like shell.
MozReview-Commit-ID: 5sUrxh1IxFC
--HG--
extra : rebase_source : b01d9b2f8ffc60da320f51a1b7e8a398781c373a
The buildconfig module predates MozbuildObject.from_environment, and
it's about time to start factoring things out such that we only have
one way to get config.status data. This is step 1: making the
buildconfig module use MozbuildObject.from_environment.
Eventually, we'll want to remove the buildconfig module uses everywhere.
The topobjdir-finding logic in mozbuild relies on MOZ_CURRENT_PROJECT
being set, and it's currently only set when going through client.mk.
On automation, during universal builds, make check is invoked directly
in one of the objdirs, so MOZ_CURRENT_PROJECT is not set. We've had
other similar problems in the past. Ensuring MOZ_CURRENT_PROJECT is set
in the objdir itself should reduce the risk of other such issues in the
future.
Historically, a mozinfo for js standalone build has not been necessary,
but with the move towards a) having things work with mach and b)
buildconfig using the MozbuildObject.from_environment in next patch,
mozinfo becomes necessary (it's required for
MozbuildObject.from_environment to find the directory is an objdir).
Interestingly, hazard builds do both a js standalone build and a desktop
Firefox build at the same time, both of which are done with MOZCONFIG
set in the environment... with the Firefox mozconfig. The result of now
writing a mozinfo for js standalone builds is that in that case, they
end up with a reference to the mozconfig, which the build system then
reads, and finds a MOZ_OBJDIR, which then doesn't match the js
standalone build objdir. So for those builds, reset MOZCONFIG.
This makes it easier to lint a path that otherwise wouldn't have been linted due to the include/exclude
directives. Now, you can pass in -n/--no-filter instead of needing to modify the linter configuration file.
MozReview-Commit-ID: GMJuE2C1NyY
--HG--
extra : rebase_source : 03627e930f76903ad629cb01b58c4ae7372e4bb1
The wizard has been ported to the version-control-tools repository
and in-tree consumers have been switched to consume it from there. This
code is now dead. Kill it.
References to the now-defunct code have been removed/updated.
MozReview-Commit-ID: 5fpCXdNIp8L
--HG--
extra : rebase_source : 6c1e2363793fe2cd3a506ce5d962788657871203
extra : histedit_source : c40d2203aaa54bbd48e4e2b46178e277dcdc2e3f
The Mercurial setup wizard has now been ported to the version-control-tools
repository, where it has testing and integrates better with Mercurial
configs.
The bootstrapper has been taught how to invoke the new version of the
Mercurial setup wizard.
This commit switched `mach mercurial-setup` to call the bootstrapper
code for invoking the Mercurial setup wizard from version-control-tools.
As of this commit, the Mercurial setup wizard in tools/mercurial is
unused.
MozReview-Commit-ID: 3xzgOYZWTZn
--HG--
extra : rebase_source : 56697d504ff41ad02d77ddd1241cebafe610751a
extra : histedit_source : feb7450130c447dc74e059173f5b54544c020929
If a state directory is available and we're running in interactive mode
(or have been told otherwise), we now configure Mercurial during
bootstrap.
This consists of cloning version-control-tools to the state directory
(mimicking code in `mach mercurial-setup` today) and running the
config wizard from version-control-tools.
Code for cloning/updating repositories has been stolen from
tools/mercurial/hgsetup.
As the inline TODO notes, I'd like to eventually support
configuring Git during bootstrap. Since Mercurial is the canonical VCS
for Firefox and since we already have a Mercurial setup wizard (and
don't have a Git one yet), I don't think we should block on implementing
Git support.
MozReview-Commit-ID: 1FZyWIlHZNy
--HG--
extra : rebase_source : c727017bbdc703399fa67e1d831280441026614b
extra : histedit_source : fdb124447b4e80277cfd70fb65a24e0947c89c60
Currently, on first run of `mach` it prompts you to create a state
directory. The hand-off between bootstrap and `mach` has always
bothered me because bootstrap is supposed to get your system in a good
state.
In this commit, we teach the bootstrap tool to create the state
directory when not present. This duplicates functionality from `mach`.
The justification for the duplication is explained by inline comment.
In future commits, we'll build on this work to have the bootstrapper
run the Mercurial config wizard, which needs this state directory.
MozReview-Commit-ID: CPKVuRJ3peM
--HG--
extra : rebase_source : 085b67183ec4fda8a23ead3328130c962c95617d
extra : histedit_source : 3ba31232521f624bcf9d0cc5a99033083c1f3657
This begins the consolidation of `mach mercurial-setup` into
`mach bootstrap`. The first step is to move the content of the
mach_commands.py file into the bootstrapper's.
I'm not crazy about adding the sys.path entry for tools/mercurial.
I intend to clean this up later.
MozReview-Commit-ID: Cq56wPG8sO1
--HG--
extra : rebase_source : 48d6d2631760c9333bf99285673430948085630e
extra : histedit_source : e062f6fbc0ae9678347801b4a1f1c9b6912afd52
Killing the sccache background daemon is part of postflight_all, but in
the current setup, postflight_all happens at the end of a "normal" build,
but we run automation build steps after that.
What happens then is that more compilations happen (gtests), which start
sccache again, but there's nothing to kill sccache again once this is
all done.
Now that the OSX universal builds postflight is gone, it is not
necessary for postflight_all to happen before the automation build steps.
So ensure postflight_all scripts happen last.
The downside of this change is that this now prevents sccache.log from
being uploaded, but we should probably send processed data to the graph
server instead.
Killing the sccache background daemon is part of postflight_all, but in
the current setup, postflight_all happens at the end of a "normal" build,
but we run automation build steps after that.
What happens then is that more compilations happen (gtests), which start
sccache again, but there's nothing to kill sccache again once this is
all done.
Now that the OSX universal builds postflight is gone, it is not
necessary for postflight_all to happen before the automation build steps.
So ensure postflight_all scripts happen last.
The downside of this change is that this now prevents sccache.log from
being uploaded, but we should probably send processed data to the graph
server instead.
The correct version of Python will get installed from the install_python method instead of with the system packages.
This is more in-line with how a bootstrapper *should* extend from the base bootstrapper.
MozReview-Commit-ID: JIMGF7XKL02
--HG--
extra : rebase_source : dc70bdf555afe0a0dfb253e01381b5e6fa52eee3
Overrode BaseBootstrapper.which to append '.exe' to any which checks since (hopefully) anything the bootstrapper looks for, must be a windows executable.
Changed base bootstrapper class to use str instead of unicode to avoid a bug in the MinGW version of Python where subprocces.Popen will not accept environment variables that are in unicode instead of str.
MozReview-Commit-ID: 4m8xNifawYS
--HG--
extra : rebase_source : 455b518b099fdba347626ab93b85ddbd44f1f977
Added convenience method for installing from pip.
Windows bootstrapper implements upgrade_mercurial to install mercurial from pip.
MozReview-Commit-ID: ClqNA2NmQcc
--HG--
extra : rebase_source : 8107bbca70b0e1e6208cc37f114ad524472174b8
Windows bootstrapper checks if pacman is installed before continuing.
Added a convenience method similar to BaseBootstrapper.which that works with the mingw version of python in msys2.
MozReview-Commit-ID: 6AG2c18KF0U
--HG--
extra : rebase_source : a76fecf19d81d05e1515647b60f118c590dd3518
These new convenience methods let the bootstrapper update the local package list, upgrade all installed packages, and install new packages.
MozReview-Commit-ID: KZPyBl0OU6Z
--HG--
extra : rebase_source : 6a345b5e0cce7c0095dc1213d6609c1ca6a58920
Created a WindowsBootstrapper class that raises a NotImplementedError when initialized.
As WindowsBootstrapper is implemented, set $MOZ_WINDOWS_BOOTSTRAP to '1' in your environment to test it.
Bootstrapper now detects if the system is being run on Windows, and if it is dispatches to the WindowsBootstrapper.
MozReview-Commit-ID: 3x6PDPuLtzs
--HG--
extra : rebase_source : 250232493a19f20cf3c2218618373cd9ae4b966f
This is a really simple and ugly formatter that is compatible with
treeherder's error highlighting mechanism. It is designed to be identical
to the current eslint output on treeherder:
https://dxr.mozilla.org/mozilla-central/rev/4d63dde701b47b8661ab7990f197b6b60e543839/tools/lint/eslint-formatter.js
Eventually eslint will also use this and we can remove that file. Once
bug 1276486 is fixed, we can make this look a little nicer. But for now
it gets the job done.
MozReview-Commit-ID: CwfWPcwWFxF
--HG--
extra : transplant_source : %F3PJ%CB%27%A5%82U%D2%CF%B3%9E%A7%9F%0F%A4%F4%E9%5D%BB
