Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build: Initial bazel build file changes for Windows #3884

Merged
merged 4 commits into from
Jul 24, 2018
Merged

build: Initial bazel build file changes for Windows #3884

merged 4 commits into from
Jul 24, 2018

Conversation

sesmith177
Copy link
Member

Description:
This is the first step in breaking up #3786 into smaller chunks. This contains the Bazel config / compiler options to allow Envoy to build on Windows. Future PRs will address the external deps build scripts and PGV.

Risk Level:
Low
Testing:
Ran bazel build //source/exe:envoy-static and bazel test //test/... on Linux
Docs Changes:
None
Release Notes:
None

This just contains the "non-controversial changes" to get Envoy building
on Windows. Future PRs will address:
1. getting external deps to build on Windows
2. getting PGV working on Windows

Signed-off-by: Sam Smith <sesmith177@gmail.com>
Signed-off-by: Amin Jamali <ajamali@pivotal.io>
Signed-off-by: Matthew Horan <mhoran@pivotal.io>
Signed-off-by: Akshat Gokhale <agokhale@pivotal.io>
@sesmith177 sesmith177 changed the title Initial bazel build file changes for Windows build: Initial bazel build file changes for Windows Jul 18, 2018
@junr03 junr03 requested a review from jmillikin-stripe July 18, 2018 15:25
@junr03
Copy link
Member

junr03 commented Jul 18, 2018

cc @laszlocsomor

@jmillikin-stripe
Copy link
Contributor

LGTM

values = {"cpu": "x64_windows"},
)

