Hi,
The CI still uses qmake to build the examples projects, to make sure that we
don't lose coverage of using qmake for application development (which is
different from building Qt).
That's been tested to work for all repos that are part of qt5, but i guess we
missed checking the addon librari
Some configurations still seem to use qmake for some parts:
https://testresults.qt.io/logs/qt/qt3d/5ef6de3b5deb13254200c1f385ce09008b287760/MacOSMacOS_10_14x86_64MacOSMacOS_10_14x86_64Clangqtci-macos-10.14-x86_64-f695c4DisableTests_Sccache/67c64555fe39a6412f13f7c4d92663fc0c175a7b/build_1607682919/l
Hi,
qmake Qt builds have been disabled in the CI and in configure.
Regards,
Alex.
> On 8. Dec 2020, at 17:51, Alexandru Croitor wrote:
>
> Hi again,
>
> A short update on the build system switch.
>
> Sine my last email (half a year ago) a number of issues were raised that we
> had to tackle
Awesome work!! 😊
Cheers,
Tor Arne
On 8 Dec 2020, at 17:51, Alexandru Croitor
mailto:alexandru.croi...@qt.io>> wrote:
Hi again,
A short update on the build system switch.
Sine my last email (half a year ago) a number of issues were raised that we had
to tackle in order to consider switching Q
Hi again,
A short update on the build system switch.
Sine my last email (half a year ago) a number of issues were raised that we had
to tackle in order to consider switching Qt's main build system to CMake.
Some of those issues were tracked in the following JIRA issues
https://bugreports.qt.io/
Hi everyone,
An update on the build system switch.
On the 8th of June I mentioned that we wanted to make the "CMake build system"
the main one and remove the .pro files.
The tentative date was 1st of July (today).
As a result of the discussion, we identified some items that had to be tackled
Am 08.06.20 um 15:43 schrieb Alexandru Croitor:
> Hi everyone,
>
> It's time to talk about everyone's favourite topic again: build systems.
>
> It's been a while since we started porting and merging the CMake ports of Qt
> repositories into the dev branches.
>
> To be precise: qtbase got merge
Am 10.06.20 um 18:28 schrieb Thiago Macieira:
> On Wednesday, 10 June 2020 04:35:51 PDT Dominik Holland wrote:
>>> Strictly speaking, you don't have to build Qt twice. You can use your
>>> system's packaged Qt, or Conan or Homebrew or one of the binary builds
>>> from qt.io as the other. If you do
On Wednesday, 10 June 2020 19:46:22 PDT Thiago Macieira wrote:
> On Wednesday, 10 June 2020 13:37:02 PDT Alexandru Croitor wrote:
> > > Ditto for macOS. A multi-arch x86_64 build would be welcome (x86_64 and
> > > x86_64h).
> >
> > I think that would be a new feature request, given we don't do it
On Wednesday, 10 June 2020 13:37:02 PDT Alexandru Croitor wrote:
> > Ditto for macOS. A multi-arch x86_64 build would be welcome (x86_64 and
> > x86_64h).
>
> I think that would be a new feature request, given we don't do it currently
> in qmake land.
More like a post-build action to merge the bi
On 10. Jun 2020, at 18:13, Thiago Macieira wrote:
>
> On Wednesday, 10 June 2020 00:44:48 PDT Alexandru Croitor wrote:
>> It is. Building Qt targeting Android with CMake works, but you only get one
>> architecture (arm64 for example) in a single build tree, instead of more
>> than one (arm64, arm
On Wednesday, 10 June 2020 04:35:51 PDT Dominik Holland wrote:
> > Strictly speaking, you don't have to build Qt twice. You can use your
> > system's packaged Qt, or Conan or Homebrew or one of the binary builds
> > from qt.io as the other. If you don't intend to develop it, you can use
> > the reg
On Tuesday, 9 June 2020 23:07:55 PDT Bogdan Vatra via Development wrote:
> > The whole point of not bootstrapping the tools for cross compilation is to
> > remove as much as we can of the bootstrapping. Right now in 5.15, the only
> > tools that really need bootstrapping are qmake and moc. And for
On Wednesday, 10 June 2020 00:44:48 PDT Alexandru Croitor wrote:
> It is. Building Qt targeting Android with CMake works, but you only get one
> architecture (arm64 for example) in a single build tree, instead of more
> than one (arm64, armv7, x86, x64) like you used to when building with
> qmake.
On 09/06/2020 14.38, Thiago Macieira wrote:
On Tuesday, 9 June 2020 00:27:35 PDT Shawn Rutledge wrote:
FWIW the configuration mechanism seems a bit less friendly so far with all
those -DSHOUTED options like -DFEATURE_developer_build=ON instead of
configure -developer-build.
The syntax of CMake
Am 6/9/20 um 8:34 PM schrieb Thiago Macieira:
> On Tuesday, 9 June 2020 05:52:30 PDT Alexandru Croitor wrote:
>>> I'm using qmake for Qt6 when I'm doing Android work, also for this reason.
>>> I don't want to build Qt twice just to use a "cool and superior" build
>>> system.
>> Unfortunately that
On 10. Jun 2020, at 04:39, André Pönitz wrote:
>> [...] at least in the early phases of a bisection one has to find out
>> what setup has to used to build a module, too.
Alexandru Croitor (10 June 2020 09:44) replied:
> Yes. But how could we improve this really? Do we create some file in
> the ro
> On 10. Jun 2020, at 04:39, André Pönitz wrote:
>
>> Here you can see the configurations that are rested currently in Coin.
>>
>> https://code.qt.io/cgit/qt/qt5.git/tree/coin/platform_configs/qtsvg.yaml
>> (svg is
>> just an example)
>>
>> So desktop Ubuntu, static qt builds on Suse, macOS
On 6/10/20 4:39 AM, André Pönitz wrote:
Android multi-ABI is currently not implemented, and we don't plan to do it for
6.0.
Isn't Android support part of qtbase?
It is. Android multi-ABI is "building Qt for Android for multiple ABIs
in one go" instead of "building Qt per ABI". The former wa
> On 10. Jun 2020, at 03:35, Lorn Potter wrote:
>
>
>
> On 9/6/20 11:23 PM, Alexandru Croitor wrote:
>>> - WebAssembly completely lost
>> That is true. As I mentioned in my reply to Andre, we tested it at some
>> point, but we don't have current plans to add it to the CI.
>
> I would be sur
On Tue, Jun 09, 2020 at 08:06:57AM +, Alexandru Croitor wrote:
> > On 9. Jun 2020, at 04:32, André Pönitz wrote:
> >
> > On Mon, Jun 08, 2020 at 01:43:20PM +, Alexandru Croitor wrote:
> >> [...]
> >> The CMake ports are built in Coin with the most important configurations
> >> (Linux, Win
În ziua de marți, 9 iunie 2020, la 21:31:17 EEST, Thiago Macieira a scris:
> On Tuesday, 9 June 2020 01:26:12 PDT Alexandru Croitor wrote:
> > > On 9. Jun 2020, at 10:17, Jean-Michaël Celerier
> > > wrote:
> > >
> > > To simplify this step, is there / could there be maybe a
> > > -DQT_BUILD_TOOLS
On 9/6/20 11:23 PM, Alexandru Croitor wrote:
- WebAssembly completely lost
That is true. As I mentioned in my reply to Andre, we tested it at some point,
but we don't have current plans to add it to the CI.
I would be surprised if it actually built, as emscripten compiler for Qt
WebAssemb
On Tuesday, 9 June 2020 01:26:12 PDT Alexandru Croitor wrote:
> > On 9. Jun 2020, at 10:17, Jean-Michaël Celerier
> > wrote:
> >
> > To simplify this step, is there / could there be maybe a
> > -DQT_BUILD_TOOLS_ONLY that would just generate... well, moc, uic, rcc and
> > a couple other friends re
On Tuesday, 9 June 2020 05:52:30 PDT Alexandru Croitor wrote:
> > I'm using qmake for Qt6 when I'm doing Android work, also for this reason.
> > I don't want to build Qt twice just to use a "cool and superior" build
> > system.
> Unfortunately that workflow will not work anymore.
Strictly speaking
On Tuesday, 9 June 2020 00:27:35 PDT Shawn Rutledge wrote:
> FWIW the configuration mechanism seems a bit less friendly so far with all
> those -DSHOUTED options like -DFEATURE_developer_build=ON instead of
> configure -developer-build.
The syntax of CMake was why KDE decided in 2004 not to use CM
Den tis 9 juni 2020 kl 16:30 skrev Matthew Woehlke :
>
> On 09/06/2020 03.55, Joerg Bornemann wrote:
> > The description of QT_NO_MAKE_TESTS is: "Should tests be built as part
> > of the default 'all' target." Meaning this variable controls whether
> > tests are build by default.
>
> Might I sugges
On 09/06/2020 05.05, Alexandru Croitor wrote:
On 09/06/2020 04.38, Shawn Rutledge wrote: >> At least json is easier to parse, if we try to write other tooling.>
> That's true. But using tooling to forever generate cmake files from
json also comes with its downsides (maintenance, inability to ex
On 9. Jun 2020, at 16:30, Matthew Woehlke wrote:
>
> On 09/06/2020 03.55, Joerg Bornemann wrote:
>> The description of QT_NO_MAKE_TESTS is: "Should tests be built as part of
>> the default 'all' target." Meaning this variable controls whether tests are
>> build by default.
>
> Might I suggest
On 09/06/2020 03.27, Shawn Rutledge wrote:
FWIW the configuration mechanism seems a bit less friendly so far
with all those -DSHOUTED options like -DFEATURE_developer_build=ON
instead of configure -developer-build. But there is cmake-gui, which
generates checkboxes for all the options after you
> On 9. Jun 2020, at 16:09, Alex Blasche wrote:
>
>
> Again this question was referring to the "build Qt module" with CMake Qt (aka
> your Webengine experiment). Not updating the dependencies is not desired at
> all.
Sorry, I missed that the question was about qmake mixing.
You compile qt
On 09/06/2020 03.55, Joerg Bornemann wrote:
The description of QT_NO_MAKE_TESTS is: "Should tests be built as part
of the default 'all' target." Meaning this variable controls whether
tests are build by default.
Might I suggest a less obtuse name? Something along the lines of
QT_TESTS_EXCLUDE
> -Original Message-
> From: Alexandru Croitor
> > Could you share details how this is done?
>
> Which part?
> First we'd have to remove all qmake configs in qt5.git/coin/platform_configs,
> leaving just the cmake ones.
> Once that's integrated, we can push & stage changes that remove
> On 9. Jun 2020, at 13:56, Alex Blasche wrote:
>
>
> Could you share details how this is done?
Which part?
First we'd have to remove all qmake configs in qt5.git/coin/platform_configs,
leaving just the cmake ones.
Once that's integrated, we can push & stage changes that remove .pro files.
> On 9. Jun 2020, at 13:25, Bogdan Vatra via Development
> wrote:
>
> But how can I send a fix to a .pr* file in dev if that file doesn't exists
> anymore in dev? In this case should we send the patches directly to 5.15. and
> add the "Cherry-pick: dev" thing to the patch message?
I think t
> On 9. Jun 2020, at 13:20, Shawn Rutledge wrote:
>
>
>> On 2020 Jun 9, at 11:05, Alexandru Croitor wrote:
>>
>>> On 9. Jun 2020, at 10:38, Shawn Rutledge wrote:
>>>
>>> Well that’s a little extra maintenance work then; I agree that configure is
>>> nicer, but maybe we can expect the cmak
> On 9. Jun 2020, at 12:07, Bogdan Vatra wrote:
>
> Hi,
> În ziua de marți, 9 iunie 2020, la 11:13:21 EEST, Alexandru Croitor a scris:
>>> On 9. Jun 2020, at 07:22, Bogdan Vatra wrote:
>>>
>>> - is it possible to cross compile Qt in one go (just like we do with
>>> qmake)?
>> Could you clarif
> On 9. Jun 2020, at 11:36, Edward Welbourne wrote:
>
> Alexandru Croitor (9 June 2020 10:41)
>> I'll acknowledge that the current Qt Creator <-> Build Qt with CMake
>> situation is sub-par.
>
> Is there a P1 ticket open about that ?
> Might even warrant P0, given ...
I created a bug report
Hi,
Am Dienstag, 9. Juni 2020, 12:07:02 CEST schrieb Bogdan Vatra via Development:
> I'm using qmake for Qt6 when I'm doing Android work, also for this reason.
> I don't want to build Qt twice just to use a "cool and superior" build system.
>
> Just out of curiosity, can some pretty please remind
> -Original Message-
> From: Development On Behalf Of
> Alexandru Croitor
> -> TL;DR here
> <
>
> The CMake Port team wants to switch the main Qt build system to the CMake
> one.
>
> What this means:
>
> - All Coin
În ziua de marți, 9 iunie 2020, la 13:46:48 EEST, Edward Welbourne a scris:
> On 6/9/20 7:22 AM, Bogdan Vatra via Development wrote:
> >>> - if you'll not support/trash all .pro/.pri files how we'll push
> >>> fixes for 5.15 branch ? Because right now we can't push fixes
> >>> directly to 5.15. br
> On 2020 Jun 9, at 11:05, Alexandru Croitor wrote:
>
>> On 9. Jun 2020, at 10:38, Shawn Rutledge wrote:
>>
>> Well that’s a little extra maintenance work then; I agree that configure is
>> nicer, but maybe we can expect the cmake way of configuring to generally be
>> more up-to-date if that
On 6/9/20 7:22 AM, Bogdan Vatra via Development wrote:
>>> - if you'll not support/trash all .pro/.pri files how we'll push
>>> fixes for 5.15 branch ? Because right now we can't push fixes
>>> directly to 5.15. branch and all the fixes must go trough dev
>>> branch first.
În ziua de marți, 9 iun
> On Jun 9, 2020, at 12:07, Eike Ziller wrote:
>
>
>
>> On Jun 9, 2020, at 09:59, Andy Nichols wrote:
>>
>> Hi Alexandru,
>>
>> I think Brett touches on the biggest blocker for me and that is actually
>> related to Qt Creators ability to open and use modules built using cmake. I
>> am a
În ziua de marți, 9 iunie 2020, la 10:35:33 EEST, Joerg Bornemann a scris:
> On 6/9/20 7:22 AM, Bogdan Vatra via Development wrote:
> > - is it possible to cross compile Qt in one go (just like we do with
> > qmake)?
> Assuming you're talking about the multi-ABI Android build you've added
> to Qt5.
> On Jun 9, 2020, at 09:59, Andy Nichols wrote:
>
> Hi Alexandru,
>
> I think Brett touches on the biggest blocker for me and that is actually
> related to Qt Creators ability to open and use modules built using cmake. I
> am actually really impressed with state of the CMake support for bui
Hi,
În ziua de marți, 9 iunie 2020, la 11:13:21 EEST, Alexandru Croitor a scris:
> > On 9. Jun 2020, at 07:22, Bogdan Vatra wrote:
> >
> > - is it possible to cross compile Qt in one go (just like we do with
> > qmake)?
> Could you clarify what you mean by "in one go"?
>
> If it's about building
Hi,
"Putting that aside, how long should we wait then? " is exactly the question we
would like to find the answer to __
My own preference is to make the switch to CMake as soon as possible and use
effort to improving the CMake port instead of keeping the qmake as a parallel
build system for Q
Alexandru Croitor (9 June 2020 10:41)
> I'll acknowledge that the current Qt Creator <-> Build Qt with CMake
> situation is sub-par.
Is there a P1 ticket open about that ?
Might even warrant P0, given ...
> We have to bite the bullet at some point.
In particular, the "Structure and platform fre
> On 9. Jun 2020, at 10:38, Shawn Rutledge wrote:
>
> Well that’s a little extra maintenance work then; I agree that configure is
> nicer, but maybe we can expect the cmake way of configuring to generally be
> more up-to-date if that’s where each change starts.
Up-to-date how?
Are you sugge
Hi Andy,
I'll acknowledge that the current Qt Creator <-> Build Qt with CMake situation
is sub-par.
Though, I believe there is a sketchy config to allow you to use a released Qt
Creator to develop Qt.
Putting that aside, how long should we wait then?
I'm not sure if we can afford to delay t
> On 2020 Jun 9, at 10:21, Alexandru Croitor wrote:
>
>> On 9. Jun 2020, at 09:27, Shawn Rutledge wrote:
>>
>> FWIW the configuration mechanism seems a bit less friendly so far with all
>> those -DSHOUTED options like -DFEATURE_developer_build=ON instead of
>> configure -developer-build. Bu
real
> solution is in place.
>
> Regards,
> Andy Nichols
>
> -Original Message-
> From: Development On Behalf Of
> Stottlemyer, Brett (B.S.)
> Sent: Monday, June 8, 2020 6:48 PM
> To: Alexandru Croitor
> Cc: Qt development mailing list
> Subj
> On 9. Jun 2020, at 10:17, Jean-Michaël Celerier
> wrote:
>
> To simplify this step, is there / could there be maybe a
> -DQT_BUILD_TOOLS_ONLY that would just generate... well, moc, uic, rcc and a
> couple other friends required for a cross-build ?
I think that should technically be possib
> On 9. Jun 2020, at 09:27, Shawn Rutledge wrote:
>
> FWIW the configuration mechanism seems a bit less friendly so far with all
> those -DSHOUTED options like -DFEATURE_developer_build=ON instead of
> configure -developer-build. But there is cmake-gui, which generates
> checkboxes for all
To simplify this step, is there / could there be maybe a
-DQT_BUILD_TOOLS_ONLY that would just generate... well, moc, uic, rcc and a
couple other friends required for a cross-build ?
Best,
Jean-Michaël
On Tue, Jun 9, 2020 at 10:14 AM Alexandru Croitor
wrote:
>
>
> > On 9. Jun 2020, at 07:22, B
> On 9. Jun 2020, at 07:22, Bogdan Vatra wrote:
>
> - is it possible to cross compile Qt in one go (just like we do with qmake)?
Could you clarify what you mean by "in one go"?
If it's about building host tools as part of the cross-compilation, then no.
You first have to build a desktop Qt,
> On 9. Jun 2020, at 04:32, André Pönitz wrote:
>
> On Mon, Jun 08, 2020 at 01:43:20PM +, Alexandru Croitor wrote:
>> [...]
>> The CMake ports are built in Coin with the most important configurations
>> (Linux, Windows, macOS, Android, iOS, qemu Linux).
>
> Is there a list of configuration
lemyer, Brett (B.S.)
Sent: Monday, June 8, 2020 6:48 PM
To: Alexandru Croitor
Cc: Qt development mailing list
Subject: Re: [Development] Switch the main "Qt Build System"
Hi Alexandru,
Thanks for the quick reply.
On 6/8/20, 12:09 PM, "Alexandru Croitor" wrote:
The curr
> -Ursprüngliche Nachricht-
> Von: Development Im Auftrag von
> [...]
> To build autotests, -DFEATURE_developer_build=ON will do that right? And
> there are also BUILD_TESTING and QT_NO_MAKE_TESTS so what’s the
> relationship?
It's currently the same as with qt 5:
* FEATURE_developer_
On 6/9/20 9:27 AM, Shawn Rutledge wrote:
FWIW the configuration mechanism seems a bit less friendly so far with all
those -DSHOUTED options like -DFEATURE_developer_build=ON instead of configure
-developer-build. But there is cmake-gui, which generates checkboxes for all
the options after yo
> On 8. Jun 2020, at 18:47, Stottlemyer, Brett (B.S.) wrote:
>
> Hi Alexandru,
>
> Thanks for the quick reply.
>
> On 6/8/20, 12:09 PM, "Alexandru Croitor" wrote:
>
>The current CMake configurations can be found in
> qt5.git/coin/platform_configs/qtsvg.yaml (and many other .yaml files
On Tue, 9 Jun 2020 at 10:35, Ville Voutilainen
wrote:
>
> On Tue, 9 Jun 2020 at 10:29, Shawn Rutledge wrote:
> >
> > FWIW the configuration mechanism seems a bit less friendly so far with all
> > those -DSHOUTED options like -DFEATURE_developer_build=ON instead of
> > configure -developer-build
On Tue, 9 Jun 2020 at 10:29, Shawn Rutledge wrote:
>
> FWIW the configuration mechanism seems a bit less friendly so far with all
> those -DSHOUTED options like -DFEATURE_developer_build=ON instead of
> configure -developer-build. But there is cmake-gui, which generates
> checkboxes for all th
On 6/9/20 7:22 AM, Bogdan Vatra via Development wrote:
- is it possible to cross compile Qt in one go (just like we do with qmake)?
Assuming you're talking about the multi-ABI Android build you've added
to Qt5. This is not yet implemented, but certainly possible with the
Ninja Multi-Config g
FWIW the configuration mechanism seems a bit less friendly so far with all
those -DSHOUTED options like -DFEATURE_developer_build=ON instead of configure
-developer-build. But there is cmake-gui, which generates checkboxes for all
the options after you have run cmake the first time. They are e
Hi,
I have a few questions:
- is it possible to cross compile Qt in one go (just like we do with qmake)?
- if you'll not support/trash all .pro/.pri files how we'll push fixes for 5.15
branch ? Because right now we can't push fixes directly to 5.15. branch and all
the fixes must go trough dev br
Hi Alexandru,
Thanks for the quick reply.
On 6/8/20, 12:09 PM, "Alexandru Croitor" wrote:
The current CMake configurations can be found in
qt5.git/coin/platform_configs/qtsvg.yaml (and many other .yaml files there,
it's just copy-pasted).
Ahh, I didn't understand what these module spec
Hi,
Replying inline.
> On 8. Jun 2020, at 17:53, Stottlemyer, Brett (B.S.) wrote:
>
> Hi Alexandru,
>
> On 6/8/20, 9:45 AM, "Development on behalf of Alexandru Croitor"
>
> wrote:
>
>The CMake ports are built in Coin with the most important configurations
> (Linux, Windows, macOS, An
Hi Alexandru,
On 6/8/20, 9:45 AM, "Development on behalf of Alexandru Croitor"
wrote:
The CMake ports are built in Coin with the most important configurations
(Linux, Windows, macOS, Android, iOS, qemu Linux).
Are the "official" cmake configs for CI in the qt5 git repo yet
(https://code
u Croitor
> Gesendet: Montag, 8. Juni 2020 15:43
> An: Qt development mailing list
> Betreff: [Development] Switch the main "Qt Build System"
>
> Hi everyone,
>
> It's time to talk about everyone's favourite topic again: build systems.
>
> It&#x
__
Von: Development im Auftrag von Alexandru
Croitor
Gesendet: Montag, 8. Juni 2020 15:43
An: Qt development mailing list
Betreff: [Development] Switch the main "Qt Build System"
Hi everyone,
It's time to talk about everyone's favourite topic again: build systems.
It&#
Hi everyone,
It's time to talk about everyone's favourite topic again: build systems.
It's been a while since we started porting and merging the CMake ports of Qt
repositories into the dev branches.
To be precise: qtbase got merged on the 7th of February.
Since then, all the enabled repositor
73 matches
Mail list logo
