Visual C++ build tools seem to be needed even though the project does not do anything related to C++. It would be helpful that this were not the case, as visual studio is a separate and very large install.
This is important for Node/Typescript projects (https://github.com/bazelbuild/rules_nodejs / https://github.com/bazelbuild/rules_typescript) that do not have a C++/Java/Python build.
mkdir bazel-repro
touch WORKSPACE
touch f.txt
echo "filegroup(name=\"foo\", srcs=[\"t.txt\"])" > BUILD.bazel
bazel run :foo
kamik@T460p MINGW64 /d/sandbox/bazel-repro
$ bazel build :foo
DEBUG: C:/users/kamik/appdata/local/temp/_bazel_kamik/bgcwgegb/external/bazel_tools/tools/cpp/lib_cc_configure.bzl:37:3:
Auto-Configuration Warning: 'BAZEL_VC' is not set, start looking for the latest Visual C++ installed.
.
DEBUG: C:/users/kamik/appdata/local/temp/_bazel_kamik/bgcwgegb/external/bazel_tools/tools/cpp/lib_cc_configure.bzl:37:3:
Auto-Configuration Warning: Looking for VS%VERSION%COMNTOOLS environment variables,eg. VS140COMNTOOLS
.
DEBUG: C:/users/kamik/appdata/local/temp/_bazel_kamik/bgcwgegb/external/bazel_tools/tools/cpp/lib_cc_configure.bzl:37:3:
Auto-Configuration Warning: Looking for Visual C++ through registry
.
ERROR: in target '//external:cc_toolchain': no such package '@local_config_cc//': Traceback (most recent call last):
File "C:/users/kamik/appdata/local/temp/_bazel_kamik/bgcwgegb/external/bazel_tools/tools/cpp/cc_configure.bzl", line 34
configure_windows_toolchain(repository_ctx)
File "C:/users/kamik/appdata/local/temp/_bazel_kamik/bgcwgegb/external/bazel_tools/tools/cpp/windows_cc_configure.bzl", line 316, in configure_windows_toolchain
_find_vc_path(repository_ctx)
File "C:/users/kamik/appdata/local/temp/_bazel_kamik/bgcwgegb/external/bazel_tools/tools/cpp/windows_cc_configure.bzl", line 165, in _find_vc_path
auto_configure_fail("Visual C++ build tools not foun...")
File "C:/users/kamik/appdata/local/temp/_bazel_kamik/bgcwgegb/external/bazel_tools/tools/cpp/lib_cc_configure.bzl", line 30, in auto_configure_fail
fail(("\n%sAuto-Configuration Error:%...)))
Auto-Configuration Error: Visual C++ build tools not found on your machine.
Operating System:
Windows 10
Bazel version (output of bazel info release):
release 0.6.0
/cc @alexeagle
The underlying problem seems to be that the built-in autoconfiguration unconditionally searches for the C toolchain. In fact that also happens for other platforms (but having a cc is not that much of a problem there).
@lberki @mhlopko Can you have a look? Maybe we should take the idea of less implicit magic and explicitly configure what is requested/needed more seriously.
@meteorcloudy
Yes, I think we should decouple cc_configure, I'll discuss this with the Windows team.
/cc @dslomov this is a big deal for Angular users. Could it be fixed before windows support goes to beta? (I happened across the blog post)
Heya, I was looking at https://github.com/bazelbuild/bazel-blog/pull/42/files and wondering if a fix for this will also go into the release for that blog post.
The gitbash bit is especially interesting... right now installing bazel on windows is a multistep process (https://docs.bazel.build/versions/master/windows.html):
With the blog post changes, for a user that already has git bash, it seems to be only
Removing visual studio out of the equation reduces the steps by half, which is pretty significant.
@alexeagle @filipesilva Good news, I've already sent a change to avoid the hard dependency on VC,
See https://bazel-review.googlesource.com/#/c/bazel/+/19050/
As long as you don't build C++ rules without VC installed, you should not get VC error anymore.
With this change, installing Bazel on Windows using chocolatey is just one step:
I do not think is is much useful to block "beta" status specifically on suitability for Angular.
I think the better thing would be to make Angular experience with Bazel on Windows really smooth and publicize this then. I think the right approach to get there is to have an initial list of current issues and then work together towards fixing them - everything we fix Bazel-side will benefit all other users on Windows, I am sure about that. I can see this happening for say our December release (0.9) maybe?
Most helpful comment
The underlying problem seems to be that the built-in autoconfiguration unconditionally searches for the C toolchain. In fact that also happens for other platforms (but having a
ccis not that much of a problem there).@lberki @mhlopko Can you have a look? Maybe we should take the idea of less implicit magic and explicitly configure what is requested/needed more seriously.