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
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 : rebase_source : 8dd39aefec1064e0836c847c6d223db43df4755b
These variables specify a version of Mercurial that is considered
modern and won't trigger giant warnings about being out of date.
We bump to 3.7.3 because 3.7.3 contains security fixes and it is
important for as many users as possible to get these security fixes.
We also update the messaging to indicate security issues with older
releases.
MozReview-Commit-ID: H4utKINrW0V
--HG--
extra : rebase_source : 5247fec94d7df351ef3c7bb2aa60396bb19a6196
extra : amend_source : 70b9aa52cde71d11e2b6d65a1a83567b8a0c7965
Now that the VisualStudio backend will no-op if nothing has changed, it
should be safe to always run this backend.
On first run, backend generation takes ~3.5s on my machine. On subsequent run,
it takes ~1.5s. Wall time for a no-op config.status is now ~15.7s. We could like
make the Visual Studio backend faster by not writing so many project files.
But this would require consolidating libraries in moz.build files. And that's
out of scope for this change.
We drop the check for MSVS_VERSION because it won't always be defined on
MinGW/GCC builds. We simply default to "2015" if it isn't set.
MozReview-Commit-ID: 5W38HMGmcuV
--HG--
extra : rebase_source : 302d76277058819c115f3c2518b8cb2067971950
extra : source : 408319d87eacb28848efeab0346eb815440adade
Should be a stopgap until bootstrapper is ported to Python 3.
MozReview-Commit-ID: 2NNC3jMftr9
--HG--
extra : rebase_source : 9d903dc0830369a84206c56136fb90006f9ad842
There is probably a way to dynamically retrieve the version. But rather
than take the chance we'd query the wrong thing, let's just parse the
version that Visual Studio writes to the solution file when saving it and
use it.
With this change, generating the VisualStudio build backend should not change
any files unless the build config has changed. This means we can generate
Visual Studio files at will without causing Visual Studio to complain
about the solution and other files changing and needing reloading.
MozReview-Commit-ID: 1udZ72SLEzP
--HG--
extra : rebase_source : d15bff5b30a021dc1180e48fb7bb0d6c84871b69
Visual Studio will write this variable to an ancient Visual Studio
version (2010 I believe) if we don't specify it. Explicitly write the
variable to the minimum Visual Studio version we support.
MozReview-Commit-ID: 8Y0im48OM2G
--HG--
extra : rebase_source : 7b1f4cfe778c6258dce068b2aec8b6acd8e85102
Upon further examination, VS2013 and VS2015 share the same file format
version. They also write the internal version number in a comment, not
the user-facing production version.
MozReview-Commit-ID: 92HB0pEzeI6
--HG--
extra : rebase_source : ebf00ae704ccd44415f8d7054359c87287734926
GetConsoleWindow() can return NULL. Previously, we may have passed a NULL
console reference into FlashWindowEx(). On my machine (when running in a
console), passing NULL doesn't seem to cause an error. But since we have
a report of this function hanging, it is quite possible it can cause
hangs in other scenarios. Since a NULL console won't result in any
notification, let's not call FlashWindowEx() when no console is available.
MozReview-Commit-ID: LrKX8weUkzX
--HG--
extra : rebase_source : 6c3fc724dbc038f6b51bbdc14d985202c47074e8
Before, ./mach build would try to use terminal-notifier after building, but would not be able to since it isn't installed.
MozReview-Commit-ID: 4oBAVfOdcNs
--HG--
extra : rebase_source : 0930e9d4dc038e59f18beb85b4911552c76c0eed
The label has been there for years. It isn't really experimental.
The Visual Studio solution still leaves a lot to be desired. But
let's not scare people away by calling it experimental.
MozReview-Commit-ID: 7UvsbsKNnWw
--HG--
extra : rebase_source : a7d3f824859629297a782a0883ebf78af1d8fa70
By using self._write_file() and FileAvoidWrite, we avoid writing files
unless they change. This means that Visual Studio won't want you to
reload the solution and projects whenever the backend is generated.
This means you can regenerate the backend all you want and chances are
it won't disrupt your Visual Studio experience.
Since self._write_file() creates parent directories for us, we were
able to remove this code.
If you run `mach build-backend --diff` with this commit, output will
change. For reasons I don't understand, we were producing XML with
e.g. \r\r\n sequences. This patch appears to restore \r\n. How
we got \r\r I don't know because I can't find anywhere in the code
where that can occur. But this commit does appear to restore sanity.
Also, it appears modern versions of Visual Studio (perhaps only VS2015)
doesn't write your project files. When I initially implemented Visual
Studio project generation several years ago, as soon as you loaded
the solution and hit "Save All" Visual Studio would re-save your files
using a slightly different formatting (it did some gnarly things with
XML indentation). VS2015 doesn't do this. So your files on disk should
be unmodified for longer, making Visual Studio a more viable development
environment. Yay.
MozReview-Commit-ID: 7CSk0dsLOli
--HG--
extra : rebase_source : 3cd04ba8ffed8fc8880de66b1f4fce1f6300b51c
Currently, self._write_file() instantiates FileAvoidWrite instances
with the default mode of 'rU' which uses universal newlines (\n).
Visual Studio project files use CRLF newlines. We want to use
self._write_file() in the Visual Studio backend (which predates
self._write_file). Prepare for this by passing the mode argument
through.
MozReview-Commit-ID: LHCUf3IrpJ8
--HG--
extra : rebase_source : be08d8e043ef625f8f846c38446e1430e072a665
If we're running VS2013, we generate VS2013 files. If we're running VS2015,
we generate VS2015 files. If we don't have a Visual Studio version
defined, refuse to generate project files (hopefully this doesn't
happen in the real world but I'm sure someone will complain if it does).
MozReview-Commit-ID: 5GdsbGmWPLB
--HG--
extra : rebase_source : 1a50c0fa5b7980ad25fb3ed3c1ec2c95f16996b6
We only support building with VS2013 and VS2015. Remove references
to older versions in the Visual Studio build backend.
MozReview-Commit-ID: 6QTSylqLwLF
--HG--
extra : rebase_source : d654f0e415dd5c1bfa1258633e26d467bea5535a
These imports make an out-of-tree build of SpiderMonkey depend on
the reftest module, which means SpiderMonkey implicitly depends on
layout/tools/reftest.
Firefox automation now uploads resource usage JSON files as
job artifacts (see bug 1272202). Now that the build system
writes the same data format and `mach resource-usage` can
read this data format, let's teach `mach resource-usage`
to load arbitrary URLs. This allows people to view system
resource usage for arbitrary jobs in automation.
Currently, you have to look at Treeherder to find the URL to
the build-resources.json artifact. Perhaps in the future
we can make finding the URL easier. Or we could integrate
source resource viewing into Treeherder itself (this is
probably preferred).
This commit continues the tradition of `mach resource-usage`
being a hacked up mess. Instead of loading the URL in
the browser, we download the URL from Python then serve it
from the HTTP server running as part of `mach resource-usage`.
This is somewhat horrible. But it was easiest to implement.
It also conveniently bypasses any cross origin request
restrictions the browser may impose. So it is useful.
MozReview-Commit-ID: IR1Cfs7SrRN
--HG--
extra : rebase_source : b33231d482ca891c1b3331f472009518bf57f8c3
We currently have our own system monitor serialization in
building.py. It predates as_dict() from mozsystemmonitor. Let's
use the "upstream" data format so we only have a single format
to consume.
This change required updating the in-tree resource viewer to
be compatible with the new data format.
This commit stops short of getting rid of the existing
data massaging code in building.py. Another day perhaps.
MozReview-Commit-ID: 1OJrSiyJjMX
--HG--
extra : rebase_source : 9782b2164d1735ed0872fe8c1637204d5b3b1313
For now, only the following two directories will be linted:
python/mozlint
tools/lint
New directories can be added by adding them to the 'include'
directive in tools/lint/flake8.lint. They all default to the
configuration specified in topsrcdir/.flake8. Subdirectories
can override this configuration by creating their own .flake8
file.
MozReview-Commit-ID: Eag48Lnkp3l
--HG--
extra : rebase_source : 6d98c9fef80055a48cc2622848aa04c3045b747e
The current algorithm for filtering down tests is too naive. For example, given the following
directory structured:
parent
- foo
- bar
- baz
And the following include/exclude directives:
include = ['foo']
exclude = ['foo/bar']
Then running ./mach lint parent and ./mach lint foo/baz should both lint all files in baz but
no files in bar. This provides a nice way to include/exclude directories, while allowing the
underlying linters to find appropriate files to lint *within* those directories.
tl;dr - Straight file paths (no globs) will be passed straight to the underlying linter as is.
While paths with globs will first be resolved to a list of matching file paths.
MozReview-Commit-ID: Eag48Lnkp3l
--HG--
extra : rebase_source : 18ce2231bc4198b1e811d39f9803f0d5e03d982e
So a few changes here:
- node_modules is downloaded using tooltool so that we dont need to rely on external infrastructure.
- We have a npm-shrinkwrap.json file that version locks all of our node packages.
- eslint, eslint-plugin-mozilla etc. are now all installed locally.
In reality this means that we don't hit the network and we don't force users into installing global packages.
./mach eslint --setup has also been improved. We install packages locally and display the path of the user's eslint binary (useful for configuring editors).
eslint-plugin-mozilla has been moved from testing/eslint-plugin-mozilla to /testing/eslint/eslint-plugin-mozilla.
The node_modules directory for eslint and other plugins is located in testing/eslint/.
MozReview-Commit-ID: 4SFSxzka6BS
--HG--
rename : testing/eslint-plugin-mozilla/LICENSE => testing/eslint/eslint-plugin-mozilla/LICENSE
rename : testing/eslint-plugin-mozilla/docs/balanced-listeners.rst => testing/eslint/eslint-plugin-mozilla/docs/balanced-listeners.rst
rename : testing/eslint-plugin-mozilla/docs/import-browserjs-globals.rst => testing/eslint/eslint-plugin-mozilla/docs/import-browserjs-globals.rst
rename : testing/eslint-plugin-mozilla/docs/import-globals.rst => testing/eslint/eslint-plugin-mozilla/docs/import-globals.rst
rename : testing/eslint-plugin-mozilla/docs/import-headjs-globals.rst => testing/eslint/eslint-plugin-mozilla/docs/import-headjs-globals.rst
rename : testing/eslint-plugin-mozilla/docs/index.rst => testing/eslint/eslint-plugin-mozilla/docs/index.rst
rename : testing/eslint-plugin-mozilla/docs/mark-test-function-used.rst => testing/eslint/eslint-plugin-mozilla/docs/mark-test-function-used.rst
rename : testing/eslint-plugin-mozilla/docs/no-aArgs.rst => testing/eslint/eslint-plugin-mozilla/docs/no-aArgs.rst
rename : testing/eslint-plugin-mozilla/docs/no-cpows-in-tests.rst => testing/eslint/eslint-plugin-mozilla/docs/no-cpows-in-tests.rst
rename : testing/eslint-plugin-mozilla/docs/reject-importGlobalProperties.rst => testing/eslint/eslint-plugin-mozilla/docs/reject-importGlobalProperties.rst
rename : testing/eslint-plugin-mozilla/docs/var-only-at-top-level.rst => testing/eslint/eslint-plugin-mozilla/docs/var-only-at-top-level.rst
rename : testing/eslint-plugin-mozilla/lib/globals.js => testing/eslint/eslint-plugin-mozilla/lib/globals.js
rename : testing/eslint-plugin-mozilla/lib/helpers.js => testing/eslint/eslint-plugin-mozilla/lib/helpers.js
rename : testing/eslint-plugin-mozilla/lib/index.js => testing/eslint/eslint-plugin-mozilla/lib/index.js
rename : testing/eslint-plugin-mozilla/lib/processors/xbl-bindings.js => testing/eslint/eslint-plugin-mozilla/lib/processors/xbl-bindings.js
rename : testing/eslint-plugin-mozilla/lib/rules/.eslintrc => testing/eslint/eslint-plugin-mozilla/lib/rules/.eslintrc
rename : testing/eslint-plugin-mozilla/lib/rules/balanced-listeners.js => testing/eslint/eslint-plugin-mozilla/lib/rules/balanced-listeners.js
rename : testing/eslint-plugin-mozilla/lib/rules/import-browserjs-globals.js => testing/eslint/eslint-plugin-mozilla/lib/rules/import-browserjs-globals.js
rename : testing/eslint-plugin-mozilla/lib/rules/import-globals.js => testing/eslint/eslint-plugin-mozilla/lib/rules/import-globals.js
rename : testing/eslint-plugin-mozilla/lib/rules/import-headjs-globals.js => testing/eslint/eslint-plugin-mozilla/lib/rules/import-headjs-globals.js
rename : testing/eslint-plugin-mozilla/lib/rules/mark-test-function-used.js => testing/eslint/eslint-plugin-mozilla/lib/rules/mark-test-function-used.js
rename : testing/eslint-plugin-mozilla/lib/rules/no-aArgs.js => testing/eslint/eslint-plugin-mozilla/lib/rules/no-aArgs.js
rename : testing/eslint-plugin-mozilla/lib/rules/no-cpows-in-tests.js => testing/eslint/eslint-plugin-mozilla/lib/rules/no-cpows-in-tests.js
rename : testing/eslint-plugin-mozilla/lib/rules/reject-importGlobalProperties.js => testing/eslint/eslint-plugin-mozilla/lib/rules/reject-importGlobalProperties.js
rename : testing/eslint-plugin-mozilla/lib/rules/var-only-at-top-level.js => testing/eslint/eslint-plugin-mozilla/lib/rules/var-only-at-top-level.js
rename : testing/eslint-plugin-mozilla/moz.build => testing/eslint/eslint-plugin-mozilla/moz.build
rename : testing/eslint-plugin-mozilla/package.json => testing/eslint/eslint-plugin-mozilla/package.json
extra : rebase_source : cf689f6cc170b9a22018c981a768f545f952e019
Currently a bug in python (https://bugs.python.org/issue8296) is preventing a KeyboardInterrupt from
reaching the parent process, meaning we can't kill the process with SIGINT. There is a workaround to
this bug, but instead I decided to ignore SIGINT in the parent process completely. Now, each child
process is responsible for handling SIGINT on its own. Since child processes should all shutdown
relatively quickly anyway, this effectively also ends the parent process.
The benefit of doing it this way is that each child process can return the results they have collected
to date. So when a developer hits Ctrl-C, they'll still see some (but not all) formatted lint output.
The downside is that a poorly implemented external linter could block the parent process from exiting
quickly, but if this happens we should just fix the linter.
MozReview-Commit-ID: 2tRJgtmoPYP
--HG--
extra : rebase_source : e72282bcc29c9b22690168dc973a817236cdf8ca
Firefox automation now uploads resource usage JSON files as
job artifacts (see bug 1272202). Now that the build system
writes the same data format and `mach resource-usage` can
read this data format, let's teach `mach resource-usage`
to load arbitrary URLs. This allows people to view system
resource usage for arbitrary jobs in automation.
Currently, you have to look at Treeherder to find the URL to
the build-resources.json artifact. Perhaps in the future
we can make finding the URL easier. Or we could integrate
source resource viewing into Treeherder itself (this is
probably preferred).
This commit continues the tradition of `mach resource-usage`
being a hacked up mess. Instead of loading the URL in
the browser, we download the URL from Python then serve it
from the HTTP server running as part of `mach resource-usage`.
This is somewhat horrible. But it was easiest to implement.
It also conveniently bypasses any cross origin request
restrictions the browser may impose. So it is useful.
MozReview-Commit-ID: IR1Cfs7SrRN
--HG--
extra : rebase_source : 91f5f807c19643ac4d1edb8f6652110813f7e53f
We currently have our own system monitor serialization in
building.py. It predates as_dict() from mozsystemmonitor. Let's
use the "upstream" data format so we only have a single format
to consume.
This change required updating the in-tree resource viewer to
be compatible with the new data format.
This commit stops short of getting rid of the existing
data massaging code in building.py. Another day perhaps.
MozReview-Commit-ID: 1OJrSiyJjMX
--HG--
extra : rebase_source : b7c7824b84110f118223dc483b03398855fe9965
Origins will be set for any caller of CommandLineHelper.add, but will only
be propagated if args are added to extra_args. This results in an incorrect
origin recorded for mozconfig injected arguments.
MozReview-Commit-ID: 9mJCaNHyd5C
Originally, the changes to FakeCompiler allowing overlays was meant to
be used for compiler target platform, but it turns out the
simplifications this allows on the compiler definitions themselves are
nice.
We use _pretty_path when specifying the targets of generated files, so
we need to use _pretty_path for the inputs as well. Otherwise make won't
know that they refer to the same file, and result in "No rule to make
target" errors.
MozReview-Commit-ID: JTdLFbkX1J0
Some generated files will depend on other generated files, but still
need to be in the export tier because they are C++ headers.
MozReview-Commit-ID: AFvp92lF0xy
Mozlint provides two main benefits:
1. A common system for defining lints across multiple languages
2. A common interface and result format for running them
This commit only adds the core library, it does not add any consumers of mozlint just yet.
MozReview-Commit-ID: CSQzq5del5k
--HG--
extra : rebase_source : b520b96177281a1b1770edf53a01cbc2196f494f
- enable debug artifact from a mozconfig file based on MOZ_DEBUG environment variable
- OSX debug artifact builds have 'mac64' instead of 'mac' into their file name
(fix debug artifact build download on OSX)
MozReview-Commit-ID: 7kAvsTfwaCb
--HG--
extra : transplant_source : %E6v%25%B79M%02%7E%A9%8B%FF%24%03%D1%BDo%AB%0F%B49
