Re: [Development] Build system for Qt 6

[Thiago Macieira]

On Monday, 14 January 2019 02:02:46 PST Christian Gagneraud wrote:
> My own, cheap/useless opinion is that the Qt company should have
> contacted gitlab or the like...
> Look at what they did with Drupal.

Those options didn't exist when the investment was done.

-- 
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

Re: [Development] Build system for Qt 6

[Christian Gagneraud]

On Tue, 8 Jan 2019 at 02:42, Edward Welbourne  wrote:
>
> On Mon, 17 Dec 2018 at 21:43, Jean-Michaël Celerier wrote:
> >> 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.
>
> Christian Gagneraud (17 December 2018 13:50)
> > What do you mean by 'everywhere'? Native Windows dockers are still
> > experimental, and i haven't heard of native MacOS docker yet (might
> > have missed smth).
>
> I can't speak for "everywhere"; but we've found that docker works
> cross-platform enough for the needs of our on-going work to replace the
> monolithic net-test-server currently used to test network-related code:
>
> https://codereview.qt-project.org/240564 - macOS
> https://codereview.qt-project.org/246535 - MS-Win
>
> So there is at least some grounds to hope docker can solve the
> cross-compilation problems Jean-Michaël had in mind.

Not sure to understand your point, AFAIU (and i had a quick look at
the commits above), you're using "docker for windows" and "docker for
mac".
These 2 run a Linux VM on Windows/Mac in which a Linux docker server
is running, so at the end you're running Linux docker inside a Linux
VM on Windows/Mac, not a Windows/Mac "native docker image".
I do not see how it can helps with cross compiling...
From my POV, i would like to see docker solves native builds, not cross builds.

Using Linux docker images for network integration testing is a very
good idea, thought.

Now, things get complicated since the introduction of "native" Windows
containers, that is a pure "Windows" docker containers running on
Windows 10 (10 GB for a core image). So far MacOS "native" docker
containers don't exists yet.

Coin uses Nebula to manage VMs of all sorts (that's my understanding),
and i think that the Qt Company did a mistake here:
Forget about custom CI, focus on custom build system (after all that
is the topic of this thread).
My own, cheap/useless opinion is that the Qt company should have
contacted gitlab or the like...
Look at what they did with Drupal.

Chris.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Build system for Qt 6

[Edward Welbourne]

On Mon, 17 Dec 2018 at 21:43, Jean-Michaël Celerier wrote:
>> 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.

Christian Gagneraud (17 December 2018 13:50)
> What do you mean by 'everywhere'? Native Windows dockers are still
> experimental, and i haven't heard of native MacOS docker yet (might
> have missed smth).

I can't speak for "everywhere"; but we've found that docker works
cross-platform enough for the needs of our on-going work to replace the
monolithic net-test-server currently used to test network-related code:

https://codereview.qt-project.org/240564 - macOS
https://codereview.qt-project.org/246535 - MS-Win

So there is at least some grounds to hope docker can solve the
cross-compilation problems Jean-Michaël had in mind.

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Build system for Qt 6

[Thiago Macieira]

On Tuesday, 18 December 2018 14:14:57 PST Sérgio Martins wrote:
> Can't pronounce about the TQC decision, but the qt-project decision is
> easy: We won't choose a build system with unclear future, with vague
> declarations of intent by 1 maintainer.

The question here was only about Qt Creator's plugin to support QBS projects. 
That one is probably fine with just one maintainer.

-- 
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

Re: [Development] Build system for Qt 6

[Sérgio Martins]

