We were unconditionally adding them, now actually check what the
compilers default to and add the flags if they are necessary.
This will, in the future, allow finer grained policy changes, where
we can decide that C++11 and C++14 are fine, downgrading compilers
that do C++17, etc.
At the same time, allow to enable jemalloc 4 with --enable-jemalloc=4.
MOZ_JEMALLOC4 will be deprecated later.
This also changes the semantics for freebsd, where the system jemalloc
is used, relying on MOZ_MEMORY being unset (default on freebsd) and
MOZ_JEMALLOC4 to be set. In this new setup, MOZ_JEMALLOC4 implies
--enable-jemalloc=4, which still works because of the corresponding
changes to old-configure.
At the same time, we improve things slightly by deriving HOST_CC from CC
in a smarter way, as well as CXX from CC, which we weren't doing
previously.
Many related things are not moved at the same time to keep the patch
somehow "small".
C4595 is "'operator new': non-member operator new or delete functions may not be declared inline".
This warning is already suppressed for newer versions of clang.
MozReview-Commit-ID: GTzLtIGtpbR
--HG--
extra : rebase_source : 2782fff9796aedc976edf2c9820125f9b74c76e1
Also fixes bug 926980 - load ICU data from an archive file.
Stop invoking ICU's autoconf build system. Instead, have hand-authored
moz.build files under config/external/icu to build what we need. In addition,
we'll commit a pre-built copy of the ICU data file (currently icudt56l.dat)
under config/external/icu/data to avoid having to build ICU host tools to
generate it. config/external/icu/data also contains some assembly files
which can generate an object file containing the ICU data file contents
so that the JS shell (or standalone JS builds) can be linked directly to
the data without having to deal with the external data file. This requires
yasm or GNU as.
Various bits of packaging have been updated to account for the ICU data file.
XPCOM initialization now sets the ICU data directory so ICU can locate its
data file.
The update-icu.sh script has been modified to read the list of C/C++ source
files out of the ICU Makefiles and update `sources.mozbuild` files under
config/external/icu, as well as build a local copy of ICU using its
autoconf build system to generate the ICU data file to be committed in-tree.
MozReview-Commit-ID: 8Pfkzqt6S1W
--HG--
extra : rebase_source : 31426cddddb5543e0191059ba2f2eb069abe7727
- HW_THREADS doesn't appear to be doing anything.
- USE_ARM_KUSER is not used since bug 675078. This also removes the configure
flag that sets it.
- HAVE_SETBUF and HAVE_SNPRINTF are leftover from bug 944935.
- MOZ_MEMORY_GONK is leftover from bug 804303.
- DEVELOPER_OPTIONS, INTEL_CC, INTEL_CXX, MOZ_ENABLE_QTMOBILITY,
GTK_CONFIG are or even were never used outside configure.
- MOZ_PROFILELOCKING which gradually became a no-op over the years. This
also removes the configure flag that sets it.
- XULRUNNER_STUB_NAME is xulrunner-only, and xulrunner is gone. This
also removes the configure flag that sets it.
- The only use of MOZ_CAN_RUN_PROGRAMS was removed in bug 780561.
- AR_LIST and AR_DELETE have not been used since bug 584474.
- MOZ_COMPONENT_NSPR_LIBS is leftover from bug 1036894.
- MOZ_PNG_ARM_NEON_CHECK is not used since bug 980488.
- MOZ_WEBRTC_LEAKING_TESTS has been no-oped by bug 825510.
- VPX_NEED_OBJ_INT_EXTRACT and NO_INTEGRATED_AS_CFLAGS are not used since
bug 1151175.
- WCHAR_CFLAGS is not used since bug 904985.
In bug 1260996, we straightened things up for the host flags on cross
compile builds, where the situation was that they were effectively empty
by default, and that hasn't changed.
While working on bug 1260996, it has become clear that there is no much
point in setting the host flags from the target flags on non cross
compile builds, especially when the target flags come from the environment.
That creates a discrepancy with cross compilation builds for no real
reason, and there are effectively too few host things to build that it
would matter anyways. The flags that do matter are the ones for C++11,
C99, and optimisations, and they all are set independently of what is
being removed here.
Gonk, Android, and the generic cross-compilation setup all were using a
different yet similar way to prefix the toolchain. The latter was even
wrong, since the target and target alias usually don't match actual
toolchain prefixes (which don't include the machine part of the target).
Note that this removes force-setting cross_compiling to yes in
old-configure, which wasn't working because every AC_TRY_COMPILE
resets it with $ac_cv_prog_cc_cross or $ac_cv_prog_cxx_cross.
WebRTC code requires VP9E_SET_NOISE_SENSITIVITY from vpx/vp8cx.h
which was added in 1.4. We could feature test, but gating on
the minimum version seems better given the m4 code is to be
replaced by python.
We also depend on VPX_MAX_LAYERS wich is part of the 1.5.0 release.
This dependency was added with an SVC support patch in May 2015,
bug 1237023.
Optional --enable-spatial-svc is handled by the work-around
in bug 1248335.
MozReview-Commit-ID: 79kg9JSFtJM
Wv:18 was added in bug 1119072 as a quick way to get the tree building
with VS2015. Now that we're closer to rolling out VS2015 support, we
want to expose its new warnings.
This patch replaces the blanket disabling of new warnings in VS2015 with
just disabling C5026 and C5027, which relate to symbols being implicitly
defined as deleted.
MozReview-Commit-ID: 8uniydfNJns
--HG--
extra : rebase_source : 5ca239cd20216e89115d1faeffc036b6eecb85ca
This also adds a GRADLE_FLAGS environment variable for use in
automation.
Manually tested.
MozReview-Commit-ID: 8nDkqz2VnJn
--HG--
extra : rebase_source : 32626a7dc0c0a6a440e300d92c31670f14319325
extra : amend_source : fe134e25f079851b4c648b53a7a485ee20c15c18
subconfigure.py shortcuts js/src/configure to avoid a msys transition
breaking the environment. But js/src/configure passes an extra
--enable-project=js that subconfigure.py currently doesn't pass.
And because in some cases, MOZ_BUILD_APP is set in the environment
(notably, in OSX universal builds, through client.mk), we need to
unset it before calling the subconfigure.
old-configure and js/src/old-configure interestingly didn't handle both
the same way. But vtune support is only actually implemented in js/src,
so only the rules from js/src/old-configure matter (nothing was
enforcing the decistion from old-configure to js/src/old-configure), and
this is what is implemented here.
Its value is always 1, and never used. Even when there were different
possible values back before bug 627277 (5 years ago), it was not used.
In fact, it hasn't been used since bug 298044 (more than 10 years ago).
Its value is always 1, and never used. Even when there were different
possible values back before bug 627277 (5 years ago), it was not used.
In fact, it hasn't been used since bug 298044 (more than 10 years ago).
Bug 1038639 removed the option, but since autoconf doesn't barf for
unknown options, the option MOZ_ARG_WITH_STRING was kept to emit a
AC_MSG_ERROR. This is not necessary anymore.
Note the AC_DEFINE used to be in a COMPILE_ENVIRONMENT block, but the
define is actually used in Gecko preferences, so it's actually better
that the define is always set when MOZ_APPLEMEDIA is enabled.
Now that the MOZ_WIDGET_TOOLKIT test is in moz.configure, the value for
MOZ_WIDGET_TOOLKIT is now set in old-configure.in very early, which
now allows to check for its value before doing to Xt test instead of
resetting XT_LIBS later.
Chris Manchester
Mike Hommey
Ryan VanderMeulen
Mike Shal
Kim Moir
George Wright
bechen
Kyle Huey
Chris Pearce
Ted Mielczarek
Alexandre Lissy
Ralph Giles
Nathan Froyd
Gregory Szorc
Nick Alexander
Carsten "Tomcat" Book
Richard Newman