[Qt-creator] Qt Creator for Linux Kernel Development

Marco Bubke Marco.Bubke at qt.io
Mon Nov 28 20:49:26 CET 2016



On November 28, 2016 19:03:57 "Jason A. Donenfeld" <Jason at zx2c4.com> wrote:

> Hello All,
>
> Responses to each of you are inline below.
>
> Sounds to me like there's a lot of work to be done, still, and I
> haven't received any enthusiastic responses from the Qt team of, "yes!
> we'd love to work on this and make Qt Creator suitable for kernel
> development!" Bummer. Seems like a great opportunity to increase the
> tool's user appeal.
>
> On Wed, Nov 23, 2016 at 8:45 AM, Konstantin Tokarev <annulen at yandex.ru> wrote:
>> BTW, I'm facing similar issue with QtWebKit: config.h is included into all
>> source files, but never in headers, so all #if's in headers are disabled
>> and code model does not function properly.
>
> Yep, this is pretty much entirely broken. It's not implemented in the
> Qt C++ model, and it straight up does not work in the clang mode
> model. The lack of good support for this feature -- project wide
> -include file -- is pretty limiting.
>
> On Wed, Nov 23, 2016 at 8:58 AM, Orgad Shaneh <orgads at gmail.com> wrote:
>> Which version do you use? Designated initializers support was added in 3.2
>> (c56b999ffff249d4cb7dc7e8026a3297b63ff56d).
>>
>> I now see that the members are not detected correctly (for e.g. Find
>> Usages), but parsing looks ok.
>
> I'm using 4.1. No, it still does not work. Here's a screenshot:
> https://data.zx2c4.com/designated-init-broken-qt-creator-49b6f51f.png
>
>> You can set PRECOMPILED_HEADER = header.h in your pro file. It should be
>> applied to all sources.
>
> Nope, that's certainly not what that field does.
>
> On Wed, Nov 23, 2016 at 10:21 AM, Eike Ziller <Eike.Ziller at qt.io> wrote:
>> Are you using the ClangCodeModel plugin? If not, you probably should.
>> It does not help for things like find usages and locator, since for this we still use the built-in model,
>> and fixes for the built-in model will be very limited.
>> But for working with the individual _source_ file it should at least help.
>> I can even open Objective-C++ files and get decent highlighting and even
>> get some completion for Objective-C ;)
>
> The clang mode model is even more buggy than the built-in one. Not
> only that, but it's an order of magnitude slower too, which makes Qt
> Creator impossible to use. The only viable usage of the IDE is through
> the built-in code model. Hopefully the Qt engineers will put in the
> time to bring it up to par with modern times with -include, and add
> explicit C support...

What is exactly buggy? The code model can handle C but we need that information from the project management. QMake isn't differentiating between C and C++ headers,  so we simply don't get that information. Like other have written there could be workarounds. Anyway it would be interesting what is your environment that makes the clang code model so slow. It's quite fine for me. There is the header guard bug which is vanishing with #pragma once. What are actually your problems? 

>
>> One other issue are header files - there is no way Qt Creator can automatically tell if a
>> .h file is supposed to be C, C++, Objective-C, Objective-C++, ....
>> One hack workaround for C might be to remove *.h from the text/x-c++hdr mime type in Options > Environment > Mime Types,
>> but that would be a big and global hack (if it worked) ;)
>> We could probably provide a project setting for a “default” language to use though, which would then also be sharable with all in the project sources with a .shared file.
>
> A project-wide setting would indeed be most welcome for this.
>
>
> On Wed, Nov 23, 2016 at 5:15 PM, Andrzej Telszewski
> <atelszewski at gmail.com> wrote:
>> I don't remember exactly, but I used some other feature of QtC (Import
>> Project was it?).
>> It allowed to easily setup QtC for kernel development.
>> It worked pretty well, most of the time.
>> Just a quick search:
>> http://stackoverflow.com/questions/5417732/howto-prepare-qtcreator-for-linux-driver-kernel-development
>
> The solution listed here is basically wrong and doesn't work. The code
> model won't actually parse that #include properly.
>
>>
>> I too remember seeing false errors when code model parsed struct members
>> initializers.
>>
>> But this code seems to work just fine now:
>
> Try something slightly more complicated and it totally blows up again.
> See the linked screenshot above.
>
>> And yes, although I'm not going to be involved in enhancing QtC, I would
>> love to see C receiving decent support.
>> QtC is my main (well, the only) IDE, and I write both C and C++ code.
>
> If only the Qt developers cared about this too. Missed opportunity IMHO.
>
> Jason
> _______________________________________________
> Qt-creator mailing list
> Qt-creator at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qt-creator


More information about the WireGuard mailing list