08.09.2016, 15:03, "Bo Thorsen" <b...@vikingsoft.eu>: > Den 08-09-2016 kl. 13:47 skrev 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. > > Ok, go try it. Create a simple python or perl script that reads a file. > The file just has a single number N inside it. And based on N the script > outputs those files: > > server.h > method1.h > method2.h > ... > methodN.h > > Inside method1.h you write this: > > #include <QObject> > > class Method1 : public QObject { > Q_OBJECT > }; > > server.h has this: > > #include "method1.h" > ... > #include "methodN.h" > > class Server { > public: > Method1* call1() { return new Method1; } > ... > MethodN* callN() { return new MethodN; } > }; > > In main.cpp you instantiate Server. > > The only problem is that you have to run moc on each of the .h files.
Run moc from inside script when you generate header. > > Solution to the problem is only accepted if you can press build one > single time inside both Visual Studio and Qt Creator and it builds this > even when you modify the input file and the main.cpp. > > I'm sure there are ways you can make the build call cmake or force a > build to fail and rebuild, and that's what you can currently do. And > those all feels annoying when you work on the project. > > You asked why modifying the tree at build time could be necessary. This > is one of the (probably very few) examples of it. > > 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 -- Regards, Konstantin _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development