Failing to build Boost components locally with Bazel build - boost

Question

I am trying to build Boost library locally and want to use it as a local_repository in my own project. I am referring to this (https://github.com/nelhage/rules_boost) for help.
I have a directory tree like this:
boost/ // root of the boost project
|
bazel/
| |
| boost.bzl // contains "boost_library" function from https://github.com/nelhage/rules_boost/blob/master/boost/boost.bzl
| |
| BUILD // empty
boost/ // the original boost headers folder from original boost dist
|
lib/ // the original boost sources folder from original boost dist
|
BUILD
|
WORKSPACE
The BUILD file looks like this one:
https://github.com/nelhage/rules_boost/blob/master/BUILD.boost
with properly loading boost.bzl
The WORKSPACE is just:
workspace( name = "boost" )
The issue:
Now I am trying to build individual components (bazel build //:<component>).
Some of the components (Boost.Container, Boost.Test) are failing to build for a similar reason (not finding header files).
bazel build //:container 1 ↵
INFO: Found 1 target...
ERROR: /home/spyder/codebase/boost/BUILD:103:1: C++ compilation of rule '//:container' failed: Process exited with status 1 [sandboxed].
libs/container/src/global_resource.cpp:12:51: fatal error: boost/container/pmr/memory_resource.hpp: No such file or directory
compilation terminated.
Use --strategy=CppCompile=standalone to disable sandboxing for the failing actions.
Target //:container failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 0.519s, Critical Path: 0.18s
bazel build //:test 1 ↵
INFO: Found 1 target...
ERROR: /home/spyder/codebase/boost/BUILD:581:1: C++ compilation of rule '//:test' failed: Process exited with status 1 [sandboxed].
libs/test/src/junit_log_formatter.cpp:11:51: fatal error: boost/test/impl/junit_log_formatter.ipp: No such file or directory
compilation terminated.
Use --strategy=CppCompile=standalone to disable sandboxing for the failing actions.
Target //:test failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 1.027s, Critical Path: 0.82s
Can anyone guide me on fixing it ?
EDIT:
I also tried to query the expanded cc_library rule by bazel query --output=build //:container and got this
cc_library(
name = "container",
visibility = ["//visibility:public"],
generator_name = "container",
generator_function = "boost_library",
generator_location = "/home/spyder/codebase/boost/BUILD:103",
licenses = ["notice"],
deps = ["//:config", "//:core", "//:intrusive", "//:move"],
defines = [],
includes = ["boost/container/"],
copts = ["-Wno-unused-value"],
srcs = ["//:libs/container/src/alloc_lib.c", "//:libs/container/src/dlmalloc.cpp", "//:libs/container/src/dlmalloc_2_8_6.c", "//:libs/container/src/dlmalloc_ext_2_8_6.c", "//:libs/container/src/global_resource.cpp", "//:libs/container/src/monotonic_buffer_resource.cpp", "//:libs/container/src/pool_resource.cpp", "//:libs/container/src/synchronized_pool_resource.cpp", "//:libs/container/src/unsynchronized_pool_resource.cpp"],
hdrs = [ ....... , "//:boost/container/pmr/map.hpp", "//:boost/container/pmr/memory_resource.hpp", "//:boost/container/pmr/monotonic_buffer_resource.hpp", "//:boost/container/pmr/polymorphic_allocator.hpp", ........ ],
)
Very shockingly, the source file which is complaining (libs/container/src/global_resource.cpp) and the header that it is complaining about (boost/container/pmr/memory_resource.hpp) are both correctly included in the srcs and hdrs list.

Answer 1

I played with your rules a bit and the biggest problem I see is incomplete dependencies. For example I tried :algorithm component, and that needs to depend on :tuple. I guess you just needs to make sure all dependencies are set correctly.
I played more with container, and the problem I encountered was incorrect include dirs. If you run your build with -s flag, bazel will output all the command lines so you can inspect them and check that -isystem flags contain the directory that contains boost/container/... . What can also help you is the bazel flag --sandbox_debug, which will prevent the sandbox directory from being deleted so you can see which files are where and also you can reproduce the compiler invocation without running through bazel.
Last, bazel does not understand .ipp header extension yet (tbh I've never heard of it, but I also know next to nothing about boost). I have a change in flight that will introduce this.