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.wo...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
