Re: [Development] unique_ptr and Qt, Take 2

[Christian Ehrlicher]

Am 13.06.2019 um 23:44 schrieb Konstantin Tokarev:


14.06.2019, 00:14, "Christian Ehrlicher" :

Am 13.06.2019 um 22:09 schrieb Ville Voutilainen:

  That's one of the things I love about Qt; object hierarchies give me
  working dynamic memory management without needing even smart pointers.

  That's the one thing that makes me queasy about using Qt in large
  applications; I always need
  to worry about ownership relationships, because I can't program with
  smart pointers. I had the pleasure
  of writing smart-pointer-only code 20 years ago; it was quite
  pleasant, especially considering that
  the largeish application was leaking like a sieve and doing
  use-after-free in all too many places.
  Once we plugged boost's smart pointers into it, all those problems
  went away over a weekend,
  and we never looked back.

A very good example on how to kill a library by simply using smart
pointer everywhere is QtXmlPatterns:

https://bugreports.qt.io/issues/?jql=project%20%3D%20QTBUG%20AND%20status%20%3D%20Reported%20AND%20component%20%3D%20%22XML%3A%20QtXmlPatterns%22%20ORDER%20BY%20key%20DESC

Any proffs that any of these issues were caused by smart pointers?

Otherwise I would not have mentioned it. Just take a look at the code
and one of the bug report issues... it awesome and you will see why
nobody want/can maintain this library.

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

Re: [Development] unique_ptr and Qt, Take 2

[Konstantin Tokarev]

14.06.2019, 00:14, "Christian Ehrlicher" :
> Am 13.06.2019 um 22:09 schrieb Ville Voutilainen:
>>>  That's one of the things I love about Qt; object hierarchies give me
>>>  working dynamic memory management without needing even smart pointers.
>>  That's the one thing that makes me queasy about using Qt in large
>>  applications; I always need
>>  to worry about ownership relationships, because I can't program with
>>  smart pointers. I had the pleasure
>>  of writing smart-pointer-only code 20 years ago; it was quite
>>  pleasant, especially considering that
>>  the largeish application was leaking like a sieve and doing
>>  use-after-free in all too many places.
>>  Once we plugged boost's smart pointers into it, all those problems
>>  went away over a weekend,
>>  and we never looked back.
>
> A very good example on how to kill a library by simply using smart
> pointer everywhere is QtXmlPatterns:
>
> https://bugreports.qt.io/issues/?jql=project%20%3D%20QTBUG%20AND%20status%20%3D%20Reported%20AND%20component%20%3D%20%22XML%3A%20QtXmlPatterns%22%20ORDER%20BY%20key%20DESC

Any proffs that any of these issues were caused by smart pointers?

>
> So simply saying 'smart pointer fix it all' is just wrong.

Nobody says 'fix it all', smart pointers fix only specific class of issues. 
Without smart pointers you are on your own with them too.

-- 
Regards,
Konstantin

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

Re: [Development] unique_ptr and Qt, Take 2

[Matthew Woehlke]

On 13/06/2019 16.09, Ville Voutilainen wrote:
> The minor problem being that to not so small audiences,
> new Whoosh(something);
> just looks like a bug, and then you need to look three times to
> realize that something is a parent.

Sure... but `something.createChild()` can help with that.

OTOH, I just realized a problem with that... when the new child needs to
take its parent in the ctor for other reasons. I don't know if there is
an easy solution to that. (Of course, you can still pass the parent with
createChild, but then you've violated DRY.)

>> That's one of the things I love about Qt; object hierarchies give me
>> working dynamic memory management without needing even smart pointers.
> 
> That's the one thing that makes me queasy about using Qt in large 
> applications; I always need to worry about ownership relationships,
> because I can't program with smart pointers.
I guess your mileage varies. My experience has been the opposite.

To be fair, I expect a lot of that is "instinctive"... that is, when you
come from a background where not using smart pointers is scary, the Qt
way is probably going to rub you the wrong way, even though it's nowhere
near as dangerous as your experience causes you to believe. Conversely,
being comfortable with Qt and its minimal need for smart pointers likely
produces an aversion to sprinkling them everywhere "because it's safer".

> [...] the largeish application was leaking like a sieve and doing
> use-after-free in all too many places.

QPointer is great for avoiding this :-). (Also, properly "owned"
signal/slot connections.)

