Qt5/Mac header finding in KDevelop5 (clang parser??)
mail at milianw.de
Wed Jun 22 09:24:27 UTC 2016
On Tuesday, June 21, 2016 7:11:19 PM CEST René J.V. Bertin wrote:
> On Tuesday June 21 2016 17:36:14 Milian Wolff wrote:
> Quick reply to "please show your paths": the -isystem and -I ones are all
> there. As I said before, this is not a problem of an incomplete path; it
> seemed as if certain components of that path were being ignored.
> I think I am beginning to understand what is happening here, and it's a bit
> of an annoying reason as I don't really see how to work around it (somewhat
> "above my pay grade").
> So CMake adds a `-iframework /opt/local/libexec/qt5/Library/Frameworks`
> argument in addition to -isystem key,value pairs for each framework in
> there. That should be enough for code that includes its headers the way
> that Apple foresaw (and it is as long as there's no -isysroot argument, but
> let's forget that for now).
> So, code that includes the main header from, say, the QtGui *framework
> bundle* would do
> #include <QtGui/QtGui> (or using #import for ObjC code)
> This would fetch QtGui/QtGui.framework/Headers/QtGui (or, with my install on
> Linux, /opt/local/include/qt5/QtGui/QtGui provided that something like
> `-isystem /opt/local/include/qt5` has been given).
> Evidently most Qt code isn't so (ahem) well-behaved, and just does `#include
> <QtGui`, which is why `-isystem
> /opt/local/libexec/qt5/Library/Frameworks/QtGui.framework/Headers` is
> So I spent some time hacking together support for -iframework in
> MakeFileResolver::processOutput(). And then I noticed an error in the
> problem reporter (which annoyingle cannot be copied to the clipboard):
> 'QtCore/qnamespace.h' file not found // Semantic analysis //
> .h // 37 // 10
> Aha! Indeed, cmake generates no -I, -isystem or other key,value pair that
> allows to resolve <QtCore/qnamespace.h>, except that famous -iframework
> argument which is understood by compilers on OS X. Evidently it is enough
> to add a custom /opt/local/include/qt5 header search path ...
> I see only 1 proper fix for this. ParseSessionData::ParseSessionData() (that
> one again :)) or an equivalent method needs to receive the -iframework (and
> the "user" equivalent -F) paths and add the corresponding key,value pairs
> to clangArguments. I just don't know how to get that list in there.
Extend the DefinesAndIncludeManager and make it aware of frameworks. Please
keep this ifdefed to macOS, as I don't want to pollute that already complex
dialog on platforms that don't care about this mac-only feature.
mail at milianw.de
More information about the KDevelop-devel