config_setting(

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you define 3 different config_setting rules for Windows for the compilation_mode options? They are all used the same way, you could substitute them with //bazel:windows_x86_64.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need the 3 different config_setting rules for this select here: https://github.com/greenhouse-org/envoy/blob/windows-build-pr/bazel/envoy_build_system.bzl#L36-L41

Specifically, we want to never append -ggdb3 to the copts on Windows, but we want to keep the selection mechanism on Linux. If we just add //bazel:windows_x86_64 to that select, it will fail since multiple options will be true (e.g. //bazel:windows_x86_64 and //bazel:dbg_build).

As far as we know, this is the best way to select on multiple conditions -- did we miss some other way to do this?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I see. No, I think you're right. Thanks for the explanation!

echo "ENVOY_BAZEL_ROOT: $env:ENVOY_BAZEL_ROOT"
echo "ENVOY_SRCDIR: $env:ENVOY_SRCDIR"

$env:BAZEL_BASE_OPTIONS="--nomaster_bazelrc --output_base=$env:ENVOY_BAZEL_ROOT --bazelrc=$env:ENVOY_SRCDIR\windows\tools\bazel.rc --batch"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

--batch is deprecated. You'll have to manually shut down the Bazel server afterwards.

echo "ENVOY_SRCDIR: $env:ENVOY_SRCDIR"

$env:BAZEL_BASE_OPTIONS="--nomaster_bazelrc --output_base=$env:ENVOY_BAZEL_ROOT --bazelrc=$env:ENVOY_SRCDIR\windows\tools\bazel.rc --batch"
$env:BAZEL_BUILD_OPTIONS="--strategy=Genrule=standalone --spawn_strategy=standalone --verbose_failures --action_env=HOME --action_env=PYTHONUSERBASE --jobs=$env:NUM_CPUS --show_task_finish $env:BAZEL_BUILD_EXTRA_OPTIONS"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does $HOME have any value on Windows? (Also in BAZEL_TEST_OPTIONS below.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does not. It doesn't look like we need any of the other action_env or test_env environment variables on Windows, so we'll remove them as well


trap { $host.SetShouldExit(1) }

Invoke-WebRequest -UseBasicParsing "https://aka.ms/vs/15/release/vs_buildtools.exe" -OutFile "$env:TEMP\vs_buildtools.exe"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI: For file downloads, Start-BitsTransfer is faster than Invoke-WebRequest. You may be able to use that.

@@ -0,0 +1,6 @@
# Windows/Envoy specific Bazel build/test options.

build --experimental_shortened_obj_file_path

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI, this flag:

  • is false by default in Bazel 0.15.2
  • will be true by default in Bazel 0.16.0
  • will be unsupported by Bazel 0.17.0

ajgokhale and others added 3 commits July 19, 2018 09:37
- --batch is deprecated
- the --action_env and --test_env settings aren't necesssary on Windows

Signed-off-by: Sam Smith <sesmith177@gmail.com>

Signed-off-by: Akshat Gokhale <agokhale@pivotal.io>
Signed-off-by: Akshat Gokhale <agokhale@pivotal.io>

Signed-off-by: Sam Smith <sesmith177@gmail.com>
will be removed in future versions of Bazel

Signed-off-by: Sam Smith <sesmith177@gmail.com>

Signed-off-by: Akshat Gokhale <agokhale@pivotal.io>
@laszlocsomor
Copy link

LGTM

Copy link
Member

@htuch htuch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome, thanks.

@htuch htuch merged commit e89c9d6 into envoyproxy:master Jul 24, 2018
@rgs1
Copy link
Member

rgs1 commented Jul 24, 2018

@sesmith177 @htuch this broke the example filter:

~/src/envoy-filter-example (master) > bazel build //:envoy
Starting local Bazel server and connecting to it...
...................
DEBUG: /home/rgs/.cache/bazel/_bazel_rgs/978e967c6368412c05ae0af37ca6ae3c/external/io_bazel_rules_go/proto/def.bzl:138:3: You no longer need to call proto_register_toolchains(), it does nothing
ERROR: /home/rgs/src/envoy-filter-example/BUILD:10:1: no such package 'bazel': BUILD file not found on package path and referenced by '//:envoy'
ERROR: /home/rgs/src/envoy-filter-example/BUILD:10:1: no such package 'bazel': BUILD file not found on package path and referenced by '//:envoy'
ERROR: Analysis of target '//:envoy' failed; build aborted: no such package 'bazel': BUILD file not found on package path
INFO: Elapsed time: 15.514s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (5 packages loaded)

@htuch
Copy link
Member

htuch commented Jul 24, 2018

@sesmith177 could you investigate? Thanks.

@rgs1
Copy link
Member

rgs1 commented Jul 24, 2018

@sesmith177 to repro (on Linux):

git clone https://github.com/envoyproxy/envoy-filter-example.git 
cd envoy-filter-example
git submodule update --init
bazel build //:envoy

@sesmith177
Copy link
Member Author

OK, I can repro

@sesmith177
Copy link
Member Author

It looks like some of the references to "//bazel:windows_x86_64" in https://github.com/envoyproxy/envoy/blob/master/bazel/envoy_build_system.bzl weren't properly prefixed with the repository name.

I noticed that some select statements in that file hardcode "@envoy", e.g.

"@envoy//bazel:coverage_build": [],
and some use a repository variable, e.g.:
repository + "//bazel:opt_build": [] if test else ["-ggdb3"],
. Is there a reason that some are hardcoded and some are not?

Anyways, fixing these prefixes up allows the build to succeed. How should we proceed from here?

@htuch @rgs1

@htuch
Copy link
Member

htuch commented Jul 24, 2018

I would use @envoy everywhere. If you can get the small fix PR up I can approve and we can merge quickly, no need to roll back.

@sesmith177
Copy link
Member Author

Done, submitted: #3947

@rgs1
Copy link
Member

rgs1 commented Jul 25, 2018

@sesmith177 hmm still seeing this with our internal build (which operates like the filter example):

17:12:50 Makefile:64: recipe for target '/build/tmp/_bazel_bazel/b570b5ccd0454dc9af9f65ab1833764d/external/envoy_deps_cache_2c744dffd279d7e9e0910ce594eb4f4f/benchmark.dep' failed
17:12:50 make: *** [/build/tmp/_bazel_bazel/b570b5ccd0454dc9af9f65ab1833764d/external/envoy_deps_cache_2c744dffd279d7e9e0910ce594eb4f4f/benchmark.dep] Error 1
17:12:50 + 1532477553.908601192 . /source/envoy/ci/build_container/build_recipes/libevent.sh
17:12:50 ++ 1532477553.909974402 set -e
17:12:50 ++ 1532477553.911713828 VERSION=2.1.8-stable
17:12:50 ++ 1532477553.913660857 curl https://github.com/libevent/libevent/archive/release-2.1.8-stable.tar.gz -sLo libevent-release-2.1.8-stable.tar.gz
17:12:50 ++ 1532477554.316359265 tar xf libevent-release-2.1.8-stable.tar.gz
17:12:50 ++ 1532477554.342869444 cd libevent-release-2.1.8-stable
17:12:50 ++ 1532477554.344297614 mkdir build
17:12:50 ++ 1532477554.346709184 cd build
17:12:50 ++ 1532477554.348043344 build_type=Release
17:12:50 ++ 1532477554.349984389 [[ '' == \W\i\n\d\o\w\s\_\N\T ]]
17:12:50 ++ 1532477554.351489148 cmake -G Ninja -DCMAKE_INSTALL_PREFIX=/build/tmp/_bazel_bazel/b570b5ccd0454dc9af9f65ab1833764d/external/envoy_deps_cache_2c744dffd279d7e9e0910ce594eb4f4f/thirdparty_build/ -DEVENT__DISABLE_OPENSSL:BOOL=on -DEVENT__DISABLE_REGRESS:BOOL=on -DCMAKE_BUILD_TYPE=Release ..
17:12:50 CMake Error: CMake was unable to find a build program corresponding to "Ninja".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.
17:12:50 CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
17:12:50 -- Configuring incomplete, errors occurred!

on my side... investigating...

@rgs1
Copy link
Member

rgs1 commented Jul 25, 2018

@sesmith177 ah, looks like we need to update our build container to include ninja. sorry for the false alarm.

@sesmith177 sesmith177 deleted the windows-build-1 branch October 5, 2018 16:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants