Discussion:
[Development] Build system for Qt 6
Lars Knoll
2018-10-29 12:17:04 UTC
Permalink
Hi all,

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.

Thiago wrote a set of relatively strict requirements for such a build tool in his mail in July. While some of the requirements had a bit of a Linux specific background, they have been a good basis.

There have been rather lively discussions around alternatives, but most focused around two possible choices for us: Qbs and cmake.

Qbs is something that has been developed almost exclusively by The Qt Company. As such, TQtC had to also look at it from a business perspective and how it fits into the larger picture of making Qt successful. To make a long story short, while Qbs is pretty cool and interesting technology, it doesn’t really help us expand the Qt ecosystem and usage.

To make Qbs really successful would require a rather large effort and investment in promoting it towards the larger C++ ecosystem as a new build tool. At the same time it has to be an open source product to stand any chance in the market. Together this makes it challenging for TQtC to see how to recover that investment. 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.

As such, we were left with the question on whether we need Qbs as the build system for Qt 6 or whether cmake (as the other alternative) would be up to the task.

Given that background, we’ve done some more research on using both Qbs and cmake to build Qt. Both projects did give us good results but we were actually surprised on how far we got with cmake in a rather limited period of time.

In addition, cmake has the advantage of being very widely used in the C++ ecosystem (amongst many others by KDE), has a very wide support in many IDEs and other tools (e.g. VCPkg, Conan etc.), and there’s a lot of knowledge about the build system available in the ecosystem. Using it with Qt 6 would also mean that we can focus our support on two build systems for our users (qmake and cmake) and we would not have to add a third one to the mix.

Given that we are confident we can build Qt 6 with cmake, I believe that it makes most sense to follow down that route. In case you’re interested, you can have a look at the cmake prototype code for qtbase on Gerrit in the wip/cmake branch. Please also let us know if you’re interested in helping with the effort of porting Qt’s build system over to cmake.

We have been developing Qbs over the last years, and as such are committed to it for some more time. We are planning on another feature release in the first quarter of next year and will support it in Qt Creator for at least another year. Qbs is open source and if someone wants to take over and develop it further let us know as well. I’d also like to use this place to thank Christian and Jörg for all their great work on Qbs (and of course also anybody else who contributed to it).

Cheers,
Lars
Corentin
2018-10-29 16:24:17 UTC
Permalink
Having had the pleasure to use QBS quite extensively (and successfully) in
the past, I would like to thank the QBS team and contributors for showing
us what a sane, modern build system could look like.
So long!

On Mon, 29 Oct 2018 at 13:17 Lars Knoll <***@qt.io> wrote:

