search

hedronvision / bazel-compile-commands-extractor

Goal: Enable awesome tooling for Bazel users of the C language family.
Other
659 stars 109 forks source link

cuda_rules triggers assert "Something went wrong in makefile parsing to get headers. The target should be an object file." #181

Open axbycc-mark opened 5 months ago

axbycc-mark commented 5 months ago

I'm using the cuda_rules https://github.com/bazel-contrib/rules_cuda project to generate a cuda_library target. Running :refresh_all triggers the assert here https://github.com/hedronvision/bazel-compile-commands-extractor/blob/4689147cf4b1c2d507fd8bbb8eb748a7bbaad4ef/refresh.template.py#L176C45-L176C102.

The function documentation mentions this clang or gcc. Parse a set of headers from the contents of a*.ddependency file generated by clang (or gcc)

On my system, it is somehow encountering an nvcc generated file, erroring out with the following.

Something went wrong in makefile parsing to get headers. The target should be an object file. Output:
Failed to run D:/TMP/marki/tmpxft_00007f68_00000000-2.bat (The directory name is invalid.

).
nvcc fatal   : Could not set up the environment for Microsoft Visual Studio using 'D:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.39.33519/bin/HostX64/x64/../../../../../../../VC/Auxiliary/Build/vcvars64.bat'

Commenting out the assert, and just returning empty set() here allows the :refresh_all to seemingly generate a correct (or at least very usable) compile_commands.json.

PhamLeHai commented 2 months ago

I have a similar issue, but it was due to some .d files are not in the expected format of target.o: dependencies.

In my case, a library has a .d file like:

-no-canonical-prefixes: external/s2n~/crypto/s2n_aead_cipher_aes_gcm.c \
  external/openssl~/include/openssl/aes.h \

After reading that part of the code, it seems the target is unused, so I commented out the assert from the template file. The command works after the fix.