Some projects use -nostdinc, but need to access some intrinsics files when building specific files. The new -builtininc flag lets them use this flag when compiling these files to ensure they can access Clang's builtin headers.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/include/clang/Driver/Options.td | ||
---|---|---|
503–504 | I think -ibuiltininc might be better, since we already have lots of options that start with -i related to include paths. Please also clarify in the HelpText that this overrules -nostdinc even if -nostdinc comes later. | |
clang/lib/Driver/ToolChains/Darwin.cpp | ||
1885–1890 | It's probably better to let -ibuiltininc and -nobuiltininc cancel each other out, via a "last one wins" rule. If you agree, consider documenting the behaviour also in the HelpText. |
Add suggested changes. The -ibuiltininc flag now interacts with -nobuiltininc as well, i.e. it's cancelled out if -nobuiltininc comes after it, and vice-versa.
Unfortunately they can't control the flag in this specific case, only add flags for specific files.
To make sure I understand it correctly.
There is a project using -nostdinc. It still accesses intrinsics headers, so -ibuiltininc is added to make it work. The new option requires a new release of clang. Is it really more convenient adding a new option than teaching the project to use -nostdlibinc instead of -nostdinc?
I think -ibuiltininc might be better, since we already have lots of options that start with -i related to include paths. Please also clarify in the HelpText that this overrules -nostdinc even if -nostdinc comes later.