This is an archive of the discontinued LLVM Phabricator instance.

Rename llvm/utils/TableGen/X86ManualFoldTables.def to .inc
AbandonedPublic

Authored by chapuni on Apr 6 2023, 7:11 AM.

Details

Summary

Unfortunately, Bazel doesn't accept .def as header fragments in cc_binary.
(Corresponding to CMake's add_executable)
In addition, .def is sometimes used to Win32's module definitions.

Could you avoid using .def here?

Note, Bazel's cc_library may accept header files with any suffix.

Diff Detail

Event Timeline

chapuni created this revision.Apr 6 2023, 7:11 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 6 2023, 7:11 AM
chapuni requested review of this revision.Apr 6 2023, 7:11 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 6 2023, 7:11 AM
skan added a comment.Apr 6 2023, 7:05 PM

Hi @chapuni, why does the .def file here bother you? I can see many .def files in textual_hdrs of utils/bazel/llvm-project-overlay/llvm/BUILD.bazel.

Since Bazel is not a generally-supported build system, we shouldn't be making changes to the source solely for the benefit of the Bazel build system. I do find it a bit weird that LLVM uses the ".def" extension for these files, given that it's the extension for MSVC module definition files, but the usage appears to be widespread in the project, so I don't think it makes sense to just change this one file unless there's something that distinguishes it from the others outside of how Bazel feels about it.

chapuni abandoned this revision.Apr 9 2023, 1:32 AM

@GMNGeoffrey This was the first change to add .def to the executable, aka cc_binary, AFAIK.
I wanted to stop it since it was the first issue that was added recently.

I know we shouldn't work something for the convenience of bazel.
As you can guess, "Win32's module def" was just my 2nd excuse.

I think since rGff1b820c7d0cd46f024c0d93a0994e6f5996cc16 is sufficient, I would make adding header libraries in the future for similar issues.