If `build/vs_toolchain.py update --force` is run once on non-Windows, the
script will start keeping a Windows toolchain in depot_tools up-to-date, and
it'll copy runtime dlls into the build directory, and so on. (One can delete
build/win_toolchain.json to disable this behavior again.)
Depends on https://codereview.chromium.org/1284723006
BUG=495204
Review URL: https://codereview.chromium.org/1277913006
Cr-Original-Commit-Position: refs/heads/master@{#342917}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 4f4b137f26afe39a02f789832e840757b11f088d
Reason for revert:
It's breaking the VS2015 builder. I'm looking at it.
Original issue's description:
> win 2015: Update the toolchain package to VS2015 RTM.
>
> I've tried it locally (build Chrome with this archive on a fresh VM) and it worked well, the archive has been generated with package_from_installed.py (from depot_tools/win_toolchain)
>
> BUG=
>
> Committed: https://crrev.com/f04ff85d2b85833971ef7ca7f31f4fd5a1b1f3aa
> Cr-Commit-Position: refs/heads/master@{#340898}
TBR=brucedawson@chromium.org,thakis@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1254023004
Cr-Original-Commit-Position: refs/heads/master@{#340906}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: ff200aeebf10796f772ea5ecc61ec1be9b7cdac3
I've tried it locally (build Chrome with this archive on a fresh VM) and it worked well, the archive has been generated with package_from_installed.py (from depot_tools/win_toolchain)
BUG=
Review URL: https://codereview.chromium.org/1265503002
Cr-Original-Commit-Position: refs/heads/master@{#340898}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: f04ff85d2b85833971ef7ca7f31f4fd5a1b1f3aa
This is not intended to change anything for current VS2013 users.
The 2015 code here will not work until a change in depot_tools side
lands. (It might not work after that either, but this is
the first step in getting a 2015 fyi bot up.)
R=dpranke@chromium.org
BUG=492774
Review URL: https://codereview.chromium.org/1163723003
Cr-Original-Commit-Position: refs/heads/master@{#332296}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 54e450611852fcf8cb120f73b381a50768212415
The latest GN binaries rename cpu_arch to current_cpu and/or target_cpu
as appropriate, build_cpu_arch to host_cpu, and os to current_os and target_os as appropriate.
R=brettw@chromium.orgTBR=ddorwin@chromium.org
EXTRA_TRYBOTS=tryserver.chromium.linux:android_chromium_gn_compile_dbg,android_chromium_gn_compile_rel;tryserver.chromium.win:win8_chromium_gn_rel,win8_chromium_gn_dbg;tryserver.chromium.mac:mac_chromium_gn_rel,mac_chromium_gn_dbg
BUG=344767
Review URL: https://codereview.chromium.org/913373002
Cr-Original-Commit-Position: refs/heads/master@{#317223}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 4327621a322c964a8bc6d1ef5a4534f0f877d63e
I had to set:
DEPOT_TOOLS_WIN_TOOLCHAIN=0
GYP_MSVS_OVERRIDE_PATH=C:/Program Files (x86)/Microsoft Visual Studio 12.0
GYP_MSVS_VERSION=2013
WindowsSdkDir=C:/Program Files (x86)/Windows Kits/8.1
then
gn gen out\gn --args="is_debug=true cpu_arch=\"x86\""
ninja -C out/gn base
worked OK.
Further patches welcome to make this less ugly.
R=dpranke@chromium.org
Review URL: https://codereview.chromium.org/789303002
Cr-Original-Commit-Position: refs/heads/master@{#307791}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: fa5da3e4e515967d593c3822b1d82f5e844080c5
This fixes
"fatal error C1902: Program database manager mismatch; please check your installation"
and
"cannot find msvcr120.dll"
during gn compilation.
There were many things wrong. The primary ones were that:
1) the compiler's setup script wasn't called so we didn't get
PATH/LIB/INCLUDE for the correct cl.
2) the VS runtime dirs were not getting added to environment block.
I also removed the Express handling, as that's been removed from the
gyp path now.
This does not yet support a system-installed Visual Studio. Code
needs to be added to query the registry to find the install location.
(see _SetupScript).
R=dpranke@chromium.orgTBR=brettw@chromium.org
BUG=432375
Review URL: https://codereview.chromium.org/736073002
Cr-Original-Commit-Position: refs/heads/master@{#304864}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 9bf8fb3b74de68a85122cb45bb477d604b8c3898
- Disable 4996 (deprecated functions in 8.1, these don't help us because we have to run on old OSs anyway)
- Simplify Bluetooth LE header hacks (these headers are buggy in 8.0 and 8.1 SDKs, but less buggy in 8.1)
- Revert attempt to centralize toolchain hashes as it didn't work well, and made it hard to roll anyway (see 400830).
- Instead of basing C4702 (unreachable code) on Pro vs. Express, check whether it's actually disabled in the xtree header
- Remove automatic calling of Express toolchain setup script. It hasn't worked well since post VS2013 RTM because of being distributed as .msp files, and the new Community edition is relatively easy to install so can subsume that usage (that being the motivation for the 4702 change above)
- goma package for u4 is pushed
- ANGLE is switched to load d3dcompiler_47 and build against 8.1 sdk, roll included here.
Xrefs:
- https://codereview.chromium.org/719343004/
- https://chromium-review.googlesource.com/#/c/229616/
- b2/18365241
- https://codereview.chromium.org/733563003/
- https://codereview.chromium.org/732673002/
- https://codereview.chromium.org/729453004/
- https://chromereviews.googleplex.com/120597013/
BUG=311488,432748,400830
Review URL: https://codereview.chromium.org/720033003
Cr-Original-Commit-Position: refs/heads/master@{#304329}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: a6675a5f1f55e66b1d6625af6225d44f5d9b0f3d
In order to run both the visual studio tools and the binaries built
by them (and ninja), we need to ensure that the VS runtime DLLs
are available in the path.
In the GYP build, we accomplish this by copying them into the
Debug and Debug_x64 dirs as appropriate inside the gyp_chromium
script.
In the pure-GN build, then, things would be broken, so we need to
modify the GN build to do the copy as well, or we need to inject
a step somewhere that happens after GN runs but before Ninja tries
to run (since none of the toolchain binaries will work).
This patch accomplishes this by calling out to vs_toolchain.py to
copy the DLLs as neede when the toolchain is defined. This is somewhat
less than ideal (makes 'gn gen' slower) but seems better than forcing
devs to have to run an additional command.
In addition, the GYP build writes targets into Debug and Debug_x64
concurrently. This doesn't really carry over into GN correctly, and
we probably only ever want to write targets into Debug and Debug/64
(or some such).
However, the way the toolchains are currently implemented, it's not
clear if this really works and the interplay between 32-bit and 64-bit
is weird (we apparently normally "force" 32-bit even if we set cpu_arch
to 64-bit, and require you to specify force_win64). To work around this
and make sure that we copy the right DLLs for the right arch into the
outer Debug/ directory, this patch temporarily disables the cross-arch
part of the build, forcing the host_toolchain to match the target_toolchain.
This likely means that 'cpu_arch="x86"' works (the default), but the 'host'
binaries like image_diff and mksnapshot will be compiled in 32-bit mode,
not 64-bit mode. 'cpu_arch="x64" force_win64=true' should also work, and
produce all-64-bit binaries. 'cpu_arch="x64"' does not work at all and
won't until we can clean up the above stuff.
R=scottmg@chromium.org, brettw@chromium.org
BUG=430661
Review URL: https://codereview.chromium.org/722723004
Cr-Original-Commit-Position: refs/heads/master@{#304310}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 0b95195e49489b7a4d87048d2ce4b747173a5b8a
This is enough for this to work OK:
[gn-2013]d:\src\cr\src>gn gen out_gn
[gn-2013]d:\src\cr\src>ninja -C out_gn gn
[gn-2013]d:\src\cr\src>out_gn\gn gen out_gn2
[gn-2013]d:\src\cr\src>ninja -C out_gn2 gn
...
[297/297] LINK gn.exe
I'm not sure if we need all the deleted stuff for something
else, but I guess we can revive it when we need it.
(There's some dependency problem with linking atm, as
"ninja -C out_gn gn" always relinks, but I think it's unrelated.)
R=brettw@chromium.org
BUG=297677
Review URL: https://codereview.chromium.org/204663004
git-svn-id: http://src.chromium.org/svn/trunk/src/build@258327 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
thakis
sebmarchand
scottmg
dpranke
yyanagisawa
ckocagil
scottmg@chromium.org
sebmarchand@chromium.org
brettw@chromium.org