Adding CMake project to a qmake "subdirs" project
How can I add a CMake-based project that uses Qt to an existing Qt solution file e.g. Qt "subdirs" .pro file?
"This article":http://doc.qt.digia.com/qtcreator-snapshot/creator-project-cmake.html explains how to build a CMake-based project that either uses Qt or not, but does not give a clue for how to add such project to an existing "subdirs" project. What I want is to add "QJson":http://qjson.sourceforge.net/ to my "subdirs" project e.g. add the CMakeLists.txt.
I had the same question https://forum.qt.io/topic/58217/how-to-include-cmake-project-into-my-qmake-project and there's still no answer. It seems giving no opportunity to interoperate with cmake qmake wants to replace cmake in some manner but cmake is more powerful and hence there's no reason for creating new qmake projects. qmake is helpful only to build Qt Library and QtCreator.
qmake doesn't want to replace cmake. For all matters, cmake was created after qmake and there are many projects using qmake successfully. But that's not the point, what you both are trying to do is use two different build systems together which is not something that any of those are made for.
So the question should rather be: do you really want to rebuild these dependencies with your application ? Why not build them and use them like any other system library ?
@SGaist Thanks for replying. I think that it's normal when one project tries to read other's project properties (one of them are dependencies) and people can perform one build action instead of writing build scripts. With scripts teammates should remember where they are placed and how to work with them instead of having one project in the IDE.
For example, I'm writing QtCreator plugin that uses cocos2d-x. QtCreator is QMake\QBS but cocos2d-x is cmake. I have commits both in QtCreator and in cocos2d-x projects. And I set cocos2d-x as a git submodule of QtCreator plugin project. So it's suitable for me to have common dependencies settings for both of these projects.
Don't get me wrong, I do see the use case. But it's really not something easy to do especially if you consider that building a cmake project requires the configuration part and then the call to make.