[Qbs] Tighter clang tooling integration

Christian Gagneraud chgans at gmail.com
Wed Nov 22 05:42:23 CET 2017


On 21/11/2017 10:46 PM, Christian Kandeler wrote:
> On Tue, 21 Nov 2017 18:01:32 +1300 Christian Gagneraud
> <chgans at gmail.com> wrote:
> 
>> Qbs can generate a clang compilation database. Some (most)
>> clang-based tools are not multi-cpu aware.
>> 
>> For example a typical use of clang-check is cd repo.git qbs
>> generate -g clangdb profile:someprofile # or cmake 
>> -DCMAKE_EXPORT_COMPILE_COMMANDS=ON find path/to/some/code -name
>> '*.cpp' | xargs clang-check -analyze -p=someprofile

As a side note, in my case CMake generate one database per "module" 
(lib, app, ...), whereas qbs generate a single database for the whole 
project. I do prefer the single database right now, but the one database 
per Qbs product could be interested too.
The plugin could be improved by adding an optional product name on the 
command line.


>> There are a few annoying things with this: - First you need to give
>> clang-check which file you want to check - clang-check will process
>> all the files one after another, even if you have multi CPU
> 
> This one you can probably work around, e.g. using GNU parallel.

Thanks for the tips! I wasn't aware of this one, maybe that's all I need 
(i'm looking for a simple solution).


>> - find path/to/some/code -name '*.cpp' might retun files that
>> should not be compiled.
>> 
>> Wouldn't it be nice if we could ask qbs to run a clang-based tools
>> on all the source files and with proper load distribution?
>> 
>> Is this something that looks doable? Is it even wanted?
> 
> This has come up before. It looked deceptively tempting at first to
> just set the compiler to the clang tool and then "build" as normal,
> but upon closer inspection, there were some issues. The most obvious
> one would be that you'd have to somehow stop after the "compile"
> step, but there were others as well (I forgot the details). If you

Agree, it doesn't seems like the right approach even if sounds "easy" at 
first.

> play around a bit in that area (perhaps with a dedicated module?),
> you'll probably get more insight into where the problems lie.

I could maybe use a custom Rule item, one that "transform" every .cpp 
file into, say a .clazy file (output of clazy on the .cpp file).
But then i would have to tell qbs that i want a "master" file that 
depends on all the individual '.clazy' files.

This still looks like a hack.

Can't stop thinking of a 'qbs for-each-cpp somecommand --someflag {}' 
(similar to the 'find' and 'git for-each' commands)


Chris



More information about the Qbs mailing list