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

[Milian Wolff]

On Donnerstag, 8. September 2016 13:41:21 CEST Bo Thorsen wrote:
> 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.

At least for CMake, I don't think so - if I'm not misunderstanding the 
problem. You add a target that depends on your .json file, and then whenever 
that is changed you generate headers. Then you add a dependent target which 
runs moc. And then you let your actual target depend on that one?

> 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...)

That is not an issue, no? You have one file that you need your targets depend 
on - the JSON file. If that one changes, the dependent targets must be 
rebuild.

> 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.

I'm not yet convinced.

Bye

-- 
Milian Wolff | milian.wolff at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5901 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160908/a512e648/attachment.bin>