Hi,
I'm also using clazy creating new checks and fix it to ease the transition to 
Qt6 following https://bugreports.qt.io/browse/QTCREATORBUG-23750.
My fork is here: https://github.com/lugerard/clazy.

I'm using macOS. Clazy only work if using llvm 8 installed from macport and if 
the path to the cpp libraries (in  
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/)
 is explictly passed to clazystandalone call.

Cheers,
Lucie

------------------------------------------------------------------------
The Qt Company GmbH
Berlin-Erich Thilo Str
D-12489 Berlin<http://qt.io>

Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B


________________________________
From: Development <development-boun...@qt-project.org> on behalf of Shawn 
Rutledge <shawn.rutle...@qt.io>
Sent: Tuesday, June 9, 2020 10:29 AM
To: Qt development mailing list <development@qt-project.org>
Subject: [Development] Using clazy to build Qt and Qt-based projects

Since https://codereview.qt-project.org/c/qt/qtbase/+/303079 landed, there are 
a lot of deprecation warnings.  I’ve been using clazy to fix them, as in 
https://codereview.qt-project.org/c/qt/qtbase/+/303079 and 
https://codereview.qt-project.org/c/qt/qtsvg/+/303448. To make that possible, I 
added a qevent-accessors check to it, which is currently on the tip of my fork: 
 https://github.com/ec1oud/clazy. I plan to try to upstream that change.  But 
there might end up being more things that need to be done with QEvent 
accessors, so maybe it’s a little early to finalize what changes this 
particular qevent-accessors check will suggest.

A clazy check just generates more warnings in general; but it can also include 
replacement text (a source code change).  Most pre-existing checks do not yet 
include fixes, but IMO it’s much more useful if it does include a “fixit”, 
because that can be automatically applied.  You can see in my patch how I did 
that.  Discovering llvm APIs isn’t so straightforward for me yet, but at least 
I figured out how to do that sort of renaming in a way that doesn’t generate 
false positives.

As explained in the commit messages, if you run cmake you can specify 
-DCMAKE_CXX_COMPILER=/usr/bin/clazy ; if you run qmake you can configure with a 
clang platform, -no-pch QMAKE_CXX=clazy.  At least using it as a compiler 
wrapper is one way; there’s also clazy-standalone, but I was not having as much 
luck with that so far.  You want your build to include tests and examples too, 
so that they get checked (and fixed, to the extent possible).  Don’t use 
icecream or ccache, because it will bypass clazy.  The clazy-suggested fixes 
will generate a bunch of *.clazy.yaml files in the source tree (even if you are 
doing a shadow build, which I recommend, the yaml files go to the source 
directories).  Then you can go to the top of the module source and 
clang-apply-replacements . to apply those to the source files; git add -p to 
verify that each change is really a good one (and appropriate to be grouped in 
one patch); generate a commit and push it.  (The yaml files specify changes 
using byte offset, length, and replacement text, so that’s ephemeral obviously.)

I already generated patches for several more Qt 6 modules to take care of those 
event accessor deprecations so far.  But maybe it’s a good practice to do more 
of this, rather than applying API changes by hand.  When we add features to 
clazy, we will make it easier for users to port their code from Qt 5 to 6, too. 
 We could add something to the docs about that.

BTW one of its limitations seems to be that clang and clazy have to be in the 
same directory, so that's why I had to configure clazy with cmake 
-DCMAKE_INSTALL_PREFIX=/usr and sudo make install.   And so far I have not 
succeeded in using it on macOS, which I think is because of that limitation.  
It would be nice if that gets fixed somehow.


_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Reply via email to