[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