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.
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.
It's an opt-in flag that allows to display where the build is in
terminal window titles. The fact that it's opt-in and likely unknown
makes it very low-value, and the fact that it was added in an era where
builds were not very well parallelized made it have a meaning, but now
that builds are parallelized, its meaningfulness is diminished.
Let's just remove it.
With all the things that still depend on all the variables derived from
--host and --target in both old-configure and moz.build, we still need
to keep variables such as OS_ARCH, OS_TARGET, CPU_ARCH, OS_TEST, etc.
Eventually, we'd settle on the output of split_triplet.
This /tries/ to preserve the current values for all these variables,
while also trying to make things a little more consistent. It also
effectively rejects OSes such as HPUX or AIX, because it is unclear
the decades old accumulated scripts related to them still do anything
useful, and we might as well have them start again from scratch, which,
in the coming weeks, will be even easier.
Because --enable-application is the current way to do things, transpose
it to configure.py, but since --enable-application=js doesn't make
sense, make it an alias of a new --enable-project option.
This only partially moves --enable-application out of old-configure.in
because there are a lot of other things intertwined with it.
This moves all the reading mozconfig, finding autoconf, refreshing the
old configure, and running the old configure into sandboxed
moz.configure. This effectively bootstraps the sandboxed python configure.
The nice side effect is that now we can have actual dicts for defines
and substs from the start, which simplifies so things, although it
requires adjustments to some unit tests.
Non-Mozilla distributors may wish to run their own autopush endpoint,
using a sender ID and corresponding Google API key that they control.
This simplifies that just a little bit, and gets Mozilla's release
engineering out of the business of managing non-sensitive secrets.
In the future, this sender ID will be baked into the Android APK's
string resources, in accordance with newer Google Play Services
library requirements.
MozReview-Commit-ID: AAxreEP73B0
--HG--
extra : rebase_source : 0a35d18a83558e4d27ac6a47b3833f1d69fed264
By default llvm (and rustc) generate sse2 instructions on x84, but
we have users on old cpus without this extension, causing crashes
in the rust code. Pass a flag when building for win32 to prevent this.
Export and AC_SUBST RUSTFLAGS so it's available in the build.
This apparently wasn't hooked up before.
At the same time, remove the (useless and wrong) check for AUTOCONF in
old-configure.in (wrong because it very likely is picking autoconf > 2.5).
--HG--
extra : rebase_source : 4a17c9d92c9561ef221b1a300e0e6d48ca56862f
-Wno-psabi has not been necessary since we updated the build machines to Android NDK r8c three years ago in bug 826133.
-Wsometimes-initialized is not necessary because it is implicitly enabled by clang's -Wuninitialized, which is enable by -Wall.
-Wcast-align is very noisy and we apparently only enable it for gcc on 32-bit x86 builds?
-Wno-unused-local-typedef is no longer necessary. This is the clang flag; gcc's flag is -Wno-unused-local-typedefs, with an 's'. Suppressing gcc's warning was recently deemed unnecessary and WONTFIX'd in bug 1243604. Unsurprisingly, we no longer need it on clang either.
-Wrange-loop-analysis is no longer necessary because it is implicitly enabled by -Wloop-analysis, which is enabled by the previous commit.