> Hi all,
>
> 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.
>
> Thiago wrote a set of relatively strict requirements for such a build tool
> in his mail in July. While some of the requirements had a bit of a Linux
> specific background, they have been a good basis.
>
> There have been rather lively discussions around alternatives, but most
> focused around two possible choices for us: Qbs and cmake.
>
> Qbs is something that has been developed almost exclusively by The Qt
> Company. As such, TQtC had to also look at it from a business perspective
> and how it fits into the larger picture of making Qt successful. To make a
> long story short, while Qbs is pretty cool and interesting technology, it
> doesn’t really help us expand the Qt ecosystem and usage.
>
> To make Qbs really successful would require a rather large effort and
> investment in promoting it towards the larger C++ ecosystem as a new build
> tool. At the same time it has to be an open source product to stand any
> chance in the market. Together this makes it challenging for TQtC to see
> how to recover that investment. 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.
>
> As such, we were left with the question on whether we need Qbs as the
> build system for Qt 6 or whether cmake (as the other alternative) would be
> up to the task.
>
> Given that background, we’ve done some more research on using both Qbs and
> cmake to build Qt. Both projects did give us good results but we were
> actually surprised on how far we got with cmake in a rather limited period
> of time.
>
> In addition, cmake has the advantage of being very widely used in the C++
> ecosystem (amongst many others by KDE), has a very wide support in many
> IDEs and other tools (e.g. VCPkg, Conan etc.), and there’s a lot of
> knowledge about the build system available in the ecosystem. Using it with
> Qt 6 would also mean that we can focus our support on two build systems for
> our users (qmake and cmake) and we would not have to add a third one to the
> mix.
>
> Given that we are confident we can build Qt 6 with cmake, I believe that
> it makes most sense to follow down that route. In case you’re interested,
> you can have a look at the cmake prototype code for qtbase on Gerrit in the
> wip/cmake branch. Please also let us know if you’re interested in helping
> with the effort of porting Qt’s build system over to cmake.
>
> We have been developing Qbs over the last years, and as such are committed
> to it for some more time. We are planning on another feature release in the
> first quarter of next year and will support it in Qt Creator for at least
> another year. Qbs is open source and if someone wants to take over and
> develop it further let us know as well. I’d also like to use this place to
> thank Christian and Jörg for all their great work on Qbs (and of course
> also anybody else who contributed to it).
>
> Cheers,
> Lars
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
Ray Donnelly
2018-10-29 16:32:11 UTC
Permalink
Agreed, a brilliant bit of technology, such a shame to see it deprecated.
On Mon, Oct 29, 2018 at 4:24 PM Corentin <***@gmail.com> wrote:
>
>
> Having had the pleasure to use QBS quite extensively (and successfully) in the past, I would like to thank the QBS team and contributors for showing us what a sane, modern build system could look like.
> So long!
>
> On Mon, 29 Oct 2018 at 13:17 Lars Knoll <***@qt.io> wrote:
>>
>> Hi all,
>>
>> 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.
>>
>> Thiago wrote a set of relatively strict requirements for such a build tool in his mail in July. While some of the requirements had a bit of a Linux specific background, they have been a good basis.
>>
>> There have been rather lively discussions around alternatives, but most focused around two possible choices for us: Qbs and cmake.
>>
>> Qbs is something that has been developed almost exclusively by The Qt Company. As such, TQtC had to also look at it from a business perspective and how it fits into the larger picture of making Qt successful. To make a long story short, while Qbs is pretty cool and interesting technology, it doesn’t really help us expand the Qt ecosystem and usage.
>>
>> To make Qbs really successful would require a rather large effort and investment in promoting it towards the larger C++ ecosystem as a new build tool. At the same time it has to be an open source product to stand any chance in the market. Together this makes it challenging for TQtC to see how to recover that investment. 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.
>>
>> As such, we were left with the question on whether we need Qbs as the build system for Qt 6 or whether cmake (as the other alternative) would be up to the task.
>>
>> Given that background, we’ve done some more research on using both Qbs and cmake to build Qt. Both projects did give us good results but we were actually surprised on how far we got with cmake in a rather limited period of time.
>>
>> In addition, cmake has the advantage of being very widely used in the C++ ecosystem (amongst many others by KDE), has a very wide support in many IDEs and other tools (e.g. VCPkg, Conan etc.), and there’s a lot of knowledge about the build system available in the ecosystem. Using it with Qt 6 would also mean that we can focus our support on two build systems for our users (qmake and cmake) and we would not have to add a third one to the mix.
>>
>> Given that we are confident we can build Qt 6 with cmake, I believe that it makes most sense to follow down that route. In case you’re interested, you can have a look at the cmake prototype code for qtbase on Gerrit in the wip/cmake branch. Please also let us know if you’re interested in helping with the effort of porting Qt’s build system over to cmake.
>>
>> We have been developing Qbs over the last years, and as such are committed to it for some more time. We are planning on another feature release in the first quarter of next year and will support it in Qt Creator for at least another year. Qbs is open source and if someone wants to take over and develop it further let us know as well. I’d also like to use this place to thank Christian and Jörg for all their great work on Qbs (and of course also anybody else who contributed to it).
>>
>> Cheers,
>> Lars
>> _______________________________________________
>> Development mailing list
>> ***@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Иван Комиссаров
2018-10-29 16:36:53 UTC
Permalink
RIP Qbs=(

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

> 29 окт. 2018 г., в 17:32, Ray Donnelly <***@gmail.com> написал(а):
>
> Agreed, a brilliant bit of technology, such a shame to see it deprecated.
>> On Mon, Oct 29, 2018 at 4:24 PM Corentin <***@gmail.com> wrote:
>>
>>
>> Having had the pleasure to use QBS quite extensively (and successfully) in the past, I would like to thank the QBS team and contributors for showing us what a sane, modern build system could look like.
>> So long!
>>
>>> On Mon, 29 Oct 2018 at 13:17 Lars Knoll <***@qt.io> wrote:
>>>
>>> Hi all,
>>>
>>> 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.
>>>
>>> Thiago wrote a set of relatively strict requirements for such a build tool in his mail in July. While some of the requirements had a bit of a Linux specific background, they have been a good basis.
>>>
>>> There have been rather lively discussions around alternatives, but most focused around two possible choices for us: Qbs and cmake.
>>>
>>> Qbs is something that has been developed almost exclusively by The Qt Company. As such, TQtC had to also look at it from a business perspective and how it fits into the larger picture of making Qt successful. To make a long story short, while Qbs is pretty cool and interesting technology, it doesn’t really help us expand the Qt ecosystem and usage.
>>>
>>> To make Qbs really successful would require a rather large effort and investment in promoting it towards the larger C++ ecosystem as a new build tool. At the same time it has to be an open source product to stand any chance in the market. Together this makes it challenging for TQtC to see how to recover that investment. 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.
>>>
>>> As such, we were left with the question on whether we need Qbs as the build system for Qt 6 or whether cmake (as the other alternative) would be up to the task.
>>>
>>> Given that background, we’ve done some more research on using both Qbs and cmake to build Qt. Both projects did give us good results but we were actually surprised on how far we got with cmake in a rather limited period of time.
>>>
>>> In addition, cmake has the advantage of being very widely used in the C++ ecosystem (amongst many others by KDE), has a very wide support in many IDEs and other tools (e.g. VCPkg, Conan etc.), and there’s a lot of knowledge about the build system available in the ecosystem. Using it with Qt 6 would also mean that we can focus our support on two build systems for our users (qmake and cmake) and we would not have to add a third one to the mix.
>>>
>>> Given that we are confident we can build Qt 6 with cmake, I believe that it makes most sense to follow down that route. In case you’re interested, you can have a look at the cmake prototype code for qtbase on Gerrit in the wip/cmake branch. Please also let us know if you’re interested in helping with the effort of porting Qt’s build system over to cmake.
>>>
>>> We have been developing Qbs over the last years, and as such are committed to it for some more time. We are planning on another feature release in the first quarter of next year and will support it in Qt Creator for at least another year. Qbs is open source and if someone wants to take over and develop it further let us know as well. I’d also like to use this place to thank Christian and Jörg for all their great work on Qbs (and of course also anybody else who contributed to it).
>>>
>>> Cheers,
>>> Lars
>>> _______________________________________________
>>> Development mailing list
>>> ***@qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/development
>>
>> _______________________________________________
>> Development mailing list
>> ***@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Ola Røer Thorsen
2018-10-29 21:53:47 UTC
Permalink
>
>
> > >> We have been developing Qbs over the last years, and as such are
> > >> committed to it for some more time. We are planning on another feature
> > >> release in the first quarter of next year and will support it in Qt
> > >> Creator for at least another year.
>

This is _really_ disappointing news. I'd be happy to see qmake go, now
this.

We (at work, commercial Qt license) recently ported a rather big build
system to Qbs, replacing qmake and scons. We now have good IDE integration
for all our projects in QtCreator, both the Qt-based applications as well
as pure C/C++-based projects for desktop, embedded Linux and "bare metal"
embedded. We spent some time debugging and reporting/fixing bugs in Qbs
too. Now with Qbs 1.12.0 we're having good and stable results. Incremental
builds are _very_ fast. Project files are easy to set up, read and extend,
even with custom code generation rules, things we never were able to do
with (even undocumented) qmake. It's really impressive.

Well I guess all that was for nothing, let's rewrite the build system next
year again, and make really sure not to embrace new Qt technologies so fast
next time.

Cheers,
Ola
NIkolai Marchenko
2018-10-29 22:15:38 UTC
Permalink
I don't understand how can Qt just let QBS die like that. It's absolutely
fantastic.
I really hope open source development happens becuase ti will be bloody
shame if ti doesn't :(


On Tue, Oct 30, 2018 at 12:54 AM Ola RÞer Thorsen <***@silentwings.no>
wrote:

>
>> > >> We have been developing Qbs over the last years, and as such are
>> > >> committed to it for some more time. We are planning on another
>> feature
>> > >> release in the first quarter of next year and will support it in Qt
>> > >> Creator for at least another year.
>>
>
> This is _really_ disappointing news. I'd be happy to see qmake go, now
> this.
>
> We (at work, commercial Qt license) recently ported a rather big build
> system to Qbs, replacing qmake and scons. We now have good IDE integration
> for all our projects in QtCreator, both the Qt-based applications as well
> as pure C/C++-based projects for desktop, embedded Linux and "bare metal"
> embedded. We spent some time debugging and reporting/fixing bugs in Qbs
> too. Now with Qbs 1.12.0 we're having good and stable results. Incremental
> builds are _very_ fast. Project files are easy to set up, read and extend,
> even with custom code generation rules, things we never were able to do
> with (even undocumented) qmake. It's really impressive.
>
> Well I guess all that was for nothing, let's rewrite the build system next
> year again, and make really sure not to embrace new Qt technologies so fast
> next time.
>
> Cheers,
> Ola
>
>
>
>
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
Pier Luigi Fiorini
2018-10-29 16:36:07 UTC
Permalink
I too feel like thanks are in order to the Qbs team.
Hopefully CMake integration with QtCreator will quickly improve and include
mobile platforms as well as embedded and desktop.

Il giorno lun 29 ott 2018 alle ore 17:24 Corentin <***@gmail.com>
ha scritto:

>
> Having had the pleasure to use QBS quite extensively (and successfully) in
> the past, I would like to thank the QBS team and contributors for showing
> us what a sane, modern build system could look like.
> So long!
>
> On Mon, 29 Oct 2018 at 13:17 Lars Knoll <***@qt.io> wrote:
>
>> Hi all,
>>
>> 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.
>>
>> Thiago wrote a set of relatively strict requirements for such a build
>> tool in his mail in July. While some of the requirements had a bit of a
>> Linux specific background, they have been a good basis.
>>
>> There have been rather lively discussions around alternatives, but most
>> focused around two possible choices for us: Qbs and cmake.
>>
>> Qbs is something that has been developed almost exclusively by The Qt
>> Company. As such, TQtC had to also look at it from a business perspective
>> and how it fits into the larger picture of making Qt successful. To make a
>> long story short, while Qbs is pretty cool and interesting technology, it
>> doesn’t really help us expand the Qt ecosystem and usage.
>>
>> To make Qbs really successful would require a rather large effort and
>> investment in promoting it towards the larger C++ ecosystem as a new build
>> tool. At the same time it has to be an open source product to stand any
>> chance in the market. Together this makes it challenging for TQtC to see
>> how to recover that investment. 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.
>>
>> As such, we were left with the question on whether we need Qbs as the
>> build system for Qt 6 or whether cmake (as the other alternative) would be
>> up to the task.
>>
>> Given that background, we’ve done some more research on using both Qbs
>> and cmake to build Qt. Both projects did give us good results but we were
>> actually surprised on how far we got with cmake in a rather limited period
>> of time.
>>
>> In addition, cmake has the advantage of being very widely used in the C++
>> ecosystem (amongst many others by KDE), has a very wide support in many
>> IDEs and other tools (e.g. VCPkg, Conan etc.), and there’s a lot of
>> knowledge about the build system available in the ecosystem. Using it with
>> Qt 6 would also mean that we can focus our support on two build systems for
>> our users (qmake and cmake) and we would not have to add a third one to the
>> mix.
>>
>> Given that we are confident we can build Qt 6 with cmake, I believe that
>> it makes most sense to follow down that route. In case you’re interested,
>> you can have a look at the cmake prototype code for qtbase on Gerrit in the
>> wip/cmake branch. Please also let us know if you’re interested in helping
>> with the effort of porting Qt’s build system over to cmake.
>>
>> We have been developing Qbs over the last years, and as such are
>> committed to it for some more time. We are planning on another feature
>> release in the first quarter of next year and will support it in Qt Creator
>> for at least another year. Qbs is open source and if someone wants to take
>> over and develop it further let us know as well. I’d also like to use this
>> place to thank Christian and Jörg for all their great work on Qbs (and of
>> course also anybody else who contributed to it).
>>
>> Cheers,
>> Lars
>> _______________________________________________
>> Development mailing list
>> ***@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>


--
https://liri.io
NIkolai Marchenko
2018-10-30 01:20:35 UTC
Permalink
Lars, I have to wonder, don't you guys miss an opportunity here?
Qt 5 was not developed with QBS in mind. As such it probably took more
effort than needed to fit QBS to something that was originally QMake based.

At the same time you will have to fit CMake to suit the needs for Qt6. (or
vice versa)

Would it really be so much extra investment to have a build system fully
integrated into Qt framework process that you can just make fit on the fly,
over fiddling around the system that is overgeneralized and perhaps doesn't
support everything as much as you'd want?

You've said it yourself that qbs did give good results. Maybe give it a
chance?


On Mon, Oct 29, 2018 at 3:17 PM Lars Knoll <***@qt.io> wrote:

> Hi all,
>
> 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.
>
> Thiago wrote a set of relatively strict requirements for such a build tool
> in his mail in July. While some of the requirements had a bit of a Linux
> specific background, they have been a good basis.
>
> There have been rather lively discussions around alternatives, but most
> focused around two possible choices for us: Qbs and cmake.
>
> Qbs is something that has been developed almost exclusively by The Qt
> Company. As such, TQtC had to also look at it from a business perspective
> and how it fits into the larger picture of making Qt successful. To make a
> long story short, while Qbs is pretty cool and interesting technology, it
> doesn’t really help us expand the Qt ecosystem and usage.
>
> To make Qbs really successful would require a rather large effort and
> investment in promoting it towards the larger C++ ecosystem as a new build
> tool. At the same time it has to be an open source product to stand any
> chance in the market. Together this makes it challenging for TQtC to see
> how to recover that investment. 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.
>
> As such, we were left with the question on whether we need Qbs as the
> build system for Qt 6 or whether cmake (as the other alternative) would be
> up to the task.
>
> Given that background, we’ve done some more research on using both Qbs and
> cmake to build Qt. Both projects did give us good results but we were
> actually surprised on how far we got with cmake in a rather limited period
> of time.
>
> In addition, cmake has the advantage of being very widely used in the C++
> ecosystem (amongst many others by KDE), has a very wide support in many
> IDEs and other tools (e.g. VCPkg, Conan etc.), and there’s a lot of
> knowledge about the build system available in the ecosystem. Using it with
> Qt 6 would also mean that we can focus our support on two build systems for
> our users (qmake and cmake) and we would not have to add a third one to the
> mix.
>
> Given that we are confident we can build Qt 6 with cmake, I believe that
> it makes most sense to follow down that route. In case you’re interested,
> you can have a look at the cmake prototype code for qtbase on Gerrit in the
> wip/cmake branch. Please also let us know if you’re interested in helping
> with the effort of porting Qt’s build system over to cmake.
>
> We have been developing Qbs over the last years, and as such are committed
> to it for some more time. We are planning on another feature release in the
> first quarter of next year and will support it in Qt Creator for at least
> another year. Qbs is open source and if someone wants to take over and
> develop it further let us know as well. I’d also like to use this place to
> thank Christian and Jörg for all their great work on Qbs (and of course
> also anybody else who contributed to it).
>
> Cheers,
> Lars
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
Thiago Macieira
2018-10-30 03:34:22 UTC
Permalink
On Monday, 29 October 2018 18:20:35 PDT NIkolai Marchenko wrote:
> Lars, I have to wonder, don't you guys miss an opportunity here?
> Qt 5 was not developed with QBS in mind. As such it probably took more
> effort than needed to fit QBS to something that was originally QMake based.
>
> At the same time you will have to fit CMake to suit the needs for Qt6. (or
> vice versa)
>
> Would it really be so much extra investment to have a build system fully
> integrated into Qt framework process that you can just make fit on the fly,
> over fiddling around the system that is overgeneralized and perhaps doesn't
> support everything as much as you'd want?

I'm not Lars.

But yes.

The Qt 6 organisation won't be too different from Qt 5's, aside from the
changes that Lars and Tobias have already mentioned and that make a lot of
sense to me. So I don't see how any kind of organisation will make it easier.

More importantly, the problem is keeping that specific buildsystem working. If
the work isn't shared and others don't pitch in, the price to pay to keep a
Qt-only buildsystem working is too high: that's what Lars' email says.

Finally, I'm sure any reasonable request we may have on something CMake
doesn't support yet, upstream will be willing to hear us and implement where
necessary. I quite frankly don't expect there to be much, especially since
Lars' email says that they made so much progress in so little time.

> You've said it yourself that qbs did give good results. Maybe give it a
> chance?

It's been given a chance. The wip/qbs branch has existed for years in qtbase.
The tool has existed for years.

Can you name any project of moderate complexity using it?

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Pier Luigi Fiorini
2018-10-30 07:12:33 UTC
Permalink
Il giorno mar 30 ott 2018 alle ore 04:34 Thiago Macieira <
***@intel.com> ha scritto:

>
> > You've said it yourself that qbs did give good results. Maybe give it a
> > chance?
>
> It's been given a chance. The wip/qbs branch has existed for years in
> qtbase.
> The tool has existed for years.
>

No Qbs hasn't got visibility outside the Qt project and even inside there
are people, like me, who really learned about it a couple years ago and
then it was planned to be the Qt 6 build system.
With more visibility, documentation and examples in all those years, things
might different now.

Some people say Qt is not in the business of creating a build tool but it
was not in the business of creating an IDE but we have QtCreator, which is
an excellent IDE tailored to the needs of Qt developers.

In less than two years we went from the build system planned for Qt 6 to a
deprecated tool.
Spending those years improving CMake (documentation, IDE integration, ...)
would have been far better then.


>
> Can you name any project of moderate complexity using it?
>
>
https://github.com/lirios

--
https://liri.io
Иван Комиссаров
2018-10-30 07:47:02 UTC
Permalink
Иван Комиссаров

> 30 окт. 2018 г., в 4:34, Thiago Macieira <***@intel.com> написал(а):
>
>> On Monday, 29 October 2018 18:20:35 PDT NIkolai Marchenko wrote:
>> Lars, I have to wonder, don't you guys miss an opportunity here?
>> Qt 5 was not developed with QBS in mind. As such it probably took more
>> effort than needed to fit QBS to something that was originally QMake based.
>>
>> At the same time you will have to fit CMake to suit the needs for Qt6. (or
>> vice versa)
>>
>> Would it really be so much extra investment to have a build system fully
>> integrated into Qt framework process that you can just make fit on the fly,
>> over fiddling around the system that is overgeneralized and perhaps doesn't
>> support everything as much as you'd want?
>
> I'm not Lars.
>
> But yes.
>
> The Qt 6 organisation won't be too different from Qt 5's, aside from the
> changes that Lars and Tobias have already mentioned and that make a lot of
> sense to me. So I don't see how any kind of organisation will make it easier.
>
> More importantly, the problem is keeping that specific buildsystem working. If
> the work isn't shared and others don't pitch in, the price to pay to keep a
> Qt-only buildsystem working is too high: that's what Lars' email says.
>
> Finally, I'm sure any reasonable request we may have on something CMake
> doesn't support yet, upstream will be willing to hear us and implement where
> necessary. I quite frankly don't expect there to be much, especially since
> Lars' email says that they made so much progress in so little time.
>
>> You've said it yourself that qbs did give good results. Maybe give it a
>> chance?
>
> It's been given a chance. The wip/qbs branch has existed for years in qtbase.
> The tool has existed for years.
>
> Can you name any project of moderate complexity using it?
>

How about Qt creator? How about commercial projects?

But what I would like to ask is how about porting Qt Creator to cmake first, before porting Qt? Of course, this is not as fun as porting Qt but we can _compare_ all three build tools on that project. It is huge, uses code generation so it was a good playground for qbs. Why not use it as a playground for cmake? Then we'all have _numbers_ (speed, project files size and so on)

> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
>
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Christian Gagneraud
2018-10-30 07:59:15 UTC
Permalink
On Tue, 30 Oct 2018 at 20:47, Иван Комиссаров <***@gmail.com> wrote:
> Иван Комиссаров
> > 30 окт. 2018 г., в 4:34, Thiago Macieira <***@intel.com> написал(а):
> > Can you name any project of moderate complexity using it?
> >
>
> How about Qt creator? How about commercial projects?
>
> But what I would like to ask is how about porting Qt Creator to cmake first, before porting Qt? Of course, this is not as fun as porting Qt but we can _compare_ all three build tools on that project. It is huge, uses code generation so it was a good playground for qbs. Why not use it as a playground for cmake? Then we'all have _numbers_ (speed, project files size and so on)
>

+1, if you cannot port QtCreator to CMake, then you have no chance to
port Qt to Cmake.
Both QtCreator and Qbs can be built and developed using QtCreator+Qbs.

Interesting experience: port Qbs and QtCreator to CMake and let see
what sort of experience it is to develop QtCreator and Qbs using
QtCreator+CMake.
Richard Weickelt
2018-10-30 09:43:16 UTC
Permalink
> Can you name any project of moderate complexity using it?

https://github.com/bjorn/tiled
NIkolai Marchenko
2018-10-30 09:47:55 UTC
Permalink
Actually, what is considered moderate complexity? I have a project at work
that has been running for a few years, has 4 people working on it and has a
few thousand commits.
It has a couple dozen libraries, is integrated with gRPC and has code
generated with protobuf on build via a custom QBS module. Is this
considered moderate complexity?
(though I siuspect Lars wants a bigger project)

On Tue, Oct 30, 2018 at 12:43 PM Richard Weickelt <***@weickelt.de>
wrote:

> > Can you name any project of moderate complexity using it?
>
> https://github.com/bjorn/tiled
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
Thiago Macieira
2018-10-30 16:10:27 UTC
Permalink
On Tuesday, 30 October 2018 02:47:55 PDT NIkolai Marchenko wrote:
> Actually, what is considered moderate complexity? I have a project at work
> that has been running for a few years, has 4 people working on it and has a
> few thousand commits.

My email from July has some objective parameters. Please reread it.

> It has a couple dozen libraries, is integrated with gRPC and has code
> generated with protobuf on build via a custom QBS module. Is this
> considered moderate complexity?

Getting there. There are a couple of things missing, but the important ones
are there.

Is it packaged in a Linux distribution? My requirements also included
continuously packaged for 2 years in at least 3 Linux distributions, at the
time of the Qt switch to the particular buildsystem.

See that email for more information.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Oswald Buddenhagen
2018-10-30 16:52:18 UTC
Permalink
On Tue, Oct 30, 2018 at 09:10:27AM -0700, Thiago Macieira wrote:
> Is it packaged in a Linux distribution? My requirements also included
> continuously packaged for 2 years in at least 3 Linux distributions,
> at the time of the Qt switch to the particular buildsystem.
>
it's been packaged for much longer and by more distros already, because
it's part of qt creator for quite a while. i don't know whether all of
them ship it as separate packages already, but the official messaging
from us was that they *should*.
Lisandro Damián Nicanor Pérez Meyer
2018-10-30 17:18:05 UTC
Permalink
El martes, 30 de octubre de 2018 13:52:18 -03 Oswald Buddenhagen escribió:
> On Tue, Oct 30, 2018 at 09:10:27AM -0700, Thiago Macieira wrote:
> > Is it packaged in a Linux distribution? My requirements also included
> > continuously packaged for 2 years in at least 3 Linux distributions,
> > at the time of the Qt switch to the particular buildsystem.
>
> it's been packaged for much longer and by more distros already, because
> it's part of qt creator for quite a while. i don't know whether all of
> them ship it as separate packages already, but the official messaging
> from us was that they *should*.

The first Debian upload was:

qbs (1.2.2+dfsg-1) unstable; urgency=medium

* Initial release (closes: #745095).

-- Dmitry Shachnev <***@gmail.com> Sat, 26 Jul 2014 23:28:44 +0400

As of today, a little more than 4 years, it has only two users (reverse
dependencies): qt creator and dewall.

Considering yesterday's announce and the fact that qt creator ships a bundled
copy the only package stopping us from removing qbs from the archive is
dewall, so I don't think it will stay in the archive for much longer.


--
The box said 'Requires Windows 95 or better'. So I installed Linux.
Anonymous

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
Иван Комиссаров
2018-10-30 18:26:14 UTC
Permalink
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.

> 30 окт. 2018 г., в 18:18, Lisandro Damián Nicanor Pérez Meyer <***@gmail.com> написал(а):
>
> El martes, 30 de octubre de 2018 13:52:18 -03 Oswald Buddenhagen escribió:
>> On Tue, Oct 30, 2018 at 09:10:27AM -0700, Thiago Macieira wrote:
>>> Is it packaged in a Linux distribution? My requirements also included
>>> continuously packaged for 2 years in at least 3 Linux distributions,
>>> at the time of the Qt switch to the particular buildsystem.
>>
>> it's been packaged for much longer and by more distros already, because
>> it's part of qt creator for quite a while. i don't know whether all of
>> them ship it as separate packages already, but the official messaging
>> from us was that they *should*.
>
> The first Debian upload was:
>
> qbs (1.2.2+dfsg-1) unstable; urgency=medium
>
> * Initial release (closes: #745095).
>
> -- Dmitry Shachnev <***@gmail.com> Sat, 26 Jul 2014 23:28:44 +0400
>
> As of today, a little more than 4 years, it has only two users (reverse
> dependencies): qt creator and dewall.
>
> Considering yesterday's announce and the fact that qt creator ships a bundled
> copy the only package stopping us from removing qbs from the archive is
> dewall, so I don't think it will stay in the archive for much longer.
>
>
> --
> The box said 'Requires Windows 95 or better'. So I installed Linux.
> Anonymous
>
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Lisandro Damián Nicanor Pérez Meyer
2018-10-30 19:31:58 UTC
Permalink
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/
NIkolai Marchenko
2018-10-30 19:49:44 UTC
Permalink
> 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 <
***@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
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
Pier Luigi Fiorini
2018-10-30 17:31:54 UTC
Permalink
Il giorno mar 30 ott 2018 alle ore 17:52 Oswald Buddenhagen <
***@qt.io> ha scritto:

> On Tue, Oct 30, 2018 at 09:10:27AM -0700, Thiago Macieira wrote:
> > Is it packaged in a Linux distribution? My requirements also included
> > continuously packaged for 2 years in at least 3 Linux distributions,
> > at the time of the Qt switch to the particular buildsystem.
> >
> it's been packaged for much longer and by more distros already, because
> it's part of qt creator for quite a while. i don't know whether all of
> them ship it as separate packages already, but the official messaging
> from us was that they *should*.
>
>
Distros started packaging it separately for some time now.
Before that, as you point out, it was packaged inside QtCreator.

Debian: https://packages.debian.org/sid/qbs
Fedora: https://apps.fedoraproject.org/packages/qbs
Arch Linux: https://www.archlinux.org/packages/extra/x86_64/qbs/
OpenSuSE: https://software.opensuse.org/package/qbs?search_term=qbs

--
https://liri.io
NIkolai Marchenko
2018-10-30 17:38:57 UTC
Permalink
> From my point of view qbs is doomed as long as qmake's alive.

I would much rather this abomination died instead.
I've switched to qbs when I got way too annoyed by how qmake does things
and I've never been happier.

On Tue, Oct 30, 2018 at 8:32 PM Pier Luigi Fiorini <
***@gmail.com> wrote:

> Il giorno mar 30 ott 2018 alle ore 17:52 Oswald Buddenhagen <
> ***@qt.io> ha scritto:
>
>> On Tue, Oct 30, 2018 at 09:10:27AM -0700, Thiago Macieira wrote:
>> > Is it packaged in a Linux distribution? My requirements also included
>> > continuously packaged for 2 years in at least 3 Linux distributions,
>> > at the time of the Qt switch to the particular buildsystem.
>> >
>> it's been packaged for much longer and by more distros already, because
>> it's part of qt creator for quite a while. i don't know whether all of
>> them ship it as separate packages already, but the official messaging
>> from us was that they *should*.
>>
>>
> Distros started packaging it separately for some time now.
> Before that, as you point out, it was packaged inside QtCreator.
>
> Debian: https://packages.debian.org/sid/qbs
> Fedora: https://apps.fedoraproject.org/packages/qbs
> Arch Linux: https://www.archlinux.org/packages/extra/x86_64/qbs/
> OpenSuSE: https://software.opensuse.org/package/qbs?search_term=qbs
>
> --
> https://liri.io
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
Edward Welbourne
2018-10-30 18:30:41 UTC
Permalink
On Tue, Oct 30, 2018 at 8:32 PM Pier Luigi Fiorini wrote:
>> From my point of view qbs is doomed as long as qmake's alive.

NIkolai Marchenko (30 October 2018 18:38) replied:
> I would much rather this abomination died instead.

You are not alone. Unfortunately, the project has depended on it for
several years, with the result that we have a support commitment that we
can't simply abandon, much as we (especially those involved in
supporting it) would like to. We have to make a graceful transition to
something else first. The questions then are: what ? and: how soon can
we get to the point where we can put qmake's death on our road-maps ?

> I've switched to qbs when I got way too annoyed by how qmake does
> things and I've never been happier.

It's clear that QBS has great potential. Unfortunately, the corporation
that initially supported its development does not see a way to monetise
it, so is no longer willing to fund its development. It is available as
open source code that others can develop and maintain, but it's only
going to make it if others are willing to do most of the work.

In some sense, the history of mixed signals - TQtC continued development
but did little marketing and neglected important things like
documentation - is a symptom of it being an experiment. Until
management had a full understanding of where this lead, they let
development explore the possibility that a better build system is worth
investing in. Eventually they saw enough to make their decision and
decided to bail. Some of us may not be persuaded that decision was for
the best; but I'm not used to writing business plans, much less
evaluating their viability, so I'm not going to try to tell them that
their decision harms the interests of their share-holders, which is the
only kind of argument I can expect the officers of a publicly-traded
corporation to care about.

Meanwhile, the Qt project gets to chose its build system. If we have a
groundswell of support from outside TQtC that takes over development of
QBS and makes it capable of serving as that build system, I think quite
a lot of us shall be very happy to see it. Otherwise, CMake is the only
candidate with a road-map to deliver tolerably soon, so there we go.
Painful as its syntax is (I've begun reviewing the work for it), it's
there, someone else is supporting it, and the expected time to the final
demise of qmake does look shorter than our other options. Prove that
wrong by volunteering to work on QBS, or come to terms with the
non-ideal path we've landed on,

Eddy.
Matthew Woehlke
2018-10-30 18:47:43 UTC
Permalink
On 30/10/2018 14.30, Edward Welbourne wrote:
> Painful as [CMake's] syntax is (I've begun reviewing the work for it), it's
> there, someone else is supporting it, and the expected time to the final
> demise of qmake does look shorter than our other options.

FWIW, I don't think anyone is praising CMake's syntax. The problem is
finding a *viable* (and that includes *backwards-compatible*) plan to do
something about it.

If anyone can figure that out, I suspect CMake would be, ah, "highly
receptive" :-).

(I happen to think CMake is *overly* vilified, but I'm not going to
claim it's free of warts, either.)

--
Matthew
Oswald Buddenhagen
2018-10-30 19:21:37 UTC
Permalink
On Tue, Oct 30, 2018 at 02:47:43PM -0400, Matthew Woehlke wrote:
> On 30/10/2018 14.30, Edward Welbourne wrote:
> > Painful as [CMake's] syntax is (I've begun reviewing the work for
> > it), it's there, someone else is supporting it, and the expected
> > time to the final demise of qmake does look shorter than our other
> > options.
>
> FWIW, I don't think anyone is praising CMake's syntax. The problem is
> finding a *viable* (and that includes *backwards-compatible*) plan to
> do something about it.
>
> If anyone can figure that out, I suspect CMake would be, ah, "highly
> receptive" :-).
>
as i already said to bill (@kitware) in person at the desktop summit in
2011, there is absolutely nothing they can do to make cmake sane without
it ceasing to be cmake (and thus losing its ecosystem advantage). now, 7
years later, i can't help but observe that the evidence supports my
assertion: while there have been various incremental improvemments (i'll
happily admit that a reasonably simple "leaf" project file doesn't look
outright atrocious any more), the horrors one faces beyond the basic
stuff just aren't going away.

and to be clear, it isn't *just* the syntax (though the fact that there
is literally just one syntactical top-level construct - the "function
call" with a free-form list of arguments - to express a touring-complete
language *really* doesn't help), but also the higher-level project
structure and how the language interacts with the backend.
Thiago Macieira
2018-10-30 19:01:59 UTC
Permalink
On Tuesday, 30 October 2018 09:52:18 PDT Oswald Buddenhagen wrote:
> On Tue, Oct 30, 2018 at 09:10:27AM -0700, Thiago Macieira wrote:
> > Is it packaged in a Linux distribution? My requirements also included
> > continuously packaged for 2 years in at least 3 Linux distributions,
> > at the time of the Qt switch to the particular buildsystem.
>
> it's been packaged for much longer and by more distros already, because
> it's part of qt creator for quite a while. i don't know whether all of
> them ship it as separate packages already, but the official messaging
> from us was that they *should*.

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.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Oswald Buddenhagen
2018-10-30 19:29:46 UTC
Permalink
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.
Thiago Macieira
2018-10-30 19:53:48 UTC
Permalink
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
Oswald Buddenhagen
2018-10-30 20:47:00 UTC
Permalink
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*.
Thiago Macieira
2018-10-30 21:07:16 UTC
Permalink
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
Jean-Michaël Celerier
2018-10-30 21:14:27 UTC
Permalink
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 <***@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
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
Иван Комиссаров
2018-10-30 21:25:10 UTC
Permalink
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 <***@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 <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 <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 <http://www.jcelerier.name/>
>
> On Tue, Oct 30, 2018 at 10:07 PM Thiago Macieira <***@intel.com <mailto:***@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 <http://intel.com/>
> Software Architect - Intel Open Source Technology Center
>
>
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org <mailto:***@qt-project.org>
> http://lists.qt-project.org/mailman/listinfo/development <http://lists.qt-project.org/mailman/listinfo/development>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Jean-Michaël Celerier
2018-10-30 21:36:52 UTC
Permalink
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
>> <***@gmail.com
>> <mailto:***@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 <http://www.jcelerier.name/>
>>
>>
>> On Tue, Oct 30, 2018 at 10:07 PM Thiago Macieira
>> <***@intel.com <mailto:***@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 <http://intel.com/>
>>   Software Architect - Intel Open Source Technology Center
>>
>>
>>
>> _______________________________________________
>> Development mailing list
>> ***@qt-project.org <mailto:***@qt-project.org>
>> http://lists.qt-project.org/mailman/listinfo/development
>>
>> _______________________________________________
>> Development mailing list
>> ***@qt-project.org <mailto:***@qt-project.org>
>> http://lists.qt-project.org/mailman/listinfo/development
>
NIkolai Marchenko
2018-10-30 21:44:55 UTC
Permalink
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 <
***@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 <
> ***@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 <
> ***@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
>> ***@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
NIkolai Marchenko
2018-10-30 21:54:07 UTC
Permalink
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.
NIkolai Marchenko
2018-10-30 21:15:46 UTC
Permalink
> 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 <***@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
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
Thiago Macieira
2018-10-30 21:32:28 UTC
Permalink
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
r***@centrum.cz
2018-10-30 05:29:39 UTC
Permalink
Honestly I feel very disappointed as well with this decision. I feel similarly to others, Qbs is now being phased out so fast (half a year of development, another half a year of maintanance after that it seems). So better get to porting stuff to CMake right away. Having experience with CMake this is gonna be very ugly... 
 
What I do not understand is why the decision was qmake + cmake in the first place. Why not Qbs + CMake? Was not the qmake deemed unmaintainable? It is perfectly understandable to tap into wide CMake user base but why ditching Qbs and not qmake? I wouldn't expect people would mourn qmake...
 
Oh and on the point of CMake. Lets write a simple if statement as per docs:
 
set(var1 "Hello")
set(var2 "Hello")
if(var1 EQUAL var2)
    message("They are equal")
endif()
 
Guess what, it prints NOTHING despite docs explicitly saying this should work. Nothig will help, STREQUAL, MATCHES, dereferencing the arguments, whatever. This will work:
 
string(COMPARE EQUAL ${var1} ${var2} _cmp)
if (_cmp)
    message("They are equal")
endif()
 
Yeah, fortunately there is a wide knowledge how to work around this kind of stuff. There are MANY other things like that that will make you cry when writing even simple things in CMake's "language". Not to mention CMake is not a build system, Qbs is.
 
Anyway, what's done is done I guess. 
Michael
Christian Gagneraud
2018-10-30 07:13:30 UTC
Permalink
Warning: Free sarcasm, i'm not serious (well, maybe a little bit...)

On Tue, 30 Oct 2018 at 18:29, <***@centrum.cz> wrote:
>
> Honestly I feel very disappointed as well with this decision. I feel similarly to others, Qbs is now being phased out so fast (half a year of development, another half a year of maintanance after that it seems). So better get to porting stuff to CMake right away. Having experience with CMake this is gonna be very ugly...

Come on, the CMake project will quickly implement all the Qt project
requirements.
And Qt Creator is about to have full blown support for it.

> What I do not understand is why the decision was qmake + cmake in the first place. Why not Qbs + CMake? Was not the qmake deemed unmaintainable? It is perfectly understandable to tap into wide CMake user base but why ditching Qbs and not qmake? I wouldn't expect people would mourn qmake...

2 unmaintainable systems are better than one.

> Oh and on the point of CMake. Lets write a simple if statement as per docs:
> set(var1 "Hello")
> set(var2 "Hello")
> if(var1 EQUAL var2)
> message("They are equal")
> endif()
>
> Guess what, it prints NOTHING despite docs explicitly saying this should work. Nothing will help, STREQUAL, MATCHES, dereferencing the arguments, whatever. This will work:
>
> string(COMPARE EQUAL ${var1} ${var2} _cmp)
> if (_cmp)
> message("They are equal")
> endif()

Looks cool! :P Big improvement over qmake! Writing
Android/IOS/tvOS/embedded Linux/WinRT/whatever is about to get to the
next level, can't wait!

> Yeah, fortunately there is a wide knowledge how to work around this kind of stuff. There are MANY other things like that that will make you cry when writing even simple things in CMake's "language". Not to mention CMake is not a build system, Qbs is.

Don't underestimate it, CMake is GNU m4 but better, like SVN was CVS but better.
Honestly, i never switched to git, I don't need a Ferrari to go fast,
you should see me on my bicycle. It even has a dynamo for the lights.

Come on, haven't you see the new build instructions
cmake -g Ninja
cmake --build . --target install --config release

Makes sense to me. Clear as mud! :)
--build and --target are not to be confused with GNU autotools
build/host/target, but the reader would have spotted that straight
away.
No need to explain '-g Ninja' (Capital N please), it makes sense to
first tell your build system, what build system it needs to use.
Ah yeah, BTW: "sudo cmake --build . --target install --config release".
Just to make sure that your build tree will be own by root b/c CMake
needs to go through the whole build phase before it dares evaluating
the install phase...
With CMake, you should drop your user account and log into X11R6 as
root, like the good old time, it works better with auto login tho.
For extra spice, try systemd's DHCP client.

Chris
Christian Ehrlicher
2018-10-30 08:04:26 UTC
Permalink
Am 30.10.2018 um 06:29 schrieb ***@centrum.cz:
>
> set(var1 "Hello")
>
> set(var2 "Hello")
>
> if(var1 EQUAL var2)
>
>     message("They are equal")
>
> endif()
>
> Guess what, it prints NOTHING despite docs explicitly saying this
> should work. Nothig will help, STREQUAL, MATCHES, dereferencing the
> arguments, whatever.
>
You read the docs wrong:
EQUAL: True if the given string or variable’s value is a valid number
and equal to that on the right.
Neither var1 nor var2 is a valid numbers.

You want
if (var1 STREQUAL var2) and this works as expected (and documented).

//
Christian
Olivier Goffart
2018-10-30 08:59:28 UTC
Permalink
On 10/30/18 6:29 AM, ***@centrum.cz wrote:
> Honestly I feel very disappointed as well with this decision. I feel similarly
> to others, Qbs is now being phased out so fast (half a year of development,
> another half a year of maintanance after that it seems). So better get to
> porting stuff to CMake right away. Having experience with CMake this is gonna
> be very ugly...
>
> What I do not understand is why the decision was qmake + cmake in the first
> place. Why not Qbs + CMake? Was not the qmake deemed unmaintainable? It is
> perfectly understandable to tap into wide CMake user base but why ditching Qbs
> and not qmake? I wouldn't expect people would mourn qmake...

This is not about "qmake + cmake" vs. anything.

Qbs did not disappear from one day to the other.
What Lars said, if I read the email properly, is that the Qt Company does not
see a business value in developing it further.
But the project is open source and the code is there and anyone is free to take
over if they are interested in it.

It's exactly the same for qmake, which was already in just maintenance mode,
and hasn't gotten new feature for a long time and will not get any. Just
continue to work as is.

And Qbs does not have to build Qt for you to use it.

> Oh and on the point of CMake. Lets write a simple if statement as per docs:
>
> set(var1 "Hello")
> set(var2 "Hello")
> if(var1 EQUAL var2)
>     message("They are equal")
> endif()
>
> Guess what, it prints NOTHING despite docs explicitly saying this should work.
> Nothig will help, STREQUAL, MATCHES, dereferencing the arguments, whatever.

Well don't use C++ then.

char var1[] = "Hello";
char var2[] = "Hello";
if (var1 == var2)
puts("They are equal");

Guess what, it prints NOTHING. My point is that you should not trash the whole
language just because of a few tricks. Every languages (including JS used by
Qbs) has its small drawback. And there are more documentation and example of
script using cmake out there than both qmake and qbs together.


Nobody is forcing you to use cmake if you don't like it. (Unless you want to
contribute to Qt.) There are plenty of other build system out there that can be
used to build your C++ application using the Qt library.

--
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org
Pier Luigi Fiorini
2018-10-30 10:06:21 UTC
Permalink
Il giorno mar 30 ott 2018 alle ore 09:59 Olivier Goffart <***@woboq.com>
ha scritto:

> On 10/30/18 6:29 AM, ***@centrum.cz wrote:
> > Honestly I feel very disappointed as well with this decision. I feel
> similarly
> > to others, Qbs is now being phased out so fast (half a year of
> development,
> > another half a year of maintanance after that it seems). So better get
> to
> > porting stuff to CMake right away. Having experience with CMake this is
> gonna
> > be very ugly...
> >
> > What I do not understand is why the decision was qmake + cmake in the
> first
> > place. Why not Qbs + CMake? Was not the qmake deemed unmaintainable? It
> is
> > perfectly understandable to tap into wide CMake user base but why
> ditching Qbs
> > and not qmake? I wouldn't expect people would mourn qmake...
>
> This is not about "qmake + cmake" vs. anything.
>
> Qbs did not disappear from one day to the other.
> What Lars said, if I read the email properly, is that the Qt Company does
> not
> see a business value in developing it further.
> But the project is open source and the code is there and anyone is free to
> take
> over if they are interested in it.
>

We all know that without company support, the project will stagnate.


> And Qbs does not have to build Qt for you to use it.
>

No but it would have been a great indicator of confidence on the project
and help its adoption because it would have been much more noticeable than
QtCreator (not all Qt users and developers build QtCreator but a lot of
them do build Qt).
The main problem here is not that Qt will use CMake, the problem is that
Qbs will no longer be maintained.
Given that qmake is not suitable for large projects, Qbs will not be
developed anymore we can expect only CMake support on QtCreator to improve,
therefore a lot of us will need to migrate to CMake.

--
https://liri.io
NIkolai Marchenko
2018-10-30 10:17:25 UTC
Permalink
I would like to point out that until very, and I mean *very* recently QBS'
did not even have a bunch of tutorial pages, There was a (poorly
documented) reference and that was it.
If someone wanted to learn QBS and there was no one in their company
already familiar with it, it was one very basic qmake porting tutorial and
then the only source ppl had was asking on IRC.
Like... what did you expect when all the time was spent developing it but
largely ignoring documentaton that would let ppl actually use it with any
kind of success?


On Tue, Oct 30, 2018 at 1:07 PM Pier Luigi Fiorini <
***@gmail.com> wrote:

> Il giorno mar 30 ott 2018 alle ore 09:59 Olivier Goffart <
> ***@woboq.com> ha scritto:
>
>> On 10/30/18 6:29 AM, ***@centrum.cz wrote:
>> > Honestly I feel very disappointed as well with this decision. I feel
>> similarly
>> > to others, Qbs is now being phased out so fast (half a year of
>> development,
>> > another half a year of maintanance after that it seems). So better get
>> to
>> > porting stuff to CMake right away. Having experience with CMake this is
>> gonna
>> > be very ugly...
>> >
>> > What I do not understand is why the decision was qmake + cmake in the
>> first
>> > place. Why not Qbs + CMake? Was not the qmake deemed unmaintainable? It
>> is
>> > perfectly understandable to tap into wide CMake user base but why
>> ditching Qbs
>> > and not qmake? I wouldn't expect people would mourn qmake...
>>
>> This is not about "qmake + cmake" vs. anything.
>>
>> Qbs did not disappear from one day to the other.
>> What Lars said, if I read the email properly, is that the Qt Company does
>> not
>> see a business value in developing it further.
>> But the project is open source and the code is there and anyone is free
>> to take
>> over if they are interested in it.
>>
>
> We all know that without company support, the project will stagnate.
>
>
>> And Qbs does not have to build Qt for you to use it.
>>
>
> No but it would have been a great indicator of confidence on the project
> and help its adoption because it would have been much more noticeable than
> QtCreator (not all Qt users and developers build QtCreator but a lot of
> them do build Qt).
> The main problem here is not that Qt will use CMake, the problem is that
> Qbs will no longer be maintained.
> Given that qmake is not suitable for large projects, Qbs will not be
> developed anymore we can expect only CMake support on QtCreator to improve,
> therefore a lot of us will need to migrate to CMake.
>
> --
> https://liri.io
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
Uwe Rathmann
2018-10-30 10:18:48 UTC
Permalink
On Tue, 30 Oct 2018 09:59:28 +0100, Olivier Goffart wrote:

> What Lars said, if I read the email properly, is that the Qt Company
> does not see a business value in developing it further.

Yes and this is relevant if it is relevant for the maintainers of Qbs. Do
we have a statement from them so far ?

> But the project is open source and the code is there and anyone is free
> to take over if they are interested in it.

In case a maintainer decides to step down the normal process would be to
find a new one. Only if this is not possible further steps have to be
taken.

Using Qbs for building Qt has been discussed here and lead to a solid
decision against it. Obviously then the Qt company decided not to work on
this code anymore - so far so good.

But deprecating Qbs as a tool for building user projects is absolutely
not covered by this discussion and if there was a more related one I seem
to have missed it.

This all has a lot to do with the question if the Qt Company sees itself
as being a member or the owner of the Qt project. If we really want to be
a community project, then the process of inventing and deprecating
modules has to become more independent.

Uwe
NIkolai Marchenko
2018-10-30 10:25:54 UTC
Permalink
> Yes and this is relevant if it is relevant for the maintainers of Qbs. Do
we have a statement from them so far ?

We have a confirmation from Lars that QtCreator is dropping qbs support in
a year.
That basically reads "qbs dead as there will be no IDE supporting it left".

On Tue, Oct 30, 2018 at 1:21 PM Uwe Rathmann <***@tigertal.de>
wrote:

> On Tue, 30 Oct 2018 09:59:28 +0100, Olivier Goffart wrote:
>
> > What Lars said, if I read the email properly, is that the Qt Company
> > does not see a business value in developing it further.
>
> Yes and this is relevant if it is relevant for the maintainers of Qbs. Do
> we have a statement from them so far ?
>
> > But the project is open source and the code is there and anyone is free
> > to take over if they are interested in it.
>
> In case a maintainer decides to step down the normal process would be to
> find a new one. Only if this is not possible further steps have to be
> taken.
>
> Using Qbs for building Qt has been discussed here and lead to a solid
> decision against it. Obviously then the Qt company decided not to work on
> this code anymore - so far so good.
>
> But deprecating Qbs as a tool for building user projects is absolutely
> not covered by this discussion and if there was a more related one I seem
> to have missed it.
>
> This all has a lot to do with the question if the Qt Company sees itself
> as being a member or the owner of the Qt project. If we really want to be
> a community project, then the process of inventing and deprecating
> modules has to become more independent.
>
> Uwe
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
Иван Комиссаров
2018-10-30 10:42:12 UTC
Permalink
I guess, VS still will support QBS in case VS generator is working.
Unfortunately, Xcode generator doesn't, I checked recently.

é×ÁÎ ëÏÍÉÓÓÁÒÏ×

> 30 ÏËÔ. 2018 Ç., × 11:25, NIkolai Marchenko <***@gmail.com> ÎÁÐÉÓÁÌ(Á):
>
> > Yes and this is relevant if it is relevant for the maintainers of Qbs. Do
> we have a statement from them so far ?
>
> We have a confirmation from Lars that QtCreator is dropping qbs support in a year.
> That basically reads "qbs dead as there will be no IDE supporting it left".
>
>> On Tue, Oct 30, 2018 at 1:21 PM Uwe Rathmann <***@tigertal.de> wrote:
>> On Tue, 30 Oct 2018 09:59:28 +0100, Olivier Goffart wrote:
>>
>> > What Lars said, if I read the email properly, is that the Qt Company
>> > does not see a business value in developing it further.
>>
>> Yes and this is relevant if it is relevant for the maintainers of Qbs. Do
>> we have a statement from them so far ?
>>
>> > But the project is open source and the code is there and anyone is free
>> > to take over if they are interested in it.
>>
>> In case a maintainer decides to step down the normal process would be to
>> find a new one. Only if this is not possible further steps have to be
>> taken.
>>
>> Using Qbs for building Qt has been discussed here and lead to a solid
>> decision against it. Obviously then the Qt company decided not to work on
>> this code anymore - so far so good.
>>
>> But deprecating Qbs as a tool for building user projects is absolutely
>> not covered by this discussion and if there was a more related one I seem
>> to have missed it.
>>
>> This all has a lot to do with the question if the Qt Company sees itself
>> as being a member or the owner of the Qt project. If we really want to be
>> a community project, then the process of inventing and deprecating
>> modules has to become more independent.
>>
>> Uwe
>>
>> _______________________________________________
>> Development mailing list
>> ***@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Lars Knoll
2018-10-30 10:50:31 UTC
Permalink
On 30 Oct 2018, at 06:25, NIkolai Marchenko <***@gmail.com<mailto:***@gmail.com>> wrote:

> Yes and this is relevant if it is relevant for the maintainers of Qbs. Do
we have a statement from them so far ?

We have a confirmation from Lars that QtCreator is dropping qbs support in a year.
That basically reads "qbs dead as there will be no IDE supporting it left”.

No, you have a confirmation that we’ll keep it there for at least another year. If we have a proper maintainer for the Qbs integration, I do not see a reason why it couldn’t stay in creator for longer.

Cheers,
Lars


On Tue, Oct 30, 2018 at 1:21 PM Uwe Rathmann <***@tigertal.de<mailto:***@tigertal.de>> wrote:
On Tue, 30 Oct 2018 09:59:28 +0100, Olivier Goffart wrote:

> What Lars said, if I read the email properly, is that the Qt Company
> does not see a business value in developing it further.

Yes and this is relevant if it is relevant for the maintainers of Qbs. Do
we have a statement from them so far ?

> But the project is open source and the code is there and anyone is free
> to take over if they are interested in it.

In case a maintainer decides to step down the normal process would be to
find a new one. Only if this is not possible further steps have to be
taken.

Using Qbs for building Qt has been discussed here and lead to a solid
decision against it. Obviously then the Qt company decided not to work on
this code anymore - so far so good.

But deprecating Qbs as a tool for building user projects is absolutely
not covered by this discussion and if there was a more related one I seem
to have missed it.

This all has a lot to do with the question if the Qt Company sees itself
as being a member or the owner of the Qt project. If we really want to be
a community project, then the process of inventing and deprecating
modules has to become more independent.

Uwe

_______________________________________________
Development mailing list
***@qt-project.org<mailto:***@qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
***@qt-project.org<mailto:***@qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development
Lars Knoll
2018-10-30 10:47:56 UTC
Permalink
> On 30 Oct 2018, at 06:18, Uwe Rathmann <***@tigertal.de> wrote:
>
> On Tue, 30 Oct 2018 09:59:28 +0100, Olivier Goffart wrote:
>
>> What Lars said, if I read the email properly, is that the Qt Company
>> does not see a business value in developing it further.
>
> Yes and this is relevant if it is relevant for the maintainers of Qbs. Do
> we have a statement from them so far ?
>
>> But the project is open source and the code is there and anyone is free
>> to take over if they are interested in it.
>
> In case a maintainer decides to step down the normal process would be to
> find a new one. Only if this is not possible further steps have to be
> taken.
>
> Using Qbs for building Qt has been discussed here and lead to a solid
> decision against it. Obviously then the Qt company decided not to work on
> this code anymore - so far so good.
>
> But deprecating Qbs as a tool for building user projects is absolutely
> not covered by this discussion and if there was a more related one I seem
> to have missed it.
>
> This all has a lot to do with the question if the Qt Company sees itself
> as being a member or the owner of the Qt project. If we really want to be
> a community project, then the process of inventing and deprecating
> modules has to become more independent.

I’d be happy if Qbs development continues, and there is a place for it on qt-project if people want to continue developing it. But this is a bit a different thing from The Qt Company saying that the company will support this for commercial customers, especially given the fact that Qbs never was part of Qt itself.

Cheers,
Lars
Vlad Stelmahovsky
2018-10-30 07:51:44 UTC
Permalink
feels like you hit the wall at full speed. disappointing :(

On 10/29/18 1:17 PM, Lars Knoll wrote:
> Hi all,
>
> 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.
>
> Thiago wrote a set of relatively strict requirements for such a build tool in his mail in July. While some of the requirements had a bit of a Linux specific background, they have been a good basis.
>
> There have been rather lively discussions around alternatives, but most focused around two possible choices for us: Qbs and cmake.
>
> Qbs is something that has been developed almost exclusively by The Qt Company. As such, TQtC had to also look at it from a business perspective and how it fits into the larger picture of making Qt successful. To make a long story short, while Qbs is pretty cool and interesting technology, it doesn’t really help us expand the Qt ecosystem and usage.
>
> To make Qbs really successful would require a rather large effort and investment in promoting it towards the larger C++ ecosystem as a new build tool. At the same time it has to be an open source product to stand any chance in the market. Together this makes it challenging for TQtC to see how to recover that investment. 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.
>
> As such, we were left with the question on whether we need Qbs as the build system for Qt 6 or whether cmake (as the other alternative) would be up to the task.
>
> Given that background, we’ve done some more research on using both Qbs and cmake to build Qt. Both projects did give us good results but we were actually surprised on how far we got with cmake in a rather limited period of time.
>
> In addition, cmake has the advantage of being very widely used in the C++ ecosystem (amongst many others by KDE), has a very wide support in many IDEs and other tools (e.g. VCPkg, Conan etc.), and there’s a lot of knowledge about the build system available in the ecosystem. Using it with Qt 6 would also mean that we can focus our support on two build systems for our users (qmake and cmake) and we would not have to add a third one to the mix.
>
> Given that we are confident we can build Qt 6 with cmake, I believe that it makes most sense to follow down that route. In case you’re interested, you can have a look at the cmake prototype code for qtbase on Gerrit in the wip/cmake branch. Please also let us know if you’re interested in helping with the effort of porting Qt’s build system over to cmake.
>
> We have been developing Qbs over the last years, and as such are committed to it for some more time. We are planning on another feature release in the first quarter of next year and will support it in Qt Creator for at least another year. Qbs is open source and if someone wants to take over and develop it further let us know as well. I’d also like to use this place to thank Christian and Jörg for all their great work on Qbs (and of course also anybody else who contributed to it).
>
> Cheers,
> Lars
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
r***@centrum.cz
2018-10-30 08:21:02 UTC
Permalink
//Christian Gagneraud wrote:
//
// // set(var1 "Hello")
// // set(var2 "Hello")
// // 
// // if(var1 EQUAL var2)
// //     message("They are equal")
// // endif()
// // 
// // Guess what, it prints NOTHING despite docs explicitly saying this should work. Nothig will help, STREQUAL, MATCHES, dereferencing the arguments, whatever.
// 
// You read the docs wrong:
// EQUAL: True if the given string or variable’s value is a valid number and equal to that on the right.
// Neither var1 nor var2 is a valid numbers.
// 
// You want
// if (var1 STREQUAL var2) and this works as expected (and documented).
// 
// //
// Christian
 
No it does not. Have you tried it? As I mentioned it does not work. And even if you somehow managed to make it work it would break the moment someone would define the variable "Hello" elsewhere in the script. See https://cmake.org/pipermail/cmake/2013-February/053587.html
 
And that is the point. The fact we are discussing the very fundamental programming feature - control flow - that just does not work as expected (or documented) is the main problem with CMake. It is a software made of features botched together. You will be constantly running into these kinds of things because it is CMake "language" is not a standardized programming language (like JS is). Writing complex projects in it is extremely difficult which I have been unfortunate to experience first hand (had to write a few in it). While the business decision might be understandable from the technical standpoint it is an absolute nightmarish prospect. Not to mention it is very slow so working with codebase the size of Qt will be extra difficult. There will likely be effort to improve on that either on CMake side (if they cared) or QtComany side (more likely, because they do care).
 
However I have no problem with CMake becoming the primary build generator replacing qmake. It is widespread etc. My issue is with deprecating Qbs. Having 2 people (likely very motivated now after they spent years developing Qbs) transfered or replaced to CMake support in Qt can hardly mean "Deprecating Qbs allows us to significantly improve CMake support.". Sounds more like standard PR BS to me, sorry.
 
And saying Qbs got a chance when it was literally never promoted anywhere, not even in Qt project itself is riduclous. And coming from Thiago who even claimed before he never actually used it.
Christian Ehrlicher
2018-10-30 08:42:24 UTC
Permalink
Am 30.10.2018 um 09:21 schrieb ***@centrum.cz:
>
> // // set(var1 "Hello")
>
> // // set(var2 "Hello")
>
> // //
>
> // // if(var1 EQUAL var2)
>
> // //  message("They are equal")
>
> // // endif()
>
Using STREQUAL works here for me with cmake 3.12 on linux so if it does
not work for you please file a bug report in the cmake bugtracker.

set(var1 "Hello")
set(var2 "Hello")
set(var3 "Hello2")
if(var1 STREQUAL var2)
    message("They are equal")
endif()
if(NOT var1 STREQUAL var3)
    message("They are *NOT* equal")
endif()

Christian
NIkolai Marchenko
2018-10-30 08:45:15 UTC
Permalink
I really have to wonder how can they think QBS is a failure when it was
literally never given a chance.

Thiago, Lars : did you _really_ expect QBS to take off without any kind of
proper documentation (has only started appearing in the last year) or
advertisement? Seriously?
I've pointed out this artificial entry barrier for years. It's not that QBS
hasn't taken off, the people who were responsible for it to take off did
not do even minimal effort to make sure it did.

During the course of the last year QBS imporved in leaps in leaps and
bounds and it suddenly comes to a schreeching halt now when it's really the
time to push it to gain momentum....

I think you really need to revisit this topic before deprecating what could
easily outclass CMAKE and the likes.



On Tue, Oct 30, 2018 at 11:21 AM <***@centrum.cz> wrote:

> //Christian Gagneraud wrote:
>
> //
>
> // // set(var1 "Hello")
>
> // // set(var2 "Hello")
>
> // //
>
> // // if(var1 EQUAL var2)
>
> // // message("They are equal")
>
> // // endif()
>
> // //
>
> // // Guess what, it prints NOTHING despite docs explicitly saying this
> should work. Nothig will help, STREQUAL, MATCHES, dereferencing the
> arguments, whatever.
>
> //
>
> // You read the docs wrong:
>
> // EQUAL: True if the given string or variable’s value is a valid number
> and equal to that on the right.
>
> // Neither var1 nor var2 is a valid numbers.
>
> //
>
> // You want
>
> // if (var1 STREQUAL var2) and this works as expected (and documented).
>
> //
>
> // //
>
> // Christian
>
>
>
> No it does not. Have you tried it? As I mentioned it does not work. And
> even if you somehow managed to make it work it would break the moment
> someone would define the variable "Hello" elsewhere in the script. See
> https://cmake.org/pipermail/cmake/2013-February/053587.html
>
>
>
> And that is the point. The fact we are discussing the very fundamental
> programming feature - control flow - that just does not work as expected
> (or documented) is the main problem with CMake. It is a software made of
> features botched together. You will be constantly running into these kinds
> of things because it is CMake "language" is not a standardized programming
> language (like JS is). Writing complex projects in it is extremely
> difficult which I have been unfortunate to experience first hand (had to
> write a few in it). While the business decision might be understandable
> from the technical standpoint it is an absolute nightmarish prospect. Not
> to mention it is very slow so working with codebase the size of Qt will be
> extra difficult. There will likely be effort to improve on that either on
> CMake side (if they cared) or QtComany side (more likely, because they do
> care).
>
>
>
> However I have no problem with CMake becoming the primary build generator
> replacing qmake. It is widespread etc. My issue is with deprecating Qbs.
> Having 2 people (likely very motivated now after they spent years
> developing Qbs) transfered or replaced to CMake support in Qt can hardly
> mean "Deprecating Qbs allows us to significantly improve CMake support.".
> Sounds more like standard PR BS to me, sorry.
>
>
>
> And saying Qbs got a chance when it was literally never promoted anywhere,
> not even in Qt project itself is riduclous. And coming from Thiago who even
> claimed before he never actually used it.
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
NIkolai Marchenko
2018-10-30 08:50:58 UTC
Permalink
Main question is: why you even developing it, when you've never properly
advertised/documented it? Just as an internal experiment?
"Lets' make this thing and make sure almost no one knows of it or can find
enough guidance to use it and then call it deprecated."

Like... this makes no sense whatsoever.

Part of it is me being annoyed at the loss of my primary build system ofc,
but mostly I am generally baffled.

On Tue, Oct 30, 2018 at 11:45 AM NIkolai Marchenko <***@gmail.com>
wrote:

> I really have to wonder how can they think QBS is a failure when it was
> literally never given a chance.
>
> Thiago, Lars : did you _really_ expect QBS to take off without any kind of
> proper documentation (has only started appearing in the last year) or
> advertisement? Seriously?
> I've pointed out this artificial entry barrier for years. It's not that
> QBS hasn't taken off, the people who were responsible for it to take off
> did not do even minimal effort to make sure it did.
>
> During the course of the last year QBS imporved in leaps in leaps and
> bounds and it suddenly comes to a schreeching halt now when it's really the
> time to push it to gain momentum....
>
> I think you really need to revisit this topic before deprecating what
> could easily outclass CMAKE and the likes.
>
>
>
> On Tue, Oct 30, 2018 at 11:21 AM <***@centrum.cz> wrote:
>
>> //Christian Gagneraud wrote:
>>
>> //
>>
>> // // set(var1 "Hello")
>>
>> // // set(var2 "Hello")
>>
>> // //
>>
>> // // if(var1 EQUAL var2)
>>
>> // // message("They are equal")
>>
>> // // endif()
>>
>> // //
>>
>> // // Guess what, it prints NOTHING despite docs explicitly saying this
>> should work. Nothig will help, STREQUAL, MATCHES, dereferencing the
>> arguments, whatever.
>>
>> //
>>
>> // You read the docs wrong:
>>
>> // EQUAL: True if the given string or variable’s value is a valid number
>> and equal to that on the right.
>>
>> // Neither var1 nor var2 is a valid numbers.
>>
>> //
>>
>> // You want
>>
>> // if (var1 STREQUAL var2) and this works as expected (and documented).
>>
>> //
>>
>> // //
>>
>> // Christian
>>
>>
>>
>> No it does not. Have you tried it? As I mentioned it does not work. And
>> even if you somehow managed to make it work it would break the moment
>> someone would define the variable "Hello" elsewhere in the script. See
>> https://cmake.org/pipermail/cmake/2013-February/053587.html
>>
>>
>>
>> And that is the point. The fact we are discussing the very fundamental
>> programming feature - control flow - that just does not work as expected
>> (or documented) is the main problem with CMake. It is a software made of
>> features botched together. You will be constantly running into these kinds
>> of things because it is CMake "language" is not a standardized programming
>> language (like JS is). Writing complex projects in it is extremely
>> difficult which I have been unfortunate to experience first hand (had to
>> write a few in it). While the business decision might be understandable
>> from the technical standpoint it is an absolute nightmarish prospect. Not
>> to mention it is very slow so working with codebase the size of Qt will be
>> extra difficult. There will likely be effort to improve on that either on
>> CMake side (if they cared) or QtComany side (more likely, because they do
>> care).
>>
>>
>>
>> However I have no problem with CMake becoming the primary build generator
>> replacing qmake. It is widespread etc. My issue is with deprecating Qbs.
>> Having 2 people (likely very motivated now after they spent years
>> developing Qbs) transfered or replaced to CMake support in Qt can hardly
>> mean "Deprecating Qbs allows us to significantly improve CMake support.".
>> Sounds more like standard PR BS to me, sorry.
>>
>>
>>
>> And saying Qbs got a chance when it was literally never promoted
>> anywhere, not even in Qt project itself is riduclous. And coming from
>> Thiago who even claimed before he never actually used it.
>> _______________________________________________
>> Development mailing list
>> ***@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>>
>
NIkolai Marchenko
2018-10-30 08:55:07 UTC
Permalink
And if you want large projects using it, shouldn't you have invested time
and people actually helping those large projects rewrite their build system
to QBS and show them just how good it is?
Any large project consists of a lot of experienced developers and every
experienced developer knows that::"If i works, don't touch it".

Qt needed to invest time and resources to show at least a few projects the
real benefit of qbs instead of hoping someone randomly would decide to
rewrite what amounts of hundreds of ours in an extremely poorly documented
system.

On Tue, Oct 30, 2018 at 11:50 AM NIkolai Marchenko <***@gmail.com>
wrote:

> Main question is: why you even developing it, when you've never properly
> advertised/documented it? Just as an internal experiment?
> "Lets' make this thing and make sure almost no one knows of it or can find
> enough guidance to use it and then call it deprecated."
>
> Like... this makes no sense whatsoever.
>
> Part of it is me being annoyed at the loss of my primary build system ofc,
> but mostly I am generally baffled.
>
> On Tue, Oct 30, 2018 at 11:45 AM NIkolai Marchenko <
> ***@gmail.com> wrote:
>
>> I really have to wonder how can they think QBS is a failure when it was
>> literally never given a chance.
>>
>> Thiago, Lars : did you _really_ expect QBS to take off without any kind
>> of proper documentation (has only started appearing in the last year) or
>> advertisement? Seriously?
>> I've pointed out this artificial entry barrier for years. It's not that
>> QBS hasn't taken off, the people who were responsible for it to take off
>> did not do even minimal effort to make sure it did.
>>
>> During the course of the last year QBS imporved in leaps in leaps and
>> bounds and it suddenly comes to a schreeching halt now when it's really the
>> time to push it to gain momentum....
>>
>> I think you really need to revisit this topic before deprecating what
>> could easily outclass CMAKE and the likes.
>>
>>
>>
>> On Tue, Oct 30, 2018 at 11:21 AM <***@centrum.cz> wrote:
>>
>>> //Christian Gagneraud wrote:
>>>
>>> //
>>>
>>> // // set(var1 "Hello")
>>>
>>> // // set(var2 "Hello")
>>>
>>> // //
>>>
>>> // // if(var1 EQUAL var2)
>>>
>>> // // message("They are equal")
>>>
>>> // // endif()
>>>
>>> // //
>>>
>>> // // Guess what, it prints NOTHING despite docs explicitly saying this
>>> should work. Nothig will help, STREQUAL, MATCHES, dereferencing the
>>> arguments, whatever.
>>>
>>> //
>>>
>>> // You read the docs wrong:
>>>
>>> // EQUAL: True if the given string or variable’s value is a valid number
>>> and equal to that on the right.
>>>
>>> // Neither var1 nor var2 is a valid numbers.
>>>
>>> //
>>>
>>> // You want
>>>
>>> // if (var1 STREQUAL var2) and this works as expected (and documented).
>>>
>>> //
>>>
>>> // //
>>>
>>> // Christian
>>>
>>>
>>>
>>> No it does not. Have you tried it? As I mentioned it does not work. And
>>> even if you somehow managed to make it work it would break the moment
>>> someone would define the variable "Hello" elsewhere in the script. See
>>> https://cmake.org/pipermail/cmake/2013-February/053587.html
>>>
>>>
>>>
>>> And that is the point. The fact we are discussing the very fundamental
>>> programming feature - control flow - that just does not work as expected
>>> (or documented) is the main problem with CMake. It is a software made of
>>> features botched together. You will be constantly running into these kinds
>>> of things because it is CMake "language" is not a standardized programming
>>> language (like JS is). Writing complex projects in it is extremely
>>> difficult which I have been unfortunate to experience first hand (had to
>>> write a few in it). While the business decision might be understandable
>>> from the technical standpoint it is an absolute nightmarish prospect. Not
>>> to mention it is very slow so working with codebase the size of Qt will be
>>> extra difficult. There will likely be effort to improve on that either on
>>> CMake side (if they cared) or QtComany side (more likely, because they do
>>> care).
>>>
>>>
>>>
>>> However I have no problem with CMake becoming the primary build
>>> generator replacing qmake. It is widespread etc. My issue is with
>>> deprecating Qbs. Having 2 people (likely very motivated now after they
>>> spent years developing Qbs) transfered or replaced to CMake support in Qt
>>> can hardly mean "Deprecating Qbs allows us to significantly improve
>>> CMake support.". Sounds more like standard PR BS to me, sorry.
>>>
>>>
>>>
>>> And saying Qbs got a chance when it was literally never promoted
>>> anywhere, not even in Qt project itself is riduclous. And coming from
>>> Thiago who even claimed before he never actually used it.
>>> _______________________________________________
>>> Development mailing list
>>> ***@qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/development
>>>
>>
NIkolai Marchenko
2018-10-30 08:56:31 UTC
Permalink
That's basically how I switched ppl here at my workplace to QBS: I've
rewritten their .pro files for them and they didn't look back.

On Tue, Oct 30, 2018 at 11:55 AM NIkolai Marchenko <***@gmail.com>
wrote:

> And if you want large projects using it, shouldn't you have invested time
> and people actually helping those large projects rewrite their build system
> to QBS and show them just how good it is?
> Any large project consists of a lot of experienced developers and every
> experienced developer knows that::"If i works, don't touch it".
>
> Qt needed to invest time and resources to show at least a few projects the
> real benefit of qbs instead of hoping someone randomly would decide to
> rewrite what amounts of hundreds of ours in an extremely poorly documented
> system.
>
> On Tue, Oct 30, 2018 at 11:50 AM NIkolai Marchenko <
> ***@gmail.com> wrote:
>
>> Main question is: why you even developing it, when you've never properly
>> advertised/documented it? Just as an internal experiment?
>> "Lets' make this thing and make sure almost no one knows of it or can
>> find enough guidance to use it and then call it deprecated."
>>
>> Like... this makes no sense whatsoever.
>>
>> Part of it is me being annoyed at the loss of my primary build system
>> ofc, but mostly I am generally baffled.
>>
>> On Tue, Oct 30, 2018 at 11:45 AM NIkolai Marchenko <
>> ***@gmail.com> wrote:
>>
>>> I really have to wonder how can they think QBS is a failure when it was
>>> literally never given a chance.
>>>
>>> Thiago, Lars : did you _really_ expect QBS to take off without any kind
>>> of proper documentation (has only started appearing in the last year) or
>>> advertisement? Seriously?
>>> I've pointed out this artificial entry barrier for years. It's not that
>>> QBS hasn't taken off, the people who were responsible for it to take off
>>> did not do even minimal effort to make sure it did.
>>>
>>> During the course of the last year QBS imporved in leaps in leaps and
>>> bounds and it suddenly comes to a schreeching halt now when it's really the
>>> time to push it to gain momentum....
>>>
>>> I think you really need to revisit this topic before deprecating what
>>> could easily outclass CMAKE and the likes.
>>>
>>>
>>>
>>> On Tue, Oct 30, 2018 at 11:21 AM <***@centrum.cz> wrote:
>>>
>>>> //Christian Gagneraud wrote:
>>>>
>>>> //
>>>>
>>>> // // set(var1 "Hello")
>>>>
>>>> // // set(var2 "Hello")
>>>>
>>>> // //
>>>>
>>>> // // if(var1 EQUAL var2)
>>>>
>>>> // // message("They are equal")
>>>>
>>>> // // endif()
>>>>
>>>> // //
>>>>
>>>> // // Guess what, it prints NOTHING despite docs explicitly saying this
>>>> should work. Nothig will help, STREQUAL, MATCHES, dereferencing the
>>>> arguments, whatever.
>>>>
>>>> //
>>>>
>>>> // You read the docs wrong:
>>>>
>>>> // EQUAL: True if the given string or variable’s value is a valid
>>>> number and equal to that on the right.
>>>>
>>>> // Neither var1 nor var2 is a valid numbers.
>>>>
>>>> //
>>>>
>>>> // You want
>>>>
>>>> // if (var1 STREQUAL var2) and this works as expected (and documented).
>>>>
>>>> //
>>>>
>>>> // //
>>>>
>>>> // Christian
>>>>
>>>>
>>>>
>>>> No it does not. Have you tried it? As I mentioned it does not work. And
>>>> even if you somehow managed to make it work it would break the moment
>>>> someone would define the variable "Hello" elsewhere in the script. See
>>>> https://cmake.org/pipermail/cmake/2013-February/053587.html
>>>>
>>>>
>>>>
>>>> And that is the point. The fact we are discussing the very fundamental
>>>> programming feature - control flow - that just does not work as expected
>>>> (or documented) is the main problem with CMake. It is a software made of
>>>> features botched together. You will be constantly running into these kinds
>>>> of things because it is CMake "language" is not a standardized programming
>>>> language (like JS is). Writing complex projects in it is extremely
>>>> difficult which I have been unfortunate to experience first hand (had to
>>>> write a few in it). While the business decision might be understandable
>>>> from the technical standpoint it is an absolute nightmarish prospect. Not
>>>> to mention it is very slow so working with codebase the size of Qt will be
>>>> extra difficult. There will likely be effort to improve on that either on
>>>> CMake side (if they cared) or QtComany side (more likely, because they do
>>>> care).
>>>>
>>>>
>>>>
>>>> However I have no problem with CMake becoming the primary build
>>>> generator replacing qmake. It is widespread etc. My issue is with
>>>> deprecating Qbs. Having 2 people (likely very motivated now after they
>>>> spent years developing Qbs) transfered or replaced to CMake support in Qt
>>>> can hardly mean "Deprecating Qbs allows us to significantly improve
>>>> CMake support.". Sounds more like standard PR BS to me, sorry.
>>>>
>>>>
>>>>
>>>> And saying Qbs got a chance when it was literally never promoted
>>>> anywhere, not even in Qt project itself is riduclous. And coming from
>>>> Thiago who even claimed before he never actually used it.
>>>> _______________________________________________
>>>> Development mailing list
>>>> ***@qt-project.org
>>>> http://lists.qt-project.org/mailman/listinfo/development
>>>>
>>>
Иван Комиссаров
2018-10-30 09:00:50 UTC
Permalink
You have one year (or 2 Qt creator releases) to rewrite everything again=) 3, 2, 1, go!

Èâàí Êîìèññàðîâ

> 30 îêò. 2018 ã., â 9:56, NIkolai Marchenko <***@gmail.com> íàïèñàë(à):
>
> That's basically how I switched ppl here at my workplace to QBS: I've rewritten their .pro files for them and they didn't look back.
>
>> On Tue, Oct 30, 2018 at 11:55 AM NIkolai Marchenko <***@gmail.com> wrote:
>> And if you want large projects using it, shouldn't you have invested time and people actually helping those large projects rewrite their build system to QBS and show them just how good it is?
>> Any large project consists of a lot of experienced developers and every experienced developer knows that::"If i works, don't touch it".
>>
>> Qt needed to invest time and resources to show at least a few projects the real benefit of qbs instead of hoping someone randomly would decide to rewrite what amounts of hundreds of ours in an extremely poorly documented system.
>>
>>> On Tue, Oct 30, 2018 at 11:50 AM NIkolai Marchenko <***@gmail.com> wrote:
>>> Main question is: why you even developing it, when you've never properly advertised/documented it? Just as an internal experiment?
>>> "Lets' make this thing and make sure almost no one knows of it or can find enough guidance to use it and then call it deprecated."
>>>
>>> Like... this makes no sense whatsoever.
>>>
>>> Part of it is me being annoyed at the loss of my primary build system ofc, but mostly I am generally baffled.
>>>
>>>> On Tue, Oct 30, 2018 at 11:45 AM NIkolai Marchenko <***@gmail.com> wrote:
>>>> I really have to wonder how can they think QBS is a failure when it was literally never given a chance.
>>>>
>>>> Thiago, Lars : did you _really_ expect QBS to take off without any kind of proper documentation (has only started appearing in the last year) or advertisement? Seriously?
>>>> I've pointed out this artificial entry barrier for years. It's not that QBS hasn't taken off, the people who were responsible for it to take off did not do even minimal effort to make sure it did.
>>>>
>>>> During the course of the last year QBS imporved in leaps in leaps and bounds and it suddenly comes to a schreeching halt now when it's really the time to push it to gain momentum....
>>>>
>>>> I think you really need to revisit this topic before deprecating what could easily outclass CMAKE and the likes.
>>>>
>>>>
>>>>
>>>>> On Tue, Oct 30, 2018 at 11:21 AM <***@centrum.cz> wrote:
>>>>> //Christian Gagneraud wrote:
>>>>> //
>>>>> // // set(var1 "Hello")
>>>>> // // set(var2 "Hello")
>>>>> // //
>>>>> // // if(var1 EQUAL var2)
>>>>> // // message("They are equal")
>>>>> // // endif()
>>>>> // //
>>>>> // // Guess what, it prints NOTHING despite docs explicitly saying this should work. Nothig will help, STREQUAL, MATCHES, dereferencing the arguments, whatever.
>>>>> //
>>>>> // You read the docs wrong:
>>>>> // EQUAL: True if the given string or variable’s value is a valid number and equal to that on the right.
>>>>> // Neither var1 nor var2 is a valid numbers.
>>>>> //
>>>>> // You want
>>>>> // if (var1 STREQUAL var2) and this works as expected (and documented).
>>>>> //
>>>>> // //
>>>>> // Christian
>>>>>
>>>>> No it does not. Have you tried it? As I mentioned it does not work. And even if you somehow managed to make it work it would break the moment someone would define the variable "Hello" elsewhere in the script. See https://cmake.org/pipermail/cmake/2013-February/053587.html
>>>>>
>>>>> And that is the point. The fact we are discussing the very fundamental programming feature - control flow - that just does not work as expected (or documented) is the main problem with CMake. It is a software made of features botched together. You will be constantly running into these kinds of things because it is CMake "language" is not a standardized programming language (like JS is). Writing complex projects in it is extremely difficult which I have been unfortunate to experience first hand (had to write a few in it). While the business decision might be understandable from the technical standpoint it is an absolute nightmarish prospect. Not to mention it is very slow so working with codebase the size of Qt will be extra difficult. There will likely be effort to improve on that either on CMake side (if they cared) or QtComany side (more likely, because they do care).
>>>>>
>>>>> However I have no problem with CMake becoming the primary build generator replacing qmake. It is widespread etc. My issue is with deprecating Qbs. Having 2 people (likely very motivated now after they spent years developing Qbs) transfered or replaced to CMake support in Qt can hardly mean "Deprecating Qbs allows us to significantly improve CMake support.". Sounds more like standard PR BS to me, sorry.
>>>>>
>>>>> And saying Qbs got a chance when it was literally never promoted anywhere, not even in Qt project itself is riduclous. And coming from Thiago who even claimed before he never actually used it.
>>>>> _______________________________________________
>>>>> Development mailing list
>>>>> ***@qt-project.org
>>>>> http://lists.qt-project.org/mailman/listinfo/development
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Matthew Woehlke
2018-10-30 17:18:29 UTC
Permalink
On 30/10/2018 04.21, ***@centrum.cz wrote:
> Christian Gagneraud wrote:
>> On Tue, 30 Oct 2018 at 18:29, <***@centrum.cz> wrote:
>>> set(var1 "Hello")
>>> set(var2 "Hello")
>>>
>>> if(var1 EQUAL var2)
>>>     message("They are equal")
>>> endif()
>>>
>>> Guess what, it prints NOTHING despite docs explicitly saying this
>>> should work. Nothig will help, STREQUAL, MATCHES, dereferencing
>>> the arguments, whatever.>>
>> You want
>> if (var1 STREQUAL var2) and this works as expected (and documented).
>  
> No it does not. Have you tried it?

$ cat test.cmake
set(var1 "Hello")
set(var2 "Hello")
if(var1 STREQUAL var2)
message("They are equal")
endif()
$ cmake -P test.cmake
They are equal

> As I mentioned it does not work. And even if you somehow managed to
> make it work it would break the moment someone would define the
> variable "Hello" elsewhere in the script.
$ cat test2.cmake
set(Hello good bye)
set(var1 "Hello")
set(var2 "Hello")
if(var1 STREQUAL var2)
message("They are equal")
endif()
$ cmake -P test2.cmake
They are equal

As written, the variables will only be expanded once. But, even if you
wrote:

if(${var1} STREQUAL ${var2})

...which will expand to:

if("good;bye" STREQUAL "good;bye")

...they will still be equal. (And I don't see your point, because if you
wrote it like that, you *wanted* it to be able to expand the way it did.)

> The fact we are discussing the very fundamental programming feature -
> control flow - that just does not work as expected (or documented) is
> the main problem with CMake.
That's a strong claim that lacks substantiation.

p.s. Please use '>' to quote like the rest of the world.

--
Matthew
(This should always go without saying when I'm using this e-mail
address, but opinions expressed herein do not necessarily reflect those
of my employer.)
Christian Gagneraud
2018-10-30 09:00:18 UTC
Permalink
On Tue, 30 Oct 2018 at 01:17, Lars Knoll <***@qt.io> wrote:
>
> Hi all,

Hi Lars,

Playing the devil's advocate here.

May I ask: Which democratic/meritocratic process was used to take
this decision?
I do understand that the QtC is the Qbs instigator/maintainer, so
nobody can blame you for pulling the plug off and adjusting resources
allocation.

Who/when/where was the decision of switching to CMake taken?
Any trace record? A vote, a ballot, something? I havent's hear of any
"Qt Project" event/announcement recently.
So far i've seen some broad (but useful) un-authoritative requirements
from Thiago,
followed by a lengthy (endless) discussion, and suddenly your email
that seems to announce the result of the "election".
When did the election happened?

So some claims that build systems are no "The Qt Company" business,
yet you're about to take the road of having to bend a dinosaur (CMake,
that's a personal opinion) to suit your modern requirements.
Are you planning to have Qt employees fix CMake?

Then why spend energy/money to fix something that is broken by design?
(Again, that is a personal opinion, if needed to say)

No conspiracy here, but i have a few more questions (not related, in
no particular order)
- 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)
- Did you drop Qbs due to it's "unsolvable" dependency on deprecated Qt Script?
- Any track record that Qbs was not fit for the job? (Please no "we
can't build Qt with it", as you cannot build Qt with anything but
qmake right now)

Sincerely,
Chris
Christian Gagneraud
2018-10-30 09:26:33 UTC
Permalink
On Tue, 30 Oct 2018 at 22:18, Richard Weickelt <***@weickelt.de> wrote:
>
> Ich schick's doch nicht an die Liste, ist wenig konstruktiv :-/
> > No conspiracy here, but i have a few more questions (not related, in
> > no particular order)
> > - 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)
> > - Did you drop Qbs due to it's "unsolvable" dependency on deprecated Qt Script?
> > - Any track record that Qbs was not fit for the job? (Please no "we
> > can't build Qt with it", as you cannot build Qt with anything but
> > qmake right now)
>
> Do You remember Tino Pyssysalo's ominous survey on the qbs mailing list in
> June? I asked him explicitly for more transparency about the decision-making
> process about the future of Qbs. Apart from a vague promise, I heard nothing
> back.

