On Mon, 17 Dec 2018 at 18:38, Thiago Macieira <thiago.macie...@intel.com> wrote: > > On Sunday, 16 December 2018 20:12:47 PST Richard Weickelt wrote: > > ... and if you cross-compile, you definetly don't want to your build system > > to stick its nose into your system librararies on any platform. > > No, you really DO. The issue is what "system" is: it's the sysroot for your > target platform, not the host system where you're building from. > > A good buildsystem should have support for being told where the sysroot and > cross-compiler are, then execute pkg-config and .cmake file searches there. > When installing, it also needs to be able to install to a separate install > root, so it can be packaged. Installing into the sysroot is optional: it's > only a convenience.
That's sound pretty standard stuff to me. Does pkg-config and cmake works on Qnx and Windows? Can you cross compile for iOS, tvOS, ... using CMake? Has it been ever tried once? CMake doesn't support (very well) cross-compilation for android on Windows for example, although, it pretends to be multi-platform and honor/embrace sysroot... > > Of course, this assumes that the libraries to be found do not require > executing anything from the sysroot. This is not an issue of the buildsystem > though: the problem is the dependency itself and would happen regardless of > buildsystem. Yes, autoconf got around that with site cache, a loooong time ago. > > So, in general, cross-compiling is difficult and error-prone. That's why > solutions like Yocto Project attempt at cross-compiling as if it were native, > via qemu and pseudo. And that's why I don't cross-compile. I've been cross-compiling and cross-debugging for 20 years, yes it's not always easy, but at the end of the day it's always the same symptoms, so once you know the arcane and your tools, it's not that bad. Things get only interesting when you attempt "canadian" cross-build of your SDK, where your build machine, your host machine and your target machine are 3 different arch/OS (and you do not "cheat" with emulators). It's very hard, fun (or not) but very rewarding. Yocto is not the only thing on the planet, there's lot of meta build system around that does cross-compile everything and are way easier to use, read, write and understand. You obviously don't do bare metal dev either, as there is not such thing as native build, not even emulated since there is no "real" OS. Even if there were one, you do not want to feel the pain to native-build on a N MHz processor - where n < 100, sometimes < 10. I wonder how many days it will take to build a full-featured boot2qt from scratch on a native ARM machine. FYI, you can do bare-metal development with Qbs and QtCreator, and that's pretty cool. I've never tried, but i'm sure it shouldn't be that hard to add support for VHDL/Verilog to Qbs, that's the power of modern SW architectures. And then QtCreator's solid code base (SW arch again?) would help to add FPGA deployment and simulation support, adding support for JTAG probes, this would even attract bootloader and kernel developers too. Just look at how LLVM made it in a all-gcc world. Everyone wants to use LLVM these days, their architecture was a true revolution (in the Open Source world at least) and is the key to their success. Would you say in 2018, that LLVM is the wolf? And as such, everyone should stick to gcc? No, you wouldn't, nobody would. What's important is not the critical mass, it's the rate at which you gain mass. Chris > > -- > 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 _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development