Passing all of the extra build flags though to the compiler detection of
includes and defines allows for flags like -nostdinc, -nostdinc++, -std=,
and --sysroot= from the build manager to override what is picked
automatically. The flags from the build manager are sanitized to those
which are known to affect includes and defines and are supported by both
clang and gcc. These sanitized flags go at the end and override any
defaults.
Details
Details
- Reviewers
- None
- Group Reviewers
KDevelop
It appears difficult to test anything involving the build manager at the moment.
Let me know if it makes sense to add a TestBuildManager.
Diff Detail
Diff Detail
- Repository
- R32 KDevelop
- Branch
- nostd (branched from master)
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 13828 Build 13846: arc lint + arc unit
| plugins/custom-definesandincludes/compilerprovider/gcclikecompiler.cpp | ||
|---|---|---|
| 42–45 ↗ | (On Diff #61040) | I don't think we need this, since later options always overwrite earlier ones. So if the build system should specify the language manually (which is very unlikely, I've never seen that), and we end with something like -xc -xc++, then the latter option overrides the former and the file is read as C++. Both Clang and GCC do that: $ clang -fsyntax-only -xc -xc++ - <<<'class X {};' $ gcc -fsyntax-only -xc -xc++ - <<<'class X {};' |
| 75–80 ↗ | (On Diff #61040) | The same applies here. |
| 118 ↗ | (On Diff #61040) | This is a substantial change, and it's pretty hard to estimate the impact. I'm not sure we can just pass on all arguments without further looking into them, given what can be done with compiler arguments. This might work for some projects, but break others. I haven't written this code (although I've worked on it), but I think that if we could just pass the build system arguments one-to-one to the libclang parser, it would have been done that way in the first place. We'd probably be better of if we continued the whitelisting approach, unless we want to be flooded with bug reports when this hits the shelves. |
Comment Actions
Overall I think this is a good idea, although we need to figure out some details. Could you either remove commented out flags or add a comment why we have them (commented out)?
| plugins/custom-definesandincludes/compilerprovider/gcclikecompiler.cpp | ||
|---|---|---|
| 100 ↗ | (On Diff #61040) | Since we pass them to the Clang parser, they need only be supported by Clang, and if supported by both compilers, they should have the same semantics. |
| 102–103 ↗ | (On Diff #61040) | Clang has these two with a single dash. For GCC I can find only -nostdlib. I didn't try it though. |
| 104 ↗ | (On Diff #61040) | Clang seems to have -i[[framework]with]sysroot, but not --sysroot. |
| 110 ↗ | (On Diff #61040) | How does this affect includes? |
| 116 ↗ | (On Diff #61040) | I haven't seen a build system set this. Why would it do that? The file type is usually inferred from the file ending, so you can just use the proper file ending. |
| 126–127 ↗ | (On Diff #61040) | Some other -f flags are good candidates, e.g. -fexceptions, -fgnu-keywords, -f[no-]signed-char, -ftrigraphs, -fwritable-strings (although the latter two are perhaps not so important), or those enabling language features, like -fmodules[-ts], -fcoroutines-ts. |
| 145–146 ↗ | (On Diff #61040) | Why did you break here before the brace? |
Comment Actions
I've just stumbled into a case where I would need -stdlib=libc++, which this change would solve.