[Qt-creator] Few random questions regarding QTC hacking

[Eike Ziller]

> On Mar 19, 2020, at 15:02, jeandet <alexis.jeandet at member.fsf.org> wrote:
> 
> Hi,
> 
> I started this week to look at QTC code(master branch) to try writing a
> meson build plugin from scratch. I've alredy played with QTC code base
> in the past but long time ago and using qmake.
> 
> So first question, is CMake build ready to use?

In principle yes, many devs use the CMake build now (including me). But see Tobias’ comment about Clang 8.

If you are developing a separate plugin, you need to point the CMAKE_PREFIX_PATH to Qt Creator (as well as Qt).
And you need to run Qt Creator with “-pluginpath <path_to_your_plugin_lib>” for Qt Creator to pick it up (if you don’t copy the plugin into one of Qt Creator’s default search paths).

> Looks like no. At least
> clang detection/link looks broken:
> 
> - with clang 10(packaged) all libs are merged in one so I get loads of:
> /usr/bin/ld: cannot find -lclangTooling
> /usr/bin/ld: cannot find -lclangQuery
> ....
> /usr/bin/ld: cannot find -lclangTooling
> /usr/bin/ld: cannot find -lclangQuery
> 
> - with clang 9(self built) I get this error while linking
> clangrefactoringbackend:
> 
> "/opt/llvm-9/lib/libLLVMSupport.so.9: error adding symbols: DSO missing
> from command line"
> 
> Because it ads libraries as if they were objects:
> 
> /usr/bin/c++     CMakeFiles/clangrefactoringbackend.dir/clangrefactorin
> gbackend_autogen/mocs_compilation.cpp.o
> CMakeFiles/clangrefactoringbackend.dir/clangrefactoringbackendmain.cpp.
> o  -o ../../../libexec/qtcreator/clangrefactoringbackend  -Wl,-
> rpath,"\$ORIGIN/../../lib/qtcreator:/opt/llvm-
> 9/lib:/home/jeandet/Documents/prog/build-qt-creator-Desktop-
> Debug/lib/qtcreator:"
> ../../../lib/qtcreator/libclangrefactoringbackend_lib.a -lpthread
> /opt/llvm-9/lib/libclang.so.9 /opt/llvm-9/lib/libclangHandleCXX.so.9
> /opt/llvm-9/lib/libclangIndex.so.9 /opt/llvm-9/lib/libclangTooling.so.9 
> /opt/llvm-9/lib/libclangQuery.so.9 /opt/llvm-
> 9/lib/libclangDynamicASTMatchers.so.9 /opt/llvm-
> 9/lib/libclangFrontend.so.9 /opt/llvm-9/lib/libclangSerialization.so.9
> /opt/llvm-9/lib/libclangASTMatchers.so.9 /opt/llvm-
> 9/lib/libclangAST.so.9 /opt/llvm-9/lib/libclangLex.so.9 /opt/llvm-
> 9/lib/libclangBasic.so.9 /opt/llvm-9/lib/libLLVMCore.so.9
> ../../../lib/qtcreator/libClangSupport.so.4.11.83
> ../../../lib/qtcreator/libSqlite.so.4.11.83
> ../../../lib/qtcreator/libUtils.so.4.11.83
> /usr/lib64/libQt5Concurrent.so.5.13.2 /usr/lib64/libQt5Qml.so.5.13.2
> /usr/lib64/libQt5Widgets.so.5.13.2 /usr/lib64/libQt5Gui.so.5.13.2
> /usr/lib64/libQt5Network.so.5.13.2 /usr/lib64/libQt5Core.so.5.13.2
> -Wl,-rpath-link,/opt/llvm-9/lib
> 
> 
> Second question, is #qt-creator:matrix.org bridged with IRC chan? Where
> can I reach devs?

#qt-creator on freenode.net
No idea what matrix.org is.

> 
> Third question, I saw a mail about Python support in QTC, from the
> answer it looks like we can't write a QTC plugin in Python. Is it one
> goal to allow python plugins? 

There are many open questions regarding that. We have an experimental plugin adding support for “extensions” written in python, but 1. only a minimal API was exported, 2. nobody continued on that approach.
Basically:

1) Allowing to use python would remove the barrier of creating binary releases of custom plugins
2) It would on the other hand make API compatibility issues even greater than in C++ (no compiler errors/warnings)
3) Someone would need to maintain the bindings

In the light of build services existing out there (e.g. we added a configuration for Github Actions to the plugin wizard), the of advantage of number 1) with python is lessened.

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
eike.ziller at qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B