Android headers can have a <sys/quota.h> header but with its functions
ifdef'ed out. Check for that by checking for the presence of quotactl().
MozReview-Commit-ID: 26ILnbP7flO
--HG--
extra : rebase_source : fe78c114189a362cdad3d79ce67868b045328392
NDK headers are grouped into a "sysroot" directory, which doesn't
contain architecture-specific bits, and a "system" directory, which
contains only the architecture-specific bits. Previously, both
directories are the same, under platforms/android-*/arch-*/. However,
with unified headers in NDK r16, the two are different, so we need to
support that in the Android build scripts.
Unified headers also rely on the build system defining the
__ANDROID_API__ macro, so we add support for that as well.
MozReview-Commit-ID: 9zBNQC3BRFl
--HG--
extra : rebase_source : 9ded282343df64d9cc4abcf7d7c6b03ac3423ff0
Android headers can have a <sys/quota.h> header but with its functions
ifdef'ed out. Check for that by checking for the presence of quotactl().
MozReview-Commit-ID: 26ILnbP7flO
--HG--
extra : rebase_source : 147e4be9eb98326fd4946b7b3695c573c7108347
NDK headers are grouped into a "sysroot" directory, which doesn't
contain architecture-specific bits, and a "system" directory, which
contains only the architecture-specific bits. Previously, both
directories are the same, under platforms/android-*/arch-*/. However,
with unified headers in NDK r16, the two are different, so we need to
support that in the Android build scripts.
Unified headers also rely on the build system defining the
__ANDROID_API__ macro, so we add support for that as well.
MozReview-Commit-ID: 9zBNQC3BRFl
--HG--
extra : rebase_source : 36c9d4d5625fecbbe2485668811f85f9d94372d5
It's been more than two weeks since the 1.23 stable release, and
we're making official builds with that toolchain release, so begin
requiring that version so new language features can be used in
development.
MozReview-Commit-ID: E6WuP41ceTn
--HG--
extra : rebase_source : 75850dd9edbf8e3f9beab394e4af7fad76ce3b17
Will also address Bug 1377553 and part of Bug 1419607
MozReview-Commit-ID: AUCqBxEGpAl
--HG--
extra : rebase_source : 5547e2c8fbf4e2e87182b8720d8352c131e4ec65
We currently use a 32-bit Rust toolchain for win32 builds, but this can lead
to OOM situations. This patch makes win32 builds use a 64-bit Rust toolchain,
which requires a little bit of extra configuration because rustc needs to
be able to find a link.exe that produces 64-bit binaries for building
things like build scripts, which are host binaries.
We will now generate a batch file that sets LIB to the paths to 64-bit
libraries and invokes the x64-targeting link.exe, and add a section to the
.cargo/config file to instruct cargo to use that batch file as the linker
when producing 64-bit binaries.
MozReview-Commit-ID: 9vKBbm7Gvra
--HG--
extra : rebase_source : 273a99be71914167664482c2bdb26c840ec6867b
At the same time, we make it actually do something on spidermonkey
builds. We also add an environment variable alternative, that we use
in mozconfig.stdcxx, allowing for mozconfig.no-compile to override it
and avoid configure failures on e.g. artifact builds.
--HG--
extra : rebase_source : b68d362025e0c99f9184a03391c652ec2c9357ad
Bug 1325632 added some facility to add target compiler flags. This
change extends it to add allow adding host compiler flags as well.
--HG--
extra : rebase_source : 424b405a1d8f9a4778ff75c3308c9622f050e194
We currently use a 32-bit Rust toolchain for win32 builds, but this can lead
to OOM situations. This patch makes win32 builds use a 64-bit Rust toolchain,
which requires a little bit of extra configuration because rustc needs to
be able to find a link.exe that produces 64-bit binaries for building
things like build scripts, which are host binaries.
We will now generate a batch file that sets LIB to the paths to 64-bit
libraries and invokes the x64-targeting link.exe, and add a section to the
.cargo/config file to instruct cargo to use that batch file as the linker
when producing 64-bit binaries.
MozReview-Commit-ID: 9vKBbm7Gvra
--HG--
extra : rebase_source : 366dd966cafe4f07b8e59fc170d2db2dada32627
We need MOZ_UI_LOCALE even when building the JS shell so
config/config.mk variable assignments don't run into issues. But it
doesn't make any sense to configure a UI locale for the JS shell. So
make --enable-ui-locale a normal `option`, but give it a `default`,
which is the value shell-only builds will always see.
--HG--
extra : amend_source : 047759dd6ec446d9d6f8f5992ed9cf6628ce859e
This has the virtue of not executing python three times during configure
just to read the same value of milestone.txt and munge it. We can also
remove milestone.py as a happy side effect, so all the milestone
computations can be done in init.configure.
Bump the minimum required Rust version now that 1.22.1
has been in stable release for more than two weeks.
Version 1.22.0 works fine everywhere but macOS 10.13,
but 1.22.1 was released the same day, so it's no harder
to upgrade to.
Also update the base-toolchain builds to ensure we
continue to build with this version.
MozReview-Commit-ID: GlRWUNE07G0
--HG--
extra : rebase_source : f37585db5633e6e64b02bc94c2516b5ab18c3e15
Will also address Bug 1377553 and part of Bug 1419607
MozReview-Commit-ID: AUCqBxEGpAl
--HG--
extra : rebase_source : f7582d7089f0f4582a02aeaef090dc0701df994d
--enable-ion was only used by --enable-simulator and related options, so
there wasn't much point in making two separate commits.
This translation is a little more verbose than the original
old-configure code, but I think it is more readable and easier to
follow. We also don't port over --enable-simulator=no, as there doesn't
seem to be much point in doing so.
And statically link logalloc.
Statically linking is the default, except when building with
--enable-project=memory, allowing to use the generated libraries from
such builds with Firefox.
--HG--
extra : rebase_source : efe9edce8db6a6264703e0105c2192edc5ca8415
And statically link logalloc.
Statically linking is the default, except when building with
--enable-project=memory, allowing to use the generated libraries from
such builds with Firefox.
--HG--
extra : rebase_source : efe9edce8db6a6264703e0105c2192edc5ca8415
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
