rustup installs rustc+cargo to ~/.cargo/bin by default, so make configure look
there to avoid the annoying case where someone installed rust and cargo
(possibly via `mach bootstrap`) but forgot to add ~/.cargo/bin to their PATH.
MozReview-Commit-ID: GZOcFdFmzA5
--HG--
extra : rebase_source : 9dae473b5804f096992cae7f90df4c87bb4e5af4
extra : source : 9324e5e56038a1e548b0fc4d94d9df445734ff1e
The first step of making --enable-jemalloc the default everywhere is to
at least allow to build with it everywhere. Which currently probably
fails on a few platforms, but they're not going to be fixed if they're
explicitly rejected at configure time.
--HG--
extra : rebase_source : f29383e2d73986f3e5b033ac82c0d520bacd4fa6
Hopefully, the bug we worked around by disabling jemalloc on 32-bit OSX
is gone. We're not shipping 32-bit binaries for OSX anyways.
--HG--
extra : rebase_source : 148a80a7ab006d3be81fb931cbbb4ad2c81690c3
The first step of making --enable-jemalloc the default everywhere is to
at least allow to build with it everywhere. Which currently probably
fails on a few platforms, but they're not going to be fixed if they're
explicitly rejected at configure time.
--HG--
extra : rebase_source : 0905861d5a2cc62f5b37c5ee811e56e1e063a133
Hopefully, the bug we worked around by disabling jemalloc on 32-bit OSX
is gone. We're not shipping 32-bit binaries for OSX anyways.
--HG--
extra : rebase_source : bfe765977dedf1949da4d5919032cadfb4675f1f
-Wc++14-compat warns about code whose meaning differs between C++11 and C++14. We want the new C++14 meanings, so we don't need to warn about these differences. We still want -Wc++1z-compat because we want to know about C++14 code whose meaning will change in C++17 or C++20.
MozReview-Commit-ID: 1CD11l2Fd86
--HG--
extra : rebase_source : 7bac029fd3e852fbb92f07e0358307c2c834ddc8
extra : source : 2d49767b136e420d39b88267f611fbe72ed0a3b8
We currently turn off the C++14 sized-deallocation facility on MSVC, and
we'd like to ensure we do the same thing for clang and gcc. To do so,
we add new functionality to moz.configure for checking and adding
compilation flags, similar to the facility for checking and adding
warning flags. The newly added facility is then used to add
-fno-sized-deallocation to the compilation flags, when the option is
supported.
Once we do this, we can't define the sized deallocation functions in
mozalloc.h; the compiler will complain that we are using
-fno-sized-deallocation, yet defining these special functions that we'll
never use. These functions were added for MinGW, where we needed to
compile with C++14 ahead of other platforms to be compatible with MSVC
headers. But they're no longer necessary, though they would be if we
removed -fno-sized-deallocation; the compiler will complain if we do
that and we'll add them back at that point.
We have code to test whether particular flags are supported for the
compiler we're using. Unfortunately, that code is tied up with checking
for warning flags. We're about to add a separate facility for generic
compilation flags, and we'd like to avoid cutting and pasting code if
possible. Let's split the core code out into a separate, reusable function.
Our toolchain detection logic checks whether we can reuse the target
C (resp. C++) compiler for the host compiler. This is generally only
applicable in the not-cross-compiling case, but we had special logic to
check for clang in the cross-compiling case and accept it, as clang is
able to generate code for multiple architectures from a single compiler
binary.
Our recent switch to clang on Android has exposed a problem in this
logic: we would never check whether the target clang, compiling for the
host, could actually find the host's headers. This was especially
problematic on OS X hosts, where the host clang contains special logic
to grovel inside the XCode installation to find C++ headers. The clang
from the NDK, however, was ignorant of the XCode installation.
Therefore, the NDK clang would happily compile code for the host, even
including C headers for the host, but would be hopelessly lost when it
came to compiling C++ headers during the actual build.
In hopes of mitigating this, we now include a check for a representative
header for C and C++ when checking compilers for each of those
languages. This check will detect such problems as the above, and will
also alert people to potentially misconfigured compilers in other
situations.
We need to modify our test framework to cope with headers being
included, since our mock environment isn't actually equipped with a full
set of compilers and headers.
Now that extra_toolchain_flags includes stlport_cppflags, there's no
reason bindgen_cflags_defaults should depend on them both. So remove
the stlport_cppflags dependency. (There's no harm to multiply-including
stlport_cppflags, but not repeating -I options is good practice.)
extra_toolchain_flags is used for compiling target-specific bits of code
elsewhere in configure. Very shortly, we'll need to compile bits of
code that depend on the C++ standard library, so we'll want to point the
compiler at the C++ standard library. Making extra_toolchain_flags
include stlport_cppflags is the best way to do that.
extra_toolchain_flags is going to depend on stlport_cppflags
momentarily, so this commit is just for moving code around. Note that
the diff shows other things moving *after* stlport_cppflags.
We compute the same set of data in extra_toolchain_flags as we were
computing in bindgen_cflags_defaults. We might as well reuse the former
to compute the latter.
The current code will fail if "RUSTC_OPT_LEVEL=" is passed. This can happen
if the value isn't present and that fact is injected into js' configure. We
only want to respect RUSTC_OPT_LEVEL if a value is passed, so we simply check
for the presence of a value rather than its origin.
MozReview-Commit-ID: 6GhLfprJEEn
--HG--
extra : rebase_source : 40f3e381a128e04d65cc0175df32cdcd8302e05e
The changesets in bug 1412932 changed the semantics for MOZ_PGO.
Before, it was effectively being set as an environment variable
by client.mk all the time. Afterwards - specifically after
2013c8dd1824 - the variable is set in mozconfigs via ac_add_options,
which means it is only exposed to configure, not the environment.
Investigation by dmajor revealed that -WX (warnings as errors) was
added to a js/src file's compiler invocation after the PGO code
refactor. (PGO and warnings as errors have a strange interaction
- bug 437002 - and should be disabled there.) Strangely, addition
of -WX was only present on Dev Edition PGO builds.
The reason for this is likely mozharness. Mozharness will export
the MOZ_PGO=1 environment variable for build configurations that
it knows are PGO. It appears to do this for all PGO build
configurations except Dev Edition. Since make and moz.configure
inherit environment variables, mozharness was basically papering
over the intended behavior change in 2013c8dd1824.
This commit fixes the problem by marking MOZ_PGO as a JS option
in moz.configure. This means `ac_add_options MOZ_PGO=1` (the new
convention for enabling PGO) will set MOZ_PGO for SpiderMonkey's
moz.configure.
Of course, MOZ_PGO=1 in an environment variable still works. And
mozharness's setting of this variable has the intended effect.
Eventually, I'd like to clean up the mozharness code so it is less
PGO aware and enables PGO via ac_add_options. But that's for another
day.
MozReview-Commit-ID: 1KYPJARI6SJ
--HG--
extra : amend_source : 5291cead9f1c1af9ed2a1f608af770bc8e4958c5
This doesn't need to be in client.mk.
Also, we inline the info to help people correct the failure, as this
results in a better user experience.
MozReview-Commit-ID: KURL3RIGzKf
--HG--
extra : rebase_source : dc79d3f6aa4e91a12cab0e26d5fc0a3e15afa833
extra : source : 2eceb30625acd8cfadda0baa6326a7e9fd07dece
Checks like this are what configure is for.
In addition to moving the check, we also validate topobjdir as well.
MozReview-Commit-ID: 9sVNQJsAnjO
--HG--
extra : rebase_source : 688961fffca5922c7186c0d39182de7220f7dbe3
extra : source : d9a4ea9bc34a1e0c710469fc0a556ed624ea387b
