D5491: Improve detection of builtin defines from compiler command

Aaron Puchert noreply at phabricator.kde.org
Sun Aug 13 19:44:37 UTC 2017

aaronpuchert added inline comments.


> gcclikecompiler.cpp:45
> -QStringList languageOptions(const QString& arguments)
> +QStringList languageOptions(const QStringList& arguments)
>  {

This function is pretty complex and full of hacks, even before this change. But what bothers me most: why do we try to guess the language here?

As far as I can see, it's only used in `GccLikeCompiler::defines` and `GccLikeCompiler::includes`, which are used in `CompilerProvider::defines` and `CompilerProvider::includes`, respectively. But there we know the language (it's just `languageType`), so why do we try to detect it again?

I think this can be made a lot easier by redesigning some of the methods a bit.

> gcclikecompiler.cpp:63
> +                language = minusXCL();
> +            } else if (standardVersion.startsWith(QLatin1String("cuda"))) {
> +                language = minusXCuda();

There is no standard beginning with `cuda`, as far as I know. (See the Clang documentation <http://clang.llvm.org/docs/UsersManual.html#differences-between-various-standard-modes>.) It seems that Cuda just uses the already known C and C++ standards, if we are to believe the comments in D5210: Proper CUDA handling <https://phabricator.kde.org/D5210>. I don't think we can detect Cuda from the arguments, but I also think we don't need to. (See my other comment.)

  R32 KDevelop


To: arichardson, #kdevelop, kfunk, mwolff
Cc: skalinichev, aaronpuchert, kdevelop-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20170813/14f0bf08/attachment.html>

More information about the KDevelop-devel mailing list