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
Before making top-level traverse js/src moz.build files, there was a need to
distinguish between top-level traversing e.g. top-level moz.build or
config/moz.build and js/src traversing them. With a single traversal of both
moz.build sets, we now only need to distinguish between js standalone builds
and gecko builds.
There is still, however, a need to distinguish between top-level vs. js/src
configure runs on gecko builds to make them subconfigure icu and libffi from
top-level instead of js/src in js standalone builds, or when choosing to make
js/src's config.status do something when run or not.
Mike Hommey
Nick Alexander
Chris Manchester
Richard Marti
Jan Beich
Tooru Fujisawa
Mike Shal
Gregory Szorc
Wes Kocher
Carsten "Tomcat" Book
Kartikaya Gupta
Brian O'Keefe
Neil Rashbrook