[Qt-creator] Few random questions regarding QTC hacking

[jeandet]

Hi Eike and Tobias,

Thank you for your answers.

On Fri, 2020-03-20 at 08:28 +0000, Eike Ziller wrote:
> > 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.
Ok, I checked afterward Fedora's QTC RPM sources, it uses clang9 and
builds with qmake on FC31:
https://src.fedoraproject.org/rpms/qt-creator/blob/f31/f/qt-creator.spec#_108
uses clang 10 and builds with qmake and this patch on FC32:
https://src.fedoraproject.org/rpms/qt-creator/blob/f32/f/0001-Link-against-libclang-cpp.so.patch

It works well on fc31 except known Wayland issues, fc32 no but it's a
beta...

For CMake, yeah, I gave up with self built(on my laptop...) clang9 and
linking against libclang-cpp works well.
> 
> 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).
Thanks for the tip, I did "in source" for now with the hope that it
could eventually go upstream :).
I'm really motivated to get this done, I really want to switch my
projects to Meson only and stay on QTC.
And coronavirus stuff in France gives me a lot of time...
> 
> > 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/clangrefact
> > orin
> > 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.
Yeah that's a big issue I would say, binary distribution of plugins is
big pain without market place. I can't say for sure but I would be
tempted to say that VS Code success might come from market place + JS
usage. 

I switched to VS Code this week because QTC is broken on FC32 and I
have to say that it's quite amazing to see that they have at least 2
extensions available for most search in market place.

So I wonder what would be the effect of lowering the barrier for QTC
would we see tons of plugins with few nice stuff? Or QTC would still be
niche IDE? Would opening QTC to Python (PyPi) ecosystem unlock many
nice features? 

Also contributing to Qt or Qtc is way more complex than a simple PR on
github or uploading and extension on VS Code market place.

> 
> -- 
> 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
>