Support OSX Signed nightlies (in the complete.mar too)
MozReview-Commit-ID: HXiFGE14wYJ
--HG--
extra : rebase_source : 1d02b4714c8fafe6cdcd74e6d9b5612c44dcb3b4
- Set the extensions.legacy.enabled pref for mochitests etc
- Skip a plugin-inside-xpi test for now if legacy extensions
are force-disabled. That test can just be removed once we
get to 57.
MozReview-Commit-ID: As9LtkQTcTS
--HG--
extra : rebase_source : fcc84daef95c453e893cc3b98498fdb87f54b1bb
This adds a py_action invocation wrapping aapt and implements a hacky
implementation of the Gradle build system's resource merging
algorithm; once we have the moz.build and Gradle resources identical,
we'll be one big step closer to producing bit-identical builds and
flipping the switch in favour of Gradle. With this, the R.txt
produced by the aapt invocation is the same as the R.txt produced by
the py_action invocation.
Originally I wrote this to use GENERATED_FILES, but it produced a
world of pain. Since Android's aapt tool is fundamentally directory
oriented, not file oriented, it required adding support for FORCE to
GENERATED_FILES and required directory crawling and FileAvoidWrite in
the wrapper. After getting that working I was eventually stymied by
the arcane requirements of the Android re-packaging system, which
interacts with the l10n system. I would have required support for
building GENERATED_FILES in the libs tier rather than the misc tier.
After that realization I gave up and turned to py_action: the
dependencies on branding are just too entangled with l10n to use
GENERATED_FILES.
And, in the not-so-distant future, all of this moz.build and
Makefile.in chicanery will be deleted in favour of invoking Gradle at
the appropriate points!
MozReview-Commit-ID: 4ueVNa7gzgs
--HG--
extra : rebase_source : dab092a188bc735ef819a4be0ad13387e85c87e2
extra : source : a05bd87b09ee5e4cff20fe84c2e75ac3b2a494a1
Create a test for version control related functionality.
MozReview-Commit-ID: GXd27O69GNg
--HG--
extra : rebase_source : 56ce4a38b591fd62f05fbaed0ff05d56ec127422
The underlying commands to mozlint's vcs.py had a few problems. This:
1. Ensures deleted files aren't considered in both hg and git
2. Automatically determines the default remote repo and branch when using --outgoing with git
3. Excludes metadata from output of the git command used with --outgoing
4. Adds --cached to the git command for --workdir, which lints all staged files
MozReview-Commit-ID: EBtM3MCiCDs
--HG--
extra : rebase_source : 982b24acd81c86e383b28b8a71bcd51a041e60f4
The old method had a bunch of 'if vcs == git' statements and the like. This
made it hard to follow code paths for a given vcs system. I think this refactor
makes things cleaner to read. It shouldn't be changing any functionality.
MozReview-Commit-ID: EBtM3MCiCDs
--HG--
extra : rebase_source : 9c0fda3f4f824351bae852af25bcd2240b1b1024
The rev option is inherently broken. It does let you lint files touched by any
revision, but it doesn't update those files to that revision first. Instead,
they get linted at whatever the working directory is and their results are
bogus. Even if we did some magic to update the files to the proper revision
with in-memory version control magic, the config files would still be out of
date.
Plus, the new --outgoing option does pretty much the only thing --rev was good
for. Rather than cause confusion, I think it's better to just remove the
option.
MozReview-Commit-ID: 2y2UnfIkvsR
--HG--
extra : rebase_source : 9b5c142270c98905d71ebb89d1620e91914c0b47
This prevents us from redundantly installing httpd.js and httpd.manifest
from the test package during an artifact build, which interferes with
the Tup backend's handling of these files as symlinks.
MozReview-Commit-ID: LuMurUc1P36
--HG--
extra : rebase_source : 1aabd788ff71ae28434a4076d5304f611ada5d92
As mozprocess doesn't have any special handling of stderr, should cargo
operations fail their output is dropped. Switch to subprocess.check_call to
ensure cargo errors are displayed to the caller.
This was a regression from bug 1288432. The 'extensions' config in mozlint required a
leading period, but eslint requires them without the period (and this got copied over
to the linter definition). The result was mozlint filtering out any files (not dirs)
that were passed in.
This just modifies mozlint to strip out the period so both are acceptable.
MozReview-Commit-ID: CbNynYzrbGz
--HG--
extra : rebase_source : 51c740cb1d2febaee3ae46784f83381cda5e5eaa
libGL package was consolidated into mesa-libs but quarterly set still
uses the old name. Since gtk3 (via libepoxy) and gtk2 (via cairo)
already indirectly depend on mesa-libs take advantage of it to avoid
churn on updates.
MozReview-Commit-ID: F5LBOOthAMc
--HG--
extra : rebase_source : 4e3e30e817187c3ffef30e280554b12b02f44568
Bump the target version and checksums for the rustup installers
we use for the latest release so reduce the variance with manual
installs.
MozReview-Commit-ID: E5O4UOu1wLr
--HG--
extra : rebase_source : a0745515957667787929bc5df05a66adb29cbd66
If we don't do this, various bits of test infrastructure will turn on
when stylo is merely built, not enabled, which will cause no end of
orange and unhappiness.
Before, MSVS was set in old-configure and could only be unset or
"2015." We move the definition of the variable to moz.configure
and support defining its value as "2017" when VS2017 is being used.
As part of this, I discovered that GYP barfs with a "2017" value.
This is likely a limitation of the legacy version of GYP we have
vendored. Rather than go down the rabbit hole of upgrading GYP,
I added code to convert the value to "2015." This preserves existing
behavior and unblocks us from setting MSVS_VERSION properly. A
warning is emitted to remind us to remove this hack once GYP is
upgraded.
After this commit, we now generate native VS2017 solutions and
projects when building with VS2017.
MozReview-Commit-ID: BvNJX3F8qCn
--HG--
extra : rebase_source : 13a495856a83d9ca7afbb4770ebab1cc7f651cae
