Bazel: Bazel + MSVC C++ = missing dependency declarations [culprit #5136]

[derekmauro]

Description of the problem / feature request:

We are getting a spurious this rule is missing dependency declarations for the following files included by ... when using MSVC to build on Windows. I say it is spurious because the same command works correctly on Linux and OSX, and I've verified the BUILD rule is correct.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

On Windows + MSVC:

git clone https://github.com/abseil/abseil-cpp.git
bazel test --define absl=1 absl/...

The --define absl=1 part makes Google Test use Abseil. So Abseil tests uses Google Test, which in turn uses the Abseil libraries. I'm not sure if the circular project dependency has anything to do with this. Everything works as expected without --define absl=1.

Output on my machine:

PS C:\Users\dmauro\abseil-cpp> bazel --bazelrc=/dev/null test --define absl=1 absl/...
Loading:
Loading: 0 packages loaded
INFO: Build options have changed, discarding analysis cache.
Analyzing: 157 targets (16 packages loaded)
INFO: Analysed 157 targets (34 packages loaded).
INFO: Found 55 targets and 102 test targets...
[0 / 11] [-----] Creating source manifest for //absl/strings:ascii_test
[10 / 33] Compiling external/com_google_absl/absl/strings/charconv.cc; 1s local ... (4 actions running)
[15 / 33] Compiling external/com_google_absl/absl/strings/substitute.cc; 1s local ... (4 actions, 3 running)
[19 / 33] Compiling external/com_google_absl/absl/strings/str_cat.cc; 1s local ... (4 actions, 3 running)
[24 / 38] Compiling external/com_google_absl/absl/strings/str_replace.cc; 1s local ... (3 actions running)
[36 / 55] Compiling external/com_google_absl/absl/debugging/failure_signal_handler.cc; 0s local ... (4 actions running)
[39 / 58] Compiling external/com_google_absl/absl/debugging/failure_signal_handler.cc; 1s local ... (4 actions running)
[45 / 66] Compiling absl/base/internal/spinlock.cc; 1s local ... (4 actions, 3 running)
[54 / 78] Compiling external/com_google_absl/absl/base/internal/low_level_alloc.cc; 1s local ... (4 actions running)
[55 / 79] Compiling external/com_google_googletest/googletest/src/gtest-death-test.cc; 2s local ... (4 actions running)
[60 / 84] Compiling external/com_google_googletest/googletest/src/gtest.cc; 2s local ... (3 actions running)
[64 / 89] Compiling external/com_google_googletest/googletest/src/gtest-printers.cc; 2s local ... (4 actions running)
[73 / 98] Compiling absl/strings/str_replace.cc; 1s local ... (4 actions running)
[86 / 113] Compiling external/com_google_absl/absl/base/internal/spinlock.cc; 1s local ... (4 actions running)
ERROR: C:/users/dmauro/abseil-cpp/absl/strings/BUILD.bazel:148:1: undeclared inclusion(s) in rule '//absl/strings:ascii_
test':
this rule is missing dependency declarations for the following files included by 'absl/strings/ascii_test.cc':
  'absl/types/optional.h'
  'absl/utility/utility.h'
  'absl/types/bad_optional_access.h'
  'absl/types/variant.h'
  'absl/types/internal/variant.h'
  'absl/types/bad_variant_access.h'
INFO: Elapsed time: 29.078s, Critical Path: 4.50s
INFO: 71 processes: 71 local.
FAILED: Build did NOT complete successfully

It's interesting that I see both Compiling absl/base/internal/spinlock.cc; and external/com_google_absl/absl/base/internal/low_level_alloc.cc; (note the external/com_google_absl prefix). It is as if Bazel doesn't understand that the root WORKSPACE, named com_google_absl, isn't the same Abseil that Google Test depends on, even though it depends on Abseil under the name com_google_absl. A Linux build never shows the external/com_google_absl in the output.

What operating system are you running Bazel on?

Windows 2008 R2 on GCP. I also tried it on a Kokoro instance (not sure of the Windows version of that) and got the same result.

What's the output of bazel info release?

PS C:\Users\dmauro\abseil-cpp> bazel version
Build label: 0.15.0
Build target: bazel-out/x64_windows-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Tue Jun 26 12:09:42 2018 (1530014982)
Build timestamp: 1530014982
Build timestamp as int: 1530014982
PS C:\Users\dmauro\abseil-cpp> bazel info release
release 0.15.0

What's the output of git remote get-url origin ; git rev-parse master ; git rev-parse HEAD ?

PS C:\Users\dmauro\abseil-cpp> git remote get-url origin ; git rev-parse master ; git rev-parse HEAD
https://github.com/abseil/abseil-cpp.git
2c5af55ed34850d8b7dd46177c8ca53fdfda920e
2c5af55ed34850d8b7dd46177c8ca53fdfda920e

Have you found anything relevant by searching the web?

https://github.com/bazelbuild/bazel/issues/5087 is possibly the same issue, but I'm not sure. That issue refers to remote workers.

[rongjiecomputer]

I can reproduce the issue with Bazel from master branch and VS 2017 15.7 and Clang on Windows (master).

@derekmauro I have some idea, but I will need your help to verify it. Can you do the following on Linux machine with GCC/Clang?

1. Run bazel test --define absl=1 //absl/base:throw_delegate_test
2. Modify throw_delegate_test.cc.
3. Run bazel test --define absl=1 //absl/base:throw_delegate_test -s
4. Paste the console output here (I am only interested in the subcommand when compiling throw_delegate_test.cc).

[derekmauro]

Output from step 3:

$ bazel test --define absl=1 //absl/base:throw_delegate_test -s
INFO: Analysed target //absl/base:throw_delegate_test (0 packages loaded).
INFO: Found 1 test target...
SUBCOMMAND: # //absl/base:throw_delegate_test [action 'Compiling absl/base/throw_delegate_test.cc']
(cd /home/dmauro/.cache/bazel/_bazel_dmauro/e240e8f4f46ded87fd03013f5525686b/execroot/com_google_absl && \
  exec env - \
    PATH=/home/dmauro/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
    PWD=/proc/self/cwd \
  /usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -B/usr/bin -B/usr/bin -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer '-std=c++0x' -MD -MF bazel-out/k8-fastbuild/bin/absl/base/_objs/throw_delegate_test/absl/base/throw_delegate_test.pic.d '-frandom-seed=bazel-out/k8-fastbuild/bin/absl/base/_objs/throw_delegate_test/absl/base/throw_delegate_test.pic.o' -fPIC -D__CLANG_SUPPORT_DYN_ANNOTATION__ '-DGTEST_HAS_ABSL=1' -iquote . -iquote bazel-out/k8-fastbuild/genfiles -iquote external/bazel_tools -iquote bazel-out/k8-fastbuild/genfiles/external/bazel_tools -iquote external/com_google_googletest -iquote bazel-out/k8-fastbuild/genfiles/external/com_google_googletest -iquote external/com_google_absl -iquote bazel-out/k8-fastbuild/genfiles/external/com_google_absl -isystem external/com_google_googletest/googlemock -isystem bazel-out/k8-fastbuild/genfiles/external/com_google_googletest/googlemock -isystem bazel-out/k8-fastbuild/bin/external/com_google_googletest/googlemock -isystem external/com_google_googletest/googlemock/include -isystem bazel-out/k8-fastbuild/genfiles/external/com_google_googletest/googlemock/include -isystem bazel-out/k8-fastbuild/bin/external/com_google_googletest/googlemock/include -isystem external/com_google_googletest/googletest -isystem bazel-out/k8-fastbuild/genfiles/external/com_google_googletest/googletest -isystem bazel-out/k8-fastbuild/bin/external/com_google_googletest/googletest -isystem external/com_google_googletest/googletest/include -isystem bazel-out/k8-fastbuild/genfiles/external/com_google_googletest/googletest/include -isystem bazel-out/k8-fastbuild/bin/external/com_google_googletest/googletest/include -Wall -Wextra -Wcast-qual -Wconversion-null -Wmissing-declarations -Woverlength-strings -Wpointer-arith -Wunused-local-typedefs -Wunused-result -Wvarargs -Wvla -Wwrite-strings -Wno-sign-compare -Wno-conversion-null -Wno-missing-declarations -Wno-sign-compare -Wno-unused-function -Wno-unused-parameter -Wno-unused-private-field -fexceptions -fno-canonical-system-headers -Wno-builtin-macro-redefined '-D__DATE__="redacted"' '-D__TIMESTAMP__="redacted"' '-D__TIME__="redacted"' -c absl/base/throw_delegate_test.cc -o bazel-out/k8-fastbuild/bin/absl/base/_objs/throw_delegate_test/absl/base/throw_delegate_test.pic.o)
SUBCOMMAND: # //absl/base:throw_delegate_test [action 'Linking absl/base/throw_delegate_test']
(cd /home/dmauro/.cache/bazel/_bazel_dmauro/e240e8f4f46ded87fd03013f5525686b/execroot/com_google_absl && \
  exec env - \
    PATH=/home/dmauro/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
    PWD=/proc/self/cwd \
  /usr/bin/gcc -o bazel-out/k8-fastbuild/bin/absl/base/throw_delegate_test '-Wl,-rpath,$ORIGIN/../../_solib_k8/' -Lbazel-out/k8-fastbuild/bin/_solib_k8 -pthread '-fuse-ld=gold' -Wl,-no-as-needed -Wl,-z,relro,-z,now -B/usr/bin -B/usr/bin -pass-exit-codes -Wl,-S -Wl,@bazel-out/k8-fastbuild/bin/absl/base/throw_delegate_test-2.params)
SUBCOMMAND: # //absl/base:throw_delegate_test [action 'Testing //absl/base:throw_delegate_test']
(cd /home/dmauro/.cache/bazel/_bazel_dmauro/e240e8f4f46ded87fd03013f5525686b/execroot/com_google_absl && \
  exec env - \
    JAVA_RUNFILES=bazel-out/k8-fastbuild/bin/absl/base/throw_delegate_test.runfiles \
    PATH=/home/dmauro/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
    PYTHON_RUNFILES=bazel-out/k8-fastbuild/bin/absl/base/throw_delegate_test.runfiles \
    RUNFILES_DIR=bazel-out/k8-fastbuild/bin/absl/base/throw_delegate_test.runfiles \
    RUN_UNDER_RUNFILES=1 \
    TEST_BINARY=absl/base/throw_delegate_test \
    TEST_INFRASTRUCTURE_FAILURE_FILE=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.infrastructure_failure \
    TEST_LOGSPLITTER_OUTPUT_FILE=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.raw_splitlogs/test.splitlogs \
    TEST_PREMATURE_EXIT_FILE=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.exited_prematurely \
    TEST_SIZE=medium \
    TEST_SRCDIR=bazel-out/k8-fastbuild/bin/absl/base/throw_delegate_test.runfiles \
    TEST_TARGET=//absl/base:throw_delegate_test \
    TEST_TIMEOUT=300 \
    TEST_TMPDIR=_tmp/5cb1cd4ee5a296cc53b755bf19211d99 \
    TEST_UNDECLARED_OUTPUTS_ANNOTATIONS=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.outputs_manifest/ANNOTATIONS \
    TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.outputs_manifest \
    TEST_UNDECLARED_OUTPUTS_DIR=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.outputs \
    TEST_UNDECLARED_OUTPUTS_MANIFEST=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.outputs_manifest/MANIFEST \
    TEST_UNDECLARED_OUTPUTS_ZIP=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.outputs/outputs.zip \
    TEST_UNUSED_RUNFILES_LOG_FILE=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.unused_runfiles_log \
    TEST_WARNINGS_OUTPUT_FILE=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.warnings \
    TEST_WORKSPACE=com_google_absl \
    TZ=UTC \
    XML_OUTPUT_FILE=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.xml \
  external/bazel_tools/tools/test/test-setup.sh absl/base/throw_delegate_test)
Target //absl/base:throw_delegate_test up-to-date:
  bazel-bin/absl/base/throw_delegate_test
INFO: Elapsed time: 1.118s, Critical Path: 0.91s
INFO: 3 processes: 3 linux-sandbox.
INFO: Build completed successfully, 4 total actions
//absl/base:throw_delegate_test                                          PASSED in 0.1s

Executed 1 out of 1 test: 1 test passes.
There were tests whose specified size is too big. Use the --test_verbose_timeoutINFO: Build completed successfully, 4 total actions

[rongjiecomputer]

Thanks for the console output. It disprove my guess that the include flags -I might be different for GCC/Clang and MSVC. Bazel always add include path . before external/com_google_absl regardless of compilers.

From what I can see in Bazel's java code, Bazel handles MSVC's /showIncludes output and GCC/Clang's -MD ouput in different code path (see [0]), but the validation seems to be done in the same function (see [1]). Java code is not my expertise, so I think I will stop here.

[rongjiecomputer]

@meteorcloudy @mhlopko Can you take a look?

[meteorcloudy]

@rongjiecomputer Thanks for the help, I'll take it from here.

[meteorcloudy]

@derekmauro I've debugged on this and found the root cause. Let me explain how this issue happened on Windows and not on Linux.

• First, the google test framework depends on a certain version of absel. See
  https://github.com/google/googletest/blob/master/WORKSPACE. Bazel downloads it as an external repository, that's why external/com_google_absl/absl/... exists. It will be compiled when enabling define absl=1. This is also true on Linux.

$ bazel query 'somepath(//absl/strings:ascii_test, @com_google_absl//absl/types:optional)'
//absl/strings:ascii_test
@com_google_googletest//:gtest_main
@com_google_googletest//:gtest
@com_google_absl//absl/types:optional

• When compiling absl/strings/ascii_test.cc, two include directories will be added - . and external/com_google_absl. Both directories contains absl/types/optional.h and other header files. The first one will be detected by the compiler, but only the second one is declared as dependency of the test. The dependency check thus failed.
• It didn't happen on Linux because sandbox is enabled by default. Since absl/types/optional.h is not declared as dependency, the compiler won't see it. If you build with --spawn_strategy=standalone, you'll get the same error as Windows.

@dslomov Is there anyway to override @com_google_absl in googletest to point to the local absl repository ?

[dslomov]

Not right now, but there will be once experimental_enable_repo_mapping is fully finished and #3115 is fixed.

[meteorcloudy]

@dslomov Thanks! Then I'll assign this to you.

[meteorcloudy]

FYI @laszlocsomor, this is the similar bug you encountered recently.

[meteorcloudy]

/cc @mhlopko This issue happens when you have the same header file under /I. and /Iextenral/<repository_name>, I guess we don't have any other way to avoid the conflict except enabling sandbox? (which only available on Unix).

[laszlocsomor]

@mhlopko, @meteorcloudy : I think the culprit is that every action runs in the same execution root. I believe the single execution root is the reason the compilation action has /Iexternal/foo -- to enable compiling cc_* rules even when they are in external repos.

[laszlocsomor]

And I believe we could solve this problem if all build actions corresponding to rules in external repos would use <execroot>/external/<reponame> as their execution root, and only the main repo's build actions would use <execroot>.

[meteorcloudy]

@laszlocsomor What if you have a cc_library lib.cc in your main repo, which depends on repo_x and includes foo/bar/x.h under <execroot>/external/repo_x. And you happen to have foo/bar/x.h under your source tree. We'll still have the same problem during compiling lib.cc, because /I. and /Iexternal/repo_x (relative to <execroot>) are both passed to the compiler.

[rongjiecomputer]

If /I. is added only after all the /Iexternal/repo, it should solve the issue Abseil is having, but I afraid that other issues might arise.

[meteorcloudy]

@rongjiecomputer Yes, that would be wrong if the actual file you want to include is in your main repo instead of external repo. I think the only way to make it right is sandbox, this way it can keep the compiler from accidentally discovering undeclared include files. (although there could still be header file conflicts between declared dependencies).

[laszlocsomor]

@meteorcloudy : Indeed you're right.

I also forgot to consider @repo//bar/b.cc may #include "bar/b.h", but @repo//bar:b may depend on rules in other external repos (e.g. @oper//qux:c), so even if the effective execution root for compiling @repo//bar:b were <execroot>/external/repo, this directory would have to contain a symlink <execroot>/external/repo/external/oper pointing to <execroot>/external/oper.

Update: fixed repo paths.

[laszlocsomor]

Correction: the symlink would have to be <execroot>/external/repo/external/oper, and point to <execroot>/external/oper. (Fixed in previous post.)

[laszlocsomor]

@meteorcloudy :

although there could still be header file conflicts between declared dependencies

Right, for example when a library depends on both //foo:x and @repo//foo:x and those both have foo/x.h in hdrs.

[laszlocsomor]

I think the include scanner could catch this error and suggest a fix ("Did you mean to include external/repo/foo/x.h instead of foo/x.h?"). Bazel knows the allowed set of included headers, so the include scanner could detect if an illegally included header file exists under one of the external repos.

[meteorcloudy]

the include scanner could catch this error and suggest a fix ("Did you mean to include external/repo/foo/x.h instead of foo/x.h?")

I agree.

[laszlocsomor]

After in-person discussion with @mhlopko and @meteorcloudy, it became clear that including files via "external/reponame" is in fact the wrong approach.

When a header file (lib/x.h) includes another file from its own package (lib/y.h), the inclusion path will be repo-relative. But if these headers are in an external repo (@foo) and a file in the main repo (main.cc) includes the first header as external/foo/lib/x.h, then the header's own inclusion path will now be wrong because it is missing the external/foo/ part.

The author of lib/x.h of course cannot foresee what external repo names their code will be imported under, so they cannot write future-proof include paths under external/. That's why repo-relative include paths must remain supported even for headers included from external repos, and my idea of including via external/foo/ is misguided.

[gennadiycivil]

Ping. Any updates on this? Thank you

[gennadiycivil]

This issue is of a particular importance for the federation work and googletest. @laszlocsomor @dslomov @meteorcloudy - plmk, thank you!

[laszlocsomor]

@gennadiycivil , sorry for the silence, we were away.

The original bug report already hinted at the core of the problem, namely the circular dependency:

The --define absl=1 part makes Google Test use Abseil. So Abseil tests uses Google Test, which in turn uses the Abseil libraries. I'm not sure if the circular project dependency has anything to do with this. Everything works as expected without --define absl=1.

I see these options. None of them is trivial or easy:

1. Implement sandboxing on Windows.

   • Pro: Docker-based and symlink-based sandboxing are both probably feasible.
   • Contra: May be impractically slow.

2. Fake sandboxing: create unique execroots for C++ compilation actions, stage the include directories (copy the allowed headers).

   • Pro: Works on older Windows versions.
   • Contra: Even slower than sandboxing because of file copying.

3. Merge repos of Abseil and Google Test to form a mini-monorepo.

   • Pro: Sidesteps the problem with external deps.
   • Contra: May not be desirable / feasible?

Any other ideas?

[gennadiycivil]

Thank you for your response, lets try to go one by one:

>
The --define absl=1 part makes Google Test use Abseil. So Abseil tests uses
Google Test, which in turn uses the Abseil libraries. I'm not sure if the
circular project dependency has anything to do with this. Everything works
as expected without --define absl=1.
>

I think better way to describe this would be as follows:
--define absl=1 makes Abseil types available for Googletest, so they can be
tested. In essence, there is no 'real' circular dependency, Abseil only
needs googletest for test targets, and googletest does not need abseil at
all.

The elephant in the room is of course "This works just fine on Linux so can
we please make it work on Windows as well"

The reason we need it is precisely creating a mono-repo , googletest is
going to be a member of Abseil OSS Federation. ahedberg@ is a
Technical Lead and can provide more details, without Windows support this
is much harder.

Thank you for your help!
G

On Thu, Nov 8, 2018 at 8:25 AM László Csomor [e-mail]
wrote:

@gennadiycivil https://github.com/gennadiycivil , sorry for the
silence, we were away.

The original bug report already hinted at the core of the problem, namely
the circular dependency:

The --define absl=1 part makes Google Test use Abseil. So Abseil tests
uses Google Test, which in turn uses the Abseil libraries. I'm not sure if
the circular project dependency has anything to do with this. Everything
works as expected without --define absl=1.

I see these options. None of them is trivial or easy:

1.

Implement sandboxing on Windows.

• Pro: Docker-based and symlink-based sandboxing are both probably
  feasible.
  
  
  
  • Contra: May be impractically slow.
    
    2.
  
  

Fake sandboxing: create unique execroots for C++ compilation actions,
stage the include directories (copy the allowed headers).

• Pro: Works on older Windows versions.
  
  
  
  • Contra: Even slower than sandboxing because of file copying.
    
    3.
  
  

Merge repos of Abseil and Google Test to form a mini-monorepo.

• Pro: Sidesteps the problem with external deps.
  
  
  
  • Contra: May not be desirable / feasible?
  
  

Any other ideas?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/bazel/issues/5640#issuecomment-436992423,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMJSMhZT8ebSuG8r0ZPeDfmvCmxh5gc6ks5utDCwgaJpZM4VWlmm
.

[rongjiecomputer]

Implementing sandbox on Windows without Docker or symlink is not impossible because Chromium already does it. Chromium's sandbox uses a few Windows NT APIs (aka system calls) from ntdll.dll to intercept other NT APIs. Win32 APIs is built on top of NT APIs, so this is how Chromium's sandbox can control child process's access to certain resources (registry, socket, file and pipe).

NT APIs are not documented by Microsoft because people aren't suppose to use it, this is probably why Bazel team didn't know about this possibility.

I think if Bazel team wants to implement sandbox on Windows, the best way is to consult Chromium team first. Mozilla once tried to port Chromium's sandbox code to Firefox and it was no easy task.

A few related links:

• https://cs.chromium.org/chromium/src/services/service_manager/sandbox/win/sandbox_win.cc?type=cs&q=AddRule+sandbox&sq=package:chromium&g=0&l=166
• https://cs.chromium.org/chromium/src/sandbox/win/src/filesystem_interception.h?type=cs&sq=package:chromium&g=0

[laszlocsomor]

@rongjiecomputer , thanks for the pointers! We have an open bug for sandbox support (https://github.com/bazelbuild/bazel/issues/5136) but we haven't been able to work on that yet.

[laszlocsomor]

@gennadiycivil : The build works on Linux because of sandboxing. If you disable sandboxing with --spawn_strategy=standalone, the build breaks on Linux too:

  $ bazel build --define absl=1 absl/... --spawn_strategy=standalone
Starting local Bazel server and connecting to it...
INFO: Analysed 204 targets (42 packages loaded, 1882 targets configured).
INFO: Found 204 targets...
ERROR: /usr/local/google/home/laszlocsomor/stuff/abseil-cpp/absl/time/internal/cctz/BUILD.bazel:79:1: undeclared inclusion(s) in rule '//absl/time/internal/cctz:time_zone_format_test':
this rule is missing dependency declarations for the following files included by 'absl/time/internal/cctz/src/time_zone_format_test.cc':
  'absl/strings/string_view.h'
  'absl/base/config.h'
  'absl/base/policy_checks.h'
  'absl/base/internal/throw_delegate.h'
  'absl/base/macros.h'
  'absl/base/port.h'
  'absl/base/attributes.h'e
  'absl/base/optimization.h'
  'absl/types/optional.h'
  'absl/utility/utility.h'
  'absl/base/internal/inline_variable.h'
  'absl/base/internal/identity.h'
  'absl/base/internal/invoke.h'
  'absl/meta/type_traits.h'
  'absl/memory/memory.h'
  'absl/types/bad_optional_access.h'
  'absl/types/variant.h'
  'absl/types/internal/variant.h'
  'absl/types/bad_variant_access.h'
INFO: Elapsed time: 8.772s, Critical Path: 4.63s, Remote (0.00% of the time): [queue: 0.00%, setup: 0.00%, process: 0.00%]
INFO: 83 processes: 83 local.
FAILED: Build did NOT complete successfully

We can fix this problem in one of two ways:

• implement sandboxing on Windows
• merge the Abseil and GoogleTest repos and remove external repo references to each other

In fact I just did that (merging the repos):

1. I looked at the com_google_googletest rule in Abseil's WORKSPACE, downloaded the zip file, extracted it somewhere, copied everything except for the WORKSPACE file into the Abseil source tree.
2. Removed the com_google_googletest from Abseil's WORKSPACE.
3. Removed the strings @com_google_googletest and @com_google_absl from all BUILD* files.

After that I could successfully bazel build --define absl=1 absl/... on Windows.

[gennadiycivil]

Thabk you for the suggestion. googletest is a standalone repo which is
serving thousands of users. We can't just merge it with abseil .

Looks like windows sandboxing would br the answer .

Thanks again
G

On Fri, Nov 9, 2018, 05:03 László Csomor <[email protected] wrote:

@gennadiycivil https://github.com/gennadiycivil : The build works on
Linux because of sandboxing. If you disable sandboxing with
--spawn_strategy=standalone, the build breaks on Linux too:

$ bazel build --define absl=1 absl/... --spawn_strategy=standalone
Starting local Bazel server and connecting to it...
INFO: Analysed 204 targets (42 packages loaded, 1882 targets configured).
INFO: Found 204 targets...
ERROR: /usr/local/google/home/laszlocsomor/stuff/abseil-cpp/absl/time/internal/cctz/BUILD.bazel:79:1: undeclared inclusion(s) in rule '//absl/time/internal/cctz:time_zone_format_test':
this rule is missing dependency declarations for the following files included by 'absl/time/internal/cctz/src/time_zone_format_test.cc':
'absl/strings/string_view.h'
'absl/base/config.h'
'absl/base/policy_checks.h'
'absl/base/internal/throw_delegate.h'
'absl/base/macros.h'
'absl/base/port.h'
'absl/base/attributes.h'e
'absl/base/optimization.h'
'absl/types/optional.h'
'absl/utility/utility.h'
'absl/base/internal/inline_variable.h'
'absl/base/internal/identity.h'
'absl/base/internal/invoke.h'
'absl/meta/type_traits.h'
'absl/memory/memory.h'
'absl/types/bad_optional_access.h'
'absl/types/variant.h'
'absl/types/internal/variant.h'
'absl/types/bad_variant_access.h'
INFO: Elapsed time: 8.772s, Critical Path: 4.63s, Remote (0.00% of the time): [queue: 0.00%, setup: 0.00%, process: 0.00%]
INFO: 83 processes: 83 local.
FAILED: Build did NOT complete successfully

We can fix this problem in one of two ways:

• implement sandboxing on Windows
• merge the Abseil and GoogleTest repos and remove external repo
  references to each other

In fact I just did that (merging the repos):

1. I looked at the com_google_googletest rule in Abseil's WORKSPACE,
   downloaded the zip file, extracted it somewhere, copied everything except
   for the WORKSPACE file into the Abseil source tree.
2. Removed the com_google_googletest from Abseil's WORKSPACE.
3. Removed the strings @com_google_googletest and @com_google_absl
   from all BUILD* files.

After that I could successfully bazel build --define absl=1 absl/... on
Windows.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/bazel/issues/5640#issuecomment-437310804,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMJSMkukP7o75kTLNAAfcPpAaDYAbDCCks5utVLbgaJpZM4VWlmm
.

[rongjiecomputer]

Inspired by @laszlocsomor's solution:

In a WORKSPACE, specify Abseil and GoogleTest as [new_]local_repository or [new_]http_archive (so neither Abseil nor GoogleTest is the main repo __main__) (*), then run bazel test --define absl=1 @com_google_absl//absl/base/.... All tests pass.

I believe (*) is how most Bazel users consume Abseil and GoogleTest (main repo is user's own code). This solution should enable Abseil team to continue their work without breaking existing Abseil and GoogleTest users.

[gennadiycivil]

Thank you for this suggestion!
I am a bit hazy for some reason.... could you please point me to the actual
workspace file to look at?
Thanks again
G

On Fri, Nov 9, 2018 at 9:37 AM Loo Rong Jie [e-mail]
wrote:

Inspired by @laszlocsomor https://github.com/laszlocsomor's solution:

In a WORKSPACE, specify Abseil and GoogleTest as [new_]local_repository
or [new_]http_archive (so neither Abseil nor GoogleTest is the main repo
__main__) (*), then run bazel test --define absl=1
@com_google_absl//absl/base/.... All tests pass.

I believe (*) is how most Bazel users consume Abseil and GoogleTest.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/bazel/issues/5640#issuecomment-437377899,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMJSMrSmlWMgJYIrcwSO0LymG25SPtUuks5utZMZgaJpZM4VWlmm
.

[rongjiecomputer]

Sure thing! See https://github.com/rongjiecomputer/bazel-issue/tree/master/abseil

EDIT: fix cd command.

git clone --depth 1 https://github.com/rongjiecomputer/bazel-issue
cd bazel-issue/abseil
bazel test -c opt --define absl=1 @com_google_absl//absl/...

[laszlocsomor]

Sandboxing on Windows would solve this problem.

[laszlocsomor]

Lack of sandboxing is the culprit of this bug, and @rongjiecomputer is working on https://github.com/bazelbuild/bazel/issues/5136 to address that.

Closing this in favor of https://github.com/bazelbuild/bazel/issues/5136.

[laszlocsomor]

Actually, let's keep this open until sandoxing is done.