We'll require preprocessing that configure subst files don't allow in
the next change, so prepare for that.
Differential Revision: https://phabricator.services.mozilla.com/D43011
--HG--
extra : moz-landing-system : lando
We don't actually care that much about LTO'ing the rust parts of libxul
for gtests, and not LTO'ing it would save multiple minutes of build time
on automation.
Differential Revision: https://phabricator.services.mozilla.com/D42812
--HG--
extra : moz-landing-system : lando
Make the target and host targets depend on those, and flatten the
dependencies.
That is, instead of chains like:
browser/app/target: mozglue/build/target
mozglue/build/target: memory/build/target
we now have:
browser/app/target: browser/app/target-objects \
mozglue/build/target-objects \
memory/build/target-objects
Which means Make can feel free to build the object files in browser/app
before building other dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D42252
--HG--
extra : moz-landing-system : lando
With the addition of toolkit/library/build because of the rust
shenanigans, bug 1573314 and bug 1572046 don't do anything useful
anymore. We're going to do something better anyways.
Differential Revision: https://phabricator.services.mozilla.com/D42251
--HG--
extra : moz-landing-system : lando
Fixes Thunderbird build bustage related to target-shared.
Investigation into the build issue revealed that this hack is no longer necessary and can be removed. And it's always nice to remove Thunderbird specific code from the build system.
Differential Revision: https://phabricator.services.mozilla.com/D41307
--HG--
extra : moz-landing-system : lando
When a directory, like toolkit/library, builds both a static and a
shared library, and another, like toolkit/library/gtest, depends on the
static part, it currently needs to wait for the shared library to be
finished building, preventing both libraries being built in parallel.
By separating shared libraries to a different target, we allow more
parallelism to the build.
Differential Revision: https://phabricator.services.mozilla.com/D41099
--HG--
extra : moz-landing-system : lando
At the same time, make things a little more tangible in the tiers setup
in baseconfig.mk.
Differential Revision: https://phabricator.services.mozilla.com/D37942
--HG--
extra : moz-landing-system : lando
This adds just enough host shared library support for this one use case,
but also takes shortcuts, because fully supporting host shared library
is a deep rabbit hole I'm not ready to take just to fix --enable-lto
--enable-clang-plugin on mac builds.
One downside is that one my machine the plugin now takes > 80s to build,
instead of 15s before, thanks to the lack of unified sources.
--HG--
extra : rebase_source : bf52a72a01d4e3eb77cf52b646b19734b9273075
We want annotationProcessors to be compiled and archived into a JAR at
build time, ready to generate JNI wrappers. (That is, until we turn
the whole thing into a real annotation processor.) But even if we do
use a real annotation processor, we still need to generate SDK
bindings, which is less clearly expressed as an annotation processor.
(It's more of a build step.)
Gradle provides a huge number of ways to organize build logic to
achieve this: see
https://docs.gradle.org/current/userguide/organizing_build_logic.html.
Unfortunately, the best such way -- putting the code into
$topsrcdir/buildSrc -- has key disadvantages:
1) it pollutes the top-level $topsrcdir, and there's no way to change the
location of buildSrc (https://github.com/gradle/gradle/issues/2472);
2) it's complicated to have a dependent project
(mobile/android/annotations) expose its code via a buildSrc project;
3) using buildSrc at all appears to conflict with the Android-Gradle
plugin version that we are using.
Therefore, this commit does something much simpler: it adds a
Java-only project and uses the resulting Gradle "Jar" task and archive
output as input to the existing Gradle "generate JNI wrappers" task.
MozReview-Commit-ID: 2OyYLPneE1M
--HG--
extra : rebase_source : d99b74a0a1e0bb3e8f4d4540978328388e5c2e42
Some content in Makefile.in is removed because after this change, the
scripts no longer invoke the preprocessor and thus don't have unknown
dependencies anymore outside what is provided in their inputs array.
The order of exports.PREFERENCES in properties-db changes because the
data file has shorthands placed after longhands. The only usage of it
is in test_css-properties-db.js which doesn't care about the order.
MozReview-Commit-ID: AMjzTRf2HYN
--HG--
extra : rebase_source : 7976e48e7c7bba467d77a34ab0d7709cde1ecdf4
Some content in Makefile.in is removed because after this change, the
scripts no longer invoke the preprocessor and thus don't have unknown
dependencies anymore outside what is provided in their inputs array.
The order of exports.PREFERENCES in properties-db changes because the
data file has shorthands placed after longhands. The only usage of it
is in test_css-properties-db.js which doesn't care about the order.
MozReview-Commit-ID: AMjzTRf2HYN
--HG--
extra : rebase_source : f9db0659a81bea28b335806ac70e23dc0d36e493
MOZ_REPLACE_MALLOC_LINKAGE was added back when there were problems with
getting weak references working properly for replace-malloc.
Versions of OSX < 10.6 needed flat namespace, but aren't supported
anymore.
Versions of Xcode < 4.5 required flat namespace + a dummy library in
order to produce proper weak references. There is virtually nobody still
building with such an ancient toolchain.
Keeping those around doesn't /really/ hurt, except recent versions of
Xcode don't expose dyldinfo in /usr/bin, used for the configure test.
Consequently, MOZ_REPLACE_MALLOC_LINKAGE ended up being set to use the
dummy library setup, which, by using flat namespace, now causes harm in
bug 1356701, causing bug 1378332.
--HG--
extra : rebase_source : e3edc1f2cf905943c33fafeb631f2f88fc87167e
The Java Addons mechanism never got traction and is not Web Extensions
compatible. Removing it simplifies the product and the build system.
MozReview-Commit-ID: ABUxkqqMISa
--HG--
extra : rebase_source : 346f88882774f072316714cf637a54d771d81a9a
This creates "syms" targets that depend on the corresponding "target" for
directories containing shared libraries or programs. These targets are added
to the main compile graph in automation, and can be invoked through a special
"symbols" target. A future commit will use these targets to dump symbols for
shared libraries and programs during the compile tier.
MozReview-Commit-ID: KLuvmqsK4Zj
--HG--
extra : rebase_source : 8d76b999cb6fac8f11168ac6ebfb58774dfc2d3c
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
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 : 94527a0be3f107991998185903f1c6cf6e190f9f
There are several parts to this ticket:
1) Produce javaaddons-1.0.jar, a standalone JAR defining a (versioned)
Java interface suitable for consumption by third-party Java addon
implementations.
2) Support the new V1 interface in the JavaAddonManager.
3) Add Robocop JavascriptTests testing the JavaScript message passing
interface to and from Java.
This patch can be read as "not in tests/" and "everything in tests/".
--HG--
rename : mobile/android/base/JavaAddonManager.java => mobile/android/base/javaaddons/JavaAddonManager.java
extra : commitid : ApOd0Iz9BrZ
extra : rebase_source : 9808487ec3b233f31524e3694d1e997af78a0c84
extra : histedit_source : c8883a01805d7ed39ffb58e8523103260aa72d0b
Without this, invoking Make in a sub-directory will fail with an error
that libs:: cannot find target `target'.
Without this patch, the Fennec Gradle and IDE build integration fails
compiling its custom targets in mobile/android/base and
mobile/android/base/locales.
--HG--
extra : rebase_source : a105072aee28e4f7693958a175d1d8ce3188b5f4
extra : source : 3232d253cf909e38da318c3ed3c04e7b5fc6a94f
Without this, invoking Make in a sub-directory will fail with an error
that libs:: cannot find target `target'.
Without this patch, the Fennec Gradle and IDE build integration fails
compiling its custom targets in mobile/android/base and
mobile/android/base/locales.
--HG--
extra : rebase_source : be5cc6764b7c1fc7a5bdc177760a709e015e02d4
Mike Hommey
Rob Lemley
Chris Manchester
Narcis Beleuzu
Nick Alexander
Xidorn Quan
Andreea Pavel
David Major
Richard Marti
Jan Beich
Tooru Fujisawa
Mike Shal
Gregory Szorc
Wes Kocher
Carsten "Tomcat" Book
Kartikaya Gupta
Brian O'Keefe