Lots of "fatal error ... something.cppmap not found" #83
Comments
|
Hey! Thanks for writing in. Definitely unexpected--and not something I've seen yet. Any chance I could get some more details on the error messages? Like maybe copy some in so I can see? Any idea what flags might be causing them--or any other error messages? If you run a build and then rerun, do they go away? (making sure that the build and extraction are done with the same flags). Cheers, |
|
Here is the repo. If you open it in VSCode, it will auto-build a Docker image with a reproducible environment (otherwise you can also use the https://github.com/HappyCerberus/meetingcpp22-bazel It does go away on subsequent runs. Note that the compilation error is expected, the repository has examples that deliberately do not compile: |
|
I should also note that this is for a conference talk so it's a combination of pre-release Bazel + plenty of features turned on (therefore can totally be a Bazel bug). |
|
Thanks! Honored to be included in the code for your talk. Thanks for helping teach people! We use Bazel rolling, too. I'm think I know what is causing this and how to fix it.
To test: Could I ask you to If so, I'll fix this problem by automatically toggling off that feature while analyze Bazel's action graph, just like we do for param files on Windows. |
|
Actually, to save a round trip, I've just pushed the change that I think will fix the problem. Could I still have you run the test above, still rm'ing, but grabbing the latest commit of this tool rather than manually removing layering_check from your bazelrc? That'll tell us whether the fix worked! Also, to satisfy my curiosity, could I ask you to also confirm (before doing the checks above) that (1) the module map files do indeed not exist (bazel cleaning them away if they do) and (2) when they don't exist, checking whether or not clangd shows errors in the editor about the missing module maps? They'd probably show up under a red squiggly at the very first character of the file and in the error panel. This is super helpful because it'd inform future decisions around how we support modules. |
|
Perfect, thank you. Your intuition was indeed correct, I can confirm that manual delete + disabling layering fixed it and the updated version does as well. I'm still seeing one more unexpected error if you are interested in digging further :-D |
|
Great! Glad we could get that fixed for you. Thanks for reporting and checking. Did you get a chance to check whether the previous error showed up in the red squiggly – before the fix? I'll take a look at the other one when I get a chance. It looks emscripten specific. As always, any more errors or context would be handy. Any idea how that file is normally created or where it actually is? My guess is that that's the compiler, and we're trying to invoke it to get headers, but that the compiler indeed does not exist yet. |
|
Have reproduced this new issue. let me see if I can figure out what's going on :) |
|
Oh, boy, okay, something slightly different. What's happening is that the emscripten wrapper is dependent on environment variables that this (v annoying) bazel bug stops us from getting, unfortunately. |
|
Hey, @HappyCerberus. I worked on this a bit more, and I think I've now gotten things working for emscripten. (you were the first to ask!) It took a bit of doing, since emscripten is set up to be so reliant on all its environment variables...and that Bazel bug means we'd have to reconstruct them all. So instead I took the approach of instead calling clang or gcc for header extraction. I think that'll make things work (so I'm going to optimistically close), but I'd love it if you'd Cheers, |
|
This fell through the cracks on my side, but I can finally confirm that this is fixed. Thanks again! |
|
Great! You're very welcome. Thanks for getting back to me. Happy coding! |
ngiloq6
added a commit
to ngiloq6/bazel-compile-commands-extractor
that referenced
this issue
Aug 17, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This does not seem to cause issues, but when I run the command to generate the compilation database, I get a lot of these errors (several pages).
Since this isn't mentioned in the documentation, I'm just curious if this is expected.
The text was updated successfully, but these errors were encountered: