> 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?
Seriously, it's a google search away: https://github.com/leetal/ios-cmake > CMake doesn't support (very well) cross-compilation for android on > Windows for example, fairly interesting considering that Android Studio uses CMake: https://developer.android.com/studio/projects/add-native-code They used to use Gradle but saw the light at some point :-) (or at least the incredible pain that gradle was inflicting on their end-users). But in this day and age where docker works everywhere I don't really see the point in fighting to make windows behave like a proper unix system, just write a dockerscript that does your cross-compile job. Also, there's WSL, I suppose that it should work somehow. > 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. what makes you think that it wouldn't work with CMake too ? e.g. it supported java for a long time ( https://cmake.org/cmake/help/latest/module/UseJava.html), and C# since 3.8 ( https://cmake.org/cmake/help/latest/module/CSharpUtilities.html) Here's a simple example of FPGA toolchain (again, 5 seconds of google) : https://github.com/jamieiles/fpga-cmake Jean-Michaël On Mon, Dec 17, 2018 at 8:15 AM Christian Gagneraud <chg...@gmail.com> wrote: > 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 >
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
