This patch introduces a small change in behavior: we now unconditionally
require libffi > 3.0.9 when using system ffi, rather than accepting 3.0.9
when using GCC, as 3.0.10 was released 5 years ago, and should be widely
available.
MozReview-Commit-ID: DtSDPoZSPcx
It was setting ATTRIBUTE_ALIGNED_MAX which hasn't been used for 6 years
since 590a7be0e60f (bug 556455) removed its only consumer.
MozReview-Commit-ID: HSAql5cUrQH
--HG--
extra : rebase_source : 34193d16b6073c5ad13eb4787b876fc3a9266c2b
Skipping them saves 1.5-2.0s from configure during an artifact build
on Windows.
MozReview-Commit-ID: ArCvrFP9UsD
--HG--
extra : rebase_source : fa580b69d1d96dc0631b626512273302647126f7
Currently, the build scripts enable AltiVec unconditionally on all ppc*
targets. However, there some ppc* targets which do not support AltiVec
instruction set extensions, these are often embedded systems like the
PowerPC e500 or similar which have their own type of instruction set
extensions like SPE. Trying to enable Altivec support on these targets
results in a compiler error, hence we need to add an autoconf test for
AltiVec support before trying to enable it on ppc* targets.
Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
--HG--
extra : rebase_source : 6c4df813d97d95046fd2269c876313ce7591c5cf
Subtly, as toolkit/moz.configure happens before toolchain tests, we
can't set MOZ_SERVO_LIBS from there. And toolkit/moz.configure is
not always included either, making things awkward to do in python
configure.
OTOH, there's only one place where MOZ_SERVO_LIBS is used, and the
corresponding setup can actually be done there (in moz.build) instead.
I think we shouldn't shy away from moving things this way.
This patch introduces a small change in behavior: we now unconditionally
require libffi > 3.0.9 when using system ffi, rather than accepting 3.0.9
when using GCC, as 3.0.10 was released 5 years ago, and should be widely
available.
MozReview-Commit-ID: DtSDPoZSPcx
Also, now that we're using modern C++11 compilers, we can just rely on
static_assert, instead of the pile of macros used in the autoconf test.
--HG--
extra : rebase_source : 85d507da653d07e6527a971082277486e3502ea2
Now that we compile with cargo, we don't have fine-grained control over
the build flags used via environment variables detected in configure or
set in config.mk. We should just remove that dead code so nobody trips
over it.
Functions deprecated in GTK3 are often used for compatibility with GTK2
builds.
MozReview-Commit-ID: F220phw3wVO
--HG--
extra : rebase_source : 128e885652b184c5a7916378d9cebb067ab97eb0
The only use of this variable is to override NSINSTALL, and its value is
the same as NSINSTALL_PY.
While here, remove the outdated NSINSTALL_NATIVECMD that was used for
pymake.
--HG--
extra : rebase_source : b871fbb409836a17cb8d71cd1e5ddc9d5ad3f49f
Nothing is using MAKE in old-configure, and it was not AC_SUBST'ed, so
we don't need to set it when it's not set in the environment already.
--HG--
extra : rebase_source : 9a525517808db87add72989ab9f43a135c0cc776
Since bug 1259382, CC and CXX are always set, so we can stop
falling back to cl on Windows, and clang on OSX in compiler-opts.m4.
Also, we were actively rejecting GCC on OSX because it was based on
GCC 4.2 and known to be broken, but that test predates our requirement
for more recent versions of GCC, which would fail configure anyways.
So just remove that GCC test. Building with a modern GCC from macports
or wherever might actually work anyways.
Finally, remove target bit-width mismatch with the compiler as it's
handled in python configure since bug 1288313.
--HG--
extra : rebase_source : 9968028cc4e9c197b72136037a7298be10cc139a
The base compiler check in python configure does some preprocessing,
which ensures the compiler works to some extent. Autoconf used to have
a more complete test, doing a compile/link. We do have plenty of tests
afterwards that do that anyways, but it's better if we fail early if
the toolchain fails somehow.
This refactors try_compile such that the *_compiler variable themselves
can be used to trigger compiler tests. Eventually, we'll want something
similar for preprocessing and possibly other invocations.
This also removes similar tests from build/autoconf/toolchain.m4 and
old-configure.in.
--HG--
extra : rebase_source : 4f6f84e5ad220386e9edf82d19cc2cd6c1f4c43e
Python configure "environment variables" can be passed as actual
environment variables, but can also be passed as command line arguments
(unless they also make it to old-configure, which doesn't support that).
Passing empty environment variables is broken in msys2/cygwin: the
subprocess doesn't see the environment variable being set, so it can't
tell the difference between "not set" and "set to nothing", which has a
different meaning for python configure environment variables.
Currently, JS_STANDALONE is passed this way. Passing it as a command
line argument makes it properly passed down to the subconfigure.
--HG--
extra : rebase_source : d4ebaf9d626902166c3861ee9d6141255658194f
Its value was only used in a couple C++ files, and a corresponding value
can be gotten directly from including winsdkver.h.
--HG--
extra : rebase_source : 618f1eb2ee0243a6c1c652ccce45b2aeba959edf
The best kind of patch: bulk deletion. This removes two separate but
similar build flags, and an unsupported integration piece. The first
packaged Fennec's resources into an ill-defined GeckoView archive; the
second built on the first to produce an Android ARchive for external
consumption. Neither of these artifacts are supported or have
consumers; in fact, they mislead potential consumers, since they're
known to be broken. The Gradle build work under the --with-gradle
flag, and significant follow-up, is the path forward if Mozilla wants
to invest in packaging GeckoView on Android for external consumption.
That is, rather than hacking together AAR files, we'll use the
well-supported Gradle mechanisms for building and publishing such
libraries.
MozReview-Commit-ID: 4Z1jJ8z0cyJ
--HG--
extra : rebase_source : b8e65f39c286313fe8963bf3832d9b6977ef188f
Configure uses the value of the MT environment variable before falling back
to mt(.exe), but the build system was completely ignoring the MT
environment variable.
--HG--
extra : rebase_source : 8c9b43aeb08493ae5bd6d6361f4f18f097ea0553
This patch removes the checks for compat.h, sys/bittypes.h, gnu/libc-version.h,
X11/XKBlib.h, sys/sysmacros.h, and sys/cdefs.h from old-configure, because they
are not checked meaningfully in the tree.
The check for memory.h is removed, because while there are checks for
HAVE_MEMORY_H in the tree, they are in places this is set by a third party
build system.
The check for io.h is also removed, because while there are checks for
HAVE_IO_H, they're only relevant on windows, where this is set manually in
old-configure.
MozReview-Commit-ID: MOI50CP00k
This is what we want on msys2 installations, since it is compliant and
installable with the package manager.
MozReview-Commit-ID: ARMcpJmbk2
***
Bug 1100925 - Have JS subconfigure recognize mingw32-make as a valid GMAKE. r?gps
MozReview-Commit-ID: Gg8FcgW7BHM
--HG--
extra : rebase_source : 5bd779812e52b8ce29ca078b41e2c12e1950de09
Because bug 1282866 removed Qt support but missed a bunch of things.
* * *
Bug 1285554 - more
--HG--
extra : rebase_source : c48d2485f1fdf1c961e08d91651bbca41e3a1a53
Android and b2g have duplicated linker flags and libraries. This patch
removes the duplicates from b2g scripts. The library 'log' is now listed
in the correct variable 'LIBS'.
MozReview-Commit-ID: EtVzZpoXkdK
Not all Android releases come with their own platform release. This patch adds
a switch statement to MOZ_ANDROID_NDK to use the previous platform release in
this case.
For several tests, the autoconf script 'old-configure.in' uses an internal
variable 'ANDROID_VERSION'. The stored value comes from the environment
variable 'PLATFORM_SDK_VERSION'. This patch replaces 'ANDROID_VERSION' by
'android_version', which is defined by MOZ_ANDROID_NDK from a command-line
parameter.
MozReview-Commit-ID: EbDgZX2aJgJ
Necko's build scripts already handle include search paths for mDNS
libraries on b2g. This patch removes similar code from the configure
script.
MozReview-Commit-ID: DXMeZmi4weK
Bluetooth availability depends on available driver; not the base system's
version. This patch separates both. Following other modules, it also moves
search-path setup for BT header files into the affected moz.build scripts.
MozReview-Commit-ID: 2hzjcJVTaLY
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
-Zc:inliune introduces VS2013 update 2 to reduce build time.
https://blogs.msdn.microsoft.com/vcblog/2014/11/12/speeding-up-the-incremental-developer-build-scenario/
On my workstation (i7-3770, 4 cores 8 threads), the build time by clean build (--enable-optimize and --disable-debug) is the following.
With -Zc:inline ... 39m44s
Without -Zc:inlune ... 43m52s
So we should use this option to improve build time.
MozReview-Commit-ID: GHUdgXBBYei
--HG--
extra : rebase_source : 7972e50b188681a09e087a00f023fe5202271ba2
extra : histedit_source : 16f33b48e688ca6f275d8105438abd2b450b4aa7
Setting MOZ_DEBUG_SYMBOLS as a define was not moved, as this value is not
checked, and exporting MOZ_DEBUG_SYMBOLS was not moved, as this would only
impact nspr, and we're no longer using the nspr build system.
MozReview-Commit-ID: EvBTunhxcsr
This patch adds support for configuring Gonk/B2G with Android-specific
build scripts. This removes duplicated code and simplifies maintenance
of B2G.
The B2G builds will now use libc++ for Gecko; instead of the obsolete
STLport. A side-effect of this patch is the removal of any compile-time
dependency on B2G's bionic library.
MozReview-Commit-ID: 7V6BmC7jlrs
This patch adds support for configuring Gonk/B2G with Android-specific
build scripts. This removes duplicated code and simplifies maintenance
of B2G.
The B2G builds will now use libc++ for Gecko; instead of the obsolete
STLport. A side-effect of this patch is the removal of any compile-time
dependency on B2G's bionic library.
MozReview-Commit-ID: 7V6BmC7jlrs
netapi32's API isn't used at startup and browsing page. So netapi32 should move to delay load DLLs.
MozReview-Commit-ID: 1g25lnuwbfY
--HG--
extra : rebase_source : 7893ff80d10d3f0fd25aabe5c5fbaebe167e89fe
When target is Android, -mandroid is default parameter from gcc 4.6 So we don't need add this options.
Also clang doesn't support this argument.
MozReview-Commit-ID: AuA3Y9vlgWE
--HG--
extra : rebase_source : c1866f56f131e666cc321d21fda1317532d46101
By bug 1270621, ETW support is removed. So no one uses messege compiler.
MozReview-Commit-ID: HGUAkrb208N
--HG--
extra : rebase_source : 5178283b781e4805b4e97f09b35a4150119d060a
extra : histedit_source : 40d6992894315b51863db4e7697df1c1ef18edd8
This does a few things. First, it makes non-official builds use the
Adjust sandbox. Second, I observe that the fake sandbox key no longer
sends anything, so it's no longer valuable; this patch instead
requires an Adjust token if install tracking is enabled, since we
can't provide a default any more. Third, it removes a spurious
default in configure.in; without this default, builders can easily
enable Adjust locally using the following in their mozconfig:
ac_add_options --with-adjust-sdk-keyfile=/path/to/adjust-sdk.keyfile
export MOZ_INSTALL_TRACKING=1
With the default, the "export" had no impact, because it was
overwritten immediately.
MozReview-Commit-ID: Cn62fmrgwJL
--HG--
extra : rebase_source : 3b817c815043e0339e65125f6d6963ddd3f4570e
Now that we're no longer supporting x86 cpus without SSE2
instructions, we can relax this restriction added in
bug 1252041.
MozReview-Commit-ID: 3Is0M3Em4Wx
We've decided supporting the small number of x86 machines
without SSE2 instructions is no longer worth the cost in
developer time nor the performance impact for other users.
https://groups.google.com/d/msg/mozilla.dev.platform/dZC39mj5V-s/Xt_UqZXkAAAJ
Set -arch:SSE2 by default on x86 if an arch hasn't already
been supplied. This ensures we'll continue to build with
the right instruction set if the compiler changes its default
in the future, while still allowing custom builds to set
a lower minimum.
Also updates the filter to strip all arch switches on win64
when building the sandbox. The 64-bit compiler doesn't
support -arch:SSE2 either.
MozReview-Commit-ID: JzTRGPn9vzI
Now that we're no longer supporting x86 cpus without SSE2
instructions, we can relax this restriction added in
bug 1252041.
MozReview-Commit-ID: 3Is0M3Em4Wx
CLOSED TREE
Backed out changeset d0ab0d508a24 (bug 1271829)
Backed out changeset 9f4983dfd881 (bug 1271829)
Backed out changeset 28b45df659b7 (bug 1271794)
We've decided supporting the small number of x86 machines
without SSE2 instructions is no longer worth the cost in
developer time nor the performance impact for other users.
https://groups.google.com/d/msg/mozilla.dev.platform/dZC39mj5V-s/Xt_UqZXkAAAJ
Set -arch:SSE2 by default on x86 if an arch hasn't already
been supplied. This ensures we'll continue to build with
the right instruction set if the compiler changes its default
in the future, while still allowing custom builds to set
a lower minimum.
Also updates the filter to strip all arch switches on win64
when building the sandbox. The 64-bit compiler doesn't
support -arch:SSE2 either.
MozReview-Commit-ID: JzTRGPn9vzI
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.
Glenn Randers-Pehrson
Ryan VanderMeulen
Phil Ringnalda
Astley Chen
Wes Kocher
Sebastian Hengst
Chris Manchester
Mike Hommey
Fernando Jimenez
Franziskus Kiefer
Andrew Comminos
Gregory Szorc
Gian-Carlo Pascutto
John Paul Adrian Glaubitz
Alexandre Lissy
Nathan Froyd
Karl Tomlinson
Carsten "Tomcat" Book
Frank-Rainer Grahl
Nathan Hakkakzadeh
Eugen Sawin
Nick Alexander
Jan Beich
Jed Davis
Bob Owen
Xidorn Quan
Steve Fink
Nicholas Nethercote
Thomas Zimmermann
Fabrice Desré
Benjamin Smedberg
Julian Hector
Ted Mielczarek
Tim Taubert
Makoto Kato
Kai Engert
Christoph Diehl
Ms2ger
Michelangelo De Simone
Sebastian Kaspari
Stephen A Pohl
Ralph Giles
Mike Shal
Jeff Muizelaar
Kim Moir
Gerald Squelart
George Wright
bechen
Kyle Huey
Chris Pearce
Nathan Froyd
Richard Newman