> On Thu, 13 Jun 2019 at 22:54, Matthew Woehlke wrote:
>> My "concern", and possibly why everyone fixated on the unique_ptr stuff,
>> is how wide-sweeping the necessary API changes will be. Modifying every
>> method, everywhere, that reparents a QObject is a little intimidating.
>> (Maybe you have some WIP that can put this into perspective?)
> 
> Like https://codereview.qt-project.org/c/qt/qtbase/+/260618 ?

Uh... yeah, I suppose. And... yeah. Yike. That's a scary (or at least
intimidating) amount of API churn. In particular, there are enough files
being touched to strongly discourage me even looking at the diffs...

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

Re: [Development] unique_ptr and Qt, Take 2

[Christian Ehrlicher]

Am 13.06.2019 um 22:09 schrieb Ville Voutilainen:

That's one of the things I love about Qt; object hierarchies give me
working dynamic memory management without needing even smart pointers.

That's the one thing that makes me queasy about using Qt in large
applications; I always need
to worry about ownership relationships, because I can't program with
smart pointers. I had the pleasure
of writing smart-pointer-only code 20 years ago; it was quite
pleasant, especially considering that
the largeish application was leaking like a sieve and doing
use-after-free in all too many places.
Once we plugged boost's smart pointers into it, all those problems
went away over a weekend,
and we never looked back.

A very good example on how to kill a library by simply using smart
pointer everywhere is QtXmlPatterns:

https://bugreports.qt.io/issues/?jql=project%20%3D%20QTBUG%20AND%20status%20%3D%20Reported%20AND%20component%20%3D%20%22XML%3A%20QtXmlPatterns%22%20ORDER%20BY%20key%20DESC

So simply saying 'smart pointer fix it all' is just wrong.


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

Re: [Development] unique_ptr and Qt, Take 2

[Marco Bubke]

On June 13, 2019 17:25:15 Matthew Woehlke  wrote:

> On 13/06/2019 03.03, Marco Bubke wrote:
>> On June 12, 2019 23:13:14 Matthew Woehlke  wrote:
 me here. I think Daniel is on to something and we really should explore
 having smart pointers in Qt 6, but at this point I'm not convinced
 std::unique_ptr alone is it. I'd like to see what we could achieve with a
 QObject-specific smart pointer that understood ownership-taking functions
 (setParent, addWidget, etc.) and observing-only API (like connect()).
>>>
>>> Idea: make this hypothetical pointer be a QObject that initially "owns"
>>> the object to which it points. If the object is reparented, the pointer
>>> will stop "owning" it but will still have the reference.
>>
>> Can you implement it so that it fits owner? One of the purposes is that 
>> the static analysis can be sure about the ownership.
>
> I don't think so; at least, not without a lot of associated work. Part
> of the above idea is that I believe it is notionally implementable *now*
> (or even as far back as Qt4 at least). You can safely pass the raw
> pointer to methods that may or may not reparent the object, and
> everything will continue to work, but currently it isn't obvious what
> methods will or won't take ownership, and in some cases the answer to
> that question depends on additional (run-time) information. (Note in
> particular the QLayout example as mentioned elsewhere in this thread.)
But then the static analysis tool gives you many false positives. So the tool 
gets less useful. Tools get more and more important, so we want to send the 
message that "real" Qt developers don't need that tools? ;-)
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] unique_ptr and Qt, Take 2

[Ville Voutilainen]

On Thu, 13 Jun 2019 at 22:54, Matthew Woehlke  wrote:
>
> On 13/06/2019 14.13, Daniel Teske wrote:
> > On June 12, 2019 23:13:14 Matthew Woehlke wrote:>> Generally, if you follow 
> > three rules: - If you create an object
> on the stack, either don't parent it or ensure>>   its parent outlives
> it. (Usually not hard!)>> - If you create an object with `new`,
> **create** it with a parent.>> - Otherwise use a smart pointer
> (QScopedPointer or QSharedPointer)¹. ...you just won't have
> problems.> > And that doesn't need to change with my design at all.
> To be fair, I was responding more to Giuseppe and had only briefly
> looked at the original mail. In particular, I was responding to the part
> where he quotes your example:
>
> >  QMenu menu;
> >  auto act = std::make_unique("Action!");
> >  menu.addAction(act.get());
>
> IMHO that code should never exist, and should not be encouraged. Leaving
> aside that one could use QMenu::addAction(QString) here, even in other
> cases similar to this where that would not apply, I would encourage
> following one of my first two rules instead.

