The-OpenROAD-Project
Bazel build fails with local cmake cruft in source folder
Description
Add some cruft(left over from ./build_openroad.sh or CMake plugins in vscode or something) that breaks the build:
echo >src/sta/include/sta/StaConfig.hh \#error asdlkf
bazel test -c opt ...
ERROR: /home/oyvind/OpenROAD-flow-scripts/tools/OpenROAD/BUILD.bazel:158:11: Compiling openroad_swig.cc failed: (Exit 1): cc_wrapper.sh failed: error executing CppCompile command (from target //:openroad_lib) external/toolchains_llvm~~llvm~llvm_toolchain/bin/cc_wrapper.sh -U_FORTIFY_SOURCE '--target=x86_64-unknown-linux-gnu' -U_FORTIFY_SOURCE -fstack-protector -fno-omit-frame-pointer -fcolor-diagnostics ... (remaining 1345 arguments skipped)
Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
In file included from bazel-out/k8-opt/bin/openroad_swig.cc:1711:
In file included from src/dbSta/include/db_sta/dbSta.hh:13:
In file included from src/sta/include/sta/Sta.hh:33:
In file included from src/sta/include/sta/GraphClass.hh:34:
In file included from src/sta/include/sta/Delay.hh:27:
src/sta/include/sta/StaConfig.hh:1:2: error: asdlkf
1 | #error asdlkf
| ^
1 error generated.
Use --verbose_failures to see the command lines of failed build steps.
Now try to debug:
$ bazel query 'rdeps(//..., src/sta/include/sta/StaConfig.hh)'
ERROR: Evaluation of query "rdeps(//..., src/sta/include/sta/StaConfig.hh)" failed: preloading transitive closure failed: no such package '@@[unknown repo 'openssl' requested from @@boost.asio~]//': The repository '@@[unknown repo 'openssl' requested from @@boost.asio~]' could not be resolved: No repository visible as '@openssl' from repository '@@boost.asio~'
Suggested Solution
No response
Additional Context
No response
To see which local files exist other than those git status reports:
git ls-files --ignored --exclude-standard --others
@hzeller @QuantamHD This sheds some light on why we get varying results reports when one tries to build with bazel locally.
In https://github.com/parallaxsw/OpenSTA/pull/230 I fixed that OpenSTA writes the StaConfig.hh into the source tree but instead puts into its build/ file, and it should already be merged.
So now, there should be no StaConfig.hh ending up in the source tree anymore. Maybe it is from before that fix was merged ?
In https://github.com/parallaxsw/OpenSTA/pull/230 I fixed that OpenSTA writes the StaConfig.hh into the source tree but instead puts into its build/ file, and it should already be merged.
So now, there should be no StaConfig.hh ending up in the source tree anymore. Maybe it is from before that fix was merged ?
Yes: but why would this make the build fail?
Shouldn't Bazel be immune to this?
I noticed the same. I'm guessing a wildcard matches it
That is what I thought, but the glob() found did not fix it with and exclude arg and the query above to find it fails. Curious.
well, bazel generates a StaConfig.hh, but there are now two locations where it is: the generated file that bazel builds (in its bazel-bin/ somewhere), but also the stray one that was copied by the rogue process in the source src/sta directory. And whatever file includes it is not using a fully qualified name, but relies on the compiler that follows the -I paths -- of which there are a myriad currently as there a bunch of includes = [] configuratins.
For bazel for it to be immune, it would have to look for every file and and every -I to see if there is no such file. Right now that would almost be impossible due to the lack of using project-relative includes, so due to a lot of includes = [] clauses, now src/sta/ is part of the list of things in -I.
Once we can leave cmake behind, we can improve the project structure to not have every subdirectory in the -I paths...
@hzeller I still dont understand how a file in the source folder can cause problems if it is not in enumerated by a glob()
The failing query stopped me from digging further.
StaConfig.hh is generated by the :StaConfig which is a dependency of :opensta_lib. It provides the header StaConfig.hh and set up to be found. So the compiler makes sure that that is found.
If there is also a StaConfig.hh in the src/sta directory, this is picked up by the compiler as that directory is part of the includes= [] set. This is why it causes problems.
@hzeller I modified the glob() of src/sta to exclude StaConfig.hh, still I got an error, to my surprise.
it is not the glob. It is the overly wide
-Istatements.
I believe you, I am just not able to connect the dots: how can the build see a file that is not explicitly listed/globbed and symlinked into the build dir?
you don't build the file, as it is not part of any srcs = [].
It is #include-ed somewhere and as such found in the include search path.
Once we can leave cmake behind, we can improve the project structure to not have every subdirectory in the -I paths...
you could do the same in cmake so you don't have to wait though it be less work later
Isnt this also part of the problem?
A string list of include folder names that through shenanigans, link below, -I are added directly into the source folder?
Is the solution to explcitly list/glob all files as labels and add them as data for the action and then point -I statements to the folder of the explicitly listed files?
https://github.com/The-OpenROAD-Project/OpenROAD/blob/2511a476202575ce2f701063f03fe2b6faa949d5/bazel/tcl_wrap_cc.bzl#L123