We add vswhere.exe to support VS2017. But the description output of this command is localized, so it causes UnicodeDecodeError.
So we should use 'mbcs' encoding for this output on Windows platform. And for minor languages, we should also use replace to avoid decode error.
test_toolchain_configure.py calls vc_compiler_path without correct host.kernel, so we should check current python platform.
MozReview-Commit-ID: AkryAzrgSzs
--HG--
extra : rebase_source : 76f2584fa3890e3c11f5ee023b2359a9a19beb16
Doing something like "not foo" when foo is a @depends function is never
going to do what the user expects, while not necessarily leading to an
error (like, when used in set_config).
It is better to have an error in those cases where it's expected not to
work, at the expense of making templates a little more verbose, rather
than silently do something the user is not expecting.
--HG--
extra : rebase_source : 87ba80eccc5606322f6dd185d5cb5fc88471e51b
old-configure does not support being passed them as command line
arguments, so we have to pass them through the environment.
--HG--
extra : rebase_source : e51ea5cc5f95a35929ed1e619d8f04b5d39139fd
We now have code that unconditionally requires the rust
compiler and are committed to adding more. Remove this
last vestige of conditional support.
MozReview-Commit-ID: EK6FBnAbR
--HG--
extra : rebase_source : 6efda10a74f9ca0482304c2b1ffe6941e42138f8
Detect the NDK major/minor version numbers, and feed that to Breakpad.
For AArch64, some Breakpad headers try to workaround NDK oddities by
checking the ANDROID_NDK_MAJOR_VERSION and ANDROID_NDK_MINOR_VERSION
macros.
This patch adds a copy of vswhere.exe to build/win32, downloaded from the
current latest release (1.0.62):
https://github.com/Microsoft/vswhere/releases/download/1.0.62/vswhere.exe
It changes toolchain.configure to invoke vswhere.exe instead of reading
the registry, since that no longer works for VS2017 (but vswhere can locate
VS2015). It also removes a layer of complexity in that code by dropping
support for non-64-bit host systems, since we don't really support building
on 32-bit Windows anymore anyway.
There's a little bit of fixup in windows.configure where some LIB paths
have changed in 2017.
MozReview-Commit-ID: 5XLWjidS6W4
--HG--
extra : rebase_source : 90f79b6f4a2d8d925dd20eb0bf6ab96262c227d5
rustc generates .lib files for its libraries when compiling for Windows
(even using MinGW on Linux). But MinGW expects .a files. So we add in
rust-specific prefix and suffixes so MinGW builds can find the libs that
rustc generates. (And the RUST_LIB- variables default to the same vales
as the LIB_ variables otherwise.)
MozReview-Commit-ID: ClsA0YuJaxh
--HG--
extra : rebase_source : 7b46460c94ceb34b7a5a302ce91d3f1dca600041
This patch adds a copy of vswhere.exe to build/win32, downloaded from the
current latest release (1.0.62):
https://github.com/Microsoft/vswhere/releases/download/1.0.62/vswhere.exe
It changes toolchain.configure to invoke vswhere.exe instead of reading
the registry, since that no longer works for VS2017 (but vswhere can locate
VS2015). It also removes a layer of complexity in that code by dropping
support for non-64-bit host systems, since we don't really support building
on 32-bit Windows anymore anyway.
There's a little bit of fixup in windows.configure where some LIB paths
have changed in 2017.
MozReview-Commit-ID: 5XLWjidS6W4
--HG--
extra : rebase_source : 15c69aeca3295a1811c85a9cf4c2793312dcd122
This flag enables the stack-cookie exploit mitigation for all functions which
manipulate stack-based buffers, providing better protections than
-fstack-protector, at considerably lower performance overhead than
-fstack-protector-all.
r=froydnj
MozReview-Commit-ID: 7ZNAHHAf376
--HG--
extra : rebase_source : 6d5ccbb9537372912c3f5a73fe0fdc65bb68ac08
We add vswhere.exe to support VS2017. But the description output of this command is localized, so it causes UnicodeDecodeError.
So we should use 'mbcs' encoding for this output. And for minor languages, we should also use replace to avoid decode error.
MozReview-Commit-ID: AkryAzrgSzs
--HG--
extra : rebase_source : 8413c623902b04785b43eb77047ed436bf82a5aa
Warn about possible misuse of the comma operator such as between two statements or to call a function for side effects within an expression. Only enable these -Wcomma warnings for C++ code because there are almost two hundred -Wcomma warnings in third-party C libraries. I reviewed the C warnings and confirmed none of them were latent bugs. We won't fix these libraries' warnings so they are just noise.
MozReview-Commit-ID: 1JXJumg6DsJ
--HG--
extra : rebase_source : c48189653361aa84edd3004188315cd73aefa9b5
extra : amend_source : 30be5afeb03eff26d59ccde57c0eb547b743c304
MINGW builds do not need any of the checks that are performed in the
windows.configure file. Nor do they the D3D compiler DLL that is
needed for ANGLE, so we can skip that entire section in
old-configure.in.
MozReview-Commit-ID: DqufbgGoGy4
--HG--
extra : rebase_source : d5f1ed371f79a8a16f888ccc5d058ac72a69f34f
I've moved the mozilla specific gtest stuff to link directly in xul-gtest
rather than in the gtest static library to make it possible for standalone
programs to link against this library and not have to link
against other mozilla libraries. This allows us to build
media/webrtc/signaling/fuzztest against this version of gtest rather than the
webrtc version of gtest, which I plan to remove in a follow on bug.
I had to add a global disable for -Wgnu-zero-variadic-macro-arguments as we
hit that everywhere we use the INSTANTIATE_TEST_CASE_P macro.
This brings forward the fix from Bug 844630 to the visibility of environ in
gtest-death-test.cc.
I also removed code that set GTEST_API_ to a visibility that conflicts with
what we've defined elsewhere in tree.
MozReview-Commit-ID: 3cfuapC6vn0
--HG--
extra : rebase_source : 6e5d2684718b6ddaa5a64c1f26a0172c91b5a719
Currently mozconfig.cache overrides a few build options for sccache. This
patch moves them into toolchain.configure so that the build system will
set them properly when sccache is in use. Additionally, {CC,CXX}_WRAPPER
are set in config.mk, so just avoid setting them when sccache is in use.
MozReview-Commit-ID: FYlVKRI8OiN
--HG--
extra : rebase_source : cc7e4346869b98a52840c101824044abc236637f
We now require cargo by version, and the minimum (0.16)
supports --frozen, so we don't need to check for this.
MozReview-Commit-ID: GPoadLkhRO5
--HG--
extra : rebase_source : e191e5dd2533e28c1bca0812f2776196cc3559cf
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
Jan Beich
Sebastian Hengst
Mike Hommey
Petr Sumbera
Wes Kocher
Makoto Kato
Ted Mielczarek
Ralph Giles
Jim Chen
Alex Gaynor
Frank-Rainer Grahl
Nathan Froyd
Tom Ritter
Edmund Wong
Chris Peterson
Carsten "Tomcat" Book
Dragana Damjanovic
Iris Hsiao
Sylvestre Ledru
Dan Minor
Phil Ringnalda
Tom Tromey
Landry Breuil
John Paul Adrian Glaubitz
Masatoshi Kimura
Ryan VanderMeulen
Gregory Szorc