The minor problem being that to not so small audiences,
new Whoosh(something);
just looks like a bug, and then you need to look three times to
realize that something is a parent.

>
> That's one of the things I love about Qt; object hierarchies give me
> working dynamic memory management without needing even smart pointers.

That's the one thing that makes me queasy about using Qt in large
applications; I always need
to worry about ownership relationships, because I can't program with
smart pointers. I had the pleasure
of writing smart-pointer-only code 20 years ago; it was quite
pleasant, especially considering that
the largeish application was leaking like a sieve and doing
use-after-free in all too many places.
Once we plugged boost's smart pointers into it, all those problems
went away over a weekend,
and we never looked back.

> > And there are small benefits that even those that don't want to use
> > unique_ptr, can get with minimal effort. For example by using the new
> > makeChild function:
> >
> > parent->makeChild(...);
>
> ...this actually seems pretty reasonable to me, especially as it only
> needs to touch the API for 1-2 classes (QObject, maybe QWidget). You're
> just providing an alternate way of following my second rule, which is
> arguably better, especially by modern C++ standards, as a) it never uses
> a bare `new`, and b) it works with QObject subclasses that have bad
> ctors that don't take a parent. (I admit I've written a few, though
> usually that is because the particular class is not expected to be heap
> allocated, or is expected to be lifetime-managed in some other manner.)

This would indeed be a great improvement, regardless of what we do
with smart pointers.

> My "concern", and possibly why everyone fixated on the unique_ptr stuff,
> is how wide-sweeping the necessary API changes will be. Modifying every
> method, everywhere, that reparents a QObject is a little intimidating.
> (Maybe you have some WIP that can put this into perspective?)

Like https://codereview.qt-project.org/c/qt/qtbase/+/260618 ?

> Adding (templated) QObject::createChild is much more approachable (and
> also conveniently dodges having anything to do with STL, which can be a
> hot-button issue on its own). I suspect if you were to pursue that
> separately, it would have a good chance of being accepted, and with many
> fewer passions inflamed in the process.

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

Re: [Development] Proposing CMake as build tool for Qt 6

[Thiago Macieira]

On Thursday, 13 June 2019 05:02:01 PDT Lisandro Damián Nicanor Pérez Meyer 
wrote:
> > Giving our build tools different names depending on the version can create
> > other problems for our users, especially those that use some hand rolled
> > build systems (and we probably have lots of those as well).
> 
> And the above is clearly a thing a Qt-internals' developer should definitely
> look to, so a very valid concern. But let's take the other's too.

I REALLY don't think there are a lot of hand-rolled buildsystems out there. 
And they must represent less than 0.1% of uses and complexity. We should 
consider giving them a solution. But by the same token, we should consider 
that Linux distributions must correspond to at least 10% of uses, which is 
100x more.

> We can list qdbus and qdbusviewer as examples (perhaps not the best ones,
> but will do for now). So let's say app4 is compiled against Qt4 (we still
> have them around, sadly not every useful app was yet ported) and app5 is
> compiled against Qt5. Take Qt 6 instead of Qt 4 if you like. Both where
> developed using their own version's qdbus in mind.
> 
> As a packager my duty is to ensure that app4 has a strong dependency against
> Qt4's qdbus and app5 has a strong dependency against Qt5's qdbus, so both
> versions of qdbus will be installed.

Those are really not good examples because qdbus is a regular tool that 
retains compatibility going forward, like any other tool. That means you 
should NOT do that strong dependency. app5 should require qdbus >= Qt5, which 
means Qt 6's should suffice.

The only other application that come close are Linguist and Assistant.

> ## Binaries that need to be accesible by developers using Qt
> 
> These are moc, rcc, linguist, designer, uic, etc. Some of them really
> need to be in
> $libexecdir and ought to be found by way of the .cmake and .pc files
> [1]. But then
> there are the other tools that, once again, need to be readily accesible for
> a developer user but in a much "normal" way. Let's say for example
> linguist. Translators
> are normally more in the "user" side of things than in the "developer" side.
> 
> assistant might probably be in this situation too.
> 
> [1]
>  ml> [2]
>  ml>
> 
> And maybe lupdate is also an elegible example.

The command-line tools used by the build system (moc, rcc, lupdate, etc.) 
should be in a lib / libexec dir and found by .cmake and .pc files. For a 
foreign buildsystem, the only modification necessary is to change how it 
launches the binaries. Not very difficult and probably not the only 
modification necessary anyway to support Qt 6.

