The test in old-configure.in for MOZ_REPLACE_MALLOC_LINKAGE runs
dyldinfo, which is a native tool on OSX. We have it in the cross
toolchain as well, but as x86_64-apple-darwin11-dyldinfo. We should use
the TOOLCHAIN_PREFIX here to make sure we get the same result as native
builds.
MozReview-Commit-ID: 3jyzpaM8ZGy
--HG--
extra : rebase_source : fa0d2c1470f8d61b3f31c9a46609d8911ae2ff91
js/src/builtin/Intl.js will spew three C4819 warnings every time non-Western
developers build the tree locally on Windows because of non-ASCII characters
in the file. Usually we have compilers use UTF-8 to prevent this, but it did
not work for Intl.js because embedjs.py did not pass around $CPPFLAGS.
--enable-warnings-as-errors did not catch this because embedjs.py did not
pass around warnings-as-errors flags either.
This patch will fix both issues.
MozReview-Commit-ID: 5D1TCGnIX1T
--HG--
extra : rebase_source : 9f353d46d0a5320f9a0b9be2aea11fb66d6a88b4
-Os generates smaller code, at the expense of performance. On desktop,
this tradeoff is not necessarily the best, especially when considering
the vast performance difference. Most downstream redistributors also
don't do PGO and don't override defaults, so they would tend to ship
slower builds as a consequence.
We however keep -Os as default for debug builds for now, because -O2
triggers -Werror=strict-overflow failures somehow.
--HG--
extra : rebase_source : ad2f4fedb7934b6b23b84412c86b30d29a8fb5f8
-Os generates smaller code, at the expense of performance. On desktop,
this tradeoff is not necessarily the best, especially when considering
the vast performance difference. Most downstream redistributors also
don't do PGO and don't override defaults, so they would tend to ship
slower builds as a consequence.
--HG--
extra : rebase_source : 7d66393d03b9424fdcc46874a09239ffe46cfb33
This intentionally allows to set MOZ_INSTALL_TRACKING without
reference to the milestone being release or beta. That is, we
separate the default value (which depends on release or beta) from the
value specified, making life easier for developers.
MozReview-Commit-ID: 3vPF7KO7fEX
--HG--
extra : rebase_source : 8d5764104b5322a32e4a048bfd3222f62fed73bb
We now have code that unconditionally requires the rust
compiler and are committed to adding more. Remove this
last vestige of conditional support.
MozReview-Commit-ID: EK6FBnAbR
--HG--
extra : rebase_source : 6efda10a74f9ca0482304c2b1ffe6941e42138f8
The first attempt at this patch in Bug 1314979 turned off the entire
ANGLE section for MINGW builds on Linux for Windows. This was
incorrect, as it also turned off includes of very important files
like d3d11.h
This changes it so we go through the ANGLE section, but if we don't find
a Windows SDK we only consider that an error when we're compiling with
MinGW for Windows _on_ Windows. If the Host and Target OSes don't match
(meaning we're compiling on Linux for Windows) we ignore the lack of a
Windows SDK.
MozReview-Commit-ID: KyggI6yJCEM
rustc generates .lib files for its libraries when compiling for Windows
(even using MinGW on Linux). But MinGW expects .a files. So we add in
rust-specific prefix and suffixes so MinGW builds can find the libs that
rustc generates. (And the RUST_LIB- variables default to the same vales
as the LIB_ variables otherwise.)
MozReview-Commit-ID: ClsA0YuJaxh
--HG--
extra : rebase_source : 7b46460c94ceb34b7a5a302ce91d3f1dca600041
This flag enables the stack-cookie exploit mitigation for all functions which
manipulate stack-based buffers, providing better protections than
-fstack-protector, at considerably lower performance overhead than
-fstack-protector-all.
r=froydnj
MozReview-Commit-ID: 7ZNAHHAf376
--HG--
extra : rebase_source : 6d5ccbb9537372912c3f5a73fe0fdc65bb68ac08
MINGW builds do not need any of the checks that are performed in the
windows.configure file. Nor do they the D3D compiler DLL that is
needed for ANGLE, so we can skip that entire section in
old-configure.in.
MozReview-Commit-ID: DqufbgGoGy4
--HG--
extra : rebase_source : d5f1ed371f79a8a16f888ccc5d058ac72a69f34f
Historically, we had support for some GNOME VFS protocols through the
gnomevfs library, and this was under extension. This may not have been
built by default when it was introduced, but GNOME upstream moved those
things into Gtk itself, and we then got support for the new Gio-based
protocol, similar to what we had through the gnomevfs library.
Time passes, and we switched off the gnomevfs library entirely, and
enabled the Gio-based protocol handlers by default. We then removed
everything related to the gnomevfs library.
Fast forward to now, and disabling Gio support in Firefox just doesn't
make sense, and leaving the gio protocol handler as an extension doesn't
make sense either.
As it is a protocol handler, its natural place is under
netwerk/protocol, which is where we're moving it here.
The netwerk/protocol subdirectories being handled automatically, we
don't need to add the moved directory in any DIRS variable.
--HG--
rename : extensions/gio/moz.build => netwerk/protocol/gio/moz.build
rename : extensions/gio/nsGIOProtocolHandler.cpp => netwerk/protocol/gio/nsGIOProtocolHandler.cpp
extra : rebase_source : 071a9cb1769f013717357458df24e2fd9570ccf4
Historically, we had support for some GNOME VFS protocols through the
gnomevfs library, and this was under extension. This may not have been
built by default when it was introduced, but GNOME upstream moved those
things into Gtk itself, and we then got support for the new Gio-based
protocol, similar to what we had through the gnomevfs library.
Time passes, and we switched off the gnomevfs library entirely, and
enabled the Gio-based protocol handlers by default. We then removed
everything related to the gnomevfs library.
Fast forward to now, and disabling Gio support in Firefox just doesn't
make sense, and leaving the gio protocol handler as an extension doesn't
make sense either.
As it is a protocol handler, its natural place is under
netwerk/protocol, which is where we're moving it here.
The netwerk/protocol subdirectories being handled automatically, we
don't need to add the moved directory in any DIRS variable.
--HG--
rename : extensions/gio/moz.build => netwerk/protocol/gio/moz.build
rename : extensions/gio/nsGIOProtocolHandler.cpp => netwerk/protocol/gio/nsGIOProtocolHandler.cpp
extra : rebase_source : fe3c9480cee468aa2a24fd34e569b58e4f2c9c9a
It looks like Google decided to split these jars out a bit, so we need to piece
them all back together.
We could probably just query the sdk version instead, but I'm not 100% sure
know when this setup changed - moreover we don't know when (if?) the paths
are likely to change again. SDK 26.0 still has lint 25.3.1, so the SDK and
lint versions don't appear to be tied.
It seems that only the lint* jars are needed to compile 'build/annotationProcessor',
however we need all the remaining jars in the classpath when running that code
in 'widget/android/bindings'.
MozReview-Commit-ID: GAKwMrVXW55
--HG--
extra : rebase_source : 4e790aaccae8ccc3f151c39bf1ef4404b2581d7a
Android/x86 runs xpcshell and a limited of mochitest. These tests are already passed on m-c.
MozReview-Commit-ID: 7Qkqi0dYh95
--HG--
extra : rebase_source : 4cc064aea022a8ba17d9a78a1f36a612ab877898
Now that we don't support XP it's reasonable for us to drop support for GDI
fonts and rely solely on DirectWrite. We should start this process by removing
support for building without DirectWrite.
Franziskus Kiefer
Mike Taylor
Ryan VanderMeulen
Jean-Yves Avenard
Stephen A Pohl
Mike Shal
Tom Ritter
Masatoshi Kimura
Mike Hommey
Wes Kocher
Ben Hearsum
Bruce Sun
Petr Sumbera
Paolo Amadini
Nick Alexander
Jan Beich
Ralph Giles
Alex Gaynor
Iris Hsiao
Andrzej Hunt
Dão Gottwald
Makoto Kato
Kai Engert
Glenn Randers-Pehrson
Jeff Muizelaar
Carsten "Tomcat" Book
David Anderson