[Development] Qt 6 buildsystem support requirements

Thiago Macieira thiago.macieira at intel.com
Tue Jul 31 20:40:32 CEST 2018


On Tuesday, 31 July 2018 11:15:50 PDT Ville Voutilainen wrote:
> This provoked a thought in me, a way to make qbs worth all its effort:
> make debugging
> a build so staggeringly ridiculously good that it becomes attractive
> to use it. I don't know
> what debugging builds done with python-based build systems is like,
> but debugging make-based
> builds is rather horrible.

Aye.

Debugging qmake builds are actually pretty easy, if you know -d and -d -d 
exist. You can easily follow the decisions it made. You'll get to a few corner 
cases where things that should be lists aren't or vice-versa, or quirks of the 
language where $$ is suppressed, etc. But most of the time you don't need 
that. (I'm not talking about debugging the tool itself)

Debugging cmake builds aren't that easy. It writes a lot of logs, but 
sometimes magic happens. If the magic doesn't go your way, you're lost. 
Compared to qmake, the barrier of where the magic happens is lower, meaning 
that it happens more often than it should.

Debugging Makefiles are a PITA. THAT was libvpx's buildsystem and that is what 
prompted me to post this thread. Debugging make using the -d option is a last 
resort and is still not completely sufficient, since it shows process starts 
but not the variable evaluations.

Finally, debugging autoconf is actually not that difficult either. Because 
it's a shell script, there are tons of techniques you can use. And it creates 
a fairly comprehensive log file, similar to qmake's -d output. Debugging 
automake is a different story, but it's a very limited tool. And don't try to 
debug libtool (you can live an entire lifetime using it and never debug it).

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center






More information about the Development mailing list