[Development] Notes on "Qt Build Systems" @ QtCon 2016

[Bo Thorsen]

Den 05-09-2016 kl. 20:49 skrev Milian Wolff:
>> As an incredibly simple example, make is inherently limited in that it
>> > cannot even represent a rule with multiple outputs (there are some
>> > workarounds, but they are hacky and rather limited in how they can be
>> > applied). And ninja is no magic bullet here either, because that still
>> > represents a static build graph, whereas the content of Qbs' build graph
>> > can actually change during the execution of the build.
> Can you give an example for why we should care? This may sound flame-baity,
> but I'm really truly interested. I simply don't care about my build system, as
> long as it gets the job done without too much hassle (and yes, that is the
> case for me personally with cmake), and fast, too (which is the case with
> ninja). See also below.

I can answer that because I asked for this feature all the way back at 
QtCS in Bilbao.

The context I was talking about was code generators. At the time I had 
built a code generator that created both the Qt and the PHP side of a 
client-server system. It had a single JSON file that described a server 
with the available remote methods on it. The output from the C++ code 
generator was a .h and .cpp file per method and a single .h and .cpp 
that described the server. So on qmake run time you can't know how many 
output files you have unless you force the user to run qmake every time 
you modify the JSON description.

And to make the problem worse, the customer wanted each of the classes 
describing a remote call to be qobjects with a Q_OBJECT so a moc run is 
required.

AFAIK this is impossible to do with both qmake and cmake. Not just hard, 
actually impossible. And the reason is that you can't know until build 
time what files you have to run moc on. (Now as a mental exersize, 
imagine having multiple server descriptions in a single json file...)

It's possible to do in pure make by calling the code generator and 
creating a sub make file and then calling make on that. But you can't do 
that in any way that supports hitting the build button once in QtCreator.

I finally solved this by convincing the customer it was sufficient to 
have a qobject base class for the remote calls and live without the meta 
object descriptions on those. And yes, this is a very specific case. But 
it's an example of something that neither cmake nor qmake can do because 
they have a makefile generating step.

Maybe this seems more important to me than others because I'm a huge fan 
of custom built code generators for stuff like database connections and 
client-server communications.

Bo Thorsen,
Director, Viking Software.

-- 
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu