Open philipcraig opened 5 years ago
Nice work!
Also looked into what successful bazel windows builds (the one that ships with bazel) look like.
bazel print_action //examples/cpp:hello-lib
outputs a bunch of things. The main thing I notice is that Bazel knows which steps are doing C++ things (mnemonic: "CppCompile"
), so sets up the PATH
and INCLUDE
variables correctly. Wonder if ffig bazel windows version needs to mark its tasks that use libClang as cpp tasks in some way.
Now also wondering if all this is because (at least) ffig.bzl
has hard-coded Linux specific things
Which are the hard-coded Linux things?
Hi, to backtrack a little, perhaps the bazel task that runs FFIG.py
should become a C++ Bazel task. This is so that the Bazel will set up the correct C++ environment on Windows, bringing the INCLUDE
dir in. This could be done via something like here https://stackoverflow.com/q/52769846/105050, making the call to FFIG.py
use the cc_common API.
The story so far. On Windows, bazel ffig builds fail. e.g.
bazel build --verbose_failures //:Shape.net.src
produces:The errors in the above are related to not finding libclang.dll (as the path to LLVM has been removed from the path) and then (if this is manually corrected) not finding the
<cmath>
include file, as Visual Studio is also not being set by Bazel in the above. I suspect that on Linux/Darwin, gcc/clang have the location of their include files encoded into their binaries, so that they can always be found, whereas Windows doesn't.Investigations continue into why bazel is shortening the path so much on Windows and how this can be cirvumvented