Linguist and Assistant are a different story: they should be found by the 
desktop menu. Both should retain compatibility with old files and, in case of 
Linguist, *generate* for older formats so the same tool can be used to 
translate for Qt 3, 4, 5 and 6. Assistant is even worse because it's meant to 
be launched by applications...

That's different from Designer.

> # Seeing the problem as a Qt-internal's developer
> 
> I can see value in qtchooser for Qt-internal's developers. You can easily
> switch between Qt versions without too much hassle.

Not just versions, even different builds of the same version. For the past 7 
years, ever since I dropped the 4.8 build, I've only had a single Qt version 
built. It's built multiple times, with different compilers and options, but 
it's still the same version.

But as you said, this is a developer tool. And interestingly, if we move the 
developer tools out of $PATH, qtchooser becomes an interesting solution to 
bring them back in for those few people who want them. So I don't see anything 
wrong with qtchooser as a developer-of-Qt tool.

As a developer-using-Qt, I need to be able to install several Qt in parallel 
so I can test my application with them, but this is going to depend on which 
buildsystem I chose for my application. If I'm using qmake, qtchooser is 
interesting, but people already know to type the full path if they downloaded 
from qt.io anyway. If I'm using CMake, then I need to set some environment 
variable so CMake knows where to find the .cmake files -- this isn't solved by 
qtchooser, but by a wrapping shell function.

Additionally, I may want to run a few debugging helpers, like qtplugininfo or 
qtdiag.

> I sincerely do not know how you manage to keep up with your desktop
> environment in Linux as I'm pretty sure most of you are not using a
> GTK-based desktop :-) Why I say that? because even the smallest Qt-based
> desktop environment ships theming which requires using Qt's private API, so
> it's tightly tied to a specific ¡minor! version. And I'm pretty sure there
> are other cases which have the same issue.

My Linux desktop uses the distro-provided Qt. My own builds use a lib infix so 
that no system application 

Re: [Development] unique_ptr and Qt, Take 2

[Bernhard Lindner]

> * enable templated QObjects. There's a prototype from Olivier, so is that 
> possible? 

Yes, this is long overdue.

-- 
Best Regards,
Bernhard Lindner

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

Re: [Development] unique_ptr and Qt, Take 2

[Matthew Woehlke]

On 13/06/2019 14.13, Daniel Teske wrote:
> On June 12, 2019 23:13:14 Matthew Woehlke wrote:>> Generally, if you follow 
> three rules: - If you create an object
on the stack, either don't parent it or ensure>>   its parent outlives
it. (Usually not hard!)>> - If you create an object with `new`,
**create** it with a parent.>> - Otherwise use a smart pointer
(QScopedPointer or QSharedPointer)¹. ...you just won't have
problems.> > And that doesn't need to change with my design at all.
To be fair, I was responding more to Giuseppe and had only briefly
looked at the original mail. In particular, I was responding to the part
where he quotes your example:

>  QMenu menu;
>  auto act = std::make_unique("Action!");
>  menu.addAction(act.get());

IMHO that code should never exist, and should not be encouraged. Leaving
aside that one could use QMenu::addAction(QString) here, even in other
cases similar to this where that would not apply, I would encourage
following one of my first two rules instead.

That's one of the things I love about Qt; object hierarchies give me
working dynamic memory management without needing even smart pointers.

With that out of the way, and having gone back and looked more closely
at your original post...

> To reiterate a point that seems to be a source of misunderstanding,
> in the design I proposed the vast majority of objects are never owned
> by a unique_ptr. Most objects are created with a parent.
> 
> And there are small benefits that even those that don't want to use
> unique_ptr, can get with minimal effort. For example by using the new
> makeChild function:
> 
> parent->makeChild(...);

...this actually seems pretty reasonable to me, especially as it only
needs to touch the API for 1-2 classes (QObject, maybe QWidget). You're
just providing an alternate way of following my second rule, which is
arguably better, especially by modern C++ standards, as a) it never uses
a bare `new`, and b) it works with QObject subclasses that have bad
ctors that don't take a parent. (I admit I've written a few, though
usually that is because the particular class is not expected to be heap
allocated, or is expected to be lifetime-managed in some other manner.)

