Christian Gagneraud wrote: > On Fri, 14 Dec 2018 at 00:54, Kevin Kofler <kevin.kof...@chello.at> wrote: >> I am looking forward to this bootstrapping hack going away by just using >> CMake. > > So you want to replace a bunch of scripts with another bunch of > scripts, and magically the maintenance burden will be gone?
A CMakeLists.txt is not a handwritten bootstrapping script, but a full- fledged replacement for a QMake .pro file. Sure, a CMakeLists.txt is a form of script, but so is a QMake .pro file. My point is that you do not need to duplicate parts of the build scripts to a handwritten shell script just to bootstrap the build tool. (Bootstrapping CMake is not something Qt has to deal with, Qt can assume the binary to just be there. Users will typically just download an upstream or distro-packaged binary and not bootstrap CMake themselves.) And of course CMake itself is not a script, but a C++ executable. > My bet is that it will never happen, you'll still need the power of > perl, python or javascript to do the "dirty job", CMake is not > expressive enough, by design. For things like custom code generators, maybe, if you cannot or do not want to use Qt executables for them for whatever reason (e.g., if you need the generated code to compile QtCore). But a wrapper script around CMake (in the style of the Qt configure script) should never be needed. Also, do not understimate what CMake can do, especially with functions, which make it theoretically Turing-complete. (That said, you might actually want to restrict or ban the use of recursive (or all) functions in your CMakeLists.txt coding style if you want to ensure that your script will terminate, and do so in a reasonable time. You can have only EITHER decidability OR Turing-completeness, not both.) >> > The Qt Company has been looking for "employees" to work on Qbs for >> > month before dropping it, apparently nobody responded, or something... >> >> Then that would pretty much explain why they cannot maintain it in the >> long run. > > You are right, and it would be nice to have official statements on > that. What did really happen? That's a question I cannot answer, as I am not employed by nor otherwise affiliated with the Qt Company. I wonder whether those who know the answer (I don't) are allowed to tell you. > It's not just the output expressions, the whole page "smells bad". > Take '$<COMMA>' for example, it reminds me of m4, make and qmake, like > we haven't moved away from the old daemons. CMake feels a lot less hackish than autoconf/m4. Mainly because there is just one level of scripting language, whereas autoconf is a layer on top of m4. E.g., the escaping rules for autoconf are particularly arcane, you often have to escape the same expression multiple times: for autoconf, for m4, for the shell. CMake does not have such a legacy. >> This is a bug that was already fixed by: >> https://gitlab.kitware.com/cmake/cmake/merge_requests/2668 > > Apparently it will make it into 3.14, in 2 months. > It's a bummer to have to maintain a work around, or should i add cmake > to my toolkit, so that i can keep track of patches? Technically, the simplest workaround would be to just not use Windows as the build host for cross compilation. :-) But I guess producing a cmake.exe with the patch backported or from a git snapshot as a one-off workaround, or even just pointing to the nightly snapshot binaries from: https://cmake.org/files/dev/?C=M;O=D would be the easiest workaround to put in place. The issue affects only Windows build hosts (not compilations on other build hosts for Windows, nor any other host/target combinations), so only a Windows .exe with the patch is needed. And it can be dropped when 3.14 is released. > Do you foresee more problems like that? Unfortunately, I do not have the magic crystal ball required for that. ;-) Kevin Kofler _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
