Re: [Development] CMake && QtCreator cross-compilation for ARM fails
On Sat, 15 Dec 2018 at 01:59, Kevin Kofler wrote: > >> 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. :-) That's a no-go, most of our developers use Windows. > 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. Yes that could be a possibility, the only issue with that is i cannot use `cmake_minimum_required(VERSION 3.xy)` to make sure developers use the right version. And once 3.14 is released, i won't have any ways to check if developers uses 3.14 'special' or 3.14 'official'. Chris ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake && QtCreator cross-compilation for ARM fails
FWIW, Denis: I feel your pain and agree that the Qt Company and Qt Project have a responsibility to make cross compilation with CMake just work out of the box when you have the necessary kits installed in QtCreator. There is absolutley no excuse for us not doing this. We as a company should be very careful to make this work as developers who *use* Qt won’t care at all if CMake causes them to lose time resetting up their tool chains for cross compilation. I have also noticed that CMake does not work out of the box with many of our Boot2Qt kits. Needs fixing ASAP. From: Development on behalf of Denis Shienkov Sent: Thursday, December 13, 2018 4:59 AM To: chg...@gmail.com Cc: development@qt-project.org; kevin.kof...@chello.at Subject: Re: [Development] CMake && QtCreator cross-compilation for ARM fails > And it would be much worse for QBS, which requires much more from Qt than > QMake. It requires QML, JavaScript, etc. So what? A GCC too compiles with GCC... For me, as a developer it is not a big problem and not a my. A worse problem is in CMake's ideology. QBS just work immediatelly! Unlike of CMake! And a fact that the QBS's just work cover all CMake's bootstrap crap. CMake has no one agvantage for developers! чт, 13 дек. 2018 г. в 15:02, Denis Shienkov mailto:denis.shien...@gmail.com>>: > 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 mailto:chg...@gmail.com>>: On Thu, 13 Dec 2018 at 12:27, Kevin Kofler mailto: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 y
Re: [Development] CMake && QtCreator cross-compilation for ARM fails
Maximilian Hrabowski wrote: > - the cmake syntax is more difficult to learn and to read and there was > seen no improvement to the qmake syntax The advantages of CMake vs. QMake are not in the syntax, but in the expressiveness. There are lots of things you just cannot do with QMake. It is barely enough for Qt itself, but only because Qt has a "configure" wrapper and because it simply added custom hardcoded commands to QMake itself where it needed them (e.g., for .pc file generation). This does not apply for CMake vs. QBS though, the differences are of a different nature there. Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake && QtCreator cross-compilation for ARM fails
14.12.2018, 16:04, "Kevin Kofler" : > 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.) Also, don't overestimate what is reasonable to do with this Turing tar pit, as cmake language is primitive and untyped. Non-trivial scripts quickly get hard to understand and maintain, and there is little tooling to debug or refactor them later. Any general purpose scripting language wins hands down here when it doesn't have to manipulate with build targets directly. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake && QtCreator cross-compilation for ARM fails
Unsubscribe me Sent from my iPhone > On Dec 14, 2018, at 12:57 AM, Christian Gagneraud wrote: > > Hi Kevin, > >> On Fri, 14 Dec 2018 at 00:54, Kevin Kofler wrote: >> Bootstrapping QMake has always been the least pleasant part of the Qt build >> process. > > Yes, i think we all agree on that one. > >> 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? > 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. > >>> Can you point me to something that shows the Qt "project" contributing >>> to the Qt "company" on that very particular topic? >> The Qt Project is largely just the Qt Company when it comes to such core >> tasks. > > It seems that you cannot point me to something tangible. > >>> 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? > >>> read that one: >>> https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html#output-expressions >> >> That is a powerful feature. And you don't have to use it if you don't need >> it. Most CMake files actually do not need or use output expressions. > > It's not just the output expressions, the whole page "smells bad". > Take '$' for example, it reminds me of m4, make and qmake, like > we haven't moved away from the old daemons. > >>> And read that again and again, until you brain says: 'Actually, CMake >>> is "crap"!' >> >> My brain refuses to enter this infinite loop. ;-) > > Mine too. :-p > > 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
Re: [Development] CMake && QtCreator cross-compilation for ARM fails
> -Original Message- > [...] > > > 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? We indeed had a dedicated position open for quite some time. Anyhow, the deprecation of Qbs was ultimately a business decision, not something directly related to hiring. Kai ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake && QtCreator cross-compilation for ARM fails
On 13. Dec 2018, at 13:02, Denis Shienkov mailto:denis.shien...@gmail.com>> wrote: Where is CMake advantages? Actually that is the question i’d like to ask all the time and no one can tell me. In June we started to migrate a larger project from qmake which uses a lot of code generators. Since we haven’t been sure whether to use qbs or cmake we started a student project to evaluate both. A person without prior knowledge (i didn’t want a biased person) of cmake and qbs got the task to migrate some modules that were supposed to cover all different use cases. The result of this evaluation was as follows (statements are as objective as possible): - in the beginning for the simple stuff cmake seemed to be easier and faster to use, after a while (about 2-3 days) this opinion shifted to qbs and did not shift back - the cmake syntax is more difficult to learn and to read and there was seen no improvement to the qmake syntax - once you understand the basic concept of qbs, it is very easy to use and to extend - integrating code generators with real dependency tracking is very difficult with cmake (we could get it to work properly) and works very well with qbs (since qbs does not rely on make) - when dealing with the tough problems... - with cmake, it seemed there are always a lot of solutions found when searching properly but it seemed that everybody suggested a different way to solve the problem and no way could solve the problem entirely. So the huge community is an advantage but still did not help - with qbs we could solve every problem on our own in reasonable time (at least so far and we’re nearly done) In the end qbs was even or better than cmake in nearly every criteria we’ve based our decision on. The only criteria where cmake bet qbs was the large user community. So at least for now we stick to the wolf… Cheers, Maxim ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake && QtCreator cross-compilation for ARM fails
On Friday, 14 December 2018 04:51:58 PST Kevin Kofler wrote: > > 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. We've been very careful not to require Perl or Python to build Qt from release tarballs, at least qtbase. I think we do have one use of Perl (the ELF version files), but it's restricted to ELF systems (Linux, FreeBSD, etc.) and its input could conceivably be generated by syncqt prior to packaging. Other things are executables. Take a look at the qfloat16-tables application, which is C++ but all it does is generate a couple of tables that will not EVER change. If the restriction were lifted, we'd probably stop committing pre-generated sources to the repository: * the QXmlStreamReader parser (generated by qlalr) * the Unicode tables (generated by a Python script) * the QLocale tables (generated by a Python script) There are also a couple of string tables that can probably be replaced by C++11 constexpr code. We just have to be careful: the XCB key table was replaced in 5.12 and caused some Clang build to fail because it has too deep template recursion. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake && QtCreator cross-compilation for ARM fails
Christian Gagneraud wrote: > On Fri, 14 Dec 2018 at 00:54, Kevin Kofler 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 '$' 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
Re: [Development] CMake && QtCreator cross-compilation for ARM fails
On Fri, 14 Dec 2018 at 00:54, Kevin Kofler wrote: > 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? Do you foresee more problems like that? Chris ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake && QtCreator cross-compilation for ARM fails
Hi Kevin, On Fri, 14 Dec 2018 at 00:54, Kevin Kofler wrote: > Bootstrapping QMake has always been the least pleasant part of the Qt build > process. Yes, i think we all agree on that one. > 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? 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. > > Can you point me to something that shows the Qt "project" contributing > > to the Qt "company" on that very particular topic? > The Qt Project is largely just the Qt Company when it comes to such core > tasks. It seems that you cannot point me to something tangible. > > 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? > > read that one: > > https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html#output-expressions > > That is a powerful feature. And you don't have to use it if you don't need > it. Most CMake files actually do not need or use output expressions. It's not just the output expressions, the whole page "smells bad". Take '$' for example, it reminds me of m4, make and qmake, like we haven't moved away from the old daemons. > > And read that again and again, until you brain says: 'Actually, CMake > > is "crap"!' > > My brain refuses to enter this infinite loop. ;-) Mine too. :-p Chris ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake && QtCreator cross-compilation for ARM fails
On Thu, 13 Dec 2018 12:47:08 +0100 Kevin Kofler wrote: > Christian Gagneraud wrote: > > On Thu, 13 Dec 2018 at 12:27, Kevin Kofler wrote: > >> (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. > > Bootstrapping QMake has always been the least pleasant part of the Qt build > process. It requires building parts of Qt (QMake and the classes it depends > on) with a custom script, making it harder than necessary to get it to use > the proper build flags (optimization, security hardening, etc.). The script > is also a completely unnecessary maintenance burden for Qt. > > I am looking forward to this bootstrapping hack going away by just using > CMake. > > And it would be much worse for QBS, which requires much more from Qt than > QMake. It requires QML, JavaScript, etc. It does not require QML. Christian ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake && QtCreator cross-compilation for ARM fails
> And it would be much worse for QBS, which requires much more from Qt than > QMake. It requires QML, JavaScript, etc. So what? A GCC too compiles with GCC... For me, as a developer it is not a big problem and not a my. A worse problem is in CMake's ideology. QBS just work immediatelly! Unlike of CMake! And a fact that the QBS's just work cover all CMake's bootstrap crap. CMake has no one agvantage for developers! чт, 13 дек. 2018 г. в 15:02, Denis Shienkov : > > 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 : > >> On Thu, 13 Dec 2018 at 12:27, Kevin Kofler >> 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
Re: [Development] CMake && QtCreator cross-compilation for ARM fails
> 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 : > On Thu, 13 Dec 2018 at 12:27, Kevin Kofler 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
Re: [Development] CMake && QtCreator cross-compilation for ARM fails
Christian Gagneraud wrote: > On Thu, 13 Dec 2018 at 12:27, Kevin Kofler wrote: >> (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. Bootstrapping QMake has always been the least pleasant part of the Qt build process. It requires building parts of Qt (QMake and the classes it depends on) with a custom script, making it harder than necessary to get it to use the proper build flags (optimization, security hardening, etc.). The script is also a completely unnecessary maintenance burden for Qt. I am looking forward to this bootstrapping hack going away by just using CMake. And it would be much worse for QBS, which requires much more from Qt than QMake. It requires QML, JavaScript, etc. >> 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. Comparison with what? I did compare with QBS, which got only limited adoption, which would have to be maintained by Qt, and which just does not have a showcase project of the size of KDE. > Can you point me to something that shows the Qt "project" contributing > to the Qt "company" on that very particular topic? The Qt Project is largely just the Qt Company when it comes to such core tasks. > 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. > Cmake is crap, it is a macro based language, like it's good to be back > in the 80's. Sometimes, old concepts just work and do not need to be replaced. C++ is also from the 80's (started in 1985) and serves Qt just fine. > It has no semantic, Huh? > and no concept apart form 'macro', Not true. There are builtin commands, and there are now also functions with support for recursion. > the syntax sucks, big time, The syntax is straightforward and easy to learn. Try autoconf for a syntax that REALLY sucks. ;-) > every thing is just 'expression', Having untyped/weakly-typed expressions is typical for scripting languages. JavaScript also works this way. That does not stop it from being an extremely popular programming language, also used in QML and QBS. > read that one: > https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html#output-expressions That is a powerful feature. And you don't have to use it if you don't need it. Most CMake files actually do not need or use output expressions. > And read that again and again, until you brain says: 'Actually, CMake > is "crap"!' My brain refuses to enter this infinite loop. ;-) > 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 This is a bug that was already fixed by: https://gitlab.kitware.com/cmake/cmake/merge_requests/2668 Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake && QtCreator cross-compilation for ARM fails
On Thu, 13 Dec 2018 at 12:27, Kevin Kofler 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
Re: [Development] CMake && QtCreator cross-compilation for ARM fails
On Wednesday, 12 December 2018 15:20:28 PST Kevin Kofler wrote: > > PS: WTF? Why the Qt's management choosed the CMake's instead of QBS? > > Because CMake is a widespread tool written in C++/STL (so, unlike QBS, it > does not depend on Qt, which would mean a circular dependency when building > Qt), 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. Also, and perhaps more importantly: it has a very big community of people who can help answer questions. Like this one. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake && QtCreator cross-compilation for ARM fails
Denis Shienkov wrote: > Change Dir: > /tmp/QtCreator-iobfII/qtc-cmake-wCnOwxuI/CMakeFiles/CMakeTmp Run > Build > > Command:«/mnt/data/Yocto-miatech/sdks/sysroots/cortexa9hf-neon-poky-linux-gnueabi/usr/bin/make» > «cmTC_afb4e/fast» /lib/ld-linux-armhf.so.3: No such file or directory You cannot execute make from the sysroot without a binfmt handler and a matching ld.so. See, e.g.: https://wiki.debian.org/QemuUserEmulation https://wiki.gentoo.org/wiki/Embedded_Handbook/General/Compiling_with_qemu_user_chroot But you will probably want to just point CMake to a make from the build host instead. Have you already set: set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) in your CMake toolchain file? With that setting, it should not look for executables in your sysroot, see: https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html#cross-compiling-for-linux > PS: WTF? Why the Qt's management choosed the CMake's instead of QBS? Because CMake is a widespread tool written in C++/STL (so, unlike QBS, it does not depend on Qt, which would mean a circular dependency when building Qt), 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. 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. > 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. > 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. Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] CMake && QtCreator cross-compilation for ARM fails
Hi guys. I have the Qt project, based on both QMake and QBS. This project should be targeted on a Apalis iMX6 board with BSP Linux, generated from Yocto. Also I have a Yocto SDK which is added to QtCreator (as a configured Kits). The QMake and QBS doing the ARM cross-compilation from the QtCreator like a sharm, but the CMake fails on the configure step: " The ASM compiler identification is GNU Found assembler: /mnt/data/Yocto-miatech/sdks/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gccThe C compiler identification is GNU 6.4.0 The CXX compiler identification is GNU 6.4.0 Check for working C compiler: /mnt/data/Yocto-miatech/sdks/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gccCheck for working C compiler: /mnt/data/Yocto-miatech/sdks/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc — broken CMake Error at /usr/share/cmake-3.10/Modules/CMakeTestCCompiler.cmake:52 (message): The C compiler «/mnt/data/Yocto-miatech/sdks/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc» is not able to compile a simple test program. It fails with the following output: Change Dir: /tmp/QtCreator-iobfII/qtc-cmake-wCnOwxuI/CMakeFiles/CMakeTmp Run Build Command:«/mnt/data/Yocto-miatech/sdks/sysroots/cortexa9hf-neon-poky-linux-gnueabi/usr/bin/make» «cmTC_afb4e/fast» /lib/ld-linux-armhf.so.3: No such file or directory CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:22 (project) Configuring incomplete, errors occurred! See also «/tmp/QtCreator-iobfII/qtc-cmake-wCnOwxuI/CMakeFiles/CMakeOutput.log». See also «/tmp/QtCreator-iobfII/qtc-cmake-wCnOwxuI/CMakeFiles/CMakeError.log». CMake Project parsing failed. " I tried even specify the cmake's toolcain file from the QtCreator settings: " CMAKE_TOOLCHAIN_FILE = /mnt/data/Yocto-miatech/sdks/sysroots/x86_64-pokysdk-linux/usr/share/cmake/OEToolchainConfig.cmake " PS: WTF? Why the Qt's management choosed the CMake's instead of QBS? From my point of view, the CMake it is a 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! This is my soul cry ... guys, what are you doing? Denis ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
