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.
Am 30.10.2018 um 06:29 schrieb resurrect...@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
Il giorno mar 30 ott 2018 alle ore 04:34 Thiago Macieira <
thiago.macie...@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
On Tue, 30 Oct 2018 at 20:47, Иван Комиссаров wrote:
> Иван Комиссаров
> > 30 окт. 2018 г., в 4:34, Thiago Macieira
> > написал(а):
> > 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
> -Original Message-
> From: Edward Welbourne
> Sent: Monday, 29 October 2018 7:31 PM
> To: Mitch Curtis
> Cc: Qt development mailing list
> Subject: Re: [Development] Serialising UI state in QML via QSettings and
> JSON: QByteArray vs QString
>
> Mitch Curtis (29 October 2018 17:42)
>
Иван Комиссаров
> 30 окт. 2018 г., в 4:34, Thiago Macieira
> написал(а):
>
>> 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
>>
Warning: Free sarcasm, i'm not serious (well, maybe a little bit...)
On Tue, 30 Oct 2018 at 18:29, 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
Il giorno mar 30 ott 2018 alle ore 09:59 Olivier Goffart
ha scritto:
> On 10/30/18 6:29 AM, resurrect...@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,
> >
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
Hi Christian,
> On 30 Oct 2018, at 05:00, Christian Gagneraud wrote:
>
> On Tue, 30 Oct 2018 at 01:17, Lars Knoll 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
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
> написал(а):
>
> > Yes and this is relevant if it is relevant for the maintainers of Qbs. Do
> we
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
> 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
On Mon, Oct 29, 2018 at 02:25:20PM +, Ulf Hermann wrote:
>> All the proposals for codes of conduct that I have seen so far mention
>> banning only as a last resort and have several less drastic measures
>> that should be applied before.
André Pönitz (29 October 2018 21:18) came back with
>
Edward Welbourne (Monday, 29 October 2018 7:31 PM) wrote
>> I'm not sure where JSON got involved in that
Mitch Curtis (30 October 2018 08:37) replied
> What do you mean? It's in the title of the email; it's a popular
> choice for storing data like this, so I want SplitView's serialisation
> to be
> On 30 Oct 2018, at 06:18, Uwe Rathmann 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
On 30 Oct 2018, at 06:25, NIkolai Marchenko
mailto:enmarantis...@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
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
Hi,
On 10/30/18 12:38 PM, Jedrzej Nowacki wrote:
[...]
Extensions in that respect do not change anything, because it is about error
handling. How to inform a user that a type is not qdebug stream-able
Not really important. I just want to do
qDebug() << my_variant;
and have some useful
On Tue, Oct 30, 2018 at 12:42 PM Cristian Adam
wrote:
> On Tue, Oct 30, 2018, 12:24 Christian Gagneraud wrote:
>
>> > > On 30 Oct 2018, at 05:00, Christian Gagneraud
>> wrote:
>> > > - Any track record that Qbs was not fit for the job? (Please no "we
>> > > can't build Qt with it", as you
> -Original Message-
> From: J-P Nurmi
> Sent: Tuesday, 30 October 2018 2:49 PM
> To: Mitch Curtis
> Cc: development@qt-project.org
> Subject: Re: [Development] Serialising UI state in QML via QSettings and
> JSON: QByteArray vs QString
>
> On Mon, Oct 29, 2018 at 5:42 PM Mitch Curtis
On Mon, Oct 29, 2018 at 5:42 PM Mitch Curtis wrote:
> I thought that I could get around this by using Qt.atob() and Qt.btoa() in
> QML to convert the byte array into a Base64 QString, but it turns out that
> those functions expect a string:
>
>
> -Original Message-
> From: Development project.org> On Behalf Of Mitch Curtis
> Sent: Tuesday, 30 October 2018 3:04 PM
> To: J-P Nurmi
> Cc: development@qt-project.org
> Subject: Re: [Development] Serialising UI state in QML via QSettings and
> JSON: QByteArray vs QString
>
> >
> -Original Message-
> From: Development project.org> On Behalf Of Mitch Curtis
> Sent: Tuesday, 30 October 2018 12:30 PM
> To: Edward Welbourne
> Cc: Qt development mailing list
> Subject: Re: [Development] Serialising UI state in QML via QSettings and
> JSON: QByteArray vs QString
On Tue, Oct 30, 2018 at 3:04 PM Mitch Curtis wrote:
> Their documentation doesn't claim that they operate on a specific type, so
> I'm not sure it's a matter of not doing what they claim to do.
They do promise to handle binary data, though. Representing binary
data with null-terminated strings
On Mon, 29 Oct 2018 18:46:18 +0100, Olivier Goffart wrote:
> In Qt5, we also need the name for the string-based connection syntax.
I'm not sure if I'm ontopic for the Metatype system with my comment, so
please excuse me if I'm hijacking this thread for a moment.
I have this code:
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:
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
> 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
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
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
On Mon, Oct 29, 2018 at 12:17:04PM +, 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 &
> 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 <
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
___
Development mailing list
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
Il giorno mar 30 ott 2018 alle ore 17:52 Oswald Buddenhagen <
oswald.buddenha...@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
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
___
Development mailing list
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.
--
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
On Tue, Oct 30, 2018 at 6:41 PM Oswald Buddenhagen
wrote:
> On Mon, Oct 29, 2018 at 12:17:04PM +, 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.
>
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.
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
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,
On 30/10/2018 04.21, resurrect...@centrum.cz wrote:
> Christian Gagneraud wrote:
>> On Tue, 30 Oct 2018 at 18:29, wrote:
>>> set(var1 "Hello")
>>> set(var2 "Hello")
>>>
>>> if(var1 EQUAL var2)
>>> message("They are equal")
>>> endif()
>>>
>>> Guess what, it prints NOTHING despite docs
On Tuesday, 30 October 2018 06:13:54 PDT Mitch Curtis wrote:
> Since QCborValue also uses the Base64 string approach and it what is what I
> was planning on doing if no other solution came up, I think I will just go
> ahead and return a Base64 QString from QQuickSplitView::saveState() instead
> of
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
> 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
wrote:
> On Tuesday, 30 October 2018 10:26:15 PDT Konstantin Shegunov 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.
On Tue, Oct 30, 2018 at 10:19 PM Thiago Macieira
wrote:
> On Tuesday, 30
> 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
Just as a FYI, I have reported this on internally so hopefully this will get
fixed shortly.
Andy
Development på vegne av Thiago Macieira
skrev følgende den 30.10.2018, 17:22:
On Tuesday, 30 October 2018 02:26:33 PDT Christian Gagneraud 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
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.
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.
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
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
On Tue, Oct 30, 2018 at 9:09 PM Thiago Macieira
wrote:
> On Tuesday, 30 October 2018 10:26:15 PDT Konstantin Shegunov wrote:
> > From my point of view qbs is doomed as long as qmake's alive. Either kill
> > qmake and force the developers using Qt (or developing Qt) to use qbs
>
> That's not
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
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
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
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
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
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
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
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:
>
>
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
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
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.
>
> 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
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
On Tuesday, 30 October 2018 14:57:01 PDT Christian Gagneraud wrote:
> > Looking at the fact, that we can’t earn money on a build system and that
> > it would require quite a lot of funding to make it more than a niche
> > product it doesn’t make sense to pursue it further. Instead we would
> >
Huh? Looks like they are supporting every build system alive
https://github.com/openframeworks/openFrameworks/tree/patch-release/libs/openFrameworksCompiled/project
> 30 окт. 2018 г., в 22:14, Jean-Michaël Celerier
> написал(а):
>
> OpenFrameworks, a fairly used creative coding framework has
Tbh, as I see it: qbs is mostly usable now. The only thing it needs to stay
afloat from now on and have a chance is promise of support for it + qt6 in
qt creator.
Is that really that hard to do?
On Wed, Oct 31, 2018 at 12:37 AM Jean-Michaël Celerier <
jeanmichael.celer...@gmail.com> wrote:
>
On Wed, 31 Oct 2018 at 10:27, Thiago Macieira wrote:
> On Tuesday, 30 October 2018 13:56:45 PDT NIkolai Marchenko wrote:
> The only thing I'm criticising is that its proper chance involves Qt being the
> guinea pig. Find someone else instead and grow your community. Get track
> record for
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.
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
On Tuesday, 30 October 2018 14:44:43 PDT Christian Gagneraud wrote:
> On Wed, 31 Oct 2018 at 10:27, Thiago Macieira
wrote:
> > On Tuesday, 30 October 2018 13:56:45 PDT NIkolai Marchenko wrote:
> > The only thing I'm criticising is that its proper chance involves Qt being
> > the guinea pig. Find
> 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
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
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:
> 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
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
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
Hi Lars,
On Tue, 30 Oct 2018 at 23:42, Lars Knoll wrote:
> > On 30 Oct 2018, at 05:00, Christian Gagneraud wrote:
> > On Tue, 30 Oct 2018 at 01:17, Lars Knoll wrote:
> > Then why spend energy/money to fix something that is broken by design?
> > (Again, that is a personal opinion, if needed to
https://testresults.qt.io/logs/qt/qtbase/
4d1c701336289c6c70c86b1bdea0324214a5687a/
LinuxUbuntu_18_04x86_64LinuxQEMUarmv7GCCqtci-linux-Ubuntu-18.04-x86_64-
ea77a2DeveloperBuild_DisableTests/2a48a3b7dcb9652b1532a3ad14de7580b5b9b1ee/
build_1542285435/log.txt.gz
agent:2018/10/31 03:51:26
On Tue, Oct 30, 2018 at 02:44:03PM -0700, Thiago Macieira wrote:
> On Tuesday, 30 October 2018 14:33:41 PDT NIkolai Marchenko wrote:
> > Tbh, we wouldn't if this post hasn't almost stated that you are pulling the
> > plug.
> > As I saw it: qbs folks have finally started doing the correct thiing
Hi,
În ziua de marți, 30 octombrie 2018, la 19:11:20 EET, Oswald Buddenhagen a
scris:
> On Tue, Oct 30, 2018 at 01:16:43PM +0200, Bogdan Vatra wrote:
> > c.2) back then, none of the existing build system could deliver enough
> > information to IDEs to enable prefect code completion (e.g.
Hi,
DISCLAIMER: I was one of the biggest QBS supporters!
QBS was a dream too good to be true, its main goals were:
a) a simple sintax which anyone can use
b) no extrenal dependeincies to configure/build & deploy your apps
c) designed with tooling in mind:
c.1) imagine a world where you can
> > On 30 Oct 2018, at 05:00, Christian Gagneraud 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
> -Original Message-
> From: Edward Welbourne
> Sent: Tuesday, 30 October 2018 11:37 AM
> To: Mitch Curtis
> Cc: Qt development mailing list
> Subject: Re: [Development] Serialising UI state in QML via QSettings and
> JSON: QByteArray vs QString
>
> Edward Welbourne (Monday, 29 October
> 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
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 написал(а):
>>> On 30 Oct 2018, at 05:00, Christian Gagneraud wrote:
>>> - Any track record that Qbs was not fit for the job?
Dnia poniedziałek, 29 października 2018 18:46:18 CET Olivier Goffart pisze:
> On 10/29/18 5:39 PM, Jedrzej Nowacki wrote:
> > Hi everyone!
> >
> >While main heat on the mailing list is taken by topic how to encode
> >that we
> >
> > are nice, friendly and respectful to each other, I
On Tue, Oct 30, 2018, 12:24 Christian Gagneraud wrote:
> > > On 30 Oct 2018, at 05:00, Christian Gagneraud
> 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)
> >
> >
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
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
On 10/30/18 6:29 AM, resurrect...@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
On Tue, 30 Oct 2018 at 22:18, Richard Weickelt 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
> >
> Can you name any project of moderate complexity using it?
https://github.com/bjorn/tiled
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Hi,
Final downmerge is now completed in every submodule. If there is some open
changes in '5.12' which needs to be in Qt 5.12.0 you need to retarget those in
'5.12.0' instead.
And staging in '5.12.0' is also restricted to release team only. Please do not
try to put any nice-to-haves in
On Tue, 30 Oct 2018 at 22:50, Denis Shienkov 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
1 - 100 of 110 matches
Mail list logo
