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
11.06.2020, 01:10, "René J.V. Bertin" :
> Hi,
>
> Suppose I wanted to patch QtWebView so it will use WebKit2 from the rebooted
> QtWebKit libraries instead of the QtWebEngine bloatware, how feasible would
> that be? A rabbithole, a question of reparenting and changing a limited
> number of fun
On Wed, 10 Jun 2020 at 15:26, Lorn Potter wrote:
>
> Hi *,
> On the road to Qt 6, we must remember our past:
> What better way than to have a short break to listen to this worldwide
> hit - The Qt 4 Dance!
>
> https://www.youtube.com/watch?v=NbTEVbQLC8s
>
> --
> Lorn Potter
> Freelance Qt Develope
Hi,
Suppose I wanted to patch QtWebView so it will use WebKit2 from the rebooted
QtWebKit libraries instead of the QtWebEngine bloatware, how feasible would
that be? A rabbithole, a question of reparenting and changing a limited number
of function calls, or pointless because QtWebKit already ha
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
Hi,
FWIW, the page I made just replaced the Qt 4 to Qt 5 porting guide, so I didn't
put any thought into whether we should change the existing structure. As long
as they are accessible from a general "porting" document, I think it is a good
idea to move specifics into their respective modules.
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
Hi!
Qt Purchasing is a convenience API for handling in-app purchases on different
platforms. Qt 6 will go through lots of changes that affect many modules. It is
therefore a good time to reconsider the future of Qt Purchasing API.
One potential pitfall of the API is that apps developed with i
> 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
Hi *,
On the road to Qt 6, we must remember our past:
What better way than to have a short break to listen to this worldwide
hit - The Qt 4 Dance!
https://www.youtube.com/watch?v=NbTEVbQLC8s
--
Lorn Potter
Freelance Qt Developer. Maintainer QtSensors, Qt WebAssembly
__
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
19 matches
Mail list logo
