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 : 00715beb5fbd2c11311dec43809bd1febab56a11
extra : intermediate-source : 0f2b1b75b83737378d882a3c3e0d8dfb4efecd1f
extra : source : a8032ae9cb2ad1c4574c6ac6f5c2778863cd71e0
The values that we need to find in the registry can be inconsistent across
different installations, so we retrieve values from both views in our search
for a valid SDK. This also ensures this works for 32-bit and 64-bit python.
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
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
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
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
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 want functions without an @imports to not have any side effects, and
to not use external resources. So remove the few functions we expose from
os.path without @imports('os') that do.
--HG--
extra : rebase_source : a9485ec269d4de5785d66d7772eda4fae5a84b4a
Now that check_prog, through find_program, returns paths that the build
system can handle, we don't need MT to just be "mt.exe".
However, we still need the PATH to be altered for the other tools we're
not checking in python configure yet (e.g. midl). We also still need
PATH altered for the compiler itself, because for e.g. the amd_x86
version, a necessary DLL is in the amd directory, which means PATH
always needs to be altered for cl.exe.
Before bug 1289294, the impossibility to find the version of MT was only
issuing a warning. Warnings in configure are essentially useless, so
since we weren't and still aren't doing anything with the result of that
check, and since there are versions of MT that don't print out a version
number, just remove the check.
--HG--
extra : rebase_source : 4887cebf0f56ca1a297cd02ff1988809c5cb6fdf
Bob Owen
David Major
Masatoshi Kimura
Ted Mielczarek
Sylvestre Ledru
Sebastian Hengst
Makoto Kato
Mike Hommey
Carsten "Tomcat" Book