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

[Matthew Woehlke]

On 2016-09-08 07:41, 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).
> 
> 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.

It's not *impossible*... it "just" requires that you be able to
determine the outputs at configure time, e.g. by having the tool run in
a mode that does nothing but report what files will be produced.

Granted, this is arduous, and especially terrible if the complexity of
determining the output files is on the order of producing them in the
first place, but saying it's "actually impossible" is a bit of an
exaggeration.

(This can't exactly work with VS because the *way* it works is to force
CMake to re-run when the file(s) that determine the output files change.
That works with e.g. make/ninja, but not so well with VS, but that's a
VS failing that I don't see how Qbs could overcome, given that VS *is*
the build tool and doesn't AFAIK support dynamic build graphs. Blaming
CMake for VS's shortcomings isn't really fair.)

The project I'm working on currently uses LCM, which has this problem
(we also use CMake, and have a CMake script that parses the input files
in order to determine the names of the output files). So does PySide /
Shiboken, and I'm sure there are other examples out there.

-- 
Matthew