Reputation: 3695
I have a Bazel project (the new tcmalloc) I'm trying to integrate into a typical GNU Make project that uses it's own build of compiler/libc++. The goal is to not fork the upstream project.
If I pass all the C++ options correctly to bazel (one set of which is -nostdinc++ -I<path to libc++>
), Bazel is uhappy The include path '/home/vlovich/myproject/deps/toolchain/libc++/trunk/include' references a path outside of the execution root.
(tcmalloc is a git submodule sibling @ deps/tcmalloc
). It's possible to get this "working" by giving Bazel a custom script to invoke as the compiler that injects those flags so that Bazel never sees them. However, I'd like to just define a toolchain to work properly.
I've read all the documentation I could find on this topic but it's not clear to me how to glue all these docs together.
Specifically not really clear where I should place the toolchain definition files or how to tell Bazel to find those definitions. Is there a way to give bazel a directory that it uses to find toolchain definitions? Am I expected to create a top-level WORKSPACE @ /home/vlovich/myproject
& register tcmalloc
and my toolchain there, & then invoke bazel from /home/vlovich/myproject
instead of /home/vlovich/myproject/deps/tcmalloc
?
Upvotes: 1
Views: 385
Reputation: 1304
Toolchain support is rather complicated, and it is hard to understand, if you are not a bazel maintainer.
You can use CC
and CXX
environment variables to set a different compiler like: CC=your_c_compiler CXX=your_c++_compiler bazel build ...
. You can write your own custom script wrapper which will act as a normal C++ compiler
That -I<path to libc++>
does not work, because all normal include paths have to be defined in srcs
attribute or via dependencies indicated by the deps
attribute. For system-wide dependencies use -isystem
Read more about it https://stackoverflow.com/a/44061589/4638604
Upvotes: 0