Mostly what I don't want to see (and I'll freely admit this is probably
a result of others' fixation) is suddenly having to litter my Qt code
with `std::make_unique` and `std::move` all over the place for no more
lifetime safety than I've always had.

> So, I think what I have actually proposed has zero costs to those that
> don't want to use it, while enabling those that e.g. want to make use of
> tooling around memory managment capable of doing so.

My "concern", and possibly why everyone fixated on the unique_ptr stuff,
is how wide-sweeping the necessary API changes will be. Modifying every
method, everywhere, that reparents a QObject is a little intimidating.
(Maybe you have some WIP that can put this into perspective?)

Adding (templated) QObject::createChild is much more approachable (and
also conveniently dodges having anything to do with STL, which can be a
hot-button issue on its own). I suspect if you were to pursue that
separately, it would have a good chance of being accepted, and with many
fewer passions inflamed in the process.

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

Re: [Development] unique_ptr and Qt, Take 2

[Daniel Teske]

Hi,

I was happly ignoring the other threads, since I didn't like the 
temperature of some the responses.


But I guess you force me to write a response not just to you, but 
something that is a bit more general.

Or... just don't do that?

I can't recall that I've *ever* had problems with QObject ownership.


You, and a few others have made similar arguments, that start from your 
personal experience and since you do not needed something conclude that 
it is not worth doing.


And please don't read the rest of the mail as a attack on you, that's 
not intended. I think it's important to hear from all kind of different 
users, but I need to point out what I perceive as a faulty argument.


It is imho the wrong perspective:

There's a wide spectrum of Qt users.
* Some of which don't want Qt to change [much].
* Some of which want leverage new C++ features while using Qt
* Some of which want Qt to be more like the C++ standard

By arguing from a personal standpoint, you are implicitly ignoring all 
users that aren't like you. A proposal (or the rejection) should be 
based on considering the effect not just on you, but on all kind of 
different users.


Except, just considering current users, would be quite wrong.

Qt needs to continously attract new users, as it otherwise dies with the 
current user base. Those users will mostly - I would assume - come from 
a C++ backgroud. And my experience as a freelancer is that most projects 
I see use at least C++11 and I have no trouble finding projects using 
more modern standards.


But even that, would be the wrong perspective. We are discussing APIs in 
the context of Qt 6, which will be around for a decade. Thus, the 
correct perspective would be to consider which kind of user Qt wants to 
attract and serve in a few years. And I believe that in a few years, 
most people with a C++ background would expect modern apis.


The same perspective error happens from these arguing for deprecation 
and removal, too.


For example, obviously Q_FOREACH is ugly and outdated. It seems some 
argue that the benefit of not having to teach Q_FOREACH is worth the 
major pain and frustration that existing users would experience if it 
just got removed. I can't understand that.


In fact the whole premise of the thread is imho misguided. If the goal 
is making Qt and C++ more interoperable, then deprecation and removal is 
the wrong way to go about it.


The way forward should be to create win-win situations for both those 
that want to make use of modern C++ and those that are quite happy with 
Qt as it is.


For example, I wish Qt 6 would:

* enable templated QObjects. There's a prototype from Olivier, so is 
that possible?

* support move only types in Qt container
* add overloads for all functions taking bool * that make use of 
std::optional
* add overloads for all functions using output parameters. auto [...] = 
foo() is imho ugly, but that's nevertheless better than output parameters

* have great interoprability with ranges

None of that would require making Qt worse for existing users.


Generally, if you follow three rules:

- If you create an object on the stack, either don't parent it or ensure
its parent outlives it. (Usually not hard!)
- If you create an object with `new`, **create** it with a parent.
- Otherwise use a smart pointer (QScopedPointer or QSharedPointer)¹.

...you just won't have problems.


And that doesn't need to change with my design at all. You can just 
write the same code as is. To reiterate a point that seems to be a 
source of misunderstanding, in the design I proposed the vast majority 
of objects are never owned by a unique_ptr. Most objects are created 
with a parent.


And there are small benefits that even those that don't want to use 
unique_ptr, can get with minimal effort. For example by using the new 
makeChild function:


parent->makeChild(...);

It's almost impossible to forget to pass a parent parameter. And best of 
all, no one is forced to use that, but it can be adopted at whatever 
pace is best.


And for your last case of holding a QObject in a smart pointer, the 
propsal makes that drastically less akward.


So, I think what I have actually proposed has zero costs to those that 
don't want to use it, while enabling those that e.g. want to make use of 
tooling around memory managment capable of doing so.


