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
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
