On Donnerstag, 8. September 2016 14:03:05 CEST Bo Thorsen wrote: > 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. > > 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.
Someone else also told me that this is apparently harder then I thought it is with CMake, when the name of the output files of a code generator is not known. It is possible, but far from easy esp. when you don't have control over the generator script (though one can always use a wrapper). I see now that having support for this in QBS can be advantageous for the cases where one has such cases. Thankfully, I never ran into this so far, ever. Cheers -- 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