daniel

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

Re: [Development] unique_ptr and Qt, Take 2

[Matthew Woehlke]

On 13/06/2019 03.03, Marco Bubke wrote:
> On June 12, 2019 23:13:14 Matthew Woehlke  wrote:
>>> me here. I think Daniel is on to something and we really should explore
>>> having smart pointers in Qt 6, but at this point I'm not convinced
>>> std::unique_ptr alone is it. I'd like to see what we could achieve with a
>>> QObject-specific smart pointer that understood ownership-taking functions
>>> (setParent, addWidget, etc.) and observing-only API (like connect()).
>>
>> Idea: make this hypothetical pointer be a QObject that initially "owns"
>> the object to which it points. If the object is reparented, the pointer
>> will stop "owning" it but will still have the reference.
>
> Can you implement it so that it fits owner? One of the purposes is that 
> the static analysis can be sure about the ownership.

I don't think so; at least, not without a lot of associated work. Part
of the above idea is that I believe it is notionally implementable *now*
(or even as far back as Qt4 at least). You can safely pass the raw
pointer to methods that may or may not reparent the object, and
everything will continue to work, but currently it isn't obvious what
methods will or won't take ownership, and in some cases the answer to
that question depends on additional (run-time) information. (Note in
particular the QLayout example as mentioned elsewhere in this thread.)

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

Re: [Development] Proposing CMake as build tool for Qt 6

[Thiago Macieira]

On Thursday, 13 June 2019 01:06:06 PDT Bogdan Vatra via Development wrote:
> Hi,
> 
>   There is one more missing feature to add to your list: build & debug
> builds for msvc in one go (same as qmake does now, a single "make" command
> will build both targets).

I wouldn't call that a hard requirement. Separate builds for debug and for 
release are acceptable, the same way that we've ostensibly had support for 
shared-and-release builds but in practice they're always built separately.

The only difficult part I see is enforcing the suffix. On Mac we've had 
problems with this, since a debug-only build is un-suffixed. Maybe it's time 
to rethink the strategy and make the suffix optional altogether (using the lib 
infix feature). On Windows, we should stop enforcing that unoptimised builds 
be -MDd and make it easy for people to debug into -MD libraries. Hardly anyone 
ever debugs into Microsoft's libraries...

>   Also I wonder when do you plan to release Qt6? Because according to
> Thiago's "what a buildsystem must to have list" he mentioned that the
> buildsystem should be at least 2 years in the wild. If the needed cmake
> support is not implemented yet, are you going to delay Qt 6 release (I
> won't mid to use C++20 in Qt 6 :) ) just to give time to cmake to mature?
> Or that (part of the) list was just an excuse for TQC to ditch QBS ;-).

2 years in the wild was not for all features, it was for the buildsystem 
itself and the major features. But we need to build with the version that 
comes with the host systems that we are targetting (if they ship tools like 
this in the first place; Windows doesn't).

That means that the iOS support only needs to be present in whatever version 
of CMake that Homebrew installs. Since Homebrew always has the latest, this is 
not an impediment.

But if we want to build on Ubuntu 16.04, then that three year old version's 
CMake needs to be sufficient for a native build of Qt and whatever cross-
builds get targeted from Linux (Android and QNX, I'd guess). For Qt 6, I'd 
just recommend raising the minimum to 18.04...

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] Proposing CMake as build tool for Qt 6

[Lisandro Damián Nicanor Pérez Meyer]

Resending because I mistakenly replied just to Lars.

Lars: thansk for the heads up, and also note I rewrote a paragraph below,
hopefully to be more on point.

On 19/06/11 07:12, Lars Knoll wrote:
> Hi Lisandro,

Hi Lars!

[snip]
> That thread doesn’t explain why qtchooser isn’t a solution. It does work
> without problems for all my use cases, and I certainly do have quite a few Qt
> versions installed in parallel.

Maybe my fault, I have discussed this in this mailing list before. The mail
also has a link to our bugs list, but let me try to write down it's pros
and cons here.

> Part of the problem simply stems from the fact that Linux distributions
> want to put all the binaries into /usr/bin. As long as you keep separate
> Qt versions in separate directories there’s no problem I know of.

Each operative system has it's design rules. We might or not like them, but if
we want Qt to be really a multi-platform code-once tool then we should accept
those rules and do our best to build upon them.

Let's try to put this into two three different points of view:

- A Qt-internals' developer
- A developer using Qt to create stuff
- A system developer/integrator (within this, distro maintainers).

> Giving our build tools different names depending on the version can create
> other problems for our users, especially those that use some hand rolled
> build systems (and we probably have lots of those as well).

And the above is clearly a thing a Qt-internals' developer should definitely
look to, so a very valid concern. But let's take the other's too.

I am taking maybe another approach to what Kevin already wrote in [a], but I do
agree to what he wrote there too.

[a] 

# Problem 1: binary masking

At first I thought qtchooser might probe to be a nice tool for switching
versions much like Shawn wrote, but then experience showed us the contrary.

With "binary masking" I mean that qtchooser replaces the path for where a
binary should be with itself.

With this comes the following cases:

## Binaries that need to be accesible by "the user"

This are the ones that really need to be in $PATH because the normal user needs
it. We can't expect a normal user to add to $PATH a "weird" path of a specific
Qt version and change it every time it needs to switch versions. Let's add that
the user of that application might well be another application or
system library.

We can list qdbus and qdbusviewer as examples (perhaps not the best ones, but
will do for now). So let's say app4 is compiled against Qt4 (we still have
them around, sadly not every useful app was yet ported) and app5 is compiled
against Qt5. Take Qt 6 instead of Qt 4 if you like. Both where developed using
their own version's qdbus in mind.

