We were defining the E10S_TESTING_ONLY build-time define with the value of the E10S_TESTING_ONLY config variable,
regardless of the value of E10S_TESTING_ONLY. Even if E10S_TESTING_ONLY in configure was blank, we'd still define
E10S_TESTING_ONLY, which resulted in E10S_TESTING_ONLY ifdef'd code to be included when we didn't want it to.
We now only ever define E10S_TESTING_ONLY iff NIGHTLY_BUILD is defined, and we do it globally.
This also fixes a busted E10S_TESTING_ONLY ifdef that didn't have an endif.
--HG--
extra : amend_source : 9c8fe8db110765272fa666a5c118d388f87c23d7
This saves dexing and shipping the Google Play Services and other Google
libraries, which add resources and about 3megs of code.
Due to ordering issues, the relevant flags and toggles were moved to
configure.in and exposed early enough to be used by confvars.sh.
This patch adds a SpiderMonkey jsshell binary via tooltool and arranges
for it to be used in automation (more specifically, whenever JS_BINARY
is defined).
We'd prefer to build a host SpiderMonkey jsshell, but that's not trivial
right now; and we'd prefer to use a minifier better than the existing
Python jsmin (possibly written in JavaScript), but one step at a time.
We modify the environment before running freetype2 configure. When it uses
the same cache file, it stores knowledge about that environment in the cache
file. The cache file is then reused to configure in js/src, with yet again a
different environment, which makes subconfigure.py clear the cache because
of the differences.
The configure in js/src is however invoked with the same environment as the
main configure was invoked with (mostly), so without freetype2 on the way,
reusing the cache for it works as expected. In fact, it works better with the
cache because of things coming from mozconfig that are not exported.
With freetype2 on the way, as mentioned above, the cache is cleared. Without
the cache, js/src/configure does new detections with a possibly different
environment, and stores that in the cache. Until the next build, which then
uses that different cache for the top-level configure.
This results in subtle differences in the HOST_CC/HOST_CXX variables on
android builds because those variables are not exported from mozconfig,
depending on PATH, what the builder was building before, and if the build
is a clobber.
Avoiding the freetype2 subconfigure writing its environment variables change
to the top-level cache makes the cache never invalidate for js/src.
There are, sadly, many combinations of linkage in use throughout the tree.
The main differentiator, though, is between program/libraries related to
Gecko or not. Kind of. Some need mozglue, some don't. Some need dependent
linkage, some standalone.
Anyways, these new templates remove the need to manually define the
right dependencies against xpcomglue, nspr, mozalloc and mozglue
in most cases.
Places that build programs and were resetting MOZ_GLUE_PROGRAM_LDFLAGS
or that build libraries and were resetting MOZ_GLUE_LDFLAGS can now
just not use those Gecko-specific templates.
On automation, this brings Windows configure time on a clobber from 5:30 to 3:10.
Sadly, because make needs to run under intl/icu/host before configuring
intl/icu/target, intl/icu/host needs to be configured independently. Fortunately,
that's not configured for normal windows builds anyways.
Also, having multiple subconfigures sharing the same cache file is dangerously
racy. Fortunately, not a lot do. In fact, only js/src and $_subconfigure_subdir
do, so force the latter (only used for ldap sdk on comm-central) not to
configure in parallel.
Gecko, for better or worse, allows non-m-c apps to define custom error codes and
use them in nsresult. This error breaks the ability to switch on those custom
error codes when an error happens. For this reason, it's not reasonable to make
this an error at present.
We officially test MSVC2013 builds now, so it makes sense to
emulate the same compiler when building with clang-cl. Also,
we need to build with fallback mode, since clang-cl doesn't
still support SEH. We also need to pass these flags to NSS
too for the same reason.
With bug 1077366, --enable-wrap-malloc is not abused anymore for android
linkage. Other than android linkage, the option has been of limited
usefulness since bug 804303 (replace-malloc), which allows runtime wrapping.
In fact, chances are --enable-wrap-malloc breaks things with jemalloc
integration.
This doesn't, however, remove those options from standalone js builds,
although it's not clear they're any useful there either.
Since essentially everything is linked to libmozglue and libmozglue takes
precedence in symbol resolution in our dynamic linker, there is no need
to wrap most symbols. PR_GetEnv/PR_SetEnv still needs wrapping because
there's no other way to actually wrap the calls from NSPR itself and NSS,
as well as the symbols wrapped because our dynamic linker can't find them
in system libraries on some devices because they're weak.
DLLFLAGS was exported from main configure so that it would be picked by NSPR
configure, allowing to pass down flags to link NSPR against mozglue. With
MOZ_FOLD_LIBS always enabled on MSVC builds, that is not necessary anymore
since the NSPR build system doesn't build any shared library anymore.
Setting MOZ_FOLD_LIBS should stop being an opt-in for individual applications,
which also makes them responsible for doing the right thing, which happens not
to be the case for B2G Desktop Linux builds.
Enforcing MOZ_FOLD_LIBS to be set on the relevant platforms in configure ensures
everything is setup up correctly, and also allows to stop caring about supporting
now hypothetical e.g. MSVC builds without MOZ_FOLD_LIBS (which require to pass
DLLFLAGS down to the nspr build system to make nspr built against mozglue which
would now be unnecessary)
Currently, when there is both an expandlibs descriptor and an actual static
library, expandlibs picks the static library. This has the side effect that
if there are object files in the static library that aren't directly used,
they're dropped when linking, even when they export symbols that would be
exported in the final linked binary.
In most cases in the code base, files are not dropped that way. The most
notable counter-example is xpcomglue, where actually not dropping files
leads to link failure because of missing symbols those files reference
(yes, that would tend to say the glue is broken in some way).
On the opposite side, there is mozglue, which does have both a descriptor
and a static library (the latter being necessary for the SDK), and that
linking as a static library drops files that shouldn't be dropped (like
jemalloc). We're currently relying on -Wl,--whole-archive for those files
not to be dropped, but that won't really be possible without much hassle
in a world where mozglue dependencies live in moz.build land.
Switching expandlibs to use descriptors when they exist, even when there
is a static library (so, the opposite of the current behavior) allows to
drop -Wl,--whole-archive and prepare for a better future. However, as
mentioned, xpcomglue does still require to be linked through the static
library, so we need to make it a static library only.
To achieve that, we make NO_EXPAND_LIBS now actually mean no expandlibs
and use that to build the various different xpcomglues.
Now that Seamonkey is building with CentOS 6
we can bump the gtk version ready for some code tidy ups.
--HG--
extra : transplant_source : q%B0%27%5By%171%F2%21%04Q%B4%07s%0A%9C%BC%19%3C%8B
Masatoshi Kimura
Alexander J. Vincent
Ben Turner
Mike Hommey
Julian Seward
Cervantes Yu
Chris Peterson
Thomas Zimmermann
Carsten "Tomcat" Book
Panos Astithas
Nathan Froyd
Wes Kocher
Mike Conley
Nick Alexander
Glenn Randers-Pehrson
Nicholas Nethercote
Ehsan Akhgari
Dave Huseby
Hiroyuki Ikezoe
André Reinald
Ryan VanderMeulen
Terrence Cole
Jan Keromnes
Joshua Cranmer
Andrew Martin McDonough
Chris Jones
Tooru Fujisawa
Jordan Santell
Kai Engert
Eric Rahm
Lucas Rocha
Mike de Boer
wesj
Robert Strong
Gian-Carlo Pascutto
Jacek Caban
Timothy Arceri
David Keeler
Markus Stange
Christian Holler
Bob Owen
David Major
Chris Kitching