,https://lists.qt-project.org/mailman/listinfo/qbs gives me:
Secure Connection Failed
An error occurred during a connection to lists.qt-project.org. SSL
received a record that exceeded the maximum permissible length. Error
code: SSL_ERROR_RX_RECORD_TOO_LONG

As reported on qt-interest recently, lists.qt-project.org is serving
plain HTTP over port 443.

Chris
Jean-Michaël Celerier
2018-10-30 09:41:17 UTC
Permalink
Hi all,
I'd like to point you to a mailing list message of Brad King from a few
months ago about alternative languages for CMake :
https://cmake.org/pipermail/cmake-developers/2016-January/027379.html
(damn, two years actually.. time flies)


> In summary, I think work in this direction should first focus on designing
a declarative (or functional) specification format where most of the project
information can be specified. Then a cmake-language command can be written
to load and evaluate a specification file (as a transition). Finally we
could look at replacing the entry-point language with something else. At
that point we could have closures passed as parameters to the evaluation of
the pure spec in order to get custom generate-time logic.

Brad for those who don't know is one of the main (dare I say *the* main)
CMake contributors (https://www.kitware.com/brad-king/).
So, why not just go and propose the declarative QBS syntax as a front-end
for CMake ? This would make the world a better place. The CMake people
*want* a better language, and for these use cases, QML is certainly much
closer to the solution than others.


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


On Tue, Oct 30, 2018 at 10:26 AM Christian Gagneraud <***@gmail.com>
wrote:

> On Tue, 30 Oct 2018 at 22:18, Richard Weickelt <***@weickelt.de>
> wrote:
> >
> > Ich schick's doch nicht an die Liste, ist wenig konstruktiv :-/
> > > No conspiracy here, but i have a few more questions (not related, in
> > > no particular order)
> > > - 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)
> > > - Did you drop Qbs due to it's "unsolvable" dependency on deprecated
> Qt Script?
> > > - Any track record that Qbs was not fit for the job? (Please no "we
> > > can't build Qt with it", as you cannot build Qt with anything but
> > > qmake right now)
> >
> > Do You remember Tino Pyssysalo's ominous survey on the qbs mailing list
> in
> > June? I asked him explicitly for more transparency about the
> decision-making
> > process about the future of Qbs. Apart from a vague promise, I heard
> nothing
> > back.
>
> ,https://lists.qt-project.org/mailman/listinfo/qbs gives me:
> Secure Connection Failed
> An error occurred during a connection to lists.qt-project.org. SSL
> received a record that exceeded the maximum permissible length. Error
> code: SSL_ERROR_RX_RECORD_TOO_LONG
>
> As reported on qt-interest recently, lists.qt-project.org is serving
> plain HTTP over port 443.
>
> Chris
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
Oswald Buddenhagen
2018-10-30 17:17:54 UTC
Permalink
On Tue, Oct 30, 2018 at 10:41:17AM +0100, Jean-Michaël Celerier wrote:
> I'd like to point you to a mailing list message of Brad King from a
> few months ago about alternative languages for CMake [...]
> So, why not just go and propose the declarative QBS syntax as a
> front-end for CMake?
>
or, you know, just adding the remaining missing bits to qbs, which
doesn't have all the historical baggage of cmake? it's much easier to
make qbs generate (and even read) cmake interface files than to
re-architect cmake to make it, well, sane.
Matthew Woehlke
2018-10-30 17:46:49 UTC
Permalink
On 30/10/2018 13.17, Oswald Buddenhagen wrote:
> it's much easier to make qbs generate **and even read** cmake
> interface files than to re-architect cmake to make it, well, sane.
(Emphasis added.)