As a packager my duty is to ensure that app4 has a strong dependency against
Qt4's qdbus and app5 has a strong dependency against Qt5's qdbus, so both
versions of qdbus will be installed.

Now both app4 and app5 developer's will probably not worry about qtchooser
because it's just a hack needed on Linux, so they won't be calling 'qdbus -qt5'
(which, as Kevin said, it's not even a standard) but just 'qdbus'. So with
qtchooser around app4 and app5 will receive both the same version of qdbus, be
it Qt 4's or 5's.

So, why it has not backfired yet? Because thanks Thiago (probably) qdbus behaves
the same in both Qt 4 and 5. Had they differed in the way they behave... kaboom.
We packagers would be probably needed to start patching applications to pass
proper qtchooser arguments, which is not something developers that use Qt like a
lot.

So the big question here is: can we *really* keep this applications
backward-compatible for the whole Qt 4, 5 and 6 and future versions?

## Binaries that need to be accesible by developers using Qt

These are moc, rcc, linguist, designer, uic, etc. Some of them really
need to be in
$libexecdir and ought to be found by way of the .cmake and .pc files
[1]. But then
there are the other tools that, once again, need to be readily accesible for a
developer user but in a much "normal" way. Let's say for example
linguist. Translators
are normally more in the "user" side of things than in the "developer" side.

assistant might probably be in this situation too.

[1] 

[2] 


And maybe lupdate is also an elegible example.

## Binary masking and dependency resolution

Now the user installs qt5's qdbus. Currently that will in turn install
qtchooser (there is currently no way around it except renaming binaries),
so /usr/bin/qdbus is taken.

Now the user needs qt5's qdbus, so he simply runs 'qdbus'. It will fail. Why is
that? Because in Qt 4 the concept of qtchooser did not exist, so the
default system
consiguration needs to be qt4 as long as there is any piece of it installed on
the 

Re: [Development] Proposing CMake as build tool for Qt 6

[Bogdan Vatra via Development]

Hi,

  There is one more missing feature to add to your list: build & debug builds 
for msvc in one go (same as qmake does now, a single "make" command will build 
both targets).

  Also I wonder when do you plan to release Qt6? Because according to Thiago's 
"what a buildsystem must to have list" he mentioned that the buildsystem 
should be at least 2 years in the wild. If the needed cmake support is not 
implemented yet, are you going to delay Qt 6 release (I won't mid to use C++20 
in Qt 6 :) ) just to give time to cmake to mature? Or that (part of the) list 
was just an excuse for TQC to ditch QBS ;-).

QBS Android (and iOS) support is far superior to both cmake & qmake. It's not 
only compiles your bins (for all ABIs at once!) but it also compiles the java, 
aild, etc. parts and it packages them using the android tools directly, which 
gives it a faster build time than any other build system out there, yes faster 
than qmake/cmake + gradle!

I just hope that even if you'll use cmake to build qt itself, we can still be 
able to use any buildsystem to build our Qt Apps. 

Cheers,
BogDan.


