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, 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".
The check is for the clang plugin, which is a host library. It is especially
important to use the host compiler for this check on OSX-on-Linux cross builds.
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
- 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 1254861, we unsupported clang < 3.3, picking 3.3 essentially
because that's the smallest version we had on automation. Bug 1254854
changed that, and the smallest version on automation is now 3.5.
Now, the motivation to unsupport an old version of clang again is that
recent versions don't have the problem with __float128 used in libstdc++
headers (bug 654493). In fact, starting with clang 3.4, the hack we have
in place is not necessary.
So let's just drop support for clang 3.3 instead of keeping that hack
around longer.
As mentioned in bug 1254854, Ubuntu 12.04 LTS has clang 3.4 packages.
Update win32 builds to use a Repack of today's (2016 April 1)
rustc nightly for i686-pc-windows-msvc host and
i586-pc-windows-msvc target.
This should properly support machines without sse2 instructions.
The hack was supposed to avoid clobbers when landing bug 967556, which
might have worked somehow back then, but doesn't do anything useful
anymore. In fact, it now breaks the display of some results in
old-configure.
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.
Recent config.sub better handles all the broken android triplets (which
would have worked around bug 1257793), and added the -ios variant that
we've been relying on since bug 1257051, but that bug 1257648 broke by
using config.sub, which didn't support it)
The new config.guess interestingly now returns pc instead of unknown as
maching type on linux, which will, unfortunately, make objdir names
change when they are not manually set.
compiler-opts.m4's check for `MOZ_CXX_SUPPORTS_WARNING(-W, unreachable-code-return, ac_cxx_has_wunreachable_code_return)` is broken. The C/C++ code that configure emits for MOZ_CXX_SUPPORTS_WARNING() actually contains a -Wunreachable-code-return warning and, thus, doesn't actually detect that clang supports the -Wunreachable-code-return flag.
This configure code in MOZ_CXX_SUPPORTS_WARNING():
AC_TRY_COMPILE([],
[return(0);],
$3="yes",
$3="no")
generates something like:
int main() {
return(0);
; return 0; }
where the second return, automatically emitted by configure, is unreachable and causes a -Wunreachable-code-return warning.
The fix is to remove the redundant return(0) from MOZ_CXX_SUPPORTS_WARNING(). This allows clang's -Wunreachable-code-return flag to be detected, but then -Wunreachable-code-return breaks other configure checks, including third-party libraries' configure checks (in particular jemalloc) that also have redundant `return(0)`. So all the third-party libraries' configure checks would need to be fixed upstream, which seems like more hassle than the value of the -Wunreachable-code-return warnings.
Now that MOZ_BUILD_APP is set to js when building js/src, we can
distinguish those builds with MOZ_BUILD_APP==js instead of BUILDING_JS.
Consequently, remove BUILDING_JS.
Now that MOZ_BUILD_APP is set to js when building js/src, we can
distinguish those builds with MOZ_BUILD_APP==js instead of BUILDING_JS.
Consequently, remove BUILDING_JS.
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.
-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.
-Wsign-compare is enabled by gcc's -Wall (for C++ only), but not by clang's -Wall. -Wsign-compare is enabled for C and C++ by gcc's -Wextra and clang's -Wextra, which we don't use.
On a CLOSED TREE because this is Android only.
When we switched to fine-grained Google Play Services bundling (Bug
1115004), we stopped shipping com.google.android.gms.analytics. That
silently breaks Adjust, which queries the Google Ad ID using
reflection: now the package isn't present! This patch restores the
Play Services libraries that Adjust relies on. (Sadly, this bloats
our APK tremendously.)
There is some hijinkery, however: the Play Services libraries
reference a library (org.apache.http) that is deprecated in Android
23! However, the library is still present on Android 23 devices,
which buys Google time to replace the offending code. This compiles
just fine, breaks the Proguard global optimization pass. To give
Proguard the information, we add the library as a Proguard "library
JAR". This is equivalent to the Google-provided Gradle `useLibrary`
directive.
--HG--
extra : commitid : I4rTyC8lxLd
extra : rebase_source : 96f30d735e898cb9853d53f236ac8e2337186814
extra : amend_source : 3e4d68789b3ef980e4e1d7f743e332bdbb6be176
rustc, unlike our typical C++ compilers, can target multiple platforms
with ease through its use of the --target flag. To support
cross-compiling, we just need to pass the appropriate --target option.
rustc uses specific names for its accepted --target option, however, and
they are slightly different from the values we get out of autoconf. So
in addition to checking whether rustc can accept --target for our chosen
platform, we also need to munge autoconf's idea of the target into
something rustc understands.
When adding a backend, we currently have to add them in three different
places so that they appear in the right places.
Instead, keep the list in a single place.
The result of running this backend is a json file containing an array with 3 elements:
a map from resource:// and chrome:// url prefixes to corresponding objdir directories,
a map of overrides, and a map from objdir files to srcdir files (with a flag for whether
the file was preprocessed) for js file in FinalTargetFiles. A subsequent commit implements
the procedure to find an replace based on the url mapping, subsistute based on overrides,
and find sourcedir files based on objdir files.
--HG--
extra : commitid : Di6Ro5c9sTK
The leading 'v' was intended to distinguish the detected from
the literal version string, but this is non-obvious, and could
be confused with the git tag convention.
Instead, make the strings match, but put the detected version
first since it's what configure is likely to act on.
Rust 1.5 features fine-grained dependency tracking that we need for
proper incremental builds. As a side effect, it also features choosing
between the builtin-to-Rust jemalloc and the system allocator, which
Gecko needs for interoperation. (Gecko needs to make Rust use the
system allocator, which then gets redirected into Gecko's copy of
jemalloc if necessary.) It's not great to require an unstable Rust
target here, but we need to upgrade at some point anyway, so we might as
well make people aware of the upgrade requirement sooner rather than
later.
Rust 1.5 features fine-grained dependency tracking that we need for
proper incremental builds. As a side effect, it also features choosing
between the builtin-to-Rust jemalloc and the system allocator, which
Gecko needs for interoperation. (Gecko needs to make Rust use the
system allocator, which then gets redirected into Gecko's copy of
jemalloc if necessary.) It's not great to require an unstable Rust
target here, but we need to upgrade at some point anyway, so we might as
well make people aware of the upgrade requirement sooner rather than
later.
Since MOZ_NATIVE_DEVICES builds against play-services-{basement,base,cast},
some ad-hoc de-duplication is necessary.
--HG--
extra : commitid : 2jNIgZpLUq2
extra : source : 0957d3435ac22765d7868cb3c7db1e0787836bc3
The configure option has explicitly thrown an error for more than a year now,
and it happens that the remaining way to still forcefully use it has been
broken for more than 8 months.
This patch also adds the new base (sic) library play-services-basement.
Note that the package names have changed too:
* play-services-base: com.google.gms -> com.google.gms.base
* play-services-basement: * -> com.google.gms
--HG--
extra : commitid : EcmxZA10rzV
extra : rebase_source : f39b361807a0b8227f3fb9a6d73e066241c8e36c
The flags added in toolkit/locales/Makefile.in turn out not to be actually
used, so just remove that.
The remaining uses of XULPPFLAGS are to set debug flags depending on whether
MOZ_DEBUG is set or not. Just set a dedicated variable with the right value
from configure.
The order in which backends appear is important, and dealing with deduplication
in configure.in is not really nice, so for all simplification purposes, this relies
on using AC_SUBST_SET, which does the deduplication and keeps the original order
in which items appear (despite its name).
While the name AC_SUBST_SET suggests the underlying type would be a set, it does
not actually matter that much in moz.build, and is not used that much anyways.
Right now, --with-android-sdk expects a path to a specific Android SDK
version, like /path/to/platforms/android-22. That path is exposed as
ANDROID_SDK; the Android SDK root is exposed as ANDROID_SDK_ROOT.
Right now, the provided platform's version number is extracted into
ANDROID_TARGET_SDK. The extracted ANDROID_TARGET_SDK is checked
against a minimum version number (supplied as a parameter to
MOZ_ANDROID_SDK).
After this patch, --with-android-sdk expects what is now
ANDROID_SDK_ROOT, and then derives ANDROID_SDK from that path and a
pinned SDK platform version number. The exact version number which we
search for is now a parameter given to MOZ_ANDROID_SDK. We accept and
fail, with a helpful message, if we recognize an old-style ANDROID_SDK
path.
The existing MOZ_ANDROID_{MIN,MAX}_SDK_VERSION variables remain as
they are.
Right now, the Android build tools are searched in a deterministic but
non-obvious manner. After this patch, the exact build tools version
number is now a parameter given to MOZ_ANDROID_SDK.
--HG--
extra : commitid : 7z4T3EYH8fg
extra : rebase_source : 118a2a163d0deb1896e4959f12e9fbb132732bd8
extra : histedit_source : f18feda343e3c8e9f0dbb65eb7127262690e3cad
This stops exposing ANDROID_BUILD_TOOLS and ANDROID_PLATFORM_TOOLS via
AC_SUBST. We expose most tools already, and this adds EMULATOR, and
consumes it (and ADB) where appropriate.
--HG--
extra : commitid : 9u0pibgE00
extra : rebase_source : 04e420c53d1d75ab8f055436d7dd69e148168c67
extra : histedit_source : a930a34f4dda44ee91b52caf68e02877b0502f01
This merely groups the AAR searches in the configure output, which
reads a little easier.
--HG--
extra : commitid : 8yoM0J2NNOq
extra : rebase_source : 989bf064ca0f2d4e0126726dad7529a218e11e62
extra : histedit_source : f8c211e64741b4558b185bfbf5523b67cc428232
This gets us a limited version of AAR support: we can consume static
AAR libraries, where here static does not refer to linking, but to
static assets that are fixed at build-backend time and not modified
(or produced) during the build. This lets us pin our dependencies
(and move to Google's versioned Maven repository packages, away from
Google's unversioned ad-hoc packages).
By restricting to static AAR libraries, we avoid having to handle
truly complicated dependency trees, as changing parts of generated AAR
files require delicate rebuilding of the APKs (and internal libraries)
that depend on the AAR files.
It is possible that we will generate AARs in the tree at some time.
Right now, we don't do that, even for GeckoView: the AARs produced are
assembled as artifacts at package time and are intended for external
consumption. We might want this for GeckoView and Fennec at some
time; we should consider using Gradle everywhere at that point.
The patch itself does the simplest possible thing (which has precedent
from Gradle and other build systems): it simply "explodes" the AAR
into the object directory and uses existing mechanisms to refer to the
exploded pieces.
AARs have both required and optional components. Each component is
defined with an expected and required flag. If a component is expected
and not present, or not expected and is present, an error is raised.
If the component is expected and present, autoconf's ifelse() macro is
used to define the relevant AAR_* component variables. If the
component is not expected and not present, no action is taken. A
consuming build backend therefore can guard all AAR_* component
variables with just the top-level AAR variable.
Many AAR files have empty assets/ directories. This patch doesn't
explode empty assets/ directories, protecting against trivial changes
to AAR files that don't impact the build.
There's a lot not to like in this approach, including:
* We need to manually reference internal AAR libs;
* I haven't separated the pinned version numbers out of configure.in.
However, it's closer to what we want than what we have!
--HG--
extra : commitid : 11kUhDAkCn5
extra : rebase_source : 2454c9842ab3296d53ca5fa394a5a962aa382c8d
extra : histedit_source : e2f97502d215016925e93500b8fd93f8b32fba3a
The PR was fixed in early 2011. clang 3.3, the oldest version of clang
that we build with, was released in mid-2013. It's safe to say that all
versions of clang now have this fix, and we can delete the check.
Trying to decipher MOZ_SUBCONFIGURE_ICU given its lack of indentation is
difficult at best. It looks like some lines have tabs, and those tabs
make everything line up right...convert everything to spaces to make
sure things line up correctly.
We require ndk-r8e, so we don't need to support paths for all the other
NDKs prior to that now. Also took the opportunity to clean the paths up
so things fit on a reasonable screen.
The duplication of the code higher up is a little bit annoying, but I
don't see an easy way to avoid that. It's also still quite far from
duplicating everything.
I tested locally with a Fennec build that if I bump the requirement from
4.6 to 4.9, I get the expected build error.
I tested locally that both checks give the expected error if I
temporarily change the != to an =.
--HG--
extra : transplant_source : %01N%B9%8B%BC%1E%07%D6%AE%BA2%7B%87%FB%25Y%19%B6%A9%D3
The duplication of the code higher up is a little bit annoying, but I
don't see an easy way to avoid that. It's also still quite far from
duplicating everything.
I tested locally with a Fennec build that if I bump the requirement from
4.6 to 4.9, I get the expected build error.
--HG--
extra : transplant_source : D%D3%FE%169%05%D0X%F3KK%17%9EW%88%BCs%9B%86%5D
It looks like overwriting AS here is not intentional. Before this patch,
it is impossible to override AS through mozconfig for anything that runs
past this stage in configure.
Some Android SDK installations do not have the zipalign program in
the same directory as other Android build tools. For example,
zipalign may be found in /build-tools/21.1.2 whereas the
rest of the build tools are in /build-tools/android-4.4.
Right now, if the LLVMCONFIG variable is not set in the .mozconfig, we
first look for the system default llvm-config and only then we ask clang
itself, which breaks building with the clang plugin if you make $CC and
$CXX point to a non-default clang binary. This patch fixes the issue
by reversing the search order.
--HG--
extra : rebase_source : 23ab716f4e220097e4c31092475dba769f4e7dfc
In certain configurations, in particular when installing the Android SDK
using HomeBrew, one sees a configuration with symlinks like:
[brian@brian-macbook git]$ ls -l /usr/local/Cellar/android-sdk/23.0.2/
total 72
...
lrwxr-xr-x 1 brian admin 38 Nov 14 16:39 platforms -> ../../../var/lib/android-sdk/platforms
...
drwxr-xr-x 26 brian admin 884 Nov 14 17:43 tools
In this case, we have
ANDROID_SDK=/usr/local/Cellar/android-sdk/23.0.2/platforms/android-21.
It is an anti-pattern to use ANDORID_SDK/.. to find other paths in the
tree. This pattern is used in at least two places:
1) When we try to find
/usr/local/Cellar/android-sdk/23.0.2/platforms/android-21/../../tools,
we end up in the /usr/local/var/lib subtree. This patch works around
that by exporting and using ANDROID_TOOLS; ANDROID_TOOLS itself is
extracted using path matching, rather than following .. through the
filesystem.
2) We also need to use ANDROID_SDK_ROOT rather than
ANDROID_SDK/../.. through-out.
--HG--
extra : rebase_source : 5e0323a94f2b80550f17a624e16f338cdeec406d
On automation, this brings Windows configure time on a clobber from 5:30 to 3:10.
Sadly, because make needs to run under intl/icu/host before configuring
intl/icu/target, intl/icu/host needs to be configured independently. Fortunately,
that's not configured for normal windows builds anyways.
Also, having multiple subconfigures sharing the same cache file is dangerously
racy. Fortunately, not a lot do. In fact, only js/src and $_subconfigure_subdir
do, so force the latter (only used for ldap sdk on comm-central) not to
configure in parallel.
This saves dexing and shipping the Google Play Services and other Google
libraries, which add resources and about 3megs of code.
Due to ordering issues, the relevant flags and toggles were moved to
configure.in and exposed early enough to be used by confvars.sh.
While bug 903369 added some kind of wrapping, msys mangling on Windows made
it hard to make the python wrapper invoke subconfigures itself. This change
overcomes this, allowing to run subconfigures entirely independently of
the main configure if necessary, or to do more fancy checks without having
to resort to m4 and shell.
All subconfigures are essentially doing it already, so just inverse the process. That would also limit problems with additional subconfigures (all the recent ones had to come with their own config.cache)
This adds a format option to mach environment and uses it in client.mk to
create a .mozconfig.json in the objdir, containing all the relevant data
from mozconfig. If the mozconfig doesn't change in a way that alters that
data, we still skip configure.
At the same time, use mach environment in place of mozconfig2configure and
mozconfig2client-mk, which makes us now have only one mozconfig reader.
Also, in the mozconfig reader, keep track of environment variables (as
opposed to shell variables), so that changes such as a variable that was
exported not being exported anymore is spotted. At the opposite, in order
for irrelevant environment variable changes not to incur in re-running
configure, only a set of environment variables are stored when they are
unmodified. Otherwise, changes such as using a different terminal window,
or even rebooting, would trigger reconfigures.
Finally, make mach environment emit both MOZ_OBJDIR and OBJDIR for
client.mk, and cleanup some objdir-related things in client.mk..
At the same time, make the mozconfig reader take MOZ_OBJDIR from the
environment if it is defined there and not in the mozconfig.
CLOSED TREE (but for the commit above this because the commit hook only
appears to look at the tip commit)
--HG--
extra : rebase_source : c88e7e3f4d24dcd59a1a0b5577e3a77da68f3d08
extra : amend_source : 5be936181048b01850e9ef91c25fa0c7363d118d
This patch does two things: 1. Treat clang on Windows explicitly as MSVC. There
are some places in our build system where we try to detect clang by looking at
the output of $(CC) -v, and that will cause us to believe that we are using
clang, which is not helpful. This patch defines the CLANG_CL variable when it
detects clang being used on Windows. It also masquarades clang-cl as MSVC
2012, which is how the compiler introduces itself through the _MSC_VER
predefined variable.
2. Disable a bunch of things which currently are not supported on clang-cl. As
we proceed with this port, hopefully we'll be able to remove everything in this
list, but this will get us closer to be able to build with clang-cl.
With this patch and clang-cl trunk, we can get past the configure stage of the
build.
--HG--
extra : rebase_source : e5b8d77e4571c936820cec858953d58b6f31e0d5
This lists the directories in build-tools/*, sorts them by
version (favouring new-style 'android-*' directories), and then takes
the newest version in which aapt exists.
Ryan VanderMeulen
Andrzej Hunt
Sebastian Hengst
Chris Manchester
Nathan Froyd
Ralph Giles
Ted Mielczarek
Mike Hommey
Jan Beich
Eric Rahm
Wes Kocher
Chris Peterson
Ehsan Akhgari
Joshua Cranmer
Michael Comella
Nathan Froyd
Carsten "Tomcat" Book
Benoit Girard
Landry Breuil
Sotaro Ikeda
Nick Alexander
Simon Montagu
Sebastian Kaspari
Fabrice Desré
Terrence Cole
Samael Wang
Ted Clancy
Jacek Caban
James Willcox
Juan Gomez
ISHIKAWA, Chiaki
Makoto Kato
ijdt.editor@gmail.com
Hector Zhao
L. David Baron
Bob Owen
Akos Kiss
Abhishek Bhattacharya
Trevor Saunders
Ms2ger
Jed Davis
Georg Koppen
Tooru Fujisawa
Ian Neal
Ed Morley
Jim Chen
Christian Holler
Richard Newman
Nathan Toone
Jan de Mooij
Steve Fink
Tim Taubert
Brian R. Bondy
Birunthan Mohanathas
Wes Johnston
Henri Sivonen
Brad Lassey
Andrew McCreight
Ulrich Weigand
Phil Ringnalda