No, really, it isn't. A CMake interface file is Turing-complete and can
do anything that CMake can do. 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.

I would rather see CMake learn to read and output something more
portable, e.g. CPS¹.

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

--
Matthew
Oswald Buddenhagen
2018-10-30 18:25:03 UTC
Permalink
On Tue, Oct 30, 2018 at 01:46:49PM -0400, Matthew Woehlke wrote:
> On 30/10/2018 13.17, Oswald Buddenhagen wrote:
> > it's much easier to make qbs generate **and even read** cmake
> > interface files than to re-architect cmake to make it, well, sane.
> (Emphasis added.)
>
> No, really, it isn't.
>
it is, despite the below.

> A CMake interface file is Turing-complete and can do anything that
> CMake can do.
>
yes, and when i looked a few days ago into the code cmake
auto-generates, my jaw dropped. this is total insanity.

> In order to actually implement the ability to read CMake interface
> files (without corner cases), you basically have to *be* CMake.
>
in the most extreme case one could actually make a qbs plugin that links
against the relevant cmake code.

> If you assume that you will only have to deal with some subset, you
> will be subject to breakage at any time.
>
yes, but that's not such a big deal, because most projects just use the
auto-exports, and keeping up with changes to that isn't an
extraordinarily challenging task.
and manually covering the remaining 1% of packages that fail isn't a
huge deal, either, esp. once the qbs community grows.
and the whole thing would be only a "bridge technology" anyway. ^^

