Upload symbols when --enable-artifact-build-symbols is specified.
Add --enable-artifact-build-symbols to artifact config for linux, linux64,
win32, win64, macosx64.
MozReview-Commit-ID: LpuwfzWXPBH
--HG--
extra : rebase_source : 137466aa3c8c327cf1932e012927fceb451d82ab
Also, now that we're using modern C++11 compilers, we can just rely on
static_assert, instead of the pile of macros used in the autoconf test.
--HG--
extra : rebase_source : 85d507da653d07e6527a971082277486e3502ea2
The best kind of patch: bulk deletion. This removes two separate but
similar build flags, and an unsupported integration piece. The first
packaged Fennec's resources into an ill-defined GeckoView archive; the
second built on the first to produce an Android ARchive for external
consumption. Neither of these artifacts are supported or have
consumers; in fact, they mislead potential consumers, since they're
known to be broken. The Gradle build work under the --with-gradle
flag, and significant follow-up, is the path forward if Mozilla wants
to invest in packaging GeckoView on Android for external consumption.
That is, rather than hacking together AAR files, we'll use the
well-supported Gradle mechanisms for building and publishing such
libraries.
MozReview-Commit-ID: 4Z1jJ8z0cyJ
--HG--
extra : rebase_source : b8e65f39c286313fe8963bf3832d9b6977ef188f
A few notes:
* This doesn't accommodate general OMNIJAR_NAME definitions. The
current name (assets/omni.ja) is baked into the product in a few
places, and is very unlikely to change, so we just error out if this
isn't true.
* This makes the package-manifest.in file authoritative for what goes
into assets/, libs/, and the APK root. Previously,
package-manifest.in wrote into assets/ and libs/ but
upload-files-APK.mk also had a convoluted DIST_FILES filtering
process to work through before a file actually made it into the APK.
* This is intentional about repackaging. It simplifies the repackage
step rather than trying to make unpackage-then-repackage the same as
just package. I pretty much never get repackaging correct the first
time; this should help. (I've manually tested it.)
* The ALREADY_SZIPPED during repackaging is subsumed by the previous
check if UNPACKAGE is set. The custom linker expects stored, not
deflated, libraries, so there's some small legwork to accommodate
that in mozjar.
MozReview-Commit-ID: JvVtIUSX685
--HG--
extra : rebase_source : fd8a9cfe3dc364d23b1065995db599f99e676e38
Builds with Visual Studio 2015 require the Universal CRT. While the
universal CRT may be present on the target machine, there is no
guarantee of this. So, we have to package these DLLs to ensure target
machines are able to run js.exe.
Similar code to what this commit adds exists in build/win32/Makefile.in.
MozReview-Commit-ID: 8LIk1JlKLiT
--HG--
extra : rebase_source : 191c5344a67e9ae1ce249ae2007f193dc9f6de4e
This is several hundred lines of make goo that makes upload-files.mk
even harder to read than it actually is. Extract it to its own file.
I performed a `hg cp` to preserve file history so blame continues to
work.
MozReview-Commit-ID: IpoPE79m9SX
--HG--
rename : toolkit/mozapps/installer/upload-files.mk => toolkit/mozapps/installer/upload-files-APK.mk
extra : rebase_source : 1c3ce7596a89994fd37b9230de9752c441751877
This file is so hard to read. Add some indentation to make it easier to
grok.
I also converted some useless tabs to spaces.
MozReview-Commit-ID: 7DFKeW66uD6
--HG--
extra : rebase_source : fb816ece4dba7a7971e8f00a4f651a1f8adcf633
32-bit PGO builds need to modify the PATH to find pgortXXX.dll. We were
doing this for Visual Studio 2013 (VC12) in 2 locations. We weren't
doing it for Visual Studio 2015. This resulted in a failure to launch
PGO instrumented executables because pgort140.dll could not be found.
This commit refactors the PATH munging to support Visual Studio 2015.
MozReview-Commit-ID: 4EKf8gjcNH6
--HG--
extra : rebase_source : 2772558b06202d26583401bc41e56da8c5a69ef4
There's no slick way to determine that we're doing a single local
repack, and it's not worth adding a new flag just for this situation.
So let's not sign the bouncer APK if tests are disabled; since tests
are disabled during single local repack packaging, this should be
sufficient. This makes the bouncer APK just like the Robocop APK.
MozReview-Commit-ID: AaHUEMhcqMy
--HG--
extra : rebase_source : e386c139613f7bfc83b4e7a28e905a6489171c5a
Opt-in by adding --enable-gradle-mobile-android-builds.
Gradle dependencies (including the Android-Gradle plugin) are assumed
to be present. Local developers will fetch them from the jcentral
repository.
Android-specific Maven dependencies are shipped as "extras" with the
Android SDK, and should be found automatically by the Android-Gradle
plugin.
MozReview-Commit-ID: 966XgddWgEu
--HG--
extra : rebase_source : 8e8c6156e1d06813c250662e104fd14c621d91ab
extra : source : 306cf0271d3e3a344fcbfd2baf75e0450c288cf1
extra : histedit_source : d17446714236c408699a0953882e84ac3a192380%2Cc21b166af79ef1e00215748820bc2670405ac1dc
The behavior is not entirely idempotent (most notably for
buildconfig.html), but this can be improved later if necessary.
It is idempotent where it matters.
This allows to get rid of config/makefiles/rcs.mk and its uses.