On Tue, Dec 18, 2018 at 9:43 PM Richard Weickelt  wrote:
>
> On 18.12.2018 21:20, Thiago Macieira wrote:
> > On Tuesday, 18 December 2018 11:44:38 PST Denis Shienkov wrote:
> >> If Qt maintainers says that they will not remove the QtCreator && QBS
> >> integration in future (I'm about QBS project manager plugin), then I
> >> will not worry (don't care) about CMake. I will use QBS in any case.
> >
> > So long as someone is maintaining the plugin, it should be no problem.
> >
> > Who's the maintainer now? And who's going to be the maintainer in two years?
>
> Now: The same people who have been maintaining Qbs during the last years.
>
> Future: Unclear. Jochen was so kind and made a vague declaration of intent
> here https://lists.qt-project.org/pipermail/qbs/2018-October/002270.html
> At least for keeping Qbs integration in QtCreator at the current level.

Can't pronounce about the TQC decision, but the qt-project decision is
easy: We won't choose a build system with unclear future, with vague
declarations of intent by 1 maintainer.
Being widespread and resilient to being deprecated by a single company
is a huge point in favor of CMake.

And to be honest, I would like to see less stuff on TQC's plate and
not putting all eggs in the same basket. Will they be here in the next
10 years ? I hope so, but the qt-project should play it a bit more
defensive and embrace more 3rdparty solutions where possible to lessen
the burden.


(Despite hating CMake's syntax myself!)

Regards,
Sergio Martins
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Build system for Qt 6

[Richard Weickelt]

On 18.12.2018 21:20, Thiago Macieira wrote:
> On Tuesday, 18 December 2018 11:44:38 PST Denis Shienkov wrote:
>> If Qt maintainers says that they will not remove the QtCreator && QBS
>> integration in future (I'm about QBS project manager plugin), then I
>> will not worry (don't care) about CMake. I will use QBS in any case.
> 
> So long as someone is maintaining the plugin, it should be no problem.
> 
> Who's the maintainer now? And who's going to be the maintainer in two years?

Now: The same people who have been maintaining Qbs during the last years.

Future: Unclear. Jochen was so kind and made a vague declaration of intent
here https://lists.qt-project.org/pipermail/qbs/2018-October/002270.html
At least for keeping Qbs integration in QtCreator at the current level.

Richard
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Build system for Qt 6

[André Pönitz]

On Tue, Dec 18, 2018 at 12:20:37PM -0800, Thiago Macieira wrote:
> On Tuesday, 18 December 2018 11:44:38 PST Denis Shienkov wrote:
> > If Qt maintainers says that they will not remove the QtCreator && QBS
> > integration in future (I'm about QBS project manager plugin), then I
> > will not worry (don't care) about CMake. I will use QBS in any case.
> 
> So long as someone is maintaining the plugin, it should be no problem.
> 
> Who's the maintainer now?

https://wiki.qt.io/Maintainers

Project Management & Targets  Qbs   Christian Kandeler 

> And who's going to be the maintainer in two years?

These days it is difficult to make predictions, especially about
the future.

Andre'
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Build system for Qt 6

[Richard Weickelt]

> 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.

Yes, I implied host. I don't want any build system to crawl my host sysroot
unless being explicitly told to do so. Thanks for clarifying.

[...]

> And that's why I don't cross-compile.
The Intel world is a shiny place to live ;-)
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Build system for Qt 6

[Thiago Macieira]

On Tuesday, 18 December 2018 11:44:38 PST Denis Shienkov wrote:
> If Qt maintainers says that they will not remove the QtCreator && QBS
> integration in future (I'm about QBS project manager plugin), then I
> will not worry (don't care) about CMake. I will use QBS in any case.

So long as someone is maintaining the plugin, it should be no problem.

Who's the maintainer now? And who's going to be the maintainer in two years?

-- 
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

Re: [Development] Build system for Qt 6

[Denis Shienkov]

> preferably one that doesn't involve Qt specific stuff

A main point is that we discuss about using the CMake as an 'advanced' 
buld system in context of Qt.


> Please show a concrete example

I already provided that example - it is cross-compilation. You can try 
to cross-compile a simple application using CMake && Creator for the 
Yocto target.


I'm, as a developer want to see a perfect integration between Qt stuff 
&& CMake, because they (Qt managers) decided to choose the CMake. But 
I'm don't see that it work at all. So, why I need to believe them? How 
much time I need to wait until it will be fixed? Why I need to spent my 
time at attempt to fix it (to lookup in CMake's magic macroses,  tricks, 
to rake its ugly syntax and so on)? I' don't think that CMake is a right 
choose for a Qt developers.


Maybe, if in my case I never faced with my issue, I would be not so 
negative (maybe even I would be closed my eyes to ugly CMake syntax and 
so on).


Another issue it is that I need force to lookup a some CMake toolchains 
in different github projects from custom peoples (e.g. for 
Android/iOS/Keil/IAR toolchains). I mean, that it is not official 
CMake's stuff (I know, that IAR toolchain already has ben added to 
CMake, but I not sure that it will work too). Why I need to use for this 
custom stuff? I'm even not sure that it will work.


Of course, I can write a own stuff (toolchain file or something else) on 
CMake, but it is soo ugly. In my case I just will take QBS and do al 
what I need in 100 times fastest and shorter  and clearer and will not 
worry at all (what and I do).


If Qt maintainers says that they will not remove the QtCreator && QBS 
integration in future (I'm about QBS project manager plugin), then I 
will not worry (don't care) about CMake. I will use QBS in any case.


I tried both CMake && QBS and I can say that for me QBS is a best 
option. I'm not an expert, I'm just a user (consumer) of Qt && QtCreator 
product.


Denis

18.12.2018 21:42, Matthew Woehlke пишет:

On 16/12/2018 12.00, Denis Shienkov wrote:

As we all can see, the CMake loses even QBS. We need to spent a tens of
hours/days to find out the solution, using CMake's , but with QBS same
issue solves for 30 mins or work immediatelly.  Its very funny.

Really? Because *I* don't see that.

This still sounds like FUD. Please show a concrete example (preferably
one that doesn't involve Qt specific stuff, because that's not an
entirely fair comparison) of a problem which a user who is *equally
skilled* (or unskilled) with either tool can solve easily with QBS but
cannot solve easily with CMake.


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Build system for Qt 6

[Thiago Macieira]

On Tuesday, 18 December 2018 10:38:09 PST Matthew Woehlke wrote:
> > I work in the Anaconda Distribution as a software packager and spend
> > a significant amount of my working day battling cmake. As I say it's
> > "ok" for developers but not for packagers.
> 
> AFAIK, that experience is inconsistent with e.g. Fedora packaging where
> things usually Just Work. This makes me wonder if you're trying to do
> something that is contrary to how CMake is intended to be used or how
> packages are intended to be built/packaged/installed?

It doesn't surprise me. There are a ton of bad CMakeLists.txt out there and 
other departments at my company are known to make several of them. Plus, given 
it's popularity, you're expected to see it as a bigger proportion of packages 
to be packaged (selection bias). Autoconf may be more popular, but given its 
complexity I expect it's not used for many new projects, which means the 
problems have been long since fixed in most software that still uses it. So 
yes, having to spend time battling CMake is not surprising.

But I also don't think that's the whole story. Working in software packaging 
involves battling all buildsystems whenever the project has poorly-written 
sources. The difference is whether you can find help out there. Fighting with 
CMake or Meson or Autoconf usually means applying the same fixes over and 
over; fighting with Gyp or Bazel means tearing your hair out; fighting hand-
written Makefiles means a custom solution for every one of them.

-- 
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

Re: [Development] Build system for Qt 6

[Ray Donnelly]

On Dec 18, 2018 12:33 PM, "Matthew Woehlke" 
wrote:

On 15/12/2018 15.49, Ray Donnelly wrote:
> Do you know for example that cmake will find dlls in C:\Windows\System32,

Uh... yeah? I think most people *expect* that...

Would you also rather CMake didn't look in /usr/lib[64] on Linux
systems? *Why*?


Because you are then building software that (possibly unbeknownst to you
unless you are an expert in the arcane ways of cakeh, cannot work without
the presence of any such found DSO (or ABI and SONAME compatible DSO in the
RPATH). Compilers will happily tell you what implicit folders they will
look in on Linux and cmake does query that (it does not pay the same
respect to static linkers even though I sent in a patch for exactly that)
but this isn't of any help on Windows. Explicit is always better than
implicit for this kind of thing and hermeticity is important as is
reproducability. Take a simple example of a build that found your own
zlib.dll yesterday but no longer does today,  because you installed some
random 3rd party software that happened to put zlib.dll in System32 in the
meantime. This particular feature bites all the time. As I said 'ok' for
developers but not for packagers.


> find_package is still inscrutable, and it's for sure the cause of
> most issues we see as software packagers).

Well, yeah, find modules are... not ideal. Modern software should be
providing package configuration files with exported targets.

If we switched to CPS¹ (SHTDI!), that would be even better
(mostly-human-readable files that don't use CMake syntax).

(¹ https://mwoehlke.github.io/cps/)

-- 
Matthew
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Build system for Qt 6

[Matthew Woehlke]

On 16/12/2018 12.00, Denis Shienkov wrote:
> As we all can see, the CMake loses even QBS. We need to spent a tens of
> hours/days to find out the solution, using CMake's , but with QBS same
> issue solves for 30 mins or work immediatelly.  Its very funny.

Really? Because *I* don't see that.

This still sounds like FUD. Please show a concrete example (preferably
one that doesn't involve Qt specific stuff, because that's not an
entirely fair comparison) of a problem which a user who is *equally
skilled* (or unskilled) with either tool can solve easily with QBS but
cannot solve easily with CMake.

-- 
Matthew
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Build system for Qt 6

[Matthew Woehlke]

On 16/12/2018 08.21, Ray Donnelly wrote:
> In particular ide generators cannot express complex build
> dependencies very well and any use of scripts will tend not to work unless
> you hardcore them for each one.

Scripts can be problematic if they need to run stuff that is part of the
build, although I'm not sure *any* build tool handles this gracefully.

This area could definitely use improvement. I think the major problem is
that there is no agreement on how it should work.

> I work in the Anaconda Distribution as a software packager and spend
> a significant amount of my working day battling cmake. As I say it's
> "ok" for developers but not for packagers.
AFAIK, that experience is inconsistent with e.g. Fedora packaging where
things usually Just Work. This makes me wonder if you're trying to do
something that is contrary to how CMake is intended to be used or how
packages are intended to be built/packaged/installed?

-- 
Matthew
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Build system for Qt 6

[Matthew Woehlke]

On 15/12/2018 15.49, Ray Donnelly wrote:
> Do you know for example that cmake will find dlls in C:\Windows\System32,

Uh... yeah? I think most people *expect* that...

Would you also rather CMake didn't look in /usr/lib[64] on Linux
systems? *Why*?

> find_package is still inscrutable, and it's for sure the cause of
> most issues we see as software packagers).

Well, yeah, find modules are... not ideal. Modern software should be
providing package configuration files with exported targets.

If we switched to CPS¹ (SHTDI!), that would be even better
(mostly-human-readable files that don't use CMake syntax).

(¹ https://mwoehlke.github.io/cps/)

-- 
Matthew
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Build system for Qt 6

[Kevin Kofler]

Christian Gagneraud wrote:
> Fairly interesting indeed, and very surprising too, this WIN32/Android
> stuff was fixed last week, i didn't invent it.
> Maybe, we ran into bad luck.

The bug you ran to only hits you when ALL 3 of the following conditions are 
satisfied:
1. Windows build host,
2. non-Windows build target, AND
3. using Qt autogen.

Condition 3 is probably the one the Google developers never exercised when 
testing their Android Studio NDK support on Windows. I doubt they test with 
Qt, unfortunately.

Kevin Kofler

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Build system for Qt 6

[Christian Gagneraud]

On Mon, 17 Dec 2018 at 21:43, Jean-Michaël Celerier
 wrote:
> > 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

Fairly interesting indeed, and very surprising too, this WIN32/Android
stuff was fixed last week, i didn't invent it.
Maybe, we ran into bad luck.

> 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).

AFAIU,  you still need graddle with Android Studio and/or Cmake, to
deal with some "details" like packaging, manifest, resources,
multi-arch, ...

Here comes my ignorance of the tool, I'll direct my questions to
qt-interest or cmake ML for point outs.

>
> 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.

What do you mean by 'everywhere'? Native Windows dockers are still
experimental, and i haven't heard of native MacOS docker yet (might
have missed smth).
Automating Linux/Android with Linux is the easiest part.

> Also, there's WSL, I suppose that it should work somehow.

I've tried that, on a native Windows machine (and it's not compatible
with Virtual Box for whatever reason - HyperV responsability?).
I have no interest to run LOW ("Linux on Windows", that is what it
should be called: it produces Linux binaries).
I've tried as well Linux docker for windows (again, no interest, and
it requires VB), last resort is windows docker for windows...
it's coming and it's BIG (10 GB for a 'core' layer)

> > 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

Latest commit dc10370 on Aug 15, 2017.
It's an example of a CMake-based project using a dedicated FPGA
workflow (not a CMake toolchain, nor VHDL/Verilog), targeted at a very
specific family of FPGA.
Quartus is Altera's old "IDE", Altera manufactures FPGA and was bought
by Intel few years ago (15B$) [1][2]
I've used it, like any student of my time/space.
They have a free (as in free beer) versions for
students/academic/hobbyist, that you can run from the command line...
GNU make would be fine with dealing with this example project, i would
say that 10 SLOCs are enough.

Chris

[1] 
https://newsroom.intel.com/news-releases/intel-completes-acquisition-of-altera/
[2] https://en.wikipedia.org/wiki/Altera
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Build system for Qt 6

[Jean-Michaël Celerier]

> 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 
wrote:

> On Mon, 17 Dec 2018 at 18:38, Thiago Macieira 
> 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 lng 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 

Re: [Development] Build system for Qt 6

[Christian Gagneraud]

On Mon, 17 Dec 2018 at 17:53, Ray Donnelly  wrote:
> On Sun, Dec 16, 2018, 10:36 PM Richard Weickelt > The discussion about build systems reminds me a bit of a religious war. I
>> made my peace with CMake and use it only when being paid for. It allows me
>> to use the browser more often and to find obscure stuff on the internet.
>> It's an expensive tool. After work I want to get my stuff done with low
>> investment, hence I often use Qbs ;-)
>
> That sounds like a very sensible approach Richard.

Same here. At work, we're attempting at using CMake to do Android
builds, but once back at home, i switch to Qbs.

The funny part, is that lot of people at work think that i am the
'CMake expert', you should see their face when i tell them what i
think about CMake (nothing rude or wild, but definitely negative).
After that i try to help as much as i can. The reason being that I do
care about how we cross-build stuff, and how maintainable our build
recipes are, whatever the tool we use.

Chris
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Build system for Qt 6

[Christian Gagneraud]

On Mon, 17 Dec 2018 at 18:38, Thiago Macieira  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 lng 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

Re: [Development] Build system for Qt 6

[Thiago Macieira]

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.

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.

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.

-- 
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

Re: [Development] Build system for Qt 6

[Ray Donnelly]

On Sun, Dec 16, 2018, 10:36 PM Richard Weickelt 
> > Here in Fedora, we actually *want* CMake to find system libraries. The
> > situation on Windows is of course different, and third-party packages
> for
> > GNU/Linux may or may not want to use the system libraries, but our
> > distribution packages definitely want to use them.
>
> ... 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.
>
> Therefore I see build automation and packaging as orthogonal processes. IMO
> it lowers the usage complexity and leaves more room for flexibility when
> being kept separate. The package system would be responsible to resolve
> dependencies and could produce files that the build automation system would
> consume. I kind of like the idea behind Conan which does only package
> management, dependency resolution and provides simple-enough generators for
> all kinds of build automation system.
>
> The discussion about build systems reminds me a bit of a religious war. I
> made my peace with CMake and use it only when being paid for. It allows me
> to use the browser more often and to find obscure stuff on the internet.
> It's an expensive tool. After work I want to get my stuff done with low
> investment, hence I often use Qbs ;-)
>

That sounds like a very sensible approach Richard.

>
> Richard
> ___
> 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

Re: [Development] Build system for Qt 6

[Richard Weickelt]

> Here in Fedora, we actually *want* CMake to find system libraries. The 
> situation on Windows is of course different, and third-party packages for 
> GNU/Linux may or may not want to use the system libraries, but our 
> distribution packages definitely want to use them.

... 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.

Therefore I see build automation and packaging as orthogonal processes. IMO
it lowers the usage complexity and leaves more room for flexibility when
being kept separate. The package system would be responsible to resolve
dependencies and could produce files that the build automation system would
consume. I kind of like the idea behind Conan which does only package
management, dependency resolution and provides simple-enough generators for
all kinds of build automation system.

The discussion about build systems reminds me a bit of a religious war. I
made my peace with CMake and use it only when being paid for. It allows me
to use the browser more often and to find obscure stuff on the internet.
It's an expensive tool. After work I want to get my stuff done with low
investment, hence I often use Qbs ;-)

Richard
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Build system for Qt 6

[Thiago Macieira]

On Sunday, 16 December 2018 12:00:29 PST Ray Donnelly wrote:
> it seems to have taken
> over) is that I prefer it to bazel in most respects.

Bazel and gyp are in the list of systems packagers positively hate in our 
case.

-- 
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

Re: [Development] Build system for Qt 6

[Kevin Kofler]

Ray Donnelly wrote (NOTE: I reordered the quotes so that my replies can be 
read in order):
> I work in the Anaconda Distribution as a software packager and spend a
> significant amount of my working day battling cmake. As I say it's "ok"
> for developers but not for packagers.

I'm a packager for Fedora, a GNU/Linux distribution. I find CMake to be the 
nicest build system to work with. It is common enough for there to be macros 
and snippets/templates making it easy to package software using it.

The same theoretically applies to the Autotools, but the Autotools are a 
pain as soon as you need to change something, because:
* the script that is executed is generated, so if you make any changes to
  the actual source code, you have to rerun autoreconf or equivalent, and
* the syntax is harder to work with, so it is harder to make changes to
  begin with.
CMake, on the other hand, only requires you to edit the CMakeLists.txt 
file(s), with a much nicer syntax.

In addition, if we fix a bug in the autotools themselves, or in some aclocal 
snippet, we also have to regenerate or patch the generated files in dozens 
of packages bundling the generated scripts. On the other hand, if we fix a 
bug in CMake or in a Find*.cmake/*Config.cmake installed systemwide, a 
rebuild with no changes is enough to get other packages to pick up the fix.

Custom build systems only used by one or a handful project(s), such as QBS, 
GN, etc. are a pain because they require custom build instructions in our 
package specfiles that are specific to that build system (e.g., whereas 
Autotools and CMake use DESTDIR, QMake insists on INSTALL_ROOT) and because 
there are often no templates for those custom instructions (because your 
package's specfile likely *is* the template).

(Sadly, I don't think we will ever be able to build QtWebEngine without GN 
or yet another Chromium-only replacement (GN was already the replacement for 
Gyp). Chromium insists on using custom non-standard tooling.)

And then there are the build systems that are a *real* pain, e.g., those 
that try to automatically download dependencies from the Internet (a no-go 
during our package builds). The only way to get dependencies downloaded is 
*before* the build starts and only from Fedora packages (not some random web 
location), by specifying them as BuildRequires in the specfile. The build 
system must *never* attempt to download anything. As I understand it, Bazel 
is one of the major offenders there.

> I'll not going to do this for you, sorry. I also pointed out the lack of
> isolation from system libraries by default as a major problem.

Here in Fedora, we actually *want* CMake to find system libraries. The 
situation on Windows is of course different, and third-party packages for 
GNU/Linux may or may not want to use the system libraries, but our 
distribution packages definitely want to use them.

Kevin Kofler

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Build system for Qt 6

[Alexander Neundorf]

On 2018 M12 16, Sun 07:21:35 CET Ray Donnelly wrote:
> I'll not going to do this for you, sorry. I also pointed out the lack of
> isolation from system libraries by default as a major problem.

just to make sure we are talking about the same: basically you are saying that 
the Visual Studio generators don't support some features, or something else ?

Alex

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Build system for Qt 6

[Ray Donnelly]

The

On Sun, Dec 16, 2018, 1:17 PM Thiago Macieira  On Sunday, 16 December 2018 05:21:35 PST Ray Donnelly wrote:
> >  As I say it's "ok" for developers but not for
> > packagers.
>
> Which one is ok for packagers?
>
> In Clear Linux, we also have people who dislike CMake. They recommend only
> Autoconf and Meson.
>

I agree with that. I also like qbs and wish it had seen more adoption so
that people would be less nervous about it .. and that it was spun out from
requiring qt (or any heavy dependencies) so it could be built much earlier
in the stack. Still it hasn't and that's a shame. One thing I'll say in
cmake's defence (not that it needs any from me, it seems to have taken
over) is that I prefer it to bazel in most respects.

>
> --
> 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

Re: [Development] Build system for Qt 6

[Adam Majer]

On 12/16/2018 08:05 PM, Thiago Macieira wrote:

On Sunday, 16 December 2018 05:21:35 PST Ray Donnelly wrote:

  As I say it's "ok" for developers but not for
packagers.


Which one is ok for packagers?


From packaging standpoint, autotools are clearly the best. But I would 
say cmake is ok for 2nd place. qmake is also nice, but that's what we 
want to get rid of.


In general, the rule would be: any system that is widely used is 
superior to any system that is not so widely used. If you have some 
magic buildsystem that no one is using, it will sooner or later bite you 
in the butt. The lack of maintenance and development and simply users of 
the build system will result in large technical debt as compared to more 
popular build systems. And eventually one will have to scrap it.


I'll just give two examples here. Boost.Build - was to be the "simplest" 
build system... and now no one wants to use it, even the Boost project. 
It's the opposite of simple to understand. Another example is Gyp. It's 
used by Node and V8. It's been abandoned by Google and it's using 
python2 and there is little motivation to migrate it to Python3 - 
something will have to give here soon. And in both these cases using 
cmake would have resulted in easier maintenance. Actually, Boost is 
slowly migrating to cmake.


So yes, just use cmake knowing that you will find some problems. But at 
least you no longer have to maintain the build tool itself.


- Adam
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Build system for Qt 6

[Thiago Macieira]

On Sunday, 16 December 2018 09:00:29 PST Denis Shienkov wrote:
> As we all can see, the CMake loses even QBS. We need to spent a tens of
> hours/days to find out the solution, using CMake's , but with QBS same
> issue solves for 30 mins or work immediatelly.  Its very funny.

Then by all means continue developing it and maintaining the Qt branches for 
it. This is open source, no one is stopping you.

When the time comes for us to actually make the choice, if the QBS branch is 
in good shape and fulfills the requirements set forth, it can still be 
considered. Note especially the requirement of large and complex non-Qt 
software being used with it and packaged continuously in more than one Linux 
distro for 2 years.

-- 
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

Re: [Development] Build system for Qt 6

[Thiago Macieira]

On Sunday, 16 December 2018 05:21:35 PST Ray Donnelly wrote:
>  As I say it's "ok" for developers but not for
> packagers.

Which one is ok for packagers?

In Clear Linux, we also have people who dislike CMake. They recommend only 
Autoconf and Meson.

-- 
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

Re: [Development] Build system for Qt 6

[Denis Shienkov]

> I work in the Anaconda Distribution as a software packager and spend 
a significant amount of my working day battling cmake.


As we all can see, the CMake loses even QBS. We need to spent a tens of 
hours/days to find out the solution, using CMake's , but with QBS same 
issue solves for 30 mins or work immediatelly.  Its very funny.


> As I say it's "ok" for developers but not for packagers.

Neh.. No, it also is not 'ok' for developers too. :)



16.12.2018 16:21, Ray Donnelly пишет:
I'll not going to do this for you, sorry. I also pointed out the lack 
of isolation from system libraries by default as a major problem.


Take any complex project and try it. Basically very few will work on 
all generators. In particular ide generators cannot express complex 
build dependencies very well and any use of scripts will tend not to 
work unless you hardcore them for each one. I'm not in a position to 
investigate this. I just want build tools to get out of my way. I work 
in the Anaconda Distribution as a software packager and spend a 
significant amount of my working day battling cmake. As I say it's 
"ok" for developers but not for packagers.


On Sun, Dec 16, 2018, 6:05 AM Alexander Neundorf  wrote:


Hi,

On 2018 M12 15, Sat 14:49:16 CET Ray Donnelly wrote:
> On Sat, Dec 15, 2018, 6:35 AM Alexander Neundorf
mailto:neund...@kde.org> wrote:
> > On 2018 M10 30, Tue 18:33:03 CET NIkolai Marchenko wrote:
> > > > Thus this investment would be at the expense of other
things we’d like
> >
> > to
> >
> > > do, like improving our IDE, working on rearchitecting and
cleaning up
> > > our
> > > core frameworks for Qt 6 or the design tooling we are currently
> > > investing
> > > into. The Qt Company believes that those other investments
are more
> > > important for the future of Qt than our choice of build tool.
> > >
> > > I don't understand. Will it not be a return on the
investment when
> > > people
> > > use Qt "because their build tool is the best around" ?
> > > Project files are at the root of every project. There are
all sorts of
> >
> > good
> >
> > > IDEs around but ppl mostly are forced to use CMAKE which no
one seems to
> > > like.
> >
> > I do like it :-P
> > CMake can generate not only Makefiles and ninja files, but
also project
> > files for
> > IDEs (Visual Studio, XCode, Eclipse).
> > With the addition of "server mode" 2 or 3 years ago or so now
also a tight
> > integration with IDEs is possible. I think QtCreator and/or
KDevelop make
> > use
> > of this.
> > So, when using cmake the developer is free to chose whether he
wants to
> > use
> > simply an editor and make/ninja, or a full IDE.
>
> In my experience with cmake any non trivial implementation only
tends to
> work with the generator(s) the developer tested against most
recently.

Which features are not working for which generators ?
As far as I know the ASM support may not really be working with
the Visual
Studio generators. Is there more ?
IMO those are issues/bugs, and developers who want to use these
generators
should put some effort into getting this fixed.

Alex



___
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

Re: [Development] Build system for Qt 6

[Ray Donnelly]

I'll not going to do this for you, sorry. I also pointed out the lack of
isolation from system libraries by default as a major problem.

Take any complex project and try it. Basically very few will work on all
generators. In particular ide generators cannot express complex build
dependencies very well and any use of scripts will tend not to work unless
you hardcore them for each one. I'm not in a position to investigate this.
I just want build tools to get out of my way. I work in the Anaconda
Distribution as a software packager and spend a significant amount of my
working day battling cmake. As I say it's "ok" for developers but not for
packagers.

On Sun, Dec 16, 2018, 6:05 AM Alexander Neundorf  Hi,
>
> On 2018 M12 15, Sat 14:49:16 CET Ray Donnelly wrote:
> > On Sat, Dec 15, 2018, 6:35 AM Alexander Neundorf  wrote:
> > > On 2018 M10 30, Tue 18:33:03 CET NIkolai Marchenko wrote:
> > > > > Thus this investment would be at the expense of other things we’d
> like
> > >
> > > to
> > >
> > > > do, like improving our IDE, working on rearchitecting and cleaning up
> > > > our
> > > > core frameworks for Qt 6 or the design tooling we are currently
> > > > investing
> > > > into. The Qt Company believes that those other investments are more
> > > > important for the future of Qt than our choice of build tool.
> > > >
> > > > I don't understand. Will it not be a return on the investment when
> > > > people
> > > > use Qt "because their build tool is the best around" ?
> > > > Project files are at the root of every project. There are all sorts
> of
> > >
> > > good
> > >
> > > > IDEs around but ppl mostly are forced to use CMAKE which no one
> seems to
> > > > like.
> > >
> > > I do like it :-P
> > > CMake can generate not only Makefiles and ninja files, but also project
> > > files for
> > > IDEs (Visual Studio, XCode, Eclipse).
> > > With the addition of "server mode" 2 or 3 years ago or so now also a
> tight
> > > integration with IDEs is possible. I think QtCreator and/or KDevelop
> make
> > > use
> > > of this.
> > > So, when using cmake the developer is free to chose whether he wants to
> > > use
> > > simply an editor and make/ninja, or a full IDE.
> >
> > In my experience with cmake any non trivial implementation only tends to
> > work with the generator(s) the developer tested against most recently.
>
> Which features are not working for which generators ?
> As far as I know the ASM support may not really be working with the Visual
> Studio generators. Is there more ?
> IMO those are issues/bugs, and developers who want to use these generators
> should put some effort into getting this fixed.
>
> Alex
>
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Build system for Qt 6

[Alexander Neundorf]

Hi,

On 2018 M12 15, Sat 14:49:16 CET Ray Donnelly wrote:
> On Sat, Dec 15, 2018, 6:35 AM Alexander Neundorf  > On 2018 M10 30, Tue 18:33:03 CET NIkolai Marchenko wrote:
> > > > Thus this investment would be at the expense of other things we’d like
> > 
> > to
> > 
> > > do, like improving our IDE, working on rearchitecting and cleaning up
> > > our
> > > core frameworks for Qt 6 or the design tooling we are currently
> > > investing
> > > into. The Qt Company believes that those other investments are more
> > > important for the future of Qt than our choice of build tool.
> > > 
> > > I don't understand. Will it not be a return on the investment when
> > > people
> > > use Qt "because their build tool is the best around" ?
> > > Project files are at the root of every project. There are all sorts of
> > 
> > good
> > 
> > > IDEs around but ppl mostly are forced to use CMAKE which no one seems to
> > > like.
> > 
> > I do like it :-P
> > CMake can generate not only Makefiles and ninja files, but also project
> > files for
> > IDEs (Visual Studio, XCode, Eclipse).
> > With the addition of "server mode" 2 or 3 years ago or so now also a tight
> > integration with IDEs is possible. I think QtCreator and/or KDevelop make
> > use
> > of this.
> > So, when using cmake the developer is free to chose whether he wants to
> > use
> > simply an editor and make/ninja, or a full IDE.
> 
> In my experience with cmake any non trivial implementation only tends to
> work with the generator(s) the developer tested against most recently.

Which features are not working for which generators ?
As far as I know the ASM support may not really be working with the Visual 
Studio generators. Is there more ?
IMO those are issues/bugs, and developers who want to use these generators 
should put some effort into getting this fixed.

Alex

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Build system for Qt 6

[Ray Donnelly]

On Sat, Dec 15, 2018, 6:35 AM Alexander Neundorf  On 2018 M10 30, Tue 18:33:03 CET NIkolai Marchenko wrote:
> > > Thus this investment would be at the expense of other things we’d like
> to
> >
> > do, like improving our IDE, working on rearchitecting and cleaning up our
> > core frameworks for Qt 6 or the design tooling we are currently investing
> > into. The Qt Company believes that those other investments are more
> > important for the future of Qt than our choice of build tool.
> >
> > I don't understand. Will it not be a return on the investment when people
> > use Qt "because their build tool is the best around" ?
> > Project files are at the root of every project. There are all sorts of
> good
> > IDEs around but ppl mostly are forced to use CMAKE which no one seems to
> > like.
>
> I do like it :-P
> CMake can generate not only Makefiles and ninja files, but also project
> files for
> IDEs (Visual Studio, XCode, Eclipse).
> With the addition of "server mode" 2 or 3 years ago or so now also a tight
> integration with IDEs is possible. I think QtCreator and/or KDevelop make
> use
> of this.
> So, when using cmake the developer is free to chose whether he wants to
> use
> simply an editor and make/ninja, or a full IDE.
>

In my experience with cmake any non trivial implementation only tends to
work with the generator(s) the developer tested against most recently. Also
even when more than one generator works on a given platform, the binaries
produced will differ in many ways, some important, some not so important.
This is a terrible situation.

Other than that to achieve this multi generator goal, you end up with a
lowest common denominator or features (or generators that cannot be used on
a given project).

I dislike meta-make systems. They work ok for software developers but for
software packagers they tend to be very problematic.

Do you know for example that cmake will find dlls in C:\Windows\System32,
common libs like zlib often get put there and disabling this requires an
explicit option to be passed (and discovering that this is what happens and
how to prevent it were far from trivial - find_package is still
inscrutable, and it's for sure the cause of most issues we see as software
packagers).


> Alex
>
> ___
> 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

Re: [Development] Build system for Qt 6

[Alexander Neundorf]

On 2018 M10 30, Tue 18:33:03 CET NIkolai Marchenko wrote:
> > Thus this investment would be at the expense of other things we’d like to
> 
> do, like improving our IDE, working on rearchitecting and cleaning up our
> core frameworks for Qt 6 or the design tooling we are currently investing
> into. The Qt Company believes that those other investments are more
> important for the future of Qt than our choice of build tool.
> 
> I don't understand. Will it not be a return on the investment when people
> use Qt "because their build tool is the best around" ?
> Project files are at the root of every project. There are all sorts of good
> IDEs around but ppl mostly are forced to use CMAKE which no one seems to
> like.

I do like it :-P
CMake can generate not only Makefiles and ninja files, but also project files 
for 
IDEs (Visual Studio, XCode, Eclipse).
With the addition of "server mode" 2 or 3 years ago or so now also a tight 
integration with IDEs is possible. I think QtCreator and/or KDevelop make use 
of this.
So, when using cmake the developer is free to chose whether he wants to use 
simply an editor and make/ninja, or a full IDE.

Alex

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Build system for Qt 6

[Kuba Ober]

> 29 okt. 2018 kl. 08:17 skrev Lars Knoll :
> 
> As you will probably remember, there have been lively discussions around what 
> kind of build tool to use for Qt 6 both during Qt Contributor Summits as well 
> as on this mailing list.
> 
> There has been a strong consent that we should move away from qmake as our 
> build tool for Qt due to many shortcomings and the burden we have maintaining 
> the system.

For what it’s worth, the easiest way I found to keep the investment we had 
internally at work in qmake projects was to get it to produce ninja output. We 
used it for C/assembly firmware builds – completely unrelated to Qt, and 
started doing it sometime around Qt 4 beta era. I can’t say how good of a 
decision it was, but it worked (still works!)… and then I moved everything over 
to cmake.

I ended up tackling qtcore builds with cmake for good measure –  predating the 
current Qt-with-cmake effort by a year or two. I wasn’t too brave there at all, 
though, and qmake still does configure work for Qt, so it’s not really 
something that would be usable as-is for Qt itself; it’s a novelty if that. I 
also maintained qbs builds for everything that cmake built for us, sans qtcore 
– but I’m not particularly enamored with either. They both have quirks, to say 
the least.

I have no strong opinions otherwise, so my only question is: would the Qt 
project be willing to consider merging ninja output mode into qmake at all? I’d 
get it into reviewable shape if so, or let it die in obscurity otherwise. As 
far as I can tell, it builds everything that uses qmake with no trouble, on 
platforms I have access to: certainly all of Qt 5.11 and 4.8, and a few other 
projects I tried, but perhaps I’d extend that coverage before considering it 
“good enough to go into the wild”.

At the very least, for everyone who laments the inefficiency of recursive 
make/jom, it provides an instant “fix” that can slash no-work-done builds by an 
order of magnitude or more (Qt builds really benefit) – there’s no recursion at 
all, not even qmake recursion. Yeah, getting rid of that was a prerequisite.

As a curiosity, a friend had implement most of late-70s-era HP Basic inside 
qmake, including line number support, as a bar bet of sorts, but I’m not sure 
whether that makes any of my efforts look much saner in comparison :) Now that 
I think of it, I should be able to put that up on GitHub sometime.

Cheers, Kuba Ober
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Matthew Woehlke]

On 02/11/2018 13.39, Oswald Buddenhagen wrote:
> i honestly don't understand what your problem is. the only difference
> between the approaches is that you centralize the meta data, while i
> distribute it. TTA works exactly the same way.

My approach forces packages to be transactional. Either you find *all*
the required components in a package spec, or you ignore that package
spec. Once you've found a package, you "commit" to that; if anything
subsequently goes wrong, it's up to the user to fix it (e.g. by
specifying a different instance of the package that's causing problems).

Your approach doesn't provide for transaction points except at the
component level. That means it either has to be able to arbitrarily
backtrack (global dependency solving), or there exist cases that will
cause it to get stuck that my approach would handle more gracefully.

> On Fri, Nov 02, 2018 at 11:59:39AM -0400, Matthew Woehlke wrote:
>> For that matter, what happens to namespacing? Can I do this?
>>
>>   find_package(Qt 5.8 COMPONENTS Core Gui)
>>   find_package(Qt 2.1 COMPONENTS WebEngine)
>
> sure you can.

I suspect that would require much more significant alterations to CMake.
Also...

>> Let's say we allow that... what then is Qt_FOUND? Qt_VERSION?
>
> not relevant in the qbs model, because "package" isn't a thing there -
> that's only a convenience syntax for importing multiple modules in one
> go.

...this *is* relevant to CMake, so it needs to have a plausible answer.
Otherwise, what you are proposing is not helpful, because CMake will not
be able to use it.

It is fairly easy to make use of a package/component based system in a
tool that only works on components. Going the other way around is more
problematic. (Except... a tool that only uses components is going to
have the sorts of issues I've been describing.)

>> OTOH, there is nothing stopping you from producing component-level
>> compatibility CPS's that are just references to the individual
>> components in a multi-component package.
>
> that's correct, but then you potentially have a problem in the inverse
> direction of generating CPS files from a qbs project.

Well, that sounds like QBS's problem ;-).

Offhand, I'd guess that the most plausible solution is to manually
specify a package-level spec and auto-generate component-level specs.
(Yes, you can do that with CPS.)

-- 
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Edward Welbourne]

On 10/30/18 12:16 PM, Bogdan Vatra via Development wrote:
>>> d) While c.1 and c.2 can be fixed with some effort, here we have bigger
>>> problems:
>>>
>>>- Instread to port QBS to QML JS in the first second when QtScript was
>>>  deprecated, they fork it! I know that back then QML JS needed
>>>  some love, but instead to collaborate with QML JS folks they
>>>  decided keep using QtScript!

În ziua de luni, 12 noiembrie 2018, la 15:06:00 EET, Joerg Bornemann a scris:
>> QtScript was never forked. It even was included as git submodule at some
>> point. Unaltered.

Bogdan Vatra (12 November 2018 14:39)
>  This is very funny! did you included it as git submodule just because
> you like submodules?

Including it as a sub-module is exactly what qt5.git did, so qbs was
using it exactly the way qt5 used it.  This is not a fork: a fork has
separate development that isn't being merged back to the upstream.  If
the QBS team had any patches for QtScript or the QML parser, using them
as sub-modules meant that their fixes went into the upstream module, so
was used by Qt5 as soon as it was in use by QBS (give or take qt5's
integration delays).  Please don't misrepresent the history.

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Bogdan Vatra via Development]

Hi,

În ziua de luni, 12 noiembrie 2018, la 15:06:00 EET, Joerg Bornemann a scris:
> On 10/30/18 12:16 PM, Bogdan Vatra via Development wrote:
> 
> Late to the game, but I feel the urge to comment on some things.
> 
> 
> > c.2) Incomplete! A while ago, I created a QBS plugin for KDevelop[1] and
> > I
> > found some problems, see how QBS developers treat them here: https://
> > bugreports.qt.io/browse/QBS-902 . That was the moment when I started to
> > have doubts :).
> 
> 
> This bug report is lacking crucial information to handle it properly, 
> like what's the expected outcome etc.
> As you are known as a seasoned developer we felt you didn't need the 
> https://wiki.qt.io/Reporting_Bugs link.
> 

  Even the whole discussion is futile now, can you pretty please tell me what 
"crucial information" are those issues missing? IMHO the titile of each issue 
is more than enough for any QBS developer.

> 
> > d) While c.1 and c.2 can be fixed with some effort, here we have bigger
> > problems:
> > 
> >- Instread to port QBS to QML JS in the first second when QtScript was
> > 
> > deprecated, they fork it! I know that back then QML JS needed some love,
> > but instead to collaborate with QML JS folks they decided keep using
> > QtScript!
> 
> QtScript was never forked. It even was included as git submodule at some 
> point. Unaltered.
> 

  This is very funny! did you included it as git submodule just because you 
like submodules?

> 
> > IIRC a brave soul, port it to QML JS, but guess what, QBS devs reject it
> > and kept using QtScript!
> 
> 
> You're remembering incorrectly.

Might be... If I'll have time I'll check it.

> There was never such a port.
> 
> 
> >   - Even more, they found a few problem also in QML parser, and guess
> >   what,
> > 
> > they forked also QML!
> 
> 
> The QML parser was never forked. It always has been a copy of the QML 
> parser, because we didn't want a dependency to the QtQml module.
> 
Again this is very funny: you didn't fork it, you copy it that's a huge 
diference :).

Sadly, in this moment it's too late to continue discussions on this matter...

Cheers,
BogDan.


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Joerg Bornemann]

On 10/30/18 12:16 PM, Bogdan Vatra via Development wrote:

Late to the game, but I feel the urge to comment on some things.

> c.2) Incomplete! A while ago, I created a QBS plugin for KDevelop[1] and I
> found some problems, see how QBS developers treat them here: https://
> bugreports.qt.io/browse/QBS-902 . That was the moment when I started to have
> doubts :).

This bug report is lacking crucial information to handle it properly, 
like what's the expected outcome etc.
As you are known as a seasoned developer we felt you didn't need the 
https://wiki.qt.io/Reporting_Bugs link.

> d) While c.1 and c.2 can be fixed with some effort, here we have bigger
> problems:
>- Instread to port QBS to QML JS in the first second when QtScript was
> deprecated, they fork it! I know that back then QML JS needed some love, but
> instead to collaborate with QML JS folks they decided keep using QtScript!

QtScript was never forked. It even was included as git submodule at some 
point. Unaltered.

> IIRC a brave soul, port it to QML JS, but guess what, QBS devs reject it and
> kept using QtScript!

You're remembering incorrectly.
There was never such a port.

>   - Even more, they found a few problem also in QML parser, and guess what,
> they forked also QML!

The QML parser was never forked. It always has been a copy of the QML 
parser, because we didn't want a dependency to the QtQml module.



Cheers,

Joerg
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Oswald Buddenhagen]

On Fri, Nov 02, 2018 at 11:59:39AM -0400, Matthew Woehlke wrote:
> On 01/11/2018 08.10, Oswald Buddenhagen wrote:
> > no, instead i told you that your premise of needing a _global_ solver is
> > wrong.
> 
> ...but you have failed to explain how dependency resolution will succeed
> in a scenario such as I have outlined.
> 
> Actually, I realize now there is a possible answer: it *doesn't*
> succeed. It finds A.X-1.2. Then it finds A.Y-1.1 which is incompatible,
> and gives up, forcing the user to manually correct the situation.
> 
i honestly don't understand what your problem is. the only difference
between the approaches is that you centralize the meta data, while i
distribute it. TTA works exactly the same way.

> > users want to think in terms of namespaces, not packages. at
> > least i do. at least for modules that aren't part of "qt" but are hosted
> > on qt-project infrastructure. qtwebkit is an excellent example, and
> > qtwebengine will probably follow soon due to wanting release cycle
> > decoupling.
> 
> ...but having a separate release cycle is an excellent reason to *not*
> be the same package. And I'm not entirely convinced that users shouldn't
> be aware of that distinction, because it may well matter when they need
> to specify more fine-grained version requirements (i.e. '5.8' vs. '5').
> 
> For that matter, what happens to namespacing? Can I do this?
> 
>   find_package(Qt 5.8 COMPONENTS Core Gui)
>   find_package(Qt 2.1 COMPONENTS WebEngine)
> 
sure you can.

> Let's say we allow that... what then is Qt_FOUND? Qt_VERSION?
>
not relevant in the qbs model, because "package" isn't a thing there -
that's only a convenience syntax for importing multiple modules in one
go.

> Do I have targets Qt::Core and Qt::WebEngine?
>
yes

> Do we allow targets in the same namespace that have different
> versions?
> 
yes, provided they don't break each other.

> OTOH, there is nothing stopping you from producing component-level
> compatibility CPS's that are just references to the individual
> components in a multi-component package.
> 
that's correct, but then you potentially have a problem in the inverse
direction of generating CPS files from a qbs project.

> One reason I am optimistic about CPS's chances re: CMake is that it
> behaves very similarly to how CMake *currently works*. Trying to
> shoehorn in something that works very differently is going to be more
> work and face more resistance.
> 
it certainly is an *improvement*.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Matthew Woehlke]

On 01/11/2018 08.10, Oswald Buddenhagen wrote:
> no, instead i told you that your premise of needing a _global_ solver is
> wrong.

...but you have failed to explain how dependency resolution will succeed
in a scenario such as I have outlined.

Actually, I realize now there is a possible answer: it *doesn't*
succeed. It finds A.X-1.2. Then it finds A.Y-1.1 which is incompatible,
and gives up, forcing the user to manually correct the situation.

That has a larger surface area for breakage than CPS as currently
formulated, but whatever. I suspect you'll find it a harder sell.

> users want to think in terms of namespaces, not packages. at
> least i do. at least for modules that aren't part of "qt" but are hosted
> on qt-project infrastructure. qtwebkit is an excellent example, and
> qtwebengine will probably follow soon due to wanting release cycle
> decoupling.

...but having a separate release cycle is an excellent reason to *not*
be the same package. And I'm not entirely convinced that users shouldn't
be aware of that distinction, because it may well matter when they need
to specify more fine-grained version requirements (i.e. '5.8' vs. '5').

For that matter, what happens to namespacing? Can I do this?

  find_package(Qt 5.8 COMPONENTS Core Gui)
  find_package(Qt 2.1 COMPONENTS WebEngine)

Let's say we allow that... what then is Qt_FOUND? Qt_VERSION? Do I have
targets Qt::Core and Qt::WebEngine? Do we allow targets in the same
namespace that have different versions?

OTOH, there is nothing stopping you from producing component-level
compatibility CPS's that are just references to the individual
components in a multi-component package.

One reason I am optimistic about CPS's chances re: CMake is that it
behaves very similarly to how CMake *currently works*. Trying to
shoehorn in something that works very differently is going to be more
work and face more resistance.

-- 
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Lars Knoll]

> On 30 Oct 2018, at 22:57, Christian Gagneraud  wrote:
> 
> Hi Lars,
> 
> On Tue, 30 Oct 2018 at 23:42, Lars Knoll  wrote:
>>> On 30 Oct 2018, at 05:00, Christian Gagneraud  wrote:
>>> On Tue, 30 Oct 2018 at 01:17, Lars Knoll  wrote:
>>> Then why spend energy/money to fix something that is broken by design?
>>> (Again, that is a personal opinion, if needed to say)
>> 
>> As I said in my email, I unfortunately don’t see a way how The Qt Company 
>> can push Qbs forward. It was a difficult decision because I very much like 
>> the ideas and the technology used in Qbs.
>> 
>> From the perspective of a company, we have to justify investments we do, and 
>> they have to make sense not only from a perspective of being cool 
>> technology, but also how they can in the end generate business for us. In 
>> addition, there’s always the question, what we then can’t do (because the 
>> total money we can invest in R&D is limited).
>> 
>> Looking at the fact, that we can’t earn money on a build system and that it 
>> would require quite a lot of funding to make it more than a niche product it 
>> doesn’t make sense to pursue it further. Instead we would rather use the 
>> money to improve Qt and Qt Creator.
> 
> This doesn't add up, why did you develop and still develop and
> maintain 'coin' then?

Of course things don’t add up if you try to compare apples to oranges ;-)

One can’t simply compare one project to another that way.

Before we started coin, we tried to find something that fits our needs for CI. 
Unfortunately, we couldn’t. So we started the work on coin because we needed a 
better CI infrastructure than we had. Revenue is in a way the wrong term here, 
as having a decent CI is crucial to being able to develop and ship Qt.

> You're not making money with it. It's costing you (a lot?) and is a
> critical part of your QA infra.

A working CI is critical to Qt and being able to keep up the quality. I do 
think that has a lot of value for Qt.

Cheers,
Lars

> 
>>> - Did Jake left the QtC due to your early decision to drop qbs? ( I
>>> personally do think that the decision was taken long time ago)
>> 
>> The decision to not continue to develop Qbs was done very recently. It 
>> doesn’t make sense to make a decision and then not take actions. Whatever 
>> the reasons Jake left, they have nothing to do with this.
> 
> I believe you.
> 
> Thanks,
> Chris

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Oswald Buddenhagen]

On Wed, Oct 31, 2018 at 03:41:49PM -0400, Matthew Woehlke wrote:
> On 31/10/2018 14.26, Oswald Buddenhagen wrote:
> > On Wed, Oct 31, 2018 at 01:09:13PM -0400, Matthew Woehlke wrote:
> >> Again, how then does the consuming tool know which qt.core and which
> >> qt.gui are compatible with each other? How does it handle the case of
> >> finding a qt.core with no matching qt.gui?
> >
> > as i said below, by the sub-packages constraining their transitive
> > dependencies.
> 
> That is insufficient.
> 
no, it's not.

> A.X can be used by itself. A.Y also can be used by itself. However,
> mixing different versions of A.X and A.Y is an error.
> 
it's a rather contrived scenario that two components of a package
could be used truly independently (without a common dependency within
the package), yet still conflict between versions. anyway, let's go with
it.

> Even if you propose to solve this by having both A.X and A.Y depend on a
> "virtual" A.base target of the same version,
>
that's indeed one way to solve it.
another way are "anti-dependencies" like dpkg's Breaks: A.X != 

> you still haven't explained how to make it so a consumer can find the
> correct version of A in the pathological scenario I outlined without a
> global dependency solver.
> 
no, instead i told you that your premise of needing a _global_ solver is
wrong.

> > that answer might be unnecessarily strict, though. if i build a
> > 3rd-party qt module and install it into /opt/myqt, it might be
> > compatible with the system qt in /usr. i want to be able to use that
> > additional qt module by depending on {qt.{core,gui,3rdpartymodule}}.
> 
> Well, then, don't make it part of the "Qt" package. I don't think you
> can have it both ways. (If it's a third-party module, why is it a first
> party component of the "Qt" package?)
> 
because users want to think in terms of namespaces, not packages. at
least i do. at least for modules that aren't part of "qt" but are hosted
on qt-project infrastructure. qtwebkit is an excellent example, and
qtwebengine will probably follow soon due to wanting release cycle
decoupling.

> >> I think you are suggesting that finding build requirements has to be
> >> done as a single, monolithic pass; i.e. a project must specify ALL of
> >> its requirements before ANY attempt is made to satisfy those
> >> requirements.
> >
> > but that's exactly what you do anyway with the syntax above, within the
> > scope of a single package.
> 
> Not quite. [...]
>
you just spent ~35 lines on ... showing that i'm right.
the TTA approach cannot possibly work without the atomic resolution
scope provided by the multi-component find_library() statement. and
given that constraint, it's absolutely irrelevant to the user what
happens behind the scenes.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Gatis Paeglis]

> It’s convenient to quote what adds fuel to the fire of this discussion. Hence 
> my attempt to add water by quoting what I thought it still relevant.


In a real life never add water to a fuel fire. It will cause even more fire 😊


Gatis.


From: Development  on 
behalf of Simon Hausmann 
Sent: Thursday, November 1, 2018 12:19:11 PM
To: André Pönitz
Cc: development mailing list; q...@qt-project.org
Subject: Re: [Development] Build system for Qt 6

I agree, this is often the case.

I just wanted to emphasize that I think it’s too early to conclude that llvm is 
going to switch to gn based on that email. It’s convenient to quote what adds 
fuel to the fire of this discussion. Hence my attempt to add water by quoting 
what I thought it still relevant.

Simon

> On 1. Nov 2018, at 12:14, André Pönitz  wrote:
>
>> On Thu, Nov 01, 2018 at 08:34:34AM +, Simon Hausmann wrote:
>>
>>> From the same email perhaps it's also worth quoting the first paragraph:
>> "
>>
>> first things first: If you're happy with cmake, you can stop reading now.
>> Nobody is proposing that LLVM moves off cmake, and nobody is proposing
>> anything that's causing people using cmake more work.
>> "
>
> Sure, that's how one approaches larger controversial changes, not just
> in software development, but also general politics:
>
> 1. Promise that everything is optional, and existing uses won't change,
> and nobody will be affected unless opted-in. This keeps the initial
> outcry a bay. Optionally, start to belittle opposition as inveterate
> nay-sayers, as there is clearly no reason to oppose something people
> do voluntarily.
>
> 2. Once installed, apply salami tactics by extending the scope of the
> measure, "add value" to the new system, asked for or not, and let the old
> one rot. If needed, little stabs in the back help to speed up the process.
>
> 3. At some time the new system will indeed be better in some setups than
> the old one, and the opt-in gets opt-out. This is also a good time to
> gauge remaining resistance, and either continue with 2 or directly go
> to 4.
>
> 4. Sweep remaining issues under the carpet and declare the old system dead.
>
>
> As I said, that's nothing specific to LLVM and Cmake.
>
> The pattern to message "Nobody has any intention to do X" while planning
> or even already executing X is so widely used that in the presence of
> such a statement it is safer to assume that this is just stage 1 of the
> process above than to accept the statement at face value.
>
> Andre'
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Simon Hausmann]

I agree, this is often the case.

I just wanted to emphasize that I think it’s too early to conclude that llvm is 
going to switch to gn based on that email. It’s convenient to quote what adds 
fuel to the fire of this discussion. Hence my attempt to add water by quoting 
what I thought it still relevant.

Simon

> On 1. Nov 2018, at 12:14, André Pönitz  wrote:
> 
>> On Thu, Nov 01, 2018 at 08:34:34AM +, Simon Hausmann wrote:
>> 
>>> From the same email perhaps it's also worth quoting the first paragraph:
>> "
>> 
>> first things first: If you're happy with cmake, you can stop reading now.
>> Nobody is proposing that LLVM moves off cmake, and nobody is proposing
>> anything that's causing people using cmake more work.
>> "
> 
> Sure, that's how one approaches larger controversial changes, not just
> in software development, but also general politics:
> 
> 1. Promise that everything is optional, and existing uses won't change,
> and nobody will be affected unless opted-in. This keeps the initial
> outcry a bay. Optionally, start to belittle opposition as inveterate
> nay-sayers, as there is clearly no reason to oppose something people
> do voluntarily.
> 
> 2. Once installed, apply salami tactics by extending the scope of the
> measure, "add value" to the new system, asked for or not, and let the old
> one rot. If needed, little stabs in the back help to speed up the process.
> 
> 3. At some time the new system will indeed be better in some setups than
> the old one, and the opt-in gets opt-out. This is also a good time to
> gauge remaining resistance, and either continue with 2 or directly go
> to 4.
> 
> 4. Sweep remaining issues under the carpet and declare the old system dead.
> 
> 
> As I said, that's nothing specific to LLVM and Cmake.
> 
> The pattern to message "Nobody has any intention to do X" while planning
> or even already executing X is so widely used that in the presence of
> such a statement it is safer to assume that this is just stage 1 of the
> process above than to accept the statement at face value.
> 
> Andre'
> 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Jean-Michaël Celerier]

Especially considering that the person proposing the change is working 
at google which is where GN comes from. There's some conflict of 
interest here.


On 01/11/2018 12:13, André Pönitz wrote:

On Thu, Nov 01, 2018 at 08:34:34AM +, Simon Hausmann wrote:

>From the same email perhaps it's also worth quoting the first paragraph:
"

first things first: If you're happy with cmake, you can stop reading now.
Nobody is proposing that LLVM moves off cmake, and nobody is proposing
anything that's causing people using cmake more work.
"

Sure, that's how one approaches larger controversial changes, not just
in software development, but also general politics:

1. Promise that everything is optional, and existing uses won't change,
and nobody will be affected unless opted-in. This keeps the initial
outcry a bay. Optionally, start to belittle opposition as inveterate
nay-sayers, as there is clearly no reason to oppose something people
do voluntarily.

2. Once installed, apply salami tactics by extending the scope of the
measure, "add value" to the new system, asked for or not, and let the old
one rot. If needed, little stabs in the back help to speed up the process.

3. At some time the new system will indeed be better in some setups than
the old one, and the opt-in gets opt-out. This is also a good time to
gauge remaining resistance, and either continue with 2 or directly go
to 4.

4. Sweep remaining issues under the carpet and declare the old system dead.


As I said, that's nothing specific to LLVM and Cmake.

The pattern to message "Nobody has any intention to do X" while planning
or even already executing X is so widely used that in the presence of
such a statement it is safer to assume that this is just stage 1 of the
process above than to accept the statement at face value.

Andre'

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[André Pönitz]

On Thu, Nov 01, 2018 at 08:34:34AM +, Simon Hausmann wrote:
> 
> >From the same email perhaps it's also worth quoting the first paragraph:
> "
> 
> first things first: If you're happy with cmake, you can stop reading now.
> Nobody is proposing that LLVM moves off cmake, and nobody is proposing
> anything that's causing people using cmake more work.
> "

Sure, that's how one approaches larger controversial changes, not just
in software development, but also general politics:

1. Promise that everything is optional, and existing uses won't change,
and nobody will be affected unless opted-in. This keeps the initial
outcry a bay. Optionally, start to belittle opposition as inveterate
nay-sayers, as there is clearly no reason to oppose something people
do voluntarily.

2. Once installed, apply salami tactics by extending the scope of the
measure, "add value" to the new system, asked for or not, and let the old
one rot. If needed, little stabs in the back help to speed up the process.

3. At some time the new system will indeed be better in some setups than
the old one, and the opt-in gets opt-out. This is also a good time to
gauge remaining resistance, and either continue with 2 or directly go
to 4.

4. Sweep remaining issues under the carpet and declare the old system dead.


As I said, that's nothing specific to LLVM and Cmake.

The pattern to message "Nobody has any intention to do X" while planning
or even already executing X is so widely used that in the presence of
such a statement it is safer to assume that this is just stage 1 of the
process above than to accept the statement at face value.

Andre'

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Bogdan Vatra via Development]

Hi,

Yes, "hard to work with" :).

Cheers,
BogDan.

În ziua de joi, 1 noiembrie 2018, la 11:24:29 EET, Vlad Stelmahovsky a scris:
> you mean "hard to work with"?
> 
> On 11/1/18 9:34 AM, Bogdan Vatra via Development wrote:
> > Hi,
> > 
> >GN is the closest build system to QBS, the only problem it has it's
> > 
> > controled by Google and these guys are sometime had to work with.
> > 
> > Cheers,
> > BogDan.
> > 
> > În ziua de joi, 1 noiembrie 2018, la 10:30:01 EET, Nikolai Kosjar a scris:
> >> On 10/29/18 1:17 PM, Lars Knoll wrote:
> >>> Given that we are confident we can build Qt 6 with cmake, I believe that
> >>> it makes most sense to follow down that route.
> >> 
> >> Just some observation:
> >> 
> >> LLVM/Clang is a bigger project using CMake for some longer time and
> >> coincidentally, just now, there is a discussion whether they should add
> >> GN build files to their repositories as, let me quote:
> >> 
> >> """
> >> cmake is great for many use cases, but in my opinion local day-to-day
> >> development isn't one of them.
> >> """
> >> 
> >> Clang: https://lists.llvm.org/pipermail/cfe-dev/2018-October/060006.html
> >> LLVM: https://lists.llvm.org/pipermail/llvm-dev/2018-October/127342.html
> >> 
> >> Nikolai
> >> ___
> >> Development mailing list
> >> Development@qt-project.org
> >> http://lists.qt-project.org/mailman/listinfo/development
> > 
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Vlad Stelmahovsky]

you mean "hard to work with"?

On 11/1/18 9:34 AM, Bogdan Vatra via Development wrote:

Hi,

   GN is the closest build system to QBS, the only problem it has it's
controled by Google and these guys are sometime had to work with.

Cheers,
BogDan.

În ziua de joi, 1 noiembrie 2018, la 10:30:01 EET, Nikolai Kosjar a scris:

On 10/29/18 1:17 PM, Lars Knoll wrote:

Given that we are confident we can build Qt 6 with cmake, I believe that
it makes most sense to follow down that route.

Just some observation:

LLVM/Clang is a bigger project using CMake for some longer time and
coincidentally, just now, there is a discussion whether they should add
GN build files to their repositories as, let me quote:

"""
cmake is great for many use cases, but in my opinion local day-to-day
development isn't one of them.
"""

Clang: https://lists.llvm.org/pipermail/cfe-dev/2018-October/060006.html
LLVM: https://lists.llvm.org/pipermail/llvm-dev/2018-October/127342.html

Nikolai
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Simon Hausmann]

>From the same email perhaps it's also worth quoting the first paragraph:


"

first things first: If you're happy with cmake, you can stop reading now.
Nobody is proposing that LLVM moves off cmake, and nobody is proposing
anything that's causing people using cmake more work.
"


Simon


From: Development  on 
behalf of Nikolai Kosjar 
Sent: Thursday, November 1, 2018 9:30:01 AM
To: Lars Knoll; Qt development mailing list
Subject: Re: [Development] Build system for Qt 6

On 10/29/18 1:17 PM, Lars Knoll wrote:
> Given that we are confident we can build Qt 6 with cmake, I believe that it 
> makes most sense to follow down that route.

Just some observation:

LLVM/Clang is a bigger project using CMake for some longer time and
coincidentally, just now, there is a discussion whether they should add
GN build files to their repositories as, let me quote:

"""
cmake is great for many use cases, but in my opinion local day-to-day
development isn't one of them.
"""

Clang: https://lists.llvm.org/pipermail/cfe-dev/2018-October/060006.html
LLVM: https://lists.llvm.org/pipermail/llvm-dev/2018-October/127342.html

Nikolai
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Bogdan Vatra via Development]

Hi,

  GN is the closest build system to QBS, the only problem it has it's 
controled by Google and these guys are sometime had to work with.

Cheers,
BogDan.

În ziua de joi, 1 noiembrie 2018, la 10:30:01 EET, Nikolai Kosjar a scris:
> On 10/29/18 1:17 PM, Lars Knoll wrote:
> > Given that we are confident we can build Qt 6 with cmake, I believe that
> > it makes most sense to follow down that route.
> Just some observation:
> 
> LLVM/Clang is a bigger project using CMake for some longer time and
> coincidentally, just now, there is a discussion whether they should add
> GN build files to their repositories as, let me quote:
> 
> """
> cmake is great for many use cases, but in my opinion local day-to-day
> development isn't one of them.
> """
> 
> Clang: https://lists.llvm.org/pipermail/cfe-dev/2018-October/060006.html
> LLVM: https://lists.llvm.org/pipermail/llvm-dev/2018-October/127342.html
> 
> Nikolai
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Nikolai Kosjar]

On 10/29/18 1:17 PM, Lars Knoll wrote:
> Given that we are confident we can build Qt 6 with cmake, I believe that it 
> makes most sense to follow down that route. 

Just some observation:

LLVM/Clang is a bigger project using CMake for some longer time and 
coincidentally, just now, there is a discussion whether they should add 
GN build files to their repositories as, let me quote:

"""
cmake is great for many use cases, but in my opinion local day-to-day 
development isn't one of them.
"""

Clang: https://lists.llvm.org/pipermail/cfe-dev/2018-October/060006.html
LLVM: https://lists.llvm.org/pipermail/llvm-dev/2018-October/127342.html

Nikolai
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Matthew Woehlke]

On 31/10/2018 14.26, Oswald Buddenhagen wrote:
> On Wed, Oct 31, 2018 at 01:09:13PM -0400, Matthew Woehlke wrote:
>> Again, how then does the consuming tool know which qt.core and which
>> qt.gui are compatible with each other? How does it handle the case of
>> finding a qt.core with no matching qt.gui?
>
> as i said below, by the sub-packages constraining their transitive
> dependencies.

That is insufficient.

A.X can be used by itself. A.Y also can be used by itself. However,
mixing different versions of A.X and A.Y is an error.

Even if you propose to solve this by having both A.X and A.Y depend on a
"virtual" A.base target of the same version, you still haven't explained
how to make it so a consumer can find the correct version of A in the
pathological scenario I outlined without a global dependency solver.

Please explain this, not with platitudes, but with a *concrete example*,
i.e. show what the components specifications would look like and what
steps the build tool will take to find the correct versions of the
components.

>> Having a top-level spec provides a well-defined answer to these sorts of
>> problems; if the top-level spec doesn't meet the user's requirements,
>> you ignore the entire thing and keep looking.
>
> that answer might be unnecessarily strict, though. if i build a
> 3rd-party qt module and install it into /opt/myqt, it might be
> compatible with the system qt in /usr. i want to be able to use that
> additional qt module by depending on {qt.{core,gui,3rdpartymodule}}.

Well, then, don't make it part of the "Qt" package. I don't think you
can have it both ways. (If it's a third-party module, why is it a first
party component of the "Qt" package?)

>> I think you are suggesting that finding build requirements has to be
>> done as a single, monolithic pass; i.e. a project must specify ALL of
>> its requirements before ANY attempt is made to satisfy those
>> requirements.
>
> but that's exactly what you do anyway with the syntax above, within the
> scope of a single package. whether the interfaces are explicitly
> aggregated by some top-level file or implicitly by some shared
> properties and mutual constraints is completely inconsequential for the
> user.

Not quite. CPS as currently specified does need bookkeeping, but it does
*not* need global dependency solving. (Although this does, admittedly,
have the disadvantage that it may fail in cases where global solving
might succeed, and thus require more user hand-holding to arrive at an
overall acceptable "answer".)

As there is no global solving, each request to find a package is
considered on its own:

- First, look for a candidate package.
- For each candidate:
  - If that package's arch is incompatible, TTA¹.
  - If that package has a dependency for which an incompatible version
is already "being used", TTA.
  - For each of the package's dependencies, recursively invoke this process.
  - If dependencies could not be found, TTA.
  - If the candidate does not provide the components required by the
consumer, TTA.

(¹ "Try, Try Again"... IOW, make a note of why this package is not
acceptable and continue with the next candidate. If no suitable
candidate is found, these notes may be used to tell the user why a
candidate was rejected.)

The difference is that, once a package is found, it is found, and cannot
be "un-found". The tool does not have to try all possible candidates in
all possible combinations. Also, this process can be dropped into
existing build tools that also look for one package (or component) at a
time. It is not implausible, for example, that I could write a
CLI-compatible pkg-config implementation that uses CPS, or that I could
extend CMake's find_package to look for CPS's and turn them into
imported targets. This means that CPS has the potential to "just work"
with existing build tools, and even existing software using those build
tools. In fact, this is explicitly one of the goals of CPS. A system
relying on global dependency solving can't do that.

(The bookkeeping is that the system can't "commit" to adding
dependencies into the global space until a candidate is accepted, so it
needs a separate "holding space" that it can throw out again if it turns
out a candidate is not viable.)

-- 
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Oswald Buddenhagen]

On Wed, Oct 31, 2018 at 01:09:13PM -0400, Matthew Woehlke wrote:
> On 31/10/2018 12.46, Oswald Buddenhagen wrote:
> > On Wed, Oct 31, 2018 at 10:17:04AM -0400, Matthew Woehlke wrote:
> >> On 30/10/2018 17.51, Oswald Buddenhagen wrote:
> >>> after much thinking about the matter, i concluded that the interface
> >>> files should correspond to "atomic linkable entities", which
> >>> essentially means actual libraries
> >>
> >> That's basically the pkg-config approach... and I believe that design
> >> to be intractable. In short, it fails to specify how to do the
> >> equivalent of `find_package(X COMPONENTS A B C)`.
> >
> > i'd just aggregate by components: {qt.core, qt.gui} is the same as
> > {qt.{core, gui}}. not sure what qbs currently does internally ...
> 
> Again, how then does the consuming tool know which qt.core and which
> qt.gui are compatible with each other? How does it handle the case of
> finding a qt.core with no matching qt.gui?
> 
as i said below, by the sub-packages constraining their transitive
dependencies.

> Having a top-level spec provides a well-defined answer to these sorts of
> problems; if the top-level spec doesn't meet the user's requirements,
> you ignore the entire thing and keep looking.
> 
that answer might be unnecessarily strict, though. if i build a
3rd-party qt module and install it into /opt/myqt, it might be
compatible with the system qt in /usr. i want to be able to use that
additional qt module by depending on {qt.{core,gui,3rdpartymodule}}.

> >> You *have* to be able to do package-level queries; otherwise, how do you
> >> know (assuming X-1.z are mutually incompatible, but the consumer can use
> >> any X-1.z) to use X-1.0?
> >
> > you can specify version constraints in the dependencies like e.g. debian
> > packages do.
> 
> Again, please explain how you will ask the consuming tool to find your
> requirements, and how it will accomplish this task.
> 
> With CPS as currently designed, it is easy:
> 
>   # CMake syntax, but same principle would apply to any tool
>   find_package(X COMPONENTS A B)
> 
> I think you are suggesting that finding build requirements has to be
> done as a single, monolithic pass; i.e. a project must specify ALL of
> its requirements before ANY attempt is made to satisfy those
> requirements.
>
but that's exactly what you do anyway with the syntax above, within the
scope of a single package. whether the interfaces are explicitly
aggregated by some top-level file or implicitly by some shared
properties and mutual constraints is completely inconsequential for the
user.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Matthew Woehlke]

On 31/10/2018 12.46, Oswald Buddenhagen wrote:
> On Wed, Oct 31, 2018 at 10:17:04AM -0400, Matthew Woehlke wrote:
>> On 30/10/2018 17.51, Oswald Buddenhagen wrote:
>>> after much thinking about the matter, i concluded that the interface
>>> files should correspond to "atomic linkable entities", which
>>> essentially means actual libraries
>>
>> That's basically the pkg-config approach... and I believe that design
>> to be intractable. In short, it fails to specify how to do the
>> equivalent of `find_package(X COMPONENTS A B C)`.
>
> i'd just aggregate by components: {qt.core, qt.gui} is the same as
> {qt.{core, gui}}. not sure what qbs currently does internally ...

Again, how then does the consuming tool know which qt.core and which
qt.gui are compatible with each other? How does it handle the case of
finding a qt.core with no matching qt.gui?

Having a top-level spec provides a well-defined answer to these sorts of
problems; if the top-level spec doesn't meet the user's requirements,
you ignore the entire thing and keep looking.

>> Especially if you have e.g. (ignoring 'C' for simplicity):
>>
>>   X.A-1.2
>>   X.A-1.0
>>   X.B-1.1
>>   X.B-1.0
>>
>> You *have* to be able to do package-level queries; otherwise, how do you
>> know (assuming X-1.z are mutually incompatible, but the consumer can use
>> any X-1.z) to use X-1.0?
>
> you can specify version constraints in the dependencies like e.g. debian
> packages do.

Again, please explain how you will ask the consuming tool to find your
requirements, and how it will accomplish this task.

With CPS as currently designed, it is easy:

  # CMake syntax, but same principle would apply to any tool
  find_package(X COMPONENTS A B)

I think you are suggesting that finding build requirements has to be
done as a single, monolithic pass; i.e. a project must specify ALL of
its requirements before ANY attempt is made to satisfy those
requirements. But a) that's harder to implement, and b) existing build
systems do not work that way (at least, both CMake and autotools don't).
Moreover, a package+components based model (i.e. CPS in its current
form) can be made to work with a tool that *does* work that way (QBS?),
but you have not demonstrated how a components-only model could be made
to work with a tool that does *not* do global dependency solving.

(Admission: CPS has been strongly influenced by what *CMake* needs. A
specification that doesn't satisfy CMake's needs, e.g. pkg-config, is
probably a non-starter as far as potentially replacing CMake's current
stuff.)

-- 
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Oswald Buddenhagen]

On Wed, Oct 31, 2018 at 10:17:04AM -0400, Matthew Woehlke wrote:
> On 30/10/2018 17.51, Oswald Buddenhagen wrote:
> > for starters just some food for thought:
> > QBS-995 should be implementable on top of it.
> > if you want to go full monty, QBS-942 is your target.
> 
> What are those? Can you provide links?
> 
qt jira tasks. ;)
for me they are the first hits on google ...

> > one thing i noticed is that you multiplex build variants and other stuff
> > into a single file. this is not helpful for packaging.
> 
> This is not entirely true; a single package specification *can* be split
> into multiple units. (I'm not sure this is well documented, but it is
> definitely intended. OTOH, while I'm pretty sure this is well supported
> for separate *components*, I'm less sure about separate *configurations*
> of the same component, so maybe there is room for improvement.)

> There does need to be one package that owns the "root" specification,
> but this is not so different from one package owning the top level
> directory.
> 
for components, that seems unnecessary in principle. if there is
anything shared, that's rather naturally expressed by there typically
being a central sub-package which every other one depends on anyway
(say, qtcore).
for build variants you'd indeed get 100% redundancy with my concept,
but that really doesn't sound exceedingly problematic given that we're
talking about small auto-generated files.

> > after much thinking about the matter, i concluded that the interface
> > files should correspond to "atomic linkable entities", which
> > essentially means actual libraries
> 
> That's basically the pkg-config approach... and I believe that design
> to be intractable. In short, it fails to specify how to do the
> equivalent of `find_package(X COMPONENTS A B C)`.
>
i'd just aggregate by components: {qt.core, qt.gui} is the same as
{qt.{core, gui}}. not sure what qbs currently does internally ...

> Especially if you have e.g. (ignoring 'C' for simplicity):
> 
>   X.A-1.2
>   X.A-1.0
>   X.B-1.1
>   X.B-1.0
> 
> You *have* to be able to do package-level queries; otherwise, how do you
> know (assuming X-1.z are mutually incompatible, but the consumer can use
> any X-1.z) to use X-1.0?
> 
you can specify version constraints in the dependencies like e.g. debian
packages do.

> > not one interface to describe all build variants,
> 
> Aside from this isn't how lots of existing packages work, how would you
> then architect the system to allow the user to both be able to choose
> which build variant to use *or* to just pick one? Requiring the user to
> know which variant they want is an anti-goal.
> 
one can priorize certain property values, both inside the interface and
on the consumer side.

> > and not one interface to describe each architecture variant within a
> > multi-arch library.
>
> Actually, I'm not sure if this would work.
>

slicing interfaces would work just fine for mac, because it's possible
to use just one architecture slice at any given time. however, it would
be inefficient (more tool calls) and at some point one needs to join the
own build artifacts into a multi-arch binary again anyway.
of course, one could make the consuming system intelligent enough to
recognize that a group of interfaces refer to different slices of the
same binary, but that seems unnecessarily complex.

conversely, having "lumped" multi-arch interfaces works as well, because
that just represents the reality of the binaries. however, the interface
then actually needs to specify a list of contained architectures.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Riitta-Leena Miettinen]

>Date: Wed, 31 Oct 2018 08:28:45 -0700
>From: Thiago Macieira 
>To: 
>Subject: Re: [Development] Build system for Qt 6
>Message-ID: <7867869.XuAOyZs5DA@tjmaciei-mobl1>
>Content-Type: text/plain; charset="iso-8859-1"
>
>>On Tuesday, 30 October 2018 22:59:57 PDT Andr? P?nitz wrote:
> >Where would a QBS-promoting webpage be located?
> >
> >qt-project.org ?
>
>Sure, why not?
>
>--
>Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center

Hello,

We actually have a separate domain for Qbs at qbs.io. Currently, it redirects 
to the Qbs Manual at doc.qt.io, but we were working on it:

https://bugreports.qt.io/browse/QBS-1341

Leena



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Thiago Macieira]

On Tuesday, 30 October 2018 22:59:57 PDT André Pönitz wrote:
> Where would a QBS-promoting webpage be located?
> 
> qt-project.org ?

Sure, why not?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Thiago Macieira]

On Wednesday, 31 October 2018 03:02:04 PDT Bernhard Lindner wrote:
> Maybe I worked for the wrong companies all the time. But whenever we wanted
> to have proof that some tool or library actually meets our requirements, it
> never was sufficient to *ask* for proof. We needed to test it by *ourselfs*
> in a feasibility project.

For qbs, most of the proof was "you still have work to do". That means *I* 
didn't have to do anything, but the proponents of it had to get it to mature.

> And normally *none* of the candidates completely met all of our requirements
> so we chose the tool with the least flaws, the best potential and (most
> important!) with the most dedicated maintenance/support crew. And of course
> some trust was part of the decision.

Of course, not denying that.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Matthew Woehlke]

On 30/10/2018 17.51, Oswald Buddenhagen wrote:
> for starters just some food for thought:
> QBS-995 should be implementable on top of it.
> if you want to go full monty, QBS-942 is your target.

What are those? Can you provide links?

> one thing i noticed is that you multiplex build variants and other stuff
> into a single file. this is not helpful for packaging.

This is not entirely true; a single package specification *can* be split
into multiple units. (I'm not sure this is well documented, but it is
definitely intended. OTOH, while I'm pretty sure this is well supported
for separate *components*, I'm less sure about separate *configurations*
of the same component, so maybe there is room for improvement.)

There does need to be one package that owns the "root" specification,
but this is not so different from one package owning the top level
directory.

> after much
> thinking about the matter, i concluded that the interface files should
> correspond to "atomic linkable entities", which essentially means actual
> libraries

That's basically the pkg-config approach... and I believe that design to
be intractable. In short, it fails to specify how to do the equivalent
of `find_package(X COMPONENTS A B C)`. Especially if you have e.g.
(ignoring 'C' for simplicity):

  X.A-1.2
  X.A-1.0
  X.B-1.1
  X.B-1.0

You *have* to be able to do package-level queries; otherwise, how do you
know (assuming X-1.z are mutually incompatible, but the consumer can use
any X-1.z) to use X-1.0?

> not one interface to describe all build variants,

Aside from this isn't how lots of existing packages work, how would you
then architect the system to allow the user to both be able to choose
which build variant to use *or* to just pick one? Requiring the user to
know which variant they want is an anti-goal.

> and not one interface to describe each architecture variant within a
> multi-arch library.
Actually, I'm not sure if this would work. I won't swear that it won't
(I don't think I've ever really thought about it), but it wasn't a
design goal. The goal of having an arch specification is so that a
consumer can ignore packages that are built for an incompatible
architecture. (This is one of features that CMake is currently missing.)

IOW, the intent was for one package specification to have only a single
architecture. And at least CMake currently wouldn't support such
packages anyway. (At best, it would use the component's from the
consumer's arch and pretend the rest doesn't exist.)

-- 
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Oswald Buddenhagen]

On Wed, Oct 31, 2018 at 11:16:18AM +0100, Robin Burchell wrote:
> On Tue, Oct 30, 2018, at 5:40 PM, Oswald Buddenhagen wrote:
> > on top of that there are long-term savings to be made from increased
> > productivity (which several posters to this thread have confirmed or
> > implied). that alone won't offset the cost vs. using cmake (it would
> > vs.  developing and using qmake), but it's not negligible.
> 
> I think that qbs's worst enemy was that the "competition" of
> everything else in the space was good _enough_ (yep, even qmake, warts
> and all). Build systems, from the perspective of the people using them
> to build other things, are not a tangible part of the deliverable
> product you make money off of. They are a tool that _enable_ you to
> produce such a product.
> 
well, yes, of course. we knew that when we embarked on the journey -
build systems aren't exactly the kind of thing that many people get
excited about. mostly frustrated with. ^^

> Any effort that goes into changing that tooling takes effort away from
> other areas that more directly make money - and that effort requires
> justification. From my personal experience, I have never had a
> compelling answer for "why should we port to qbs" to give that
> justification.
> 
that's a perfectly fine attitude. nobody would ask you to port away
from a build system that is adequate and maintainable. except by telling
you "oh, btw, we just deprecated the build tool you're using", that is.

> "Why should we port to a tool that very few other people are using
> that doesn't provide clearly night-and-day amazing benefits when what
> is available today is better known and works well enough"? Indeed,
> I'll let you know if I ever figure out an answer to that one.
> 
we/i have three target audiences in mind:
- full-time build system maintainers like myself. we feel the pain all
  day, so it's a purely selfish move to create and push something that
  actually doesn't suck.  
  part of the plan is to have a tool that isn't arcane to the degree
  that any non-trivial task must involve the maintainer to arrive at an
  acceptable quality.
- "forced switchers". a lot of projects are still on autotools, and with
  the expansion of their supported platforms beyond traditonal unix,
  they typically rewrite the build system.
- qt (creator) users who have no strong preference for their new
  projects. the idea was to have qbs as the default, to offer a *fully*
  integrated out-of-the-box experience, something that cannot possibly
  be achieved with qmake or cmake. while not 100% achieved due to
  resourcing constraints, the IDE story was central to initially
  "selling" the project internally. it's all about developer experience,
  just like qt creator, and for that matter qt itself.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Maximilian Hrabowski]

On 31. Oct 2018, at 06:38, Bogdan Vatra via Development 
mailto:development@qt-project.org>> wrote:

Hi,

În ziua de marți, 30 octombrie 2018, la 19:11:20 EET, Oswald Buddenhagen a
scris:
On Tue, Oct 30, 2018 at 01:16:43PM +0200, Bogdan Vatra wrote:
c.2) back then, none of the existing build system could deliver enough
information to IDEs to enable prefect code completion (e.g.  include
paths, defines, compiler flags, etc.)
...
c.2) Incomplete! A while ago, I created a QBS plugin for KDevelop[1]
and I found some problems, see how QBS developers treat them here:
https://bugreports.qt.io/browse/QBS-902 . That was the moment when I
started to have doubts :).

for all i can tell that's a rather poor bug report with little followup
from you. that's where i start to have doubts whether you actually mean
it. ;)

You must be kidding! What do you want me to do more? Write some love poems?

This kind of reaction on https://bugreports.qt.io/browse/QBS-902 is the normal 
experience i encounter when submitting Qt-Bugs, so IMHO this is not related to 
the importance of qbs as a project but best practise.

Cheers,
Maximilian
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Christian Gagneraud]

On Wed, 31 Oct 2018 at 22:47, Christian Kandeler
 wrote:
>
> On Wed, 31 Oct 2018 10:44:43 +1300
> Christian Gagneraud  wrote:
>
> > On Wed, 31 Oct 2018 at 10:27, Thiago Macieira  
> > 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

Re: [Development] Build system for Qt 6

[Robin Burchell]

On Tue, Oct 30, 2018, at 5:40 PM, Oswald Buddenhagen wrote:
> on top of that there are long-term savings to be made from increased
> productivity (which several posters to this thread have confirmed or
> implied). that alone won't offset the cost vs. using cmake (it would vs.
> developing and using qmake), but it's not negligible.

Speaking specifically about things _other than Qt_ (this does not really apply 
to Qt - though perhaps it does a little):

I can't really judge any of these savings as I never really had the opportunity 
to try qbs (and this is coming from me - someone who deliberately tries to 
experiment with almost every new, strange thing there is out there).

I think that qbs's worst enemy was that the "competition" of everything else in 
the space was good _enough_ (yep, even qmake, warts and all). Build systems, 
from the perspective of the people using them to build other things, are not a 
tangible part of the deliverable product you make money off of. They are a tool 
that _enable_ you to produce such a product.

Any effort that goes into changing that tooling takes effort away from other 
areas that more directly make money - and that effort requires justification. 
From my personal experience, I have never had a compelling answer for "why 
should we port to qbs" to give that justification.

"Why should we port to a tool that very few other people are using that doesn't 
provide clearly night-and-day amazing benefits when what is available today is 
better known and works well enough"? Indeed, I'll let you know if I ever figure 
out an answer to that one.

This isn't meant to say that any one tool is perfect - of course, they're not. 
But they're good enough most of the time.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Bernhard Lindner]

Hi!

> No. However, I am asking for proof.

Maybe I worked for the wrong companies all the time. But whenever we wanted to 
have proof
that some tool or library actually meets our requirements, it never was 
sufficient to
*ask* for proof. We needed to test it by *ourselfs* in a feasibility project.

And normally *none* of the candidates completely met all of our requirements so 
we chose
the tool with the least flaws, the best potential and (most important!) with 
the most
dedicated maintenance/support crew. And of course some trust was part of the 
decision.

Thiago, did this startegy of yours (simply asking for an all-inclusive proof and
guarantee) ever work before?

-- 
Regards Bernhard

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Christian Kandeler]

On Wed, 31 Oct 2018 10:44:43 +1300
Christian Gagneraud  wrote:

> On Wed, 31 Oct 2018 at 10:27, Thiago Macieira  
> 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.


Christian
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Oswald Buddenhagen]

On Tue, Oct 30, 2018 at 02:07:16PM -0700, Thiago Macieira wrote:
> On Tuesday, 30 October 2018 13:47:00 PDT Oswald Buddenhagen wrote:
> > On Tue, Oct 30, 2018 at 12:53:48PM -0700, Thiago Macieira wrote:
> > > On Tuesday, 30 October 2018 12:29:46 PDT Oswald Buddenhagen wrote:
> > > > doesn't authorize you to impose requirements that make it basically
> > > > impossible to employ qt as a bootstrapping device for a qbs
> > > > ecosystem.
> > > 
> > > The whole point was "let Qt not be the guinea pig".
> > 
> > you're essentially presuming that qbs is developed by a potentially
> > incompetent external entity.
> 
> No. However, I am asking for proof.
> 
you may obtain it yourself when you distrust your own community so much.

> > > Show me that the tool can achieve what Qt needs for it to achieve
> > 
> > qtbase//wip/qbs2 speaks for itself.
> 
> That's the guinea pig. I am asking for proof by seeing someone else
> adopt it. 
>
you aren't asking for "achievements", but for a perfect guarantee of
unproblematic deployment. that's quite frankly absurd.

> The tool is now several years old, it ought to have attracted
> *someone*.
> 
almost everyone who even looked at it did the right thing: distrust the
entity behind it, because it's not showing committment. this is the
message we have been hearing again and again, most of all from within
the company.

> And even if it hasn't, there are a couple of years left until we
> switch for Qt. The community supporting this tool can find other
> projects of moderate complexity to work with and support.
> 
that's nonsense. the decision is happening *now* (in as far as it isn't
a done deal already). the cmake port is getting all the instant
committment and push from lars that he never managed to give to qbs.
there isn't going to be a time after cmake.

> > > and has enough of a track record of a community to ask for help.
> > 
> > it has enough "community" and intrinsic quality to get things going.
> 
> I'm not disputing it has quality. But it lacks a specific community I
> called for: packagers.
> 
that community has always managed, and it sure would with qbs (in as far
as it didn't already). it's not rocket science.

> Tell me, has anyone tried to build that branch in the Boot2Qt context?
> 
that seems unlikely. our QA is constantly overloaded, and certainly
doesn't want to priorize something that clearly isn't taken seriously
by parts of the company, most of all management.
however, that *would* change if there was an *actual* decision in favor
of qbs.

> > asking for more is completely unreasonable before the community from
> > which the tool originates shows committment by *relying* on it.
> 
> I disagree and I find it completely reasonable to ask. That's why I
> did so.
> 
that attitude is totally selfish and remarkably disrespectful towards
parts of your own community. it clearly shows that you don't consider
qbs part of our own dog food.

> And yes, they were right: if qbs is created for Qt alone, then they
> shouldn't rely on it. Hence the request to show that it can be used by
> others and that there's at least a modest community behind it.
> 
this thread has show beyond a reasonable doubt that there *is* a
"modest" community behind it.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Christian Gagneraud]

On Wed, 31 Oct 2018 at 11:08, Thiago Macieira  wrote:
> On Tuesday, 30 October 2018 14:44:43 PDT Christian Gagneraud wrote:
> > On Wed, 31 Oct 2018 at 10:27, Thiago Macieira 
> 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@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Adam Treat]

See: “deprecated”


From: Development  on 
behalf of Uwe Rathmann 
Sent: Wednesday, October 31, 2018 2:35:50 AM
To: development@qt-project.org
Subject: Re: [Development] Build system for Qt 6

On Tue, 30 Oct 2018 19:24:26 +, Adam Treat wrote:

> Lars gave a keynote saying pretty much the same. Simply is not true that
> we are planning major source compatible breakage for Qt6 so let's stop
> saying that.

When will the already deprecated QQuickControls 1 module going to be
finally removed - isn't it Qt6 ?

QC1 user interfaces for embedded have to be migrated to QC 2, while user
interfaces for the desktop have to be reimplemented from scratch with Qt/
Widgets in C++.

To me this absolutely justifies to insist on the term "major".

Uwe

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Uwe Rathmann]

On Tue, 30 Oct 2018 19:24:26 +, Adam Treat wrote:

> Lars gave a keynote saying pretty much the same. Simply is not true that
> we are planning major source compatible breakage for Qt6 so let's stop
> saying that.

When will the already deprecated QQuickControls 1 module going to be 
finally removed - isn't it Qt6 ?

QC1 user interfaces for embedded have to be migrated to QC 2, while user 
interfaces for the desktop have to be reimplemented from scratch with Qt/
Widgets in C++.

To me this absolutely justifies to insist on the term "major".

Uwe

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Bogdan Vatra via Development]

Hi,

În ziua de marți, 30 octombrie 2018, la 19:11:20 EET, Oswald Buddenhagen a 
scris:
> On Tue, Oct 30, 2018 at 01:16:43PM +0200, Bogdan Vatra wrote:
> > c.2) back then, none of the existing build system could deliver enough
> > information to IDEs to enable prefect code completion (e.g.  include
> > paths, defines, compiler flags, etc.)
> > ...
> > c.2) Incomplete! A while ago, I created a QBS plugin for KDevelop[1]
> > and I found some problems, see how QBS developers treat them here:
> > https://bugreports.qt.io/browse/QBS-902 . That was the moment when I
> > started to have doubts :).
> 
> for all i can tell that's a rather poor bug report with little followup
> from you. that's where i start to have doubts whether you actually mean
> it. ;)
> 
You must be kidding! What do you want me to do more? Write some love poems?

>
> > d) last but not least a clean and easily maintainable code base that can
> > be
> > used for the next decade(s).
> > ...
> > 
> >   - Instread to port QBS to QML JS in the first second when QtScript was
> > 
> > deprecated, they fork it! I know that back then QML JS needed some love,
> > but instead to collaborate with QML JS folks they decided keep using
> > QtScript! IIRC a brave soul, port it to QML JS, but guess what, QBS devs
> > reject it and kept using QtScript!
> > 
> >  - Even more, they found a few problem also in QML parser, and guess what,
> > 
> > they forked also QML!
> 
> both these items get a huge "so what?" in response. because they have no
> practical impact whatsoever.
"So what?" Qt 6 will use cmake instead of qbs?
They have a big impact when it's comming to maintainanace. Instead to focus on 
qbs code, you have to focus also on QtScript and on QML parser...

> 
> > To fix d) a large part of QBS must be reorganized/rewritten,
> 
> i see no actual evidence of that.
Well, Qt 6 using cmake instead of qbs is the best *indirect* evidence ;-).


  Anyway, as long as Lars & Tuukka announced that qbs is dead, personally I 
think in this moment the whole discussion is futile. Because of that 
decission, in this moment TQC imagine is not very good, imagine how it will 
look if in a week or two you'll announce that you ditch cmake or qmake and 
embrace QBS again, that will be a PR nightmare and I don't see it coming :).

Cheers,
BogDan.


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[André Pönitz]

On Tue, Oct 30, 2018 at 02:44:03PM -0700, Thiago Macieira wrote:
> On Tuesday, 30 October 2018 14:33:41 PDT NIkolai Marchenko wrote:
> > Tbh, we wouldn't if this post hasn't almost stated that you are pulling the
> > plug.
> > As I saw it: qbs folks have finally started doing the correct thiing (that
> > is - tutorials) and what you are speaking of had a chance to happen.
> > But as of right now no amount of tutorials will change the fact that
> > reluctance to swtich to a new system will become reluctance to change to a
> > _stillborn_ system.
> 
> Then reverse that with action. It's an open source project and people can 
> contribute to it, inside the Qt Project governance even. TQtC employees can 
> contribute in their free time too, maybe even in Creative Fridays if they 
> still have that.
> 
> [...]
>
> > Oh, and also, maybe we need a separate post about this issue: "Should QBS
> > stay?"
> 
> Sure, go ahead and gather your contributors. I still think qbs was/is a great 
> idea. It's only lacking maturity.

Ok. Let me bite.

In <2217724.thNANPicTR@tjmaciei-mobl1> you stated "Ossi and several others
are right that qbs was never given a proper chance. It hasn't"

Above you stated that contributions to QBS could even happen inside the 
Qt Project.

Active part of "giving [some piece of software] a chance" is promoting it
on some webpage.

Where would a QBS-promoting webpage be located?

qt-project.org ?

Oops.

Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Thiago Macieira]

On Tuesday, 30 October 2018 14:57:01 PDT Christian Gagneraud wrote:
> > Looking at the fact, that we can’t earn money on a build system and that
> > it would require quite a lot of funding to make it more than a niche
> > product it doesn’t make sense to pursue it further. Instead we would
> > rather use the money to improve Qt and Qt Creator.
> This doesn't add up, why did you develop and still develop and
> maintain 'coin' then?
> You're not making money with it. It's costing you (a lot?) and is a
> critical part of your QA infra.

I think the answer is simple: none of the alternatives worked. COIN is not the 
first CI system we've had, it's actually the third.

I don't remember a discussion on the benefits and drawbacks of similar 
solutions (like Jenkins) at the time COIN was adopted. There may have been an 
analysis done inside TQtC I am not aware of (mostly because I'm not interested 
in).

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Thiago Macieira]

On Tuesday, 30 October 2018 14:44:43 PDT Christian Gagneraud wrote:
> On Wed, 31 Oct 2018 at 10:27, Thiago Macieira  
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) .

> - 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.

> - 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@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Christian Gagneraud]

Hi Lars,

On Tue, 30 Oct 2018 at 23:42, Lars Knoll  wrote:
> > On 30 Oct 2018, at 05:00, Christian Gagneraud  wrote:
> > On Tue, 30 Oct 2018 at 01:17, Lars Knoll  wrote:
> > Then why spend energy/money to fix something that is broken by design?
> > (Again, that is a personal opinion, if needed to say)
>
> As I said in my email, I unfortunately don’t see a way how The Qt Company can 
> push Qbs forward. It was a difficult decision because I very much like the 
> ideas and the technology used in Qbs.
>
> From the perspective of a company, we have to justify investments we do, and 
> they have to make sense not only from a perspective of being cool technology, 
> but also how they can in the end generate business for us. In addition, 
> there’s always the question, what we then can’t do (because the total money 
> we can invest in R&D is limited).
>
> Looking at the fact, that we can’t earn money on a build system and that it 
> would require quite a lot of funding to make it more than a niche product it 
> doesn’t make sense to pursue it further. Instead we would rather use the 
> money to improve Qt and Qt Creator.

This doesn't add up, why did you develop and still develop and
maintain 'coin' then?
You're not making money with it. It's costing you (a lot?) and is a
critical part of your QA infra.

> > - Did Jake left the QtC due to your early decision to drop qbs? ( I
> > personally do think that the decision was taken long time ago)
>
> The decision to not continue to develop Qbs was done very recently. It 
> doesn’t make sense to make a decision and then not take actions. Whatever the 
> reasons Jake left, they have nothing to do with this.

I believe you.

Thanks,
Chris
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[NIkolai Marchenko]

Even the initial support for Qt6 will already make community based efforts
more likely since they will at least have something to work with.
But if QBS support in QtCreator is dropped as Qt6 releases there  is little
to no chance of anyone picking it up as he task might just be too large.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Oswald Buddenhagen]

On Tue, Oct 30, 2018 at 05:06:44PM -0400, Matthew Woehlke wrote:
> On 30/10/2018 14.25, Oswald Buddenhagen wrote:
> > On Tue, Oct 30, 2018 at 01:46:49PM -0400, Matthew Woehlke wrote:
> >> In order to actually implement the ability to read CMake interface
> >> files (without corner cases), you basically have to *be* CMake.
> >> If you assume that you will only have to deal with some subset, you
> >> will be subject to breakage at any time.
> >
> > yes, but [...] the whole thing would be only a "bridge technology" 
> > anyway.
> 
> So why not jump straight to a better way of exchanging package
> information, and teach CMake to speak that? If you can produce such a
> system (which is exactly what CPS tries to do), I think CMake would be
> receptive. Why bother with an interim solution?
> 
i would be all for it. not sure the message "would you mind accepting
that patch? it's just a bit more maintenance work for you, and it would
make it easier for everyone else to break your quasi-monopoly and
ultimately make your tool obsolete ..." would be *that* easy to sell,
though. :D

> >> I would rather see CMake learn to read and output something more
> >> portable, e.g. CPS¹.
> >
> > from a quick glance, this isn't all that bad, and in fact reflects the
> > strongly declarative concepts i'm envisaging for qbs' interface files.
> 
> Thanks :-). I've tried to make it plausible and address both likely edge
> cases and some issues that CMake currently does not handle well, while
> keeping it reasonably simple. It's mostly lacking implementation, and I
> haven't had the time/ability to do a lot more than write up the schema.
> Help would be much appreciated!
> 
for starters just some food for thought:
QBS-995 should be implementable on top of it.
if you want to go full monty, QBS-942 is your target.

one thing i noticed is that you multiplex build variants and other stuff
into a single file. this is not helpful for packaging. after much
thinking about the matter, i concluded that the interface files should
correspond to "atomic linkable entities", which essentially means actual
libraries - not one interface to describe all build variants, and not
one interface to describe each architecture variant within a multi-arch
library. any aggregation of (however) related interfaces should happen
on the consumer side (in as far as necessary at all). this is actually
closely related to QBS-995.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[NIkolai Marchenko]

Tbh, as I see it: qbs is mostly usable now. The only thing it needs to stay
afloat from now on  and have a chance is promise of support for it + qt6 in
qt creator.
Is that really that hard to do?

On Wed, Oct 31, 2018 at 12:37 AM Jean-Michaël Celerier <
jeanmichael.celer...@gmail.com> wrote:

> Yes, it's a big requirement for a lot of people using OFX that they be
> able to use also Xcode and / or Visual Studio. But QBS was at some point
> (not sure if still the case) the main one.
> On 30/10/2018 22:25, Иван Комиссаров wrote:
>
> Huh? Looks like they are supporting every build system alive
> https://github.com/openframeworks/openFrameworks/tree/patch-release/libs/openFrameworksCompiled/project
>
> 30 окт. 2018 г., в 22:14, Jean-Michaël Celerier <
> jeanmichael.celer...@gmail.com> написал(а):
>
> OpenFrameworks, a fairly used creative coding framework has been using QBS
> for a few years. My experience with it in that context has been quite
> negative - a year ago it would break on every new QBS release, so you had
> to use an exact QBS version if you wanted to use OFX (exhibit A:
> https://forum.openframeworks.cc/t/qtcreator-v4-3-1-qbs-problem/27214), so
> multiple people I know have ended up porting OF to use CMake instead :
> https://github.com/ofnode/of which frankly worked better and with less
> breakage. As always, mileage may vary.
>
>
> ---
> Jean-Michaël Celerier
> http://www.jcelerier.name
>
>
> On Tue, Oct 30, 2018 at 10:07 PM Thiago Macieira <
> thiago.macie...@intel.com> wrote:
>
>> On Tuesday, 30 October 2018 13:47:00 PDT Oswald Buddenhagen wrote:
>> > On Tue, Oct 30, 2018 at 12:53:48PM -0700, Thiago Macieira wrote:
>> > > On Tuesday, 30 October 2018 12:29:46 PDT Oswald Buddenhagen wrote:
>> > > > doesn't authorize you to impose requirements that make it basically
>> > > > impossible to employ qt as a bootstrapping device for a qbs
>> > > > ecosystem.
>> > >
>> > > The whole point was "let Qt not be the guinea pig".
>> >
>> > you're essentially presuming that qbs is developed by a potentially
>> > incompetent external entity.
>>
>> No. However, I am asking for proof.
>>
>> > > Show me that the tool can achieve what Qt needs for it to achieve
>> >
>> > qtbase//wip/qbs2 speaks for itself.
>>
>> That's the guinea pig. I am asking for proof by seeing someone else adopt
>> it.
>> The tool is now several years old, it ought to have attracted *someone*.
>>
>> And even if it hasn't, there are a couple of years left until we switch
>> for
>> Qt. The community supporting this tool can find other projects of
>> moderate
>> complexity to work with and support.
>>
>> > > and has enough of a track record of a community to ask for help.
>> >
>> > it has enough "community" and intrinsic quality to get things going.
>>
>> I'm not disputing it has quality. But it lacks a specific community I
>> called
>> for: packagers.
>>
>> Tell me, has anyone tried to build that branch in the Boot2Qt context?
>>
>> > asking for more is completely unreasonable before the community from
>> > which the tool originates shows committment by *relying* on it. and as
>> > the current situation shows, everyone who didn't trust the story was
>> > *right*.
>>
>> I disagree and I find it completely reasonable to ask. That's why I did
>> so.
>>
>> And yes, they were right: if qbs is created for Qt alone, then they
>> shouldn't
>> rely on it. Hence the request to show that it can be used by others and
>> that
>> there's at least a modest community behind it.
>>
>> There has been enough time to get more adoption and there's still time
>> left.
>> So get someone else to adopt it.
>>
>> --
>> Thiago Macieira - thiago.macieira (AT) intel.com
>>   Software Architect - Intel Open Source Technology Center
>>
>>
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Christian Gagneraud]

On Wed, 31 Oct 2018 at 10:27, Thiago Macieira  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.

Chris
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Thiago Macieira]

On Tuesday, 30 October 2018 14:33:41 PDT NIkolai Marchenko wrote:
> Tbh, we wouldn't if this post hasn't almost stated that you are pulling the
> plug.
> As I saw it: qbs folks have finally started doing the correct thiing (that
> is - tutorials) and what you are speaking of had a chance to happen.
> But as of right now no amount of tutorials will change the fact that
> reluctance to swtich to a new system will become reluctance to change to a
> _stillborn_ system.

Then reverse that with action. It's an open source project and people can 
contribute to it, inside the Qt Project governance even. TQtC employees can 
contribute in their free time too, maybe even in Creative Fridays if they 
still have that.

It only appears TQtC decided not to invest direct money.

By the way, tmake was also opensourced when Trolltech decided to stop using 
it.
http://tmake.sourceforge.net/
[We changed the "tmake" markers in the source to "qmake" in Jan 2012 - see 
78a4c46842975f23cd0d9518eca8b341abbda0b5]

> Oh, and also, maybe we need a separate post about this issue: "Should QBS
> stay?"

Sure, go ahead and gather your contributors. I still think qbs was/is a great 
idea. It's only lacking maturity.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Jean-Michaël Celerier]

Yes, it's a big requirement for a lot of people using OFX that they be 
able to use also Xcode and / or Visual Studio. But QBS was at some point 
(not sure if still the case) the main one.


On 30/10/2018 22:25, Иван Комиссаров wrote:
Huh? Looks like they are supporting every build system alive 
https://github.com/openframeworks/openFrameworks/tree/patch-release/libs/openFrameworksCompiled/project


30 окт. 2018 г., в 22:14, Jean-Michaël Celerier 
> написал(а):


OpenFrameworks, a fairly used creative coding framework has been 
using QBS for a few years. My experience with it in that context has 
been quite negative - a year ago it would break on every new QBS 
release, so you had to use an exact QBS version if you wanted to use 
OFX (exhibit A: 
https://forum.openframeworks.cc/t/qtcreator-v4-3-1-qbs-problem/27214), 
so multiple people I know have ended up porting OF to use CMake 
instead : https://github.com/ofnode/of which frankly worked better 
and with less breakage. As always, mileage may vary.



---
Jean-Michaël Celerier
http://www.jcelerier.name 


On Tue, Oct 30, 2018 at 10:07 PM Thiago Macieira 
mailto:thiago.macie...@intel.com>> wrote:


On Tuesday, 30 October 2018 13:47:00 PDT Oswald Buddenhagen wrote:
> On Tue, Oct 30, 2018 at 12:53:48PM -0700, Thiago Macieira wrote:
> > On Tuesday, 30 October 2018 12:29:46 PDT Oswald Buddenhagen
wrote:
> > > doesn't authorize you to impose requirements that make it
basically
> > > impossible to employ qt as a bootstrapping device for a qbs
> > > ecosystem.
> >
> > The whole point was "let Qt not be the guinea pig".
>
> you're essentially presuming that qbs is developed by a potentially
> incompetent external entity.

No. However, I am asking for proof.

> > Show me that the tool can achieve what Qt needs for it to achieve
>
> qtbase//wip/qbs2 speaks for itself.

That's the guinea pig. I am asking for proof by seeing someone
else adopt it.
The tool is now several years old, it ought to have attracted
*someone*.

And even if it hasn't, there are a couple of years left until we
switch for
Qt. The community supporting this tool can find other projects of
moderate
complexity to work with and support.

> > and has enough of a track record of a community to ask for help.
>
> it has enough "community" and intrinsic quality to get things
going.

I'm not disputing it has quality. But it lacks a specific
community I called
for: packagers.

Tell me, has anyone tried to build that branch in the Boot2Qt
context?

> asking for more is completely unreasonable before the community
from
> which the tool originates shows committment by *relying* on it.
and as
> the current situation shows, everyone who didn't trust the
story was
> *right*.

I disagree and I find it completely reasonable to ask. That's why
I did so.

And yes, they were right: if qbs is created for Qt alone, then
they shouldn't
rely on it. Hence the request to show that it can be used by
others and that
there's at least a modest community behind it.

There has been enough time to get more adoption and there's still
time left.
So get someone else to adopt it.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com 

  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org 
http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org 
http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[NIkolai Marchenko]

> Don't ask Qt to switch to it until you've done that work.

Tbh, we wouldn't if this post hasn't almost stated that you are pulling the
plug.
As I saw it: qbs folks have finally started doing the correct thiing (that
is - tutorials) and what you are speaking of had a chance to happen.
But as of right now no amount of tutorials will change the fact that
reluctance to swtich to a new system will become reluctance to change to a
_stillborn_ system.

By pulling the plug Lars ensures that qbs has not had a chance and _will
not have_ that chance.

Oh, and also, maybe we need a separate post about this issue: "Should QBS
stay?"
Or something like that so that it's visible on it's own and more people
jump into the discussion.
So far we have quite a few projects in the spreadsheet I created.
I wonder how many more will be added.



On Wed, Oct 31, 2018 at 12:27 AM Thiago Macieira 
wrote:

> On Tuesday, 30 October 2018 13:56:45 PDT NIkolai Marchenko wrote:
> > > and has enough of a track record of a community to ask for help.
> >
> > You quite literally have the system's developer in house.
> > Why do you even need to rely on the community so much?
> > I'd understand if qbs was an external tool, but that's not the case.
>
> Because it's a sign of maturity. If the only people who can solve any
> problem
> are the handful of people who work for the company that developed it, we
> have
> a serious Bus Factor problem. And guess what? It's exactly what's
> happening
> right now.
>
> Ossi and several others are right that qbs was never given a proper
> chance. It
> hasn't.
>
> 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.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Thiago Macieira]

On Tuesday, 30 October 2018 14:15:46 PDT NIkolai Marchenko wrote:
> Maybe, but then, you've spent quite some time developing the system ,what's
> stopping you from reaching out to suitable projects that involve packaging
> to help them set up their project with QBS?
> Instead of stating your desire to pull the plug and basically discouraging
> such a community from ever appearing.

I'm assuming that the "you" in that question is The Qt Company, not me 
specifically. I don't know why they didn't.

But if you meant me, I'm not qualified to do it myself, but I *did* ask the 
developers to do that. My email from July was that call for action: among 
other things, get involved with the packager community and show that your tool 
works for their usecases without major side-effects.

Looks like The Qt Company analysed how much effort that would be and decided 
that it wasn't worth the investment.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Thiago Macieira]

On Tuesday, 30 October 2018 13:56:45 PDT NIkolai Marchenko wrote:
> > and has enough of a track record of a community to ask for help.
> 
> You quite literally have the system's developer in house.
> Why do you even need to rely on the community so much?
> I'd understand if qbs was an external tool, but that's not the case.

Because it's a sign of maturity. If the only people who can solve any problem 
are the handful of people who work for the company that developed it, we have 
a serious Bus Factor problem. And guess what? It's exactly what's happening 
right now.

Ossi and several others are right that qbs was never given a proper chance. It 
hasn't.

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.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Иван Комиссаров]

Huh? Looks like they are supporting every build system alive 
https://github.com/openframeworks/openFrameworks/tree/patch-release/libs/openFrameworksCompiled/project

> 30 окт. 2018 г., в 22:14, Jean-Michaël Celerier 
>  написал(а):
> 
> OpenFrameworks, a fairly used creative coding framework has been using QBS 
> for a few years. My experience with it in that context has been quite 
> negative - a year ago it would break on every new QBS release, so you had to 
> use an exact QBS version if you wanted to use OFX (exhibit A: 
> https://forum.openframeworks.cc/t/qtcreator-v4-3-1-qbs-problem/27214 
> ), so 
> multiple people I know have ended up porting OF to use CMake instead : 
> https://github.com/ofnode/of  which frankly 
> worked better and with less breakage. As always, mileage may vary.
> 
> 
> ---
> Jean-Michaël Celerier
> http://www.jcelerier.name 
> 
> On Tue, Oct 30, 2018 at 10:07 PM Thiago Macieira  > wrote:
> On Tuesday, 30 October 2018 13:47:00 PDT Oswald Buddenhagen wrote:
> > On Tue, Oct 30, 2018 at 12:53:48PM -0700, Thiago Macieira wrote:
> > > On Tuesday, 30 October 2018 12:29:46 PDT Oswald Buddenhagen wrote:
> > > > doesn't authorize you to impose requirements that make it basically
> > > > impossible to employ qt as a bootstrapping device for a qbs
> > > > ecosystem.
> > > 
> > > The whole point was "let Qt not be the guinea pig".
> > 
> > you're essentially presuming that qbs is developed by a potentially
> > incompetent external entity.
> 
> No. However, I am asking for proof.
> 
> > > Show me that the tool can achieve what Qt needs for it to achieve
> > 
> > qtbase//wip/qbs2 speaks for itself.
> 
> That's the guinea pig. I am asking for proof by seeing someone else adopt it. 
> The tool is now several years old, it ought to have attracted *someone*.
> 
> And even if it hasn't, there are a couple of years left until we switch for 
> Qt. The community supporting this tool can find other projects of moderate 
> complexity to work with and support.
> 
> > > and has enough of a track record of a community to ask for help.
> > 
> > it has enough "community" and intrinsic quality to get things going.
> 
> I'm not disputing it has quality. But it lacks a specific community I called 
> for: packagers.
> 
> Tell me, has anyone tried to build that branch in the Boot2Qt context?
> 
> > asking for more is completely unreasonable before the community from
> > which the tool originates shows committment by *relying* on it. and as
> > the current situation shows, everyone who didn't trust the story was
> > *right*.
> 
> I disagree and I find it completely reasonable to ask. That's why I did so.
> 
> And yes, they were right: if qbs is created for Qt alone, then they shouldn't 
> rely on it. Hence the request to show that it can be used by others and that 
> there's at least a modest community behind it.
> 
> There has been enough time to get more adoption and there's still time left. 
> So get someone else to adopt it.
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com 
>   Software Architect - Intel Open Source Technology Center
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org 
> http://lists.qt-project.org/mailman/listinfo/development 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[NIkolai Marchenko]

> I'm not disputing it has quality. But it lacks a specific community I
called
for: packagers.

Maybe, but then, you've spent quite some time developing the system ,what's
stopping you from reaching out to suitable projects that involve packaging
to help them set up their project with QBS?
Instead of stating your desire to pull the plug and basically discouraging
such a community from ever appearing.

On Wed, Oct 31, 2018 at 12:07 AM Thiago Macieira 
wrote:

> On Tuesday, 30 October 2018 13:47:00 PDT Oswald Buddenhagen wrote:
> > On Tue, Oct 30, 2018 at 12:53:48PM -0700, Thiago Macieira wrote:
> > > On Tuesday, 30 October 2018 12:29:46 PDT Oswald Buddenhagen wrote:
> > > > doesn't authorize you to impose requirements that make it basically
> > > > impossible to employ qt as a bootstrapping device for a qbs
> > > > ecosystem.
> > >
> > > The whole point was "let Qt not be the guinea pig".
> >
> > you're essentially presuming that qbs is developed by a potentially
> > incompetent external entity.
>
> No. However, I am asking for proof.
>
> > > Show me that the tool can achieve what Qt needs for it to achieve
> >
> > qtbase//wip/qbs2 speaks for itself.
>
> That's the guinea pig. I am asking for proof by seeing someone else adopt
> it.
> The tool is now several years old, it ought to have attracted *someone*.
>
> And even if it hasn't, there are a couple of years left until we switch
> for
> Qt. The community supporting this tool can find other projects of moderate
> complexity to work with and support.
>
> > > and has enough of a track record of a community to ask for help.
> >
> > it has enough "community" and intrinsic quality to get things going.
>
> I'm not disputing it has quality. But it lacks a specific community I
> called
> for: packagers.
>
> Tell me, has anyone tried to build that branch in the Boot2Qt context?
>
> > asking for more is completely unreasonable before the community from
> > which the tool originates shows committment by *relying* on it. and as
> > the current situation shows, everyone who didn't trust the story was
> > *right*.
>
> I disagree and I find it completely reasonable to ask. That's why I did so.
>
> And yes, they were right: if qbs is created for Qt alone, then they
> shouldn't
> rely on it. Hence the request to show that it can be used by others and
> that
> there's at least a modest community behind it.
>
> There has been enough time to get more adoption and there's still time
> left.
> So get someone else to adopt it.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Jean-Michaël Celerier]

OpenFrameworks, a fairly used creative coding framework has been using QBS
for a few years. My experience with it in that context has been quite
negative - a year ago it would break on every new QBS release, so you had
to use an exact QBS version if you wanted to use OFX (exhibit A:
https://forum.openframeworks.cc/t/qtcreator-v4-3-1-qbs-problem/27214), so
multiple people I know have ended up porting OF to use CMake instead :
https://github.com/ofnode/of which frankly worked better and with less
breakage. As always, mileage may vary.


---
Jean-Michaël Celerier
http://www.jcelerier.name


On Tue, Oct 30, 2018 at 10:07 PM Thiago Macieira 
wrote:

> On Tuesday, 30 October 2018 13:47:00 PDT Oswald Buddenhagen wrote:
> > On Tue, Oct 30, 2018 at 12:53:48PM -0700, Thiago Macieira wrote:
> > > On Tuesday, 30 October 2018 12:29:46 PDT Oswald Buddenhagen wrote:
> > > > doesn't authorize you to impose requirements that make it basically
> > > > impossible to employ qt as a bootstrapping device for a qbs
> > > > ecosystem.
> > >
> > > The whole point was "let Qt not be the guinea pig".
> >
> > you're essentially presuming that qbs is developed by a potentially
> > incompetent external entity.
>
> No. However, I am asking for proof.
>
> > > Show me that the tool can achieve what Qt needs for it to achieve
> >
> > qtbase//wip/qbs2 speaks for itself.
>
> That's the guinea pig. I am asking for proof by seeing someone else adopt
> it.
> The tool is now several years old, it ought to have attracted *someone*.
>
> And even if it hasn't, there are a couple of years left until we switch
> for
> Qt. The community supporting this tool can find other projects of moderate
> complexity to work with and support.
>
> > > and has enough of a track record of a community to ask for help.
> >
> > it has enough "community" and intrinsic quality to get things going.
>
> I'm not disputing it has quality. But it lacks a specific community I
> called
> for: packagers.
>
> Tell me, has anyone tried to build that branch in the Boot2Qt context?
>
> > asking for more is completely unreasonable before the community from
> > which the tool originates shows committment by *relying* on it. and as
> > the current situation shows, everyone who didn't trust the story was
> > *right*.
>
> I disagree and I find it completely reasonable to ask. That's why I did so.
>
> And yes, they were right: if qbs is created for Qt alone, then they
> shouldn't
> rely on it. Hence the request to show that it can be used by others and
> that
> there's at least a modest community behind it.
>
> There has been enough time to get more adoption and there's still time
> left.
> So get someone else to adopt it.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Thiago Macieira]

On Tuesday, 30 October 2018 13:47:00 PDT Oswald Buddenhagen wrote:
> On Tue, Oct 30, 2018 at 12:53:48PM -0700, Thiago Macieira wrote:
> > On Tuesday, 30 October 2018 12:29:46 PDT Oswald Buddenhagen wrote:
> > > doesn't authorize you to impose requirements that make it basically
> > > impossible to employ qt as a bootstrapping device for a qbs
> > > ecosystem.
> > 
> > The whole point was "let Qt not be the guinea pig".
> 
> you're essentially presuming that qbs is developed by a potentially
> incompetent external entity.

No. However, I am asking for proof.

> > Show me that the tool can achieve what Qt needs for it to achieve
> 
> qtbase//wip/qbs2 speaks for itself.

That's the guinea pig. I am asking for proof by seeing someone else adopt it. 
The tool is now several years old, it ought to have attracted *someone*.

And even if it hasn't, there are a couple of years left until we switch for 
Qt. The community supporting this tool can find other projects of moderate 
complexity to work with and support.

> > and has enough of a track record of a community to ask for help.
> 
> it has enough "community" and intrinsic quality to get things going.

I'm not disputing it has quality. But it lacks a specific community I called 
for: packagers.

Tell me, has anyone tried to build that branch in the Boot2Qt context?

> asking for more is completely unreasonable before the community from
> which the tool originates shows committment by *relying* on it. and as
> the current situation shows, everyone who didn't trust the story was
> *right*.

I disagree and I find it completely reasonable to ask. That's why I did so.

And yes, they were right: if qbs is created for Qt alone, then they shouldn't 
rely on it. Hence the request to show that it can be used by others and that 
there's at least a modest community behind it.

There has been enough time to get more adoption and there's still time left. 
So get someone else to adopt it.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Matthew Woehlke]

On 30/10/2018 14.25, Oswald Buddenhagen wrote:
> On Tue, Oct 30, 2018 at 01:46:49PM -0400, Matthew Woehlke wrote:
>> In order to actually implement the ability to read CMake interface
>> files (without corner cases), you basically have to *be* CMake.
>> If you assume that you will only have to deal with some subset, you
>> will be subject to breakage at any time.
>
> yes, but [...] the whole thing would be only a "bridge technology" 
> anyway.

So why not jump straight to a better way of exchanging package
information, and teach CMake to speak that? If you can produce such a
system (which is exactly what CPS tries to do), I think CMake would be
receptive. Why bother with an interim solution?

(BTW, I'm hoping there will be some discussion along these lines at WG21
next week... At least there were two papers in the most recent mailing
along these lines.)

>> I would rather see CMake learn to read and output something more
>> portable, e.g. CPS¹.
>
> from a quick glance, this isn't all that bad, and in fact reflects the
> strongly declarative concepts i'm envisaging for qbs' interface files.

Thanks :-). I've tried to make it plausible and address both likely edge
cases and some issues that CMake currently does not handle well, while
keeping it reasonably simple. It's mostly lacking implementation, and I
haven't had the time/ability to do a lot more than write up the schema.
Help would be much appreciated!

-- 
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[NIkolai Marchenko]

>  and has enough of a track record of a community to ask for help.

You quite literally have the system's developer in house.
Why do you even need to rely on the community so much?
I'd understand if qbs was an external tool, but that's not the case.

On Tue, Oct 30, 2018 at 11:49 PM Konstantin Shegunov 
wrote:

>
>
> On Tue, Oct 30, 2018 at 9:09 PM Thiago Macieira 
> wrote:
>
>> On Tuesday, 30 October 2018 10:26:15 PDT Konstantin Shegunov wrote:
>> > From my point of view qbs is doomed as long as qmake's alive. Either
>> kill
>> > qmake and force the developers using Qt (or developing Qt) to use qbs
>>
>> That's not going to happen any more than our breaking source
>> compatibility in
>> a major way.
>>
>
> Fair enough. As a consequence qbs gets rather limited exposure, thus it's
> not a priority for development.
> To make matters worse smaller user base means smaller amount of
> bugreports/fixes. Less fixes in turn leads to buggier/quirkier system
> leading to fewer people using it. And the circle is complete - unfortunate,
> but somewhat expected.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Konstantin Shegunov]

On Tue, Oct 30, 2018 at 9:09 PM Thiago Macieira 
wrote:

> On Tuesday, 30 October 2018 10:26:15 PDT Konstantin Shegunov wrote:
> > From my point of view qbs is doomed as long as qmake's alive. Either kill
> > qmake and force the developers using Qt (or developing Qt) to use qbs
>
> That's not going to happen any more than our breaking source compatibility
> in
> a major way.
>

Fair enough. As a consequence qbs gets rather limited exposure, thus it's
not a priority for development.
To make matters worse smaller user base means smaller amount of
bugreports/fixes. Less fixes in turn leads to buggier/quirkier system
leading to fewer people using it. And the circle is complete - unfortunate,
but somewhat expected.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Oswald Buddenhagen]

On Tue, Oct 30, 2018 at 12:53:48PM -0700, Thiago Macieira wrote:
> On Tuesday, 30 October 2018 12:29:46 PDT Oswald Buddenhagen wrote:
> > doesn't authorize you to impose requirements that make it basically
> > impossible to employ qt as a bootstrapping device for a qbs
> > ecosystem.
> 
> The whole point was "let Qt not be the guinea pig".
>
you're essentially presuming that qbs is developed by a potentially
incompetent external entity.

> Show me that the tool can achieve what Qt needs for it to achieve
>
qtbase//wip/qbs2 speaks for itself.

> and has enough of a track record of a community to ask for help.
>
it has enough "community" and intrinsic quality to get things going.
asking for more is completely unreasonable before the community from
which the tool originates shows committment by *relying* on it. and as
the current situation shows, everyone who didn't trust the story was
*right*.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Thiago Macieira]

On Tuesday, 30 October 2018 12:21:25 PDT NIkolai Marchenko wrote:
> >  No, we will break source compatibility in a minor way.
> 
> I am not aware of what was the end result of QList discussion, but didn't
> you want to deprecate/majorly change that at some point?
> That alone would be rather huge.

No, it wouldn't, because we'll provide a mostly or entirely source-compatible 
replacement.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Thiago Macieira]

On Tuesday, 30 October 2018 12:29:46 PDT Oswald Buddenhagen wrote:
> On Tue, Oct 30, 2018 at 12:01:59PM -0700, Thiago Macieira wrote:
> > The requirement was not of the tool to be packaged.
> > 
> > It was of one similar-complexity package *using* the buildsystem to be
> > packaged for 2 years.
> 
> err, right.
> 
> but quite frankly, i call foul on that one and some other items in your
> list. you had some frustrations as a packager, but that's just part of
> the job, and doesn't authorize you to impose requirements that make it
> basically impossible to employ qt as a bootstrapping device for a qbs
> ecosystem.

The whole point was "let Qt not be the guinea pig". Show me that the tool can 
achieve what Qt needs for it to achieve and has enough of a track record of a 
community to ask for help. The requirements I outlined were about making that 
requirement more objective.

The Qt community can of course disagree with me. The only enforcement I have 
is on myself: I said I will not work on Qt if it switches to a different build 
system until it meet my requirements. The 2-year-track record is included in 
that.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[NIkolai Marchenko]

>  But the fact that in 4 years there is just one package in Debian's
archive using qbs says a lot.

Unfortunately all it says is that QBS developers _really_ didn't care to
advertise/document their system.
it's no wonder there are no projects when the only thing you have to work
off of is a bunch module references.

I am not so annoyed at the decision to drop qbs as I am annoyed at the fact
that it failed because it never was given a fair chance
and just as things seemed to begin to improve(i.e. finally tutorial pages)
they decide to drop it.
Of course now those pages become irrelevant as no one will want to jump
onto a dying system regardless of if it has documentation or not.




On Tue, Oct 30, 2018 at 10:32 PM Lisandro Damián Nicanor Pérez Meyer <
perezme...@gmail.com> wrote:

> El martes, 30 de octubre de 2018 15:26:14 -03 Иван Комиссаров escribió:
> > Wow, hold on for a minute.
> > I’ve been using a qbs package as a standalone leaf package (sudo aptitude
> > install qbs) to build my projects. Also, self-built QBS package was
> > commercially used to create several Debian packages back in 2013.
>
> I can't count what's not in Debian proper. But the fact that in 4 years
> there
> is just one package in Debian's archive using qbs says a lot.
>
> Of course anyone can jump in to help maintain qbs and keep it in the
> archive.
>
> --
> http://www.tiraecol.net/modules/comic/comic.php?content_id=162
>
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Lisandro Damián Nicanor Pérez Meyer]

El martes, 30 de octubre de 2018 15:26:14 -03 Иван Комиссаров escribió:
> Wow, hold on for a minute.
> I’ve been using a qbs package as a standalone leaf package (sudo aptitude
> install qbs) to build my projects. Also, self-built QBS package was
> commercially used to create several Debian packages back in 2013.

I can't count what's not in Debian proper. But the fact that in 4 years there 
is just one package in Debian's archive using qbs says a lot.

Of course anyone can jump in to help maintain qbs and keep it in the archive.

-- 
http://www.tiraecol.net/modules/comic/comic.php?content_id=162

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Oswald Buddenhagen]

On Tue, Oct 30, 2018 at 12:01:59PM -0700, Thiago Macieira wrote:
> The requirement was not of the tool to be packaged.
> 
> It was of one similar-complexity package *using* the buildsystem to be
> packaged for 2 years.
> 
err, right.

but quite frankly, i call foul on that one and some other items in your
list. you had some frustrations as a packager, but that's just part of
the job, and doesn't authorize you to impose requirements that make it
basically impossible to employ qt as a bootstrapping device for a qbs
ecosystem.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Adam Treat]

Lars gave a keynote saying pretty much the same. Simply is not true that 
we are planning major source compatible breakage for Qt6 so let's stop 
saying that.

On 10/30/2018 03:19 PM, Thiago Macieira wrote:
> On Tuesday, 30 October 2018 12:11:38 PDT NIkolai Marchenko wrote:
>>   >  That's not going to happen any more than our breaking source
>>
>> compatibility in
>> a major way.
>>
>> You are breaking source compatibility in a major way with Qt6 ... ;)
> No, we will break source compatibility in a minor way.
>

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[NIkolai Marchenko]

>  No, we will break source compatibility in a minor way.

I am not aware of what was the end result of QList discussion, but didn't
you want to deprecate/majorly change that at some point?
That alone would be rather huge.

On Tue, Oct 30, 2018 at 10:19 PM Thiago Macieira 
wrote:

> On Tuesday, 30 October 2018 12:11:38 PDT NIkolai Marchenko wrote:
> >  >  That's not going to happen any more than our breaking source
> >
> > compatibility in
> > a major way.
> >
> > You are breaking source compatibility in a major way with Qt6 ... ;)
>
> No, we will break source compatibility in a minor way.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development