> 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.
Matthew Woehlke
2018-10-30 21:06:44 UTC
Permalink
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
Oswald Buddenhagen
2018-10-30 21:51:01 UTC
Permalink
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.
Thiago Macieira
2018-10-30 16:22:00 UTC
Permalink
On Tuesday, 30 October 2018 02:26:33 PDT Christian Gagneraud wrote:
> https://lists.qt-project.org/mailman/listinfo/qbs gives me:
> Secure Connection Failed

The lists.qt-project.org HTTPS server is misconfigured (has been for a week or
so) and is replying with non-encrypted HTTP on port 443.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Lars Knoll
2018-10-30 10:42:13 UTC
Permalink
Hi Christian,

> On 30 Oct 2018, at 05:00, Christian Gagneraud <***@gmail.com> wrote:
>
> On Tue, 30 Oct 2018 at 01:17, Lars Knoll <***@qt.io> wrote:
>>
>> Hi all,
>
> Hi Lars,
>
> Playing the devil's advocate here.
>
> May I ask: Which democratic/meritocratic process was used to take
> this decision?
> I do understand that the QtC is the Qbs instigator/maintainer, so
> nobody can blame you for pulling the plug off and adjusting resources
> allocation.
>
> Who/when/where was the decision of switching to CMake taken?
> Any trace record? A vote, a ballot, something? I havent's hear of any
> "Qt Project" event/announcement recently.
> So far i've seen some broad (but useful) un-authoritative requirements
> from Thiago,
> followed by a lengthy (endless) discussion, and suddenly your email
> that seems to announce the result of the "election".
> When did the election happened?
>
> So some claims that build systems are no "The Qt Company" business,
> yet you're about to take the road of having to bend a dinosaur (CMake,
> that's a personal opinion) to suit your modern requirements.
> Are you planning to have Qt employees fix CMake?
>
> 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.

