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.
Until we have the ability to properly make these flags conditional in
moz.configure, do not perform these checks.
MozReview-Commit-ID: CexvgiadIw0
--HG--
extra : rebase_source : 3944a7c98a6570bf0f30dc01a9d895cc07cc0ff1
Although bug 1322703 is backed out, we can remove -FS options to build SIMPLE_PROGRAM.
MozReview-Commit-ID: 7uO3We5hc5n
--HG--
extra : rebase_source : 6f909c4f38ba5a5bdffed7f9ca5be0030b9c681b
Although I add -FS option to support VS2013+ by bug 915973, after landing bug 1322703, -FS option is unnecessary now.
MozReview-Commit-ID: 4SYmwGXHA9U
--HG--
extra : rebase_source : d6abc1d03f0fede48c11ee8a1c159d74d530169d
Currently mozconfig.cache overrides a few build options for sccache. This
patch moves them into toolchain.configure so that the build system will
set them properly when sccache is in use. Additionally, {CC,CXX}_WRAPPER
are set in config.mk, so just avoid setting them when sccache is in use.
MozReview-Commit-ID: FYlVKRI8OiN
--HG--
extra : rebase_source : cc7e4346869b98a52840c101824044abc236637f
This removes the UNIFY_DIST and UNIFIED_BUILD variables, as well as the
--unify flag from the packager and UnifiedBuildFinder from mozpack. As a
result the STAGEPATH variable is never defined anymore, so its uses can
be removed as well.
test_unify.py is currently the only mozbuild/mozpack test that fails
without running configure first, and there isn't much point in fixing
tests for things that we don't actually use anymore.
MozReview-Commit-ID: F5q1FPW3Did
--HG--
extra : rebase_source : cadbd237f51c23ea1983135294521d628d16f0df
Intl API (ECMA-402) already supports most web browsers such as Edge (including Windows 10 Mobile), Chrome (including Android), and upcoming Safari 10(https://developer.apple.com/library/prerelease/content/releasenotes/General/WhatsNewInSafari/Articles/Safari_10_0.html).
Also IDN2008 support, and number control by <input type="number"> require ICU. And, although gfx has own unicode table, we want to remove this if ICU is supported on all platform.
Also, new L20N framework (aka L20N) wants to use Intl API to localize UI.
So I would like to use ICU as default on Fennec Android.
Negative issue is file size. ICU has big table, file size of libxul.so will be following. This support requires additional 4.4MB.
before this ... 26287379 bytes
after this ... 30692696 bytes
Although android OS already has ICU, ICU version is different per OS version. And our ICU requirement is 50.1+ (Android 4.0 uses ICU 48) and exported fucntion name of ICU has ICU version suffix. So we cannot use it.
MozReview-Commit-ID: 5R5iNMzWNjS
--HG--
extra : rebase_source : fceb3ee320f885e7c03749f76cf0ad7699a21c2c
The constexpr warning no longer appears in VS2015 headers.
I spot-checked a few other warnings in the list, and we still need to keep them.
Notably, we still need -Wno-ignored-attributes, but now for a different reason!
MozReview-Commit-ID: LMqJX1KlAra
--HG--
extra : rebase_source : c1ad696f19975a1252a9bf2b01771530183c6c14
Mike Hommey
Nick Alexander
Jan Beich
Ralph Giles
Tom Ritter
Alex Gaynor
Iris Hsiao
Ryan VanderMeulen
Andrzej Hunt
Dão Gottwald
Makoto Kato
Kai Engert
Glenn Randers-Pehrson
Jeff Muizelaar
Carsten "Tomcat" Book
Franziskus Kiefer
David Anderson
Chris Manchester
Sebastian Hengst
Gian-Carlo Pascutto
Jeff Gilbert
Phil Ringnalda
Ted Mielczarek
Mike Shal
Ted Campbell
David Major
Masatoshi Kimura
Wes Kocher