[Development] Build system for Qt 6

Jean-Michaël Celerier jeanmichael.celerier at gmail.com
Mon Dec 17 09:42:42 CET 2018


> 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 <chgans at gmail.com>
wrote:

> On Mon, 17 Dec 2018 at 18:38, Thiago Macieira <thiago.macieira at 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 at qt-project.org
> > https://lists.qt-project.org/listinfo/development
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20181217/415fdcd9/attachment.html>


More information about the Development mailing list