On Wed, 31 Oct 2018 at 22:47, Christian Kandeler <christian.kande...@qt.io> wrote: > > On Wed, 31 Oct 2018 10:44:43 +1300 > Christian Gagneraud <chg...@gmail.com> wrote: > > > On Wed, 31 Oct 2018 at 10:27, Thiago Macieira <thiago.macie...@intel.com> > > wrote: > > > On Tuesday, 30 October 2018 13:56:45 PDT NIkolai Marchenko wrote: > > > The only thing I'm criticising is that its proper chance involves Qt > > > being the > > > guinea pig. Find someone else instead and grow your community. Get track > > > record for building, cross-compiling, working with weird set ups, > > > containerised build environments, build farms, etc. Don't ask Qt to > > > switch to > > > it until you've done that work. > > > > !?! > > What make you think qbs cannot be used in such environments?That all > > very basic stuff to me. > > - cross-compiling: Qbs support *out of the box* all "standard" OS > > *and* "standard" toolchains. > > - working with weird set ups: what does that even mean? That a very > > vague statement. > > - containerised build: any build system can run in a container, that's > > orthogonal. > > - build farms: Against what is the problem with build farm, i don't get it. > > - etc: again, can you elaborate? that's very vague. > > > > I've used Qbs to build a Desktop SW for Windows + MacOS + Linux, all > > producing platform specific installers. > > It was a breeze. > > I've used it to build a 1.5 million SLOC SW, with complex build > > matrix. The only reason we dropped it, was because of lack of > > integration: > > QtCreator is the only IDE that knows Qbs, as i reported on Qbs mailing > > long time ago, Qbs won't take off without XCode, Visual Stidio, Visual > > Code, Eclipse, ... integration. > > And, so far, we failed at switching to CMake, the build matrix is too > > complex. > > So what *are* you using now? Just curious.
Drum roll..... vcxproj + python + qmake! This is close to a 'hand crafted' build system, it is dirty, fragile, but "it works" (tm). The middle man, python, is where we have full freedom to do the dirty tweaking job. We even have python code that "fix" the generated Makefiles, when needed. Absolutely nobody likes this solution, it is heinous, but it is the only one that fulfill all our requirements. With enough energy, i'm sure this whole thing could be switched to Qbs, CMake or even qmake. But I do believe that Qbs would be the cleanest solution. Now, of these 3 build systems, CMake is the only one that is supported by Visual Studio (I was told), and although i do not use it, this is the most common IDE here. We do hundreds of builds per days, for ca. 15 different build configurations, and we do that in containers, in a build farm. We're even experimenting with Windows native containers, and off-loading our local build farm in the cloud. We build the whole custom embedded Linux OS as well, a bunch of in-house shell scripts that have to deal with at least the most common build systems. We have tera-bytes of artifacts every day. We generate firmwares for at least 50 commercial products, every day. Yes it's not an easy job, and CMake vs qmake vs Qbs doesn't influence the number of issue we have to face. Hence my criticism toward Thiago's requirements and arguments. I don't buy a single line of what he said in this thread. Last but not least, everyone maintaining a Embedded Linux Distro have to maintain a set of patches to work around buggy source package build system, and this includes Qt, see for example: https://github.com/meta-qt5/meta-qt5/tree/master/recipes-qt/qt5/qtbase See as well debian/patches in, eg http://http.debian.net/debian/pool/main/q/qtbase-opensource-src/qtbase-opensource-src_5.3.2+dfsg-4+deb8u2.debian.tar.xz Whatever the build system you use, your users will have to work it around and deal with it. Chris _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
