> -Original Message-
> From: Development On Behalf Of
> Volker Hilsheimer
> [...]
> I think that’s by far the exception though. Most 3rd party components we
> use have well defined, stable APIs.
I think it's the other way round, at least if you go by the number of
qt_attribution.json entr
Just to add to the discussion, Qt is clearly adopting Conan as a
first-class "service" [1].
Conan users may know that the "canonical" repos [2] have a lot of effort
put in them to remove exactly this kind of scenarios where libraries
ship their vendored dependencies. Qt is an example of this [
> On 14 Jul 2022, at 13:51, Edward Welbourne wrote:
>
> Volker Hilsheimer (14 July 2022 11:23) wrote:
>> And it makes it in general messy to maintain an overview of those 3rd
>> party components. We have a responsibility to keep track of those,
>
> That's supposed to be handled by qt_attribution
On Thursday, 14 July 2022 04:51:22 PDT Edward Welbourne wrote:
> Aside from the case of duplicated 3rdparty components, I don't really
> see how this would make it easier.
It's not for us. This does indeed add some work to us, but it's meant to make
it easier for everyone downstream of the source
On Thursday, 14 July 2022 04:22:59 PDT Laszlo Agocs wrote:
> 1. Can we assume every single 3rd party library out there has a
> sophisticated build system that builds (or at least allows building after
> appropriate configuration) exactly the way Qt needs, with first class
> cross-compilation and em
On Thursday, 14 July 2022 02:23:47 PDT Volker Hilsheimer wrote:
> As mentioned, this would be a gradual process, one 3rd party dependency at a
> time and figuring out what it takes to make this work on all platforms.
> Some 3rd party code might have to stay where it is today.
And I am partly to b
Volker Hilsheimer (14 July 2022 11:23) wrote:
> Our 3rd party dependencies currently live in the submodules where they
> are used. For some 3rd party components, that means we have two,
> sometimes different copies (e.g. assimp in both Qt Quick 3D and Qt 3D,
> only one of them patched).
Having two
Hi,
> Our 3rd party dependencies currently live in the submodules where they are
> used. For some 3rd party components, that means we have two, sometimes
> different copies (e.g. assimp in both Qt Quick 3D and Qt 3D, only one of them
> patched). And it makes it in general messy to maintain an o
Hi,
Just pointing to some relevant issues and discussions.
https://bugreports.qt.io/browse/QTBUG-68816
https://bugreports.qt.io/browse/QTBUG-73760
https://wiki.qt.io/QtCS2018_Third-Party_Sources_Policy_and_Security
> For us as Qt developers it might mean that we either have to build that 3rd
>
Hi,
Our 3rd party dependencies currently live in the submodules where they are
used. For some 3rd party components, that means we have two, sometimes
different copies (e.g. assimp in both Qt Quick 3D and Qt 3D, only one of them
patched). And it makes it in general messy to maintain an overview
10 matches
Mail list logo
