Bump the minimum version of the rust toolchain we require to
build. The 1.15 release includes support for custom #[derive]
directives, letting us use the serde serialization crate without
checking in a lot of generated code.
This is primarily motivated by webrender and the audio remoting
work, and lets us drop the heavy syntex dependency.
MozReview-Commit-ID: 6IObHhouPAn
--HG--
extra : rebase_source : 4be8b148fb653a48f6df4309811ab1d8755f7edf
In bug 1296530, we made @depends take a when argument, it can now replace
all uses of @depends_when.
--HG--
extra : rebase_source : d090723fcbf3a56e06bd9c2defc3301cac04d8b0
Remove the option to build without rust code. We are not testing
this configuration and expect to land non-optional rust code in
the near future, so it doesn't make sense to maintain this option.
MozReview-Commit-ID: CwTlMXGvr5n
--HG--
extra : rebase_source : 080a9df5b4828c66aa2452ad1c16a503bcd5e689
We want to avoid giving --help dependencies to host and target, so that
they we don't spawn config.guess and config.sub when running configure
--help, and don't need to reach out to the which module to find a
suitable shell to execute them.
So, when --help is given, we return a fake host/target namespace, and
avoid the config.guess/config.sub-invoking code being executed.
Then, by giving the --help option to the linter, it can properly find
that the config.guess/config.sub-invoking code doesn't need the
dependency on --help.
This effectively unbreaks configure --help after bug 1313306.
--HG--
extra : rebase_source : 9ed4cbe5a81121b139d0d86aff6af542c2dff53b
It turns out that running makecab to compress PDB files takes a significant
amount of time in the buildsymbols step. I wrote an implementation of
makecab in Rust that implements only the subset of features we use and
it's significantly faster:
https://github.com/luser/rust-makecab
This patch adds a makecab check to moz.configure, adds a release build of
the makecab binary to the Windows tooltool manifests, points the build at
it from mozconfig.win-common, and changes symbolstore.py to use MAKECAB
from substs instead of calling `makecab.exe` directly.
MozReview-Commit-ID: 76FHLIZFCXS
--HG--
extra : rebase_source : af4cf2e4db4607ec9329b2811cc0175d3e113b66
Many people have been shooting themselves in the foot for too long by
including in-tree mozconfigs.
This change adds a guard that makes it an error when this happens on
builds not running on automation.
Analysis of the in-tree mozconfigs indicate that
build/mozconfig.automation is properly included by the in-tree
mozconfig that matter, directly or indirectly.
The only ones that don't include it are:
b2g/config/mozconfigs/common.override
b2g/graphene/config/mozconfigs/common.override
browser/config/mozconfigs/linux64/source
browser/config/mozconfigs/win64/common-win64
build/mozconfig.cache
build/mozconfig.clang-cl
build/mozconfig.common.override
build/mozconfig.rust
build/mozconfig.vs-common
build/mozconfig.win-common
build/unix/mozconfig.gtk
build/unix/mozconfig.stdcxx
build/win32/mozconfig.vs-latest
build/win32/mozconfig.vs2015-win64
build/win64/mozconfig.vs-latest
build/win64/mozconfig.vs2015
mobile/android/config/mozconfigs/common.override
which are either empty for use in try builds (override files), or would
already cause great pain if they were directly included, so there's
little chance they would be.
--HG--
extra : rebase_source : 0e6accf241759f8d44868f253874f6546dbadb52
Spidermonkey doesn't currently depend on rust code, and this
unblocks enabling rust by default on gecko builds until we
can get the appropriate toolchain hooked up to all of the
SM automation jobs.
The include must be conditional to avoid breaking artifact builds.
MozReview-Commit-ID: 1PmcFvcZLM2
--HG--
extra : rebase_source : 1a22232e064dd253b80ebaa55decfde1ba7e1ea0
Switch from --enable-rust to optionally enable rust code
to --disable-rust to optionally disable it.
MozReview-Commit-ID: C8cQr5MXUzV
--HG--
extra : rebase_source : 0372be3cc3da56b49104b80c41974139a488ecb2
Official Mozilla builds no longer support non-SSE2 x86 cpus,
so we can use the default i686 rust target here. This allows
better code generation and removes a dependency on the extra
i585 rust std library.
MozReview-Commit-ID: BHrm4tieIym
--HG--
extra : rebase_source : e791068b6128b9f3153b9c85ebd8551d583c2bc7
Bug 1320425 using the '?' operator stabilized in rust 1.13.0.
Update the minimum supported version to reflect this.
MozReview-Commit-ID: 3HKrhfNavEZ
--HG--
extra : rebase_source : 3acb73d551b5c24dff61254e74d0c1c514b2a77c
Now that `./mach boostrap` installs rustup, suggest this if
configure fails to find the toolchain when building with
--enable-rust.
Also point out https://rustup.rs/ for those who want more control.
MozReview-Commit-ID: 8JIbERfz12f
--HG--
extra : rebase_source : a23b3f747f1d430120f16b56e79085dabf3b2018
Provide some guidance on how to resolve the common
error: can't find crate for `std`
when cross-compiling rust code. This most commonly comes up
with the Android build.
MozReview-Commit-ID: 8PKKt7tf1KS
--HG--
extra : rebase_source : 5d18bb3a2ef8b3c4c5700b87c4a899b26160999d
At the same time, remove HOST_LD. It was only used for MSVC builds,
which don't support cross-compile anyways, so we can, at least for now,
use LINK for both host and target.
--HG--
extra : rebase_source : 9ee9e7e1bd3edefc043fa63d5c03f2a242f76982
It turns out that, in practice, the LD variable is not used by the build
system, except on Windows, where it's used to feed the default for LINK,
which is then re-injected as LD.
The upcoming changes are going to normalize the use of LD/LINK.
--HG--
extra : rebase_source : 2a1a9924e963e082e119ff3874e8ff24247f4f94
We'll need this for compiling host binaries. We could just call `rustc`
without any --target value whatsoever, but since we use --target for
target code, we might as well be consistent and explicit, and use
--target for host code as well.
VS2017's directory structure for mfc is the following.
Directory of C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\vc\Tools\msvc\14.10.24629\atlmfc\lib
2016/11/21 13:57 <DIR> .
2016/11/21 13:57 <DIR> ..
2016/11/21 13:57 <DIR> arm
2016/11/21 14:00 <DIR> x64
2016/11/21 13:59 <DIR> x86
So this structure is changed, we cannot detect mfc when using VS2017.
MozReview-Commit-ID: 2ft4stYPZbe
--HG--
extra : rebase_source : c985022eb5b99f32398f1f5c1d2e274c2a4677e7
extra : amend_source : 8b94aba289397dc84d0d360991666ed5a5a8ac07
In some cases, on OSX, python's `os.path.realpath` and shell's `pwd -P`
don't agree on the case of paths on case-insensitive filesystems.
So make everyone agree by using the value from python configure.
--HG--
extra : rebase_source : 4d26bf30f3f125c4f75d42f79d8a80a4a0bf11ec
This patch does a few things:
1) Change all the in-tree tooltool manifests to contain sccache2 instead of the existing Python sccache
2) Change mozconfig.cache to point at sccache.
3) Lightly tweak the --with-cccache configure option to support sccache, and detect whether we're using ccache or sccache and set an option appropriately.
4) Add a MOZ_SCCACHE_VERBOSE_STATS option, and add a target in the top-level Makefile to make sccache spit out its stats at the end of the build. This is useful to see the cache hits/errors until we get something better.
5) Add MOZ_USING_SCCACHE to the build telemetry. Not that I think it will be immediately useful, but for future use.
MozReview-Commit-ID: 9lrdLwNj5Bm
--HG--
extra : rebase_source : d323457df10d0ee0ac5811940e518d9422a7e070
This patch contains a number of changes to the gyp_reader code:
* Add three new flags to GYP_DIRS:
** no_chromium, to skip forcing the includes/etc needed for chromium gyp files
** no_unified, to force building all sources without unification
** action_overrides, to pass scripts used when mapping gyp actions to moz.build GENERATED_FILES
* Handle the flags mentioned above in read_from_gyp
* Handle actions in gyp targets by mapping them to GENERATED_FILES, using scripts specified in the action_overrides flag. We don't try to handle the generic action case, we require special-casing for each action.
* Handle a subset of copies in gyp targets by mapping them to EXPORTS, just enough to handle the use of them for NSS exports.
* Handle shared_library and executable gyp targets
* Handle gyp target dependencies/libraries as USE_LIBS/OS_LIBS
* Handle generated source files
* Handle .def files in sources by mapping them to SYMBOLS_FILE
* Special-case some include_dirs:
** Map `<(PRODUCT_DIR)/dist/` to $DIST/include (to handle include paths for NSS exports)
** Map include_dirs starting with topobjdir to objdir-relative paths, to handle passing the NSPR include path to NSS
* split /build/gyp.mozbuild into two parts, with gyp_base.mozbuild containing generic bits, and gyp.mozbuild containing chromium-specific bits
MozReview-Commit-ID: FbDmlqDjRp4
--HG--
extra : rebase_source : d3fb470c589f92d8c956b9ecd550fb8df79ff5bc
GCC and Clang will colorize compiler output automatically if stdout is a
TTY. Unfortunately, when the build backend is invoked via `mach`,
stdout is not a TTY.
6e9a4c0b9cd8 (bug 1315785) changed mach so it exports an environment
variable indicating whether mach's original stdout is a TTY. This was
later used to add color flags to `cargo` invocations.
Building on that work, this patch adds color flags to compiler
invocations if the compiler supports color and a mach TTY is
detected. The result is that compiler output from `mach build`
will be colorized automatically if Clang or a modern version of
GCC is used.
The only issue I see with this is that Clang doesn't "unset" its color
sequences when printing a newline. As a result, mach's time line
prefixing can sometimes inherit "bold" or other stylings. AFAICT this is
only a minor cosmetic concern. GCC does not exhibit this issue.
MozReview-Commit-ID: 5Icu6aXGZBL
--HG--
extra : rebase_source : 5b2bf5a287fdf8075b3d7dde36b91f3c65b60728
Importing 'os' in python configure functions, on Windows, changes the
separate the various os.path functions use, and that can have
unexpected, badly handled, consequences. While on the long term, it is
desirable to make @imports('os') modify os.path to use the same base
functions as if there were no @imports, let's go with the simpler
workaround of restoring the non-{isfile,isdir,exists} os.path functions
from b6be0e9e3e1e.
--HG--
extra : rebase_source : a1857b5dce2aa818c72a77d0d9727ac6ce16cb8f
We actually target armv7, so we need this distinct triple
with the rust toolchain, while it's implicit with the
android ndk.
MozReview-Commit-ID: LUwdpOaWB6M
--HG--
extra : rebase_source : 820de90d0844e1519f9e02a583c8cc3abf1dfdc0
Mike Hommey
Jan Beich
Nathan Froyd
Ralph Giles
Tom Ritter
Landry Breuil
John Paul Adrian Glaubitz
Ted Mielczarek
Sylvestre Ledru
Carsten "Tomcat" Book
Makoto Kato
Masatoshi Kimura
Ryan VanderMeulen
Gregory Szorc
Phil Ringnalda
Wes Kocher