We had consensus amongst the maintainers that we want to move away from qmake, the two options being Qbs and CMake. Using CMake to build Qt is then a mostly pragmatic move. With it we don’t need to maintain the build tool ourselves, and we use a tool that already has wide support for most of what we need. This is then about minimising our work maintaining a system to build Qt itself. And the wip/cmake branch shows that this can be done without having ’to bend a dinosaur’.

>
> No conspiracy here, but i have a few more questions (not related, in
> no particular order)
> - 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.

> - Did you drop Qbs due to it's "unsolvable" dependency on deprecated Qt Script?

Huh? There’s no such thing as an ‘unsolvable’ dependency here. But of course any changes to a product involve work. More for some things, less for others.

> - Any track record that Qbs was not fit for the job? (Please no "we
> can't build Qt with it", as you cannot build Qt with anything but
> qmake right now)

No, of course one could have made it support building Qt. There were some missing items like the configuration system and some other things, all of those could of course have been implemented.

Cheers,
Lars
Christian Gagneraud
2018-10-30 11:23:48 UTC
Permalink
> > On 30 Oct 2018, at 05:00, Christian Gagneraud <***@gmail.com> wrote:
> > - Any track record that Qbs was not fit for the job? (Please no "we
> > can't build Qt with it", as you cannot build Qt with anything but
> > qmake right now)
>
> No, of course one could have made it support building Qt. There were some missing items like the configuration system and some other things, all of those could of course have been implemented.