În ziua de joi, 13 iunie 2019, la 10:42:33 EEST, Lars Knoll a scris:
> Hi all,
> 
> After all the discussion, lets go back to the original proposal. We can see
> from the discussions that there is still work to be done, but I can’t find
> anything that sounds like a real showstopper.
 
> The two missing features that were voiced as a concern (if I didn’t miss
> anything in the thread) where multi arch/fat binary support for iOS and PCH
> support. I also heard that the people working on it are confident they can
> get this fixed in time for Qt 6, something I’m happy with for now.
> Nevertheless, I think it would be good if the team working on the cmake
> port could summarise how/when they are planning to fix this.
 
> One additional concern was multi arch builds for Android, but I don’t think
> that counts as a concern as qmake does not support this neither (so it
> would be a new feature).
 
> Finally, there was a concern around qmake support for users of Qt. This is
> something I have discussed with the team in the past, and it is a strong
> requirement that qmake will continue working as a build system for our
> users at least for the foreseeable future. This can and will be solved by
> cmake creating the required files to support qmake. Btw, this is also a
> hard requirement to be able to change build system repository by
> repository, so that we don’t have to do a all or nothing switch of all our
> repos.
 
> In summary, I do agree with and support the initial proposal by Simon to
> merge wip/cmake into wip/qt6.
 
> Cheers,
> Lars
> 
> 
> > On 6 Jun 2019, at 14:43, Sérgio Martins  wrote:
> > 
> > On Thu, Jun 6, 2019 at 12:45 PM Simon Hausmann 
> > wrote:
> 
> >> 
> >> Hi,
> >> 
> >> In the past months we, some developers from the Qt Company and KDAB,
> >> have made good progress on the port of Qt to use CMake as build tool.
> > 
> > 
> > +1, simply because we only have 1 contender so far.
> > 
> > Thanks for stepping up and doing the work.
> > 
> > Regards,
> > Sérgio Martins
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development



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

Re: [Development] Proposing CMake as build tool for Qt 6

[Lars Knoll]

Hi all,

After all the discussion, lets go back to the original proposal. We can see 
from the discussions that there is still work to be done, but I can’t find 
anything that sounds like a real showstopper.

The two missing features that were voiced as a concern (if I didn’t miss 
anything in the thread) where multi arch/fat binary support for iOS and PCH 
support. I also heard that the people working on it are confident they can get 
this fixed in time for Qt 6, something I’m happy with for now. Nevertheless, I 
think it would be good if the team working on the cmake port could summarise 
how/when they are planning to fix this.

One additional concern was multi arch builds for Android, but I don’t think 
that counts as a concern as qmake does not support this neither (so it would be 
a new feature).

Finally, there was a concern around qmake support for users of Qt. This is 
something I have discussed with the team in the past, and it is a strong 
requirement that qmake will continue working as a build system for our users at 
least for the foreseeable future. This can and will be solved by cmake creating 
the required files to support qmake. Btw, this is also a hard requirement to be 
able to change build system repository by repository, so that we don’t have to 
do a all or nothing switch of all our repos.

In summary, I do agree with and support the initial proposal by Simon to merge 
wip/cmake into wip/qt6.

Cheers,
Lars

> On 6 Jun 2019, at 14:43, Sérgio Martins  wrote:
> 
> On Thu, Jun 6, 2019 at 12:45 PM Simon Hausmann  wrote:
>> 
>> Hi,
>> 
>> In the past months we, some developers from the Qt Company and KDAB,
>> have made good progress on the port of Qt to use CMake as build tool.
> 
> +1, simply because we only have 1 contender so far.
> 
> Thanks for stepping up and doing the work.
> 
> Regards,
> Sérgio Martins
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

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

Re: [Development] unique_ptr and Qt, Take 2

[Marco Bubke]

On June 12, 2019 23:13:14 Matthew Woehlke  wrote:
>> me here. I think Daniel is on to something and we really should explore
>> having smart pointers in Qt 6, but at this point I'm not convinced
>> std::unique_ptr alone is it. I'd like to see what we could achieve with a
>> QObject-specific smart pointer that understood ownership-taking functions
>> (setParent, addWidget, etc.) and observing-only API (like connect()).
>
> Idea: make this hypothetical pointer be a QObject that initially "owns"
> the object to which it points. If the object is reparented, the pointer
> will stop "owning" it but will still have the reference.
Can you implement it so that it fits owner? One of the purposes is that the 
static analysis can be sure about the ownership.

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