We were adding c_compiler.flags and toolchain_flags to some paths
through this function, but not all. Not adding those flags caused this
function to detect the host's ld.gold instead of the target's ld.gold.
And that, in turn, caused linker errors when the host ld.gold couldn't
understand the target's object files.
MozReview-Commit-ID: vJzWagUGkL
This was mainly used to support Universal MacOS builds, which were
removed several months ago.
In theory, someone could be using this feature to build multiple
applications with one build system invocation. But given that client.mk
is no longer the preferred interface to the build system and multiple
applications can be built by running `mach build` with different
mozconfigs, I don't think support for this feature is worth keeping.
This commit removes support for MOZ_BUILD_PROJECTS and related
functionality from client.mk. Support for recognizing
MOZ_CURRENT_PROJECT in configure and mozconfig evaluation has also
been removed. This includes support for the ac_add_app_options
mozconfig function.
Good riddance.
MozReview-Commit-ID: 7xI2jYxDFFr
--HG--
extra : rebase_source : 91068f3b8ae32fbcda4defb5d4bb086a04387598
LineIO currently attempts to convert bytes to unicode using the
system preferred encoding. This can obviously fail for some byte
sequences.
In many cases, the conversion is happening for purposes of logging.
In these cases, Unicode validation shouldn't be that important to
us.
So, this commit teaches LineIO to accept an argument defining its
Unicode error mode. We also teach relevant users of LineIO doing
logging to switch the default mode from "strict" to "replace" so
invalid Unicode byte sequences can be logged with the Unicode
replacement character.
During review, glandium pointed out that it may make better sense
to defer Unicode decoding to the logging layer instead of in LineIO.
I agree with this idea. But it can be implemented in another bug:
for now we should unbust the build system.
MozReview-Commit-ID: 7miuSDY8Xzv
--HG--
extra : rebase_source : 40d5d97d908d00b410b49d03729a34568e5bfb1a
The NDK clang needs to be informed about the existence of a GCC
toolchain, so important programs like the linker can be located. With
this change, we're starting to use command-line options that are
incompatible with GCC, so we also add a check to inform the user about
the non-support for this configuration.
Our normal method of locating the compilers in the NDK is to set
--with-toolchain-prefix when compiling for Android. However, the clang
binaries are in a different location than would otherwise be implied by
--with-toolchain-prefix. Additionally, we still need to know about
--with-toolchain-prefix because the NDK clang needs to be pointed there
so clang can find important binaries like the linker and because various
other bits of the build system depend on the --with-toolchain-prefix
value as well.
So we need a separate mechanism for communicating the whereabouts of the
NDK clang. We can't set CC and CXX because doing so would conflict with
the CC and CXX values exported to the js/src/ subconfigure. But Android
already has an extra_toolchain_flags function that we use for informing
moz.configure about additional flags needed solely for Android, and we
can use a similar trick to communicate the existence of the NDK's clang
to the main C/C++ compiler selection process.
We subtly changed from "-C opt=value" to "-Copt=value" in 472232499478
(bug 1411081). This change appears to confuse sccache (which has its
own option parser).
This commit restores the old behavior of using separate arguments
for -C and its value.
MozReview-Commit-ID: JCnAjt1Tdsa
--HG--
extra : rebase_source : 2ad7aaf819c0c941efa2272c91d74ae7e52629e8
While we're here, provide a reference to unique_list as defined in
moz.configure when executing config.data to avoid its redefinition
in m4.
MozReview-Commit-ID: AI6XhoYR0Ye
As the data in the bug shows, the current default of opt-level=2 is
several minutes slower at compiling than opt-level=1. This slows down
builds significantly and the added benefits of running opt-level=2
for local development can't be justified for the common/default case.
This commit changes the default for local builds from opt-level=2 to
opt-level=1.
--enable-release (what we use for builds shipped to users) will imply
opt-level=2. --enable-optimize (the default) will use opt-level=1,
and --disable-optimize will use opt-level=0.
The RUSTC_OPT_LEVEL environment variable in mozconfigs can be used
to set an explicit opt-level level, regardless of what other
configure options are set. This includes the other potential values,
"s" and "z."
A side-effect of this change is that -Copt-level is now *always*
specified by the build system. Before, it was only specified if
the value was adjusted to 0 for --disable-optimize builds.
MozReview-Commit-ID: 67KX5qScnFc
--HG--
extra : rebase_source : dac0134e952151992eee23e017e9a29f84b05172
extra : intermediate-source : c3a7cc11a987aedb81332f1a03cd082ab0ab0cb8
extra : source : 360827b8a5956d58f7f0200431d3a44c57ce8dc4
Before this commit, RUSTFLAGS was derived in rules.mk by consulting
various variables set by configure. It isn't clear to me why things
are implemented this way. We don't appear to have moz.build level
overrides for Rust compiler flags. So there doesn't appear to be a
compelling reason why we can't derive these values in configure.
So, this commit ports the code for deriving default RUSTFLAGS from
rules.mk to toolchain.configure.
The port is pretty straightforward as far as the logic goes.
MozReview-Commit-ID: JhAE9Qlo8SK
--HG--
extra : rebase_source : 6186cb81cd37c516b3d645419b9461bf501d6ba2
The Rust optimization logic is tied to --enable-optimize/MOZ_OPTIMIZE
and --enable-debug/MOZ_DEBUG. In order to more easily implement more
customization, let's move --enable-optimize/MOZ_OPTIMIZE to
moz.configure so its value can be consulted there.
The logic here is a bit wonky. The option behaves like a boolean
or a string. If a string, MOZ_OPTIMIZE is set to 2. Otherwise it
is 1 or unset depending on the boolean value.
The custom compiler flags string is passed to old-configure, where it
overwrites whatever old-configure derived as the default value.
We stop short of moving all references to MOZ_OPTIMIZE_FLAGS to
moz.configure because there are a handful of them and I don't want
to scope bloat.
MozReview-Commit-ID: 6iNDu2HwLGr
--HG--
extra : rebase_source : a64f1236012d13913f21253df1b9b5ff0ae8ea6e
We mix the added and modified variables from mozconfig and sort them.
We also print comments indicating where values come from.
MozReview-Commit-ID: 97x9iHxZe3m
--HG--
extra : rebase_source : 367bc410bc06532a91b488039e3cb0ec65850c09
Per schedule, bump the minimum-supported rust version to 1.21.0
two weeks after its stable release so we can use new code which
depends on it.
MozReview-Commit-ID: Bn8UjvTC7uw
By the schedule we would have bumped the minimum-supported rust
version to 1.20.0 some weeks ago, just before Firefox 57 went to
beta. However, that was blocked on a couple of compatibility
issues with sccache and dsymutil. See bug 1396884.
Now that 1.20.0 is working in our automation builds, require
it for all builds to unblock servo and webrender upgrades.
Also update our integration test to verify building with
the new minimum.
MozReview-Commit-ID: 8otdix6f45f
--HG--
extra : rebase_source : 7d2550e8ddc772b45602bd488f174fc180e91484
Warn about duplicated conditions in if-else-if chains, which are unreachable code and likely copy/paste bugs. The -Wduplicated-cond flag is available in gcc 6 and later.
int example(int a)
{
if (a == 0)
a = 42;
else if (a == 0) // -Wduplicated-cond warning!
a = 43;
return a;
}
MozReview-Commit-ID: F9hqxMCct74
--HG--
extra : rebase_source : 71168f79ce8f03f650167cdedbbd2e5802846eab
Building Fennec/Android uses cross compiler toolchain. So we have to generate
clang options (include path for c++ headers and gcc headers, gcc-toolchain path and etc) from NDK path for bindgen.
The following options are required for android build.
(from stlport_cppflags)
-I$topsrcdir/android-ndk/sources/cxx-stl/llvm-libc++/libcxx/include
-I$topsrcdir/android-ndk/sources/android/support/include
-I$topsrcdir/android-ndk/sources/cxx-stl/llvm-libc++abi/libcxxabi/include"
(others for clang)
-isystem $topsrcdir/android-ndk/platforms/android-9/arch-arm/usr/include
-gcc-toolchain $topsrcdir/android-ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64
-I$topsrcdir/android-ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/lib/gcc/arm-linux-androideabi/4.9/include
-I$topsrcdir/android-ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/lib/gcc/arm-linux-androideabi/4.9/include-fixed"
Also, since bindgen_cflags_defaults uses as default, some funcions requires '--help'.
MozReview-Commit-ID: 7zfhw3IxQ2W
--HG--
extra : rebase_source : 0ede4f0d1ec212cfe411f6abe0f55f4b0c70643d
To build sytlo, we have to set compiler flags via BINDGEN_CFLAGS. Since we
pass stlport flags to clang, I would like to move STLPORT_CPPFLAGS to
moz.configure.
MozReview-Commit-ID: 26jvUqUvwTY
--HG--
extra : rebase_source : 5568627368fbf2dce02904918e50a241713d0a85
Because Rust tests require panic=unwind crates and therefore recompiling
all crates we normally use (since most of our crates use panic=abort),
we've elected to enable Rust tests only if the user asks for it. Hence,
this configure option.
The configure option also enables build-time execution of the crates,
since it's not straightforward to determine at configure time the name
of the test binary Cargo will produce (Cargo produces test binaries of
the form ${NAME}-${HEX_FINGERPRINT}, but there's no way to determine
what ${HEX_FINGERPRINT} is without actually compiling the test binary).