How CMake will solve the 'configuration' problem. Will CMake allow us
to build for, say, QNX, GreenHill, VxWorks, and the likes? I doubt!
Everyone is bragging about open source (me first), but the Qt market
is medical, automotive and avionics/space industry, isn't it? How will
CMake cope with that?
CMake is not even aware that they are other OS behind WIndows and
Linux Desktop....

Just Sayin'.
Chris
Jean-Michaël Celerier
2018-10-30 11:32:41 UTC
Permalink
> Will CMake allow us to build for, say, QNX, GreenHill, VxWorks, and the
likes?

uhh... yeah? CMake has supported Green Hills for years.

>CMake is not even aware that they are other OS behind WIndows and
Linux Desktop....

sorry, that's FUD. CMake has built-in support for Android, macOS, UWP apps
and works just fine on BSDs and other niche OS such as Haiku (full list
here : https://github.com/Kitware/CMake/tree/master/Modules/Platform).
Hell, it's the build system for at least two existing alternative OSes:
ReactOS (https://github.com/reactos/reactos) and IncludeOS (
https://github.com/hioa-cs/IncludeOS).

iOS is curerntly best supported (imho) through
https://github.com/ruslo/polly which is a set of toolchains not unlike
qmake's mkspecs.

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


On Tue, Oct 30, 2018 at 12:24 PM Christian Gagneraud <***@gmail.com>
wrote:

> > > On 30 Oct 2018, at 05:00, Christian Gagneraud <***@gmail.com>
> wrote:
> > > - Any track record that Qbs was not fit for the job? (Please no "we
> > > can't build Qt with it", as you cannot build Qt with anything but
> > > qmake right now)
> >
> > No, of course one could have made it support building Qt. There were
> some missing items like the configuration system and some other things, all
> of those could of course have been implemented.
>
> How CMake will solve the 'configuration' problem. Will CMake allow us
> to build for, say, QNX, GreenHill, VxWorks, and the likes? I doubt!
> Everyone is bragging about open source (me first), but the Qt market
> is medical, automotive and avionics/space industry, isn't it? How will
> CMake cope with that?
> CMake is not even aware that they are other OS behind WIndows and
> Linux Desktop....
>
> Just Sayin'.
> Chris
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
Иван Комиссаров
2018-10-30 11:35:20 UTC
Permalink
It is aware about Mac OS!
Doesn't help actually, last time I tried to build kde apps on mac, I failed

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

30 окт. 2018 г., в 12:23, Christian Gagneraud <***@gmail.com> написал(а):

>>> On 30 Oct 2018, at 05:00, Christian Gagneraud <***@gmail.com> wrote:
>>> - Any track record that Qbs was not fit for the job? (Please no "we
>>> can't build Qt with it", as you cannot build Qt with anything but
>>> qmake right now)
>>
>> No, of course one could have made it support building Qt. There were some missing items like the configuration system and some other things, all of those could of course have been implemented.
>
> How CMake will solve the 'configuration' problem. Will CMake allow us
> to build for, say, QNX, GreenHill, VxWorks, and the likes? I doubt!
> Everyone is bragging about open source (me first), but the Qt market
> is medical, automotive and avionics/space industry, isn't it? How will
> CMake cope with that?
> CMake is not even aware that they are other OS behind WIndows and
> Linux Desktop....
>
> Just Sayin'.
> Chris
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Cristian Adam
2018-10-30 11:42:35 UTC
Permalink
On Tue, Oct 30, 2018, 12:24 Christian Gagneraud <***@gmail.com> wrote:

> > > On 30 Oct 2018, at 05:00, Christian Gagneraud <***@gmail.com>
> wrote:
> > > - Any track record that Qbs was not fit for the job? (Please no "we
> > > can't build Qt with it", as you cannot build Qt with anything but
> > > qmake right now)
> >
> > No, of course one could have made it support building Qt. There were
> some missing items like the configuration system and some other things, all
> of those could of course have been implemented.
>
> How CMake will solve the 'configuration' problem. Will CMake allow us
> to build for, say, QNX, GreenHill, VxWorks, and the likes? I doubt!
> Everyone is bragging about open source (me first), but the Qt market
> is medical, automotive and avionics/space industry, isn't it? How will
> CMake cope with that?
> CMake is not even aware that they are other OS behind WIndows and
> Linux Desktop....
>

CMake is used in Automotive.

Here is a link to the blog of one of the QNX's Eclipse CDT contributors,
and there you can see how hard it is to write a CMake toolchain file for
QNX: https://cdtdoug.ca/2017/10/06/qnx-cmake-toolchain-file.html

Cheers,
Cristian.

>
Cristian Adam
2018-10-30 14:33:04 UTC
Permalink
On Tue, Oct 30, 2018 at 12:42 PM Cristian Adam <***@gmail.com>
wrote:

> On Tue, Oct 30, 2018, 12:24 Christian Gagneraud <***@gmail.com> wrote:
>
>> > > On 30 Oct 2018, at 05:00, Christian Gagneraud <***@gmail.com>
>> wrote:
>> > > - Any track record that Qbs was not fit for the job? (Please no "we
>> > > can't build Qt with it", as you cannot build Qt with anything but
>> > > qmake right now)
>> >
>> > No, of course one could have made it support building Qt. There were
>> some missing items like the configuration system and some other things, all
>> of those could of course have been implemented.
>>
>> How CMake will solve the 'configuration' problem. Will CMake allow us
>> to build for, say, QNX, GreenHill, VxWorks, and the likes? I doubt!
>> Everyone is bragging about open source (me first), but the Qt market
>> is medical, automotive and avionics/space industry, isn't it? How will
>> CMake cope with that?
>> CMake is not even aware that they are other OS behind WIndows and
>> Linux Desktop....
>>
>
> CMake is used in Automotive.
>
> Here is a link to the blog of one of the QNX's Eclipse CDT contributors,
> and there you can see how hard it is to write a CMake toolchain file for
> QNX: https://cdtdoug.ca/2017/10/06/qnx-cmake-toolchain-file.html
>
> Cheers,
> Cristian.
>

And here is the link with the nightly builds that run on the CMake code
base:
https://open.cdash.org/index.php?project=CMake&date=2018-10-29#!/%23Nightly_Expected

There are quite some platform combinations there. QNX is not there because
of licensing I suppose.

Cheers,
Cristian.
NIkolai Marchenko
2018-10-30 15:33:03 UTC
Permalink
> 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.
QBS might have been that crucial difference going for qt. Much more
important than any IDE echancment.

On Tue, Oct 30, 2018 at 5:33 PM Cristian Adam <***@gmail.com>
wrote:

> On Tue, Oct 30, 2018 at 12:42 PM Cristian Adam <***@gmail.com>
> wrote:
>
>> On Tue, Oct 30, 2018, 12:24 Christian Gagneraud <***@gmail.com> wrote:
>>
>>> > > On 30 Oct 2018, at 05:00, Christian Gagneraud <***@gmail.com>
>>> wrote:
>>> > > - Any track record that Qbs was not fit for the job? (Please no "we
>>> > > can't build Qt with it", as you cannot build Qt with anything but
>>> > > qmake right now)
>>> >
>>> > No, of course one could have made it support building Qt. There were
>>> some missing items like the configuration system and some other things, all
>>> of those could of course have been implemented.
>>>
>>> How CMake will solve the 'configuration' problem. Will CMake allow us
>>> to build for, say, QNX, GreenHill, VxWorks, and the likes? I doubt!
>>> Everyone is bragging about open source (me first), but the Qt market
>>> is medical, automotive and avionics/space industry, isn't it? How will
>>> CMake cope with that?
>>> CMake is not even aware that they are other OS behind WIndows and
>>> Linux Desktop....
>>>
>>
>> CMake is used in Automotive.
>>
>> Here is a link to the blog of one of the QNX's Eclipse CDT contributors,
>> and there you can see how hard it is to write a CMake toolchain file for
>> QNX: https://cdtdoug.ca/2017/10/06/qnx-cmake-toolchain-file.html
>>
>> Cheers,
>> Cristian.
>>
>
> And here is the link with the nightly builds that run on the CMake code
> base:
>
> https://open.cdash.org/index.php?project=CMake&date=2018-10-29#!/%23Nightly_Expected
>
> There are quite some platform combinations there. QNX is not there because
> of licensing I suppose.
>
> Cheers,
> Cristian.
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
Matthew Woehlke
2018-10-30 16:42:26 UTC
Permalink
On 30/10/2018 07.23, Christian Gagneraud wrote:
> CMake is not even aware that they are other OS behind WIndows and
> Linux Desktop....

Have you looked at CMake's dashboards? Maybe you are confusing
"supported platforms" with "platforms for which pre-built binaries are
provided"? Support, much less awareness, is definitely not limited to
Windows and Linux.

> Will CMake allow us to build for, say, QNX, GreenHill, VxWorks, and
> the likes?
Platform support is generally contingent on someone doing the work to
get it working, and someone supplying dashboard builds. The latter
should not be difficult for TQtC. Probably the former will not be
difficult either, since presumably someone had those platforms working
with QMake... Assuming they don't already work.

BTW, that is for *native* support, i.e. running CMake on those
platforms. Cross compiling is generally easier.

--
Matthew
(This should always go without saying when I'm using this e-mail
address, but opinions expressed herein do not necessarily reflect those
of my employer.)
Christian Gagneraud
2018-10-30 21:57:01 UTC
Permalink
Hi Lars,

On Tue, 30 Oct 2018 at 23:42, Lars Knoll <***@qt.io> wrote:
> > On 30 Oct 2018, at 05:00, Christian Gagneraud <***@gmail.com> wrote:
> > On Tue, 30 Oct 2018 at 01:17, Lars Knoll <***@qt.io> 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
Thiago Macieira
2018-10-30 16:16:29 UTC
Permalink
On Tuesday, 30 October 2018 02:00:18 PDT Christian Gagneraud wrote:
> May I ask: Which democratic/meritocratic process was used to take
> this decision?

There are two decisions we're discussing here:

1) Qt Company stopping its support for qbs
2) Qt's switch to a different buildsystem (specifically, CMake)

> I do understand that the QtC is the Qbs instigator/maintainer, so
> nobody can blame you for pulling the plug off and adjusting resources
> allocation.

That's #1. That's the company's choice and does not need community
involvement. The community does not have to agree either and can continue
developing Qbs if it wants to.

> Who/when/where was the decision of switching to CMake taken?

That's #2. That decision HAS NOT been taken.

What you see is Lars saying they've done their due diligence to see if they
were shooting themselves in the foot if the choice was CMake, if they had to
pull the plug on Qbs.

However, de facto we only had two choices: Qbs and CMake. With one out of the
running, that only leaves one, which will likely win by default.

Unless someone steps up and does extra work on something else, making it
viable. I've been hearing great things about Meson and their maintainers did
contact me after the July email asking if we were considering it. I answered:
sure, so long as someone does come along and do the work.

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

He did not. He left months before the decision because he had an offer from a
different company that he wanted to take.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Oswald Buddenhagen
2018-10-30 17:11:20 UTC
Permalink
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. ;)

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

> To fix d) a large part of QBS must be reorganized/rewritten,
>
i see no actual evidence of that.
NIkolai Marchenko
2018-10-30 17:14:29 UTC
Permalink
For anyone interested in QBS survival, let's fill the sheet with QBS
ecosystem.
Maybe if we show TQtC that people are actually using it they will
reconsider.

Post your projects (and ones you know of) here:

https://docs.google.com/spreadsheets/d/1CwXx2F1zuATYY3GGOTkFgDB9jwMPghf6az_RVOnskfk/edit#gid=0

On Tue, Oct 30, 2018 at 8:11 PM Oswald Buddenhagen <***@qt.io>
wrote:

> 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. ;)
>
> > 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.
>
> > To fix d) a large part of QBS must be reorganized/rewritten,
> >
> i see no actual evidence of that.
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
Richard Weickelt
2018-10-30 19:18:57 UTC
Permalink
On 30.10.2018 18:14, NIkolai Marchenko wrote:
> For anyone interested in QBS survival, let's fill the sheet with QBS ecosystem.
> Maybe if we show TQtC that people are actually using it they will reconsider.
>
> Post your projects  (and ones you know of) here:
>
> https://docs.google.com/spreadsheets/d/1CwXx2F1zuATYY3GGOTkFgDB9jwMPghf6az_RVOnskfk/edit#gid=0

FWIW: Typing "filetype:qbs site:github.com" in google gives me 622 results.
Narrowing the search down by "Project filetype:qbs site:github.com" gives me
271 results. I don't know how to filter out duplicates nor forks of Qbs and
QtCreator. I also don't know enough about search engines to see whether the
user base of Qbs is growing or declining.
Richard Weickelt
2018-10-30 09:08:27 UTC
Permalink
> Qbs is something that has been developed almost exclusively by The Qt
> Company. As such, TQtC had to also look at it from a business perspective
> and how it fits into the larger picture of making Qt successful. To make
> a long story short, while Qbs is pretty cool and interesting technology,
> it doesn’t really help us expand the Qt ecosystem and usage.

Qbs has made the development of multi-platform applications with multiple
libraries a breeze for me. Even projects that contain firmware for different
target architectures in addition to a Qt application are no problem at all
with Qbs. Thanks to Qbs, I can focus on code and not on the build system. I
achieve more in less time.

I always thought that Qbs was a great example for using QML.

> To make Qbs really successful would require a rather large effort and
> investment in promoting it towards the larger C++ ecosystem as a new
> build tool. At the same time it has to be an open source product to stand
> any chance in the market. Together this makes it challenging for TQtC to
> see how to recover that investment. 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.

It seems that Qbs never got much traction within the Qt Company either.
Outside the regular blog posts, I don't see any attempt to promote Qbs
anywhere. Correct me if I'm wrong. I may have noticed that Jake Petroules
did his best to get the word out, but I guess that was his private mission
rather than his official role in the Qt Company. What I can't complain about
is the unprecedented dedication and professionalism of Christian, Jörg and
Jake on this project. Also all support questions were answered in lightning
speed.

> As such, we were left with the question on whether we need Qbs as the
> build system for Qt 6 or whether cmake (as the other alternative) would
> be up to the task.
> [..]
> Given that we are confident we can build Qt 6 with cmake, I believe that
> it makes most sense to follow down that route. In case you’re interested,
> you can have a look at the cmake prototype code for qtbase on Gerrit in
> the wip/cmake branch. Please also let us know if you’re interested in
> helping with the effort of porting Qt’s build system over to cmake.
>
> We have been developing Qbs over the last years, and as such are
> committed to it for some more time. We are planning on another feature
> release in the first quarter of next year and will support it in Qt
> Creator for at least another year. Qbs is open source and if someone
> wants to take over and develop it further let us know as well. I’d also
> like to use this place to thank Christian and Jörg for all their great
> work on Qbs (and of course also anybody else who contributed to it).

How can we leverage from the next half year to smoothly turn Qbs into a
community-owned OS project? Does anybody know a positive role-model for this?

I don't want to miss out on the productivity gains I've made with Qbs, but
on the other hand I have very little free time. However, I would voluntarily
contribute to the documentation of Qbs.

Richard
Denis Shienkov
2018-10-30 09:50:17 UTC
Permalink
Hi all, my personal things:

