> Once you have the cross toolchain configured properly, which is a one-time > setup effort, CMake will just work, too.
Will just work? What??! HAHA. Are you kidding? Why I need to configure something? Why I need to create an additional CMake's scripts, config files, toolchains and etc? I already have added all required cross-compilation stuff (toolchain && rootfs) to QtCreator. With QBS && QMake it works immediatelly! But for CMake I need in additional unknown things. And is it user friendly? The Qt's PR peoples (especially the CMake maintainers) are praised that they have added a lot of CMake && QtCreator integration improvements. But, I don't see any results related event to a simple cross-compilation issues! It is nonsense! How much the users need to wait for improvements for this (and other) issues with CMake? It completelly gets stuck for a working process. Where is CMake advantages? I see only regressions! And it is reality! чт, 13 дек. 2018 г. в 13:48, Christian Gagneraud <chg...@gmail.com>: > On Thu, 13 Dec 2018 at 12:27, Kevin Kofler <kevin.kof...@chello.at> wrote: > Hi Kevin, > > > PS: WTF? Why the Qt's management choosed the CMake's instead of QBS? > > > > Because CMake is a widespread tool written in C++/STL > > Some people are scared of the wolf, i'm scared of the sheepple. > > > (so, unlike QBS, it > > does not depend on Qt, which would mean a circular dependency when > building > > Qt), > > qmake has this problem, yet it's been packaged for 10+ years without a > problem. > > > widely packaged for GNU/Linux distributions, and with binaries for > > Windows and macOS shipped by CMake upstream (Kitware) themselves. It has > a > > live upstream at Kitware, so Qt does not have to maintain it. And it is > > already widely used in the Qt and KDE community. > > What a bunch of cheap free statements, w/o proper comparison. > > > > > QBS, on the other hand, is a custom tool, in practice only used by Qt > and a > > few Qt-using projects (I know the aim is to support also non-Qt projects, > > but this is not really used in the wild), which requires constant > > maintenance effort from the Qt project. > > Can you point me to something that shows the Qt "project" contributing > to the Qt "company" on that very particular topic? > The Qt Company has been looking for "employees" to work on Qbs for > month before dropping it, apparently nobody responded, or something... > > > > From my point of view, the CMake it is a crap... > > > > CMake is not a "crap", it is a powerful tool, almost as easy to use as > > QMake, but a lot more flexible and powerful. > > Cmake is crap, it is a macro based language, like it's good to be back > in the 80's. > It has no semantic, and no concept apart form 'macro', the syntax > sucks, big time, every thing is just 'expression', read that one: > > https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html#output-expressions > And read that again and again, until you brain says: 'Actually, CMake > is "crap"!' > > > > > > I know, that I'm not a CMake expert, but Why I need to spent a lot time > > > to make the CMake working wich an unknown result, > > > instead of just using QBS? Cross-compilation with QBS works > > > immediatelly, but with CMake sucks! > > > > Once you have the cross toolchain configured properly, which is a > one-time > > setup effort, CMake will just work, too. > > Oh yeah! Unless you hit some bugs, like, CMake-based cross-compilation > doesn't actually exists (yet) on Windows: > > https://github.com/Kitware/CMake/commit/5f0f84c7e0630d7b8190c18badd5a68e2dd08ff7 > > I'm telling you: with CMake, it's 1988 Christmas, right now! > > Chris. > _______________________________________________ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development >
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
