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
This makes building on msys2 easier since its pip is broken.
MozReview-Commit-ID: 1hQHeu3BKOd
--HG--
extra : rebase_source : 5447d96893a502225980d1dab7b4f89b888ad661
Added a quick for MinGW64 then adds the default location of system modules to
sys.path.
MozReview-Commit-ID: IubUhpB3rOf
--HG--
extra : rebase_source : 95f2245fb254473fb9977b37b60f087c05a7eedc
This is going to be necessary for MSYS2 which needs a custom site.py since
the MinGW64 version of Python does not import the system packages.
MozReview-Commit-ID: EfHRmRSmvlV
--HG--
extra : rebase_source : 6ffbcda31318d3581ded3bf860bbd0db2eec8780
This adds the 'xpcshell-test' command to the mach environment found in the test
package. This will allow developers to easily run xpcshell after checking out
and interactive worker.
MozReview-Commit-ID: fBAbfuG5XQ
--HG--
extra : rebase_source : 71077c9142f33843ed87d4bc4617a780f775939b
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
We need this to avoid weird site.py hacks to get msys2 to play nicely with virtualenv.
MozReview-Commit-ID: 9lJSo6MistO
--HG--
extra : rebase_source : 598f25a207dc4307ed531f4e4e5dcfb951ae8283
Before, virtualenv would try to use symlinks based entirely on the value given by the options parser.
Unfortunately, some versions of Python cannot symlink (specifically the MinGW version of Python).
Now, virtualenv ensures the os module has the symlink funciton before attempting to use the symlink function.
MozReview-Commit-ID: DFJ59AaPNpB
--HG--
extra : rebase_source : 4a92c9cbfbfe205e18b890e100fe549d78cebc81
By placing the functools module in the REQUIRED_MODULES list, the environment will not throw an ImportError when the build systemimports functools.
MozReview-Commit-ID: 8DjzXqxvxXd
--HG--
extra : rebase_source : 47ceae1e8b852e0b8bf61f9b34cc953db42e393e
This is going to be necessary in the following commits to ensure that virtualenv has access to native libraries.
MozReview-Commit-ID: FwxOoCWnQMW
--HG--
extra : rebase_source : c4cf829231757b3dc2c5ca821c7248dc3fb0d763
Before bin_path would detect msys2 as if it were a windows system which would cause a virtualenv problem since the binaries should go in a /bin folder not a /Scripts folder for msys2.
Based on a patch by :vlad 89b21efe93
MozReview-Commit-ID: IyAukszHGmN
--HG--
extra : rebase_source : 9ada9cf61b76c85cf483ad8212c95d17070a7025
Technically, this includes the mingw64 version of make, but it is still called mingw32-make when installed from pacman with msys2.
This is a necessary step to make Firefox build on a pure msys2 environment.
Also, unlike mozmake, because this make is installed from a package manager. It can be automatically updated.
MozReview-Commit-ID: EAN6xmIgYWd
--HG--
extra : rebase_source : 43fe0d4b35e91f1143ce2ea1d20f5f3c5f1f7c86
Before, mach would only detect MINGW32 (used with msys). Now it also detects MINGW64 (used with msys2).
MozReview-Commit-ID: 6IrNNmkLKgB
--HG--
extra : rebase_source : e84ee16b5bbc1b6b113163ba5b61759f763645c1
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