Welcome to the era of stagnation and dinosaurs. The new
"revolutioning" Qt6 will be released semi-dead. It will
be overgrowned with mold, moss and fungi in the form of
CMake. This will not be a new life, but it will be an
attempt to prolong the convulsions.

A real new life could give the QBS, that pushed be a new
branch of the spiral of development. It would stimulate
be the QBS integration with others IDE and etc.

PS: I don't know, what is it: or an "effective management"
or an "evil intent" or an "CMake lobby", or "not enough
money". Perhaps the thesis that "Millions of flies cannot
be mistaken when they choose shit" works here.

Anyway, RIP QBS, You were a great friend, I never forget you.
I drink Vodka and grieve about the innocently murdered projects
for the sake of conjuncture.

== R I P, QBS ==

IMHO, :(

вт, 30 Пкт. 2018 г. в 12:08, Richard Weickelt <***@weickelt.de>:

>
> > Qbs is something that has been developed almost exclusively by The Qt
> > Company. As such, TQtC had to also look at it from a business perspective
> > and how it fits into the larger picture of making Qt successful. To make
> > a long story short, while Qbs is pretty cool and interesting technology,
> > it doesn’t really help us expand the Qt ecosystem and usage.
>
> Qbs has made the development of multi-platform applications with multiple
> libraries a breeze for me. Even projects that contain firmware for
> different
> target architectures in addition to a Qt application are no problem at all
> with Qbs. Thanks to Qbs, I can focus on code and not on the build system. I
> achieve more in less time.
>
> I always thought that Qbs was a great example for using QML.
>
> > To make Qbs really successful would require a rather large effort and
> > investment in promoting it towards the larger C++ ecosystem as a new
> > build tool. At the same time it has to be an open source product to stand
> > any chance in the market. Together this makes it challenging for TQtC to
> > see how to recover that investment. 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.
>
> It seems that Qbs never got much traction within the Qt Company either.
> Outside the regular blog posts, I don't see any attempt to promote Qbs
> anywhere. Correct me if I'm wrong. I may have noticed that Jake Petroules
> did his best to get the word out, but I guess that was his private mission
> rather than his official role in the Qt Company. What I can't complain
> about
> is the unprecedented dedication and professionalism of Christian, Jörg and
> Jake on this project. Also all support questions were answered in lightning
> speed.
>
> > As such, we were left with the question on whether we need Qbs as the
> > build system for Qt 6 or whether cmake (as the other alternative) would
> > be up to the task.
> > [..]
> > Given that we are confident we can build Qt 6 with cmake, I believe that
> > it makes most sense to follow down that route. In case you’re interested,
> > you can have a look at the cmake prototype code for qtbase on Gerrit in
> > the wip/cmake branch. Please also let us know if you’re interested in
> > helping with the effort of porting Qt’s build system over to cmake.
> >
> > We have been developing Qbs over the last years, and as such are
> > committed to it for some more time. We are planning on another feature
> > release in the first quarter of next year and will support it in Qt
> > Creator for at least another year. Qbs is open source and if someone
> > wants to take over and develop it further let us know as well. I’d also
> > like to use this place to thank Christian and Jörg for all their great
> > work on Qbs (and of course also anybody else who contributed to it).
>
> How can we leverage from the next half year to smoothly turn Qbs into a
> community-owned OS project? Does anybody know a positive role-model for
> this?
>
> I don't want to miss out on the productivity gains I've made with Qbs, but
> on the other hand I have very little free time. However, I would
> voluntarily
> contribute to the documentation of Qbs.
>
> Richard
>
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
Christian Gagneraud
2018-10-30 09:55:33 UTC
Permalink
On Tue, 30 Oct 2018 at 22:50, Denis Shienkov <***@gmail.com> wrote:
> == R I P, QBS ==

Please stop these "RIP", you're cautioning a burial ceremony that is
just pure speculation so far.
"CMake will fail" (tm) [another burial ceremony that is just pure
speculation so far]

Chris
Vlad Stelmahovsky
2018-10-30 11:01:50 UTC
Permalink
while I really disappointed with this decision, I dont agree that Qt6 is
dead because of its build system. we are using Qt not because of qmake

Also, Qbs is open source, so its also not dead.


br

On 10/30/18 10:50 AM, Denis Shienkov wrote:
> Hi all, my personal things:
>
> Welcome to the era of stagnation and dinosaurs. The new
> "revolutioning" Qt6 will be released semi-dead. It will
> be overgrowned with mold, moss and fungi in the form of
> CMake. This will not be a new life, but it will be an
> attempt to prolong the convulsions.
>
> A real new life could give the QBS, that pushed be a new
> branch of the spiral of development. It would stimulate
> be the QBS integration with others IDE and etc.
>
> PS: I don't know, what is it: or an "effective management"
> or an "evil intent" or an  "CMake lobby", or "not enough
> money". Perhaps the thesis that "Millions of flies cannot
> be mistaken when they choose shit" works here.
>
> Anyway, RIP QBS, You were a great friend, I never forget you.
> I drink Vodka and grieve about the innocently murdered projects
> for the sake of conjuncture.
>
> == R I P, QBS ==
>
> IMHO, :(
>
> вт, 30 Пкт. 2018 г. в 12:08, Richard Weickelt <***@weickelt.de
> <mailto:***@weickelt.de>>:
>
>
> > Qbs is something that has been developed almost exclusively by
> The Qt
> > Company. As such, TQtC had to also look at it from a business
> perspective
> > and how it fits into the larger picture of making Qt successful.
> To make
> > a long story short, while Qbs is pretty cool and interesting
> technology,
> > it doesn’t really help us expand the Qt ecosystem and usage.
>
> Qbs has made the development of multi-platform applications with
> multiple
> libraries a breeze for me. Even projects that contain firmware for
> different
> target architectures in addition to a Qt application are no
> problem at all
> with Qbs. Thanks to Qbs, I can focus on code and not on the build
> system. I
> achieve more in less time.
>
> I always thought that Qbs was a great example for using QML.
>
> > To make Qbs really successful would require a rather large
> effort and
> > investment in promoting it towards the larger C++ ecosystem as a new
> > build tool. At the same time it has to be an open source product
> to stand
> > any chance in the market. Together this makes it challenging for
> TQtC to
> > see how to recover that investment. 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.
>
> It seems that Qbs never got much traction within the Qt Company
> either.
> Outside the regular blog posts, I don't see any attempt to promote Qbs
> anywhere. Correct me if I'm wrong. I may have noticed that Jake
> Petroules
> did his best to get the word out, but I guess that was his private
> mission
> rather than his official role in the Qt Company. What I can't
> complain about
> is the unprecedented dedication and professionalism of Christian,
> Jörg and
> Jake on this project. Also all support questions were answered in
> lightning
> speed.
>
> > As such, we were left with the question on whether we need Qbs
> as the
> > build system for Qt 6 or whether cmake (as the other
> alternative) would
> > be up to the task.
> > [..]
> > Given that we are confident we can build Qt 6 with cmake, I
> believe that
> > it makes most sense to follow down that route. In case you’re
> interested,
> > you can have a look at the cmake prototype code for qtbase on
> Gerrit in
> > the wip/cmake branch. Please also let us know if you’re
> interested in
> > helping with the effort of porting Qt’s build system over to cmake.
> >
> > We have been developing Qbs over the last years, and as such are
> > committed to it for some more time. We are planning on another
> feature
> > release in the first quarter of next year and will support it in Qt
> > Creator for at least another year. Qbs is open source and if someone
> > wants to take over and develop it further let us know as well.
> I’d also
> > like to use this place to thank Christian and Jörg for all their
> great
> > work on Qbs  (and of course also anybody else who contributed to
> it).
>
> How can we leverage from the next half year to smoothly turn Qbs
> into a
> community-owned OS project? Does anybody know a positive
> role-model for this?
>
> I don't want to miss out on the productivity gains I've made with
> Qbs, but
> on the other hand I have very little free time. However, I would
> voluntarily
> contribute to the documentation of Qbs.
>
> Richard
>
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org <mailto:***@qt-project.org>
> http://lists.qt-project.org/mailman/listinfo/development
>
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Oswald Buddenhagen
2018-10-30 16:40:57 UTC
Permalink
On Mon, Oct 29, 2018 at 12:17:04PM +0000, Lars Knoll wrote:
> while Qbs is pretty cool and interesting technology, it doesn’t really
> help us expand the Qt ecosystem and usage.
>
you actually don't know that. wide adoption outside the qt ecosystem
would create mindshare for the qt project & company.

> To make Qbs really successful would require

> a rather large effort
>
[generously assuming that this part is supposed to be read separately]

> and investment in promoting it towards the larger C++ ecosystem as a
> new build tool.
>
nonsense.
all the promotion qbs would need is being used to build qt.

> Together this makes it challenging for TQtC to see how to recover that
> investment.
>
i would venture the assertion that the decision makers at tqtc just
don't give a shit.
because other companies manage to make a living off (mostly) open-source
build tools, both with consulting and with enterprise add-ons.

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.

On Tue, Oct 30, 2018 at 10:42:13AM +0000, Lars Knoll wrote:
> it would require quite a lot of funding to make it more than a niche
> product
>
nonsense.
qbs is already a very generic and powerful tool. there isn't anything
that needs to be done to make it attractive for non-qt use.
domain-specific non-qt functionality is exactly the kind of thing the
community would contribute - that's actually what the majority of
outside contributions already have been about.

> we were actually surprised on how far we got with cmake in a rather
> limited period of time.
>
that should read "the people who volunteered for the task were
surprised".

> the wip/cmake branch shows that this can be done without having ’to
> bend a dinosaur’.
>
uhm, really? "bending a dinosaur" is an euphemism in my view - i'd call
it an effin' disease. the anticipation of exactly *that* is why we
started qbs in the first place.

> On Tue, Oct 30, 2018 at 10:00:18PM +1300, Christian Gagneraud wrote:
> > - 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.
>
actually, christian is spot-on, ironically for exactly the reason you
cite yourself. the decision to go forward with qbs was repeatedly made
internally, but never followed up by actions (in form of staffing the
project adequately to make it ready for qt in a finite timeframe). jake
had joined the company *because of qbs*, yet tqtc never assigned him to
that task - except where he managed to squeeze it into consulting jobs,
he was contributing to qbs in his spare time despite working for tqtc.
it shouldn't surpise that at some point he said "fuck that" and headed
for greener pastures.
Matthew Woehlke
2018-10-30 16:49:49 UTC
Permalink
On 30/10/2018 12.40, Oswald Buddenhagen wrote:
> all the promotion qbs would need is being used to build qt.

If that's the case, please name a few projects that are using bjam or
boost.build.

--
Matthew
Konstantin Shegunov
2018-10-30 17:26:15 UTC
Permalink
On Tue, Oct 30, 2018 at 6:41 PM Oswald Buddenhagen <***@qt.io>
wrote:

> On Mon, Oct 29, 2018 at 12:17:04PM +0000, Lars Knoll wrote:
> > and investment in promoting it towards the larger C++ ecosystem as a
> > new build tool.
> >
> nonsense.
> all the promotion qbs would need is being used to build qt.
>

Context:
I don't really have a stake in this argument - I'm a qmake user that
doesn't *much* care about the build system, but I'll throw my 2 cents in.
For me cmake is good because many projects are already using it, meaning
that there's not a new technology to learn for many developers. Also it's
powerful, even to the point of being dangerous (I've seen quite the
abominations). On the minus side - it's rather complicated and the syntax
is abysmal.

Argument:
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, with
all its quirks, or live with the fact that people don't want to spend the
time learning a new technology if they don't have to. That's leaving the
pure enthusiasm about something cool aside. Not forcing the issue, in my
opinion, is the reason for the inevitable demise of qbs. And that's exactly
in line with the situation about makefiles: everybody's still using them
underneath the build tools, and pretty much everybody is hating them, but
at the end of day they work and there's little incentive to switch; known
is *safe* but ultimately hinders change.
Matthew Woehlke
2018-10-30 17:38:42 UTC
Permalink
On 30/10/2018 13.26, Konstantin Shegunov wrote:
> [CMake is] powerful, even to the point of being dangerous (I've seen
> quite the abominations).
It's know to be Turing-complete. 'Nuff said ;-).

--
Matthew
Thiago Macieira
2018-10-30 19:09:30 UTC
Permalink
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.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
NIkolai Marchenko
2018-10-30 19:11:38 UTC
Permalink
> 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 ... ;)

On Tue, Oct 30, 2018 at 10:09 PM Thiago Macieira <***@intel.com>
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.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
>
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
Thiago Macieira
2018-10-30 19:19:27 UTC
Permalink
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
NIkolai Marchenko
2018-10-30 19:21:25 UTC
Permalink
> 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 <***@intel.com>
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
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
Thiago Macieira
2018-10-30 19:54:52 UTC
Permalink
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
Adam Treat
2018-10-30 19:24:26 UTC
Permalink
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.
>
Konstantin Shegunov
2018-10-30 20:48:30 UTC
Permalink
On Tue, Oct 30, 2018 at 9:09 PM Thiago Macieira <***@intel.com>
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.
NIkolai Marchenko
2018-10-30 20:56:45 UTC
Permalink
> 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 <***@gmail.com>
wrote:

>
>
> On Tue, Oct 30, 2018 at 9:09 PM Thiago Macieira <***@intel.com>
> 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
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
Thiago Macieira
2018-10-30 21:27:05 UTC
Permalink
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
NIkolai Marchenko
2018-10-30 21:33:41 UTC
Permalink
> 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 <***@intel.com>
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
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
Thiago Macieira
2018-10-30 21:44:03 UTC
Permalink
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
Christian Gagneraud
2018-10-30 21:44:43 UTC
Permalink
On Wed, 31 Oct 2018 at 10:27, Thiago Macieira <***@intel.com> wrote:
> On Tuesday, 30 October 2018 13:56:45 PDT NIkolai Marchenko wrote:
> The only thing I'm criticising is that its proper chance involves Qt being the
> guinea pig. Find someone else instead and grow your community. Get track
> record for building, cross-compiling, working with weird set ups,
> containerised build environments, build farms, etc. Don't ask Qt to switch to
> it until you've done that work.

!?!
What make you think qbs cannot be used in such environments?That all
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
Thiago Macieira
2018-10-30 22:08:32 UTC
Permalink
On Tuesday, 30 October 2018 14:44:43 PDT Christian Gagneraud wrote:
> On Wed, 31 Oct 2018 at 10:27, Thiago Macieira <***@intel.com>
wrote:
> > On Tuesday, 30 October 2018 13:56:45 PDT NIkolai Marchenko wrote:
> > The only thing I'm criticising is that its proper chance involves Qt being
> > the guinea pig. Find someone else instead and grow your community. Get
> > track record for building, cross-compiling, working with weird set ups,
> > containerised build environments, build farms, etc. Don't ask Qt to switch
> > to it until you've done that work.
>
> !?!
> What make you think qbs cannot be used in such environments?That all

I didn't say it can't. I'm saying I want proof that it can, by having other
projects adopt the solution and there being track record of it.

> very basic stuff to me.
> - cross-compiling: Qbs support *out of the box* all "standard" OS
> *and* "standard" toolchains.
> - working with weird set ups: what does that even mean? That a very
> vague statement.

See the July email for more details.

> - containerised build: any build system can run in a container, that's
> orthogonal.

Until you run into trouble. Example of what I literally had a problem with in
the last 30 minutes: Maven.

[ERROR] Failed to execute goal on project hadoop-auth: Could not resolve
dependencies for project org.apache.hadoop:hadoop-auth:jar:2.8.5: Failed to
collect dependencies at com.nimbusds:nimbus-jose-jwt:jar:4.41.1: Failed to
read artifact descriptor for com.nimbusds:nimbus-jose-jwt:jar:4.41.1: Could
not transfer artifact com.nimbusds:nimbus-jose-jwt:pom:4.41.1 from/to
apache.snapshots.https (https://repository.apache.org/content/repositories/
snapshots): repository.apache.org: No address associated with hostname ->
[Help 1]

Who do I turn to for help? A quick set of Google queries did not result in an
answer on how to properly populate the dependencies for this thing (Apache
Hadoop) .

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