[Development] Build system for Qt 6

[Christian Gagneraud]

On Wed, 31 Oct 2018 at 11:08, Thiago Macieira <thiago.macieira at intel.com> wrote:
> On Tuesday, 30 October 2018 14:44:43 PDT Christian Gagneraud wrote:
> > On Wed, 31 Oct 2018 at 10:27, Thiago Macieira <thiago.macieira at 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
>
> I didn't say it can't. I'm saying I want proof that it can, by having other
> projects adopt the solution and there being track record of it.
>
> > 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.
>
> See the July email for more details.
>
> > - containerised build: any build system can run in a container, that's
> > orthogonal.
>
> Until you run into trouble. Example of what I literally had a problem with in
> the last 30 minutes: Maven.
>
> [ERROR] Failed to execute goal on project hadoop-auth: Could not resolve
> dependencies for project org.apache.hadoop:hadoop-auth:jar:2.8.5: Failed to
> collect dependencies at com.nimbusds:nimbus-jose-jwt:jar:4.41.1: Failed to
> read artifact descriptor for com.nimbusds:nimbus-jose-jwt:jar:4.41.1: Could
> not transfer artifact com.nimbusds:nimbus-jose-jwt:pom:4.41.1 from/to
> apache.snapshots.https (https://repository.apache.org/content/repositories/
> snapshots): repository.apache.org: No address associated with hostname ->
> [Help 1]
>
> Who do I turn to for help? A quick set of Google queries did not result in an
> answer on how to properly populate the dependencies for this thing (Apache
> Hadoop) .

Your problem has nothing to do with containers, unplug the network
cable of your computer, and you'll have the same issue on your host.

But that's an interesting 'issue', one that even contradict some of
your requirements, like containerised, build farm, supported by Linux
distro, ...
I'm pretty sure that the build system used by Apache Hadoop meet all
your requirements, yet in your particular use case, it fails ...

So your long list of requirement cannot even bring the guarantees
you're seeking.

I'm not trying to say that your requirements are bad or useless, i'm
just saying that in themselves, they don't even bring any guarantees,
that's all.


> > - build farms: Against what is the problem with build farm, i don't get it.
>
> There's no problem until there's a problem. Can you point me to something that
> uses qbs to build getting built in a Linux distribution's build farm? I'd like
> to know that it's been properly tested.
>
> It's small things like libraries ending up in /usr/lib64 instead of /usr/lib.
> Some build systems do that automatically for you; with some others you can get
> it wrong. And here's the buildsystem that failed to install libraries in the
> right place this morning: CMake.

Packagers have to deal with that all the time, and people doing
cross-compilation have to deal with even worse things every day.
Even if you use the perfect tool, the author of the build recipe can
still screw it up.

Given who's behind Qbs, I have high expectation for Qbs to do 'the right thing'.

Chris


> > - etc: again, can you elaborate? that's very vague.
>
> I did, three months ago.
>
> > 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.
>
> Great. That's good track record. Now get 3 Linux distributions to package it.
>
> > 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.
>
> I didn't call for IDE support in my email. Tobias, in a reply to it, did.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development