On Wednesday, 13 February 2019 09:08:58 PST Stephen Kelly via Development
wrote:
> Of course it is easy to create a `Qt5or6::Core` target for transitional use
> and get all the benefits.
>
> target_link_libraries(mything PRIVATE Qt5or6::Core)
That should plain be Qt::Core, which is the same as Q
> -Original Message-
> From: Development On Behalf Of
> Thiago Macieira
> Sent: Wednesday 13 February 2019 16:36
> To: development@qt-project.org
> Subject: Re: [Development] CMake Workshop Summary
>
> On Wednesday, 13 February 2019 05:58:18 PST Kevin Funk via Development
> wrote:
> > T
On Wednesday, 13 February 2019 05:58:18 PST Kevin Funk via Development wrote:
> The problem is, besides the reasons Simon mentioned, that just using "Qt" as
> the package prefix will make it more difficult for distros to co-install
> the CMake config files for different Qt versions.
>
> Still all
On Wednesday, 13 February 2019 02:22:15 PST Vitaly Fanaskov wrote:
> It's not clear why you included version to a package name (e.g. Qt5/Qt6).
> With CMake you can pass a version as the second argument, e.g.:
> find_package(Qt 5.12) Perhaps it would be better, what do you think?
Because applicatio
On Wednesday, 13 February 2019 02:06:13 PST Simon Hausmann wrote:
> (2) Have a super-project that allows building all of Qt with one call to
> "cmake", a call to "cmake --build" and finally "$maketool install".
>
> The latter has not been "developed" yet but I think it's necessary to allow
> f
> I think the ability to compile an application with Qt 5 or 6 and the same
> build system is of critical importance for the success of Qt 6.
Certainly. We had the same requirement with Qt 4+5 and had a solution for it.
I'm wondering if you considered alternatives to what you're going to do and
> On 13 Feb 2019, at 16:21, Tor Arne Vestbø wrote:
>
> Or, when building a distro-spesific package foo that depends on qt 5.12, the
> distro would set CMAKE_PREFIX_PATH to the correct prefix.
>
> I think the latter is what Homebrew does.
At least I think it does this for pkg-config.
Tor Arn
> On 13 Feb 2019, at 16:13, Kevin Funk wrote:
>
> On Wednesday, 13 February 2019 15:40:15 CET Tor Arne Vestbø wrote:
>>> On 13 Feb 2019, at 14:58, Kevin Funk via Development
>>> wrote:
>
>>> make it more difficult for distros to co-install the CMake config files
>>> for different Qt versions.
On Wednesday, 13 February 2019 15:40:15 CET Tor Arne Vestbø wrote:
> > On 13 Feb 2019, at 14:58, Kevin Funk via Development
> > wrote:
> > make it more difficult for distros to co-install the CMake config files
> > for different Qt versions.
>
> This sounds like a generally useful feature for d
> On 13 Feb 2019, at 14:58, Kevin Funk via Development
> wrote:
>
> make it more difficult for distros to co-install the CMake config files for
> different Qt versions.
This sounds like a generally useful feature for distros to have, not just for
major versions but for minor etc too?
I gue
On Wednesday, 13 February 2019 11:22:15 CET Vitaly Fanaskov wrote:
> Hi Simon,
>
>
> Thank you for the update.
>
>
> It's not clear why you included version to a package name (e.g. Qt5/Qt6).
> With CMake you can pass a version as the second argument, e.g.:
> find_package(Qt 5.12)
Heya,
We in
Another +1. Great that you’re taking this Rebecca :)
Cheers,
Lars
> On 13 Feb 2019, at 14:14, Laszlo Agocs wrote:
>
>
> +1
>
> Cheers,
> Laszlo
>
> -Original Message-
> From: Development On Behalf Of Eskil
> Abrahamsen Blomfeldt
> Sent: onsdag 13. februar 2019 07.21
> To: developme
+1
Cheers,
Laszlo
-Original Message-
From: Development On Behalf Of Eskil
Abrahamsen Blomfeldt
Sent: onsdag 13. februar 2019 07.21
To: development@qt-project.org
Subject: [Development] Nominating Rebecca Worledge for maintainer of Qt Lottie
Hi!
In Qt 5.13 we have added a Qt.labs modu
I think the deliberate design choice to separate Qt4 and 5 visibly in the "API"
(targets) was a wise choice at that point.
For the future and with Qt 6 in mind, I think we should do it differently. I
think the ability to compile an application with Qt 5 or 6 and the same build
system is of cri
Thanks. You’re right, those are desirable commands to use instead of the
concrete tools. Something to keep in mind for the docs :)
Simon
On 13. Feb 2019, at 12:29, Stephen Kelly
mailto:stke...@microsoft.com>> wrote:
> Have a super-project that allows building all of Qt with one call to "cmak
Hi!
Qt 5.13 Alpha is released today, see
https://blog.qt.io/blog/2019/02/13/qt-5-13-alpha-released/
Big thanks to everyone involved!
BR,
Jani Heikkinen
Release Manager
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org
As a deliberate design choice years ago, we put the major version in the
package name because it avoids a class of user errors and confusion, and
because it allows a single buildsystem with targets linking to either Qt 4 or
Qt 5 (CMake ensures that nothing attempts to link to both).
Thanks,
S
> Have a super-project that allows building all of Qt with one call to "cmake",
> a call to "cmake --build" and finally "$maketool install".
Note that instead of "$maketool install" you could recommend the portable
"cmake --build . --target install". I don't think msbuild accepts a 'install'
a
> The plan for allowing people to develop apps that work with Qt 5 and Qt 6 is
> quite simple API wise:
>
> (1) In your application use either find_package(Qt5) or
> find_package(Qt6)
Will this support COMPONENTS? I would never recommend using COMPONENTS because
it can get odd in the ca
That may be possible to implement. It requires the work to be done upstream in
cmake's FindQt.cmake. It also requires maintaining compatibility with Qt 3 and
4. See
https://devdocs.io/cmake~3.12/module/findqt
I suggest for you to get in touch with the CMake developers to see what they
thi
Hi Simon,
Thank you for the update.
It's not clear why you included version to a package name (e.g. Qt5/Qt6). With
CMake you can pass a version as the second argument, e.g.: find_package(Qt 5.12)
Perhaps it would be better, what do you think?
On 2/13/19 10:33 AM, Simon Hausmann wrote:
Hi,
A non-prefix build that can be used from the outside is not something that any
of us working on this is implementing right now. I think that it may be
possible to implement (https://devdocs.io/cmake~3.12/command/export ).
Volunteers welcome :)
Simon
From: Tor
> On 13 Feb 2019, at 11:06, Simon Hausmann wrote:
>
> (1) Build a repo, install it, build the next repo, install it, etc.
Will there be a -developer-build option that doesn’t require install?
Tor Arne
___
Development mailing list
Development@qt-pr
We briefly discussed the topic and it's my understanding that an agreement
exists to support two types of builds:
(1) Build a repo, install it, build the next repo, install it, etc.
(2) Have a super-project that allows building all of Qt with one call to
"cmake", a call to "cmake --bui
Hi,
Thanks for the write up and summary.
Do you know if there has been any discussion on separate module builds vs qt5
builds?
aka
cd qtbase && cmake && make install && cd qtsvg && cmake && make install
vs
cd qt5 && cmake && make install
?
From: Developme
Hi,
On Monday/Tuesday a bunch of us met at KDAB offices in Berlin to accelerate the
attempt of building Qt with CMake. I'd like to give a brief summary of this
workshop.
Who: Jean-Michaël, Liang, Volker, Mikhail, Kevin, me, Tobias, Kai and Albert.
A very early visible artifact was the creation
Hi,
We have soft branched '5.12.2' from '5.12' now. So all new changes targeted to
Qt 5.12.2 release should be done in '5.12.2'.
Final downmerge from '5.12' to '5.12.2' will happen Wed 20th February and
target is to get the release out at the end of February.
br,
Jani Heikkinen
Release Manager
Cool! +1
> On 13 Feb 2019, at 07:21, Eskil Abrahamsen Blomfeldt
> wrote:
>
> Hi!
>
> In Qt 5.13 we have added a Qt.labs module called "Qt Lottie", with Qt
> Quick APIs for showing scenes and animations that were exported using
> the Bodymovin plugin in After Effects.
>
> https://coderev
28 matches
Mail list logo
