On 2017-04-25 19:41, Thiago Macieira wrote:
On Tuesday, 25 April 2017 13:39:52 -03 Marc Mutz wrote:
On 2017-04-25 16:34, Lars Knoll wrote:
[...]
> But I agree with Thiago, that we should have this written down in a
> QUIP, ideally with a list of the classes we consider ok to use in our
> APIs.
On Tuesday, 25 April 2017 14:30:50 -03 André Pönitz wrote:
> > Why does it need to be versioned on a per-branch basis? Because of when we
> > deprecate older compilers, we can update the list?
>
> Since the rules will likely differ per branch I actually think it's
> a good idea to have the rules c
On Tue, Apr 25, 2017 at 02:41:19PM -0300, Thiago Macieira wrote:
> On Tuesday, 25 April 2017 13:39:52 -03 Marc Mutz wrote:
> > On 2017-04-25 16:34, Lars Knoll wrote:
> > [...]
> >
> > > But I agree with Thiago, that we should have this written down in a
> > > QUIP, ideally with a list of the class
On Tuesday, 25 April 2017 13:39:52 -03 Marc Mutz wrote:
> On 2017-04-25 16:34, Lars Knoll wrote:
> [...]
>
> > But I agree with Thiago, that we should have this written down in a
> > QUIP, ideally with a list of the classes we consider ok to use in our
> > APIs.
>
> [...]
>
> I'd make the QUIP d
On 2017-04-25 16:34, Lars Knoll wrote:
[...]
But I agree with Thiago, that we should have this written down in a
QUIP, ideally with a list of the classes we consider ok to use in our
APIs.
[...]
I'd make the QUIP define the updated BC guarantee. The list of std types
available for use in Qt AP
On 25 April 2017 at 17:34, Lars Knoll wrote:
>
>> On 25 Apr 2017, at 15:51, Thiago Macieira wrote:
>>
>> Em terça-feira, 25 de abril de 2017, às 07:59:03 -03, Marc Mutz escreveu:
>>> What's holding us back?
>>
>> At this point, inertia.
>>
>> I've already lifted my objection in the grounds that n
> On 25 Apr 2017, at 15:51, Thiago Macieira wrote:
>
> Em terça-feira, 25 de abril de 2017, às 07:59:03 -03, Marc Mutz escreveu:
>> What's holding us back?
>
> At this point, inertia.
>
> I've already lifted my objection in the grounds that no one in the Linux
> sphere cares about compatibili
Em terça-feira, 25 de abril de 2017, às 07:59:03 -03, Marc Mutz escreveu:
> What's holding us back?
At this point, inertia.
I've already lifted my objection in the grounds that no one in the Linux
sphere cares about compatibility between libstdc++ and libc++ without a
"rebuild the world" step.
On Tuesday 14 March 2017 11:32:39 Olivier Goffart wrote:
> On Dienstag, 14. März 2017 10:33:44 CET Simon Hausmann wrote:
> > Hi,
> >
> >
> > I understand that there are limitations (to put it mildly) regarding the
> > use of API from the C++ standard library in Qt API itself due to the
> > inabil
Earlier, Thiago said:
>>> The point however is that if libstdc++ does break its ABI, then
>>> you'll have to rebuild half the world anyway. The few libraries and
>>> applications that did use Qt and were not affected would be the
>>> minority. Telling them apart could be a higher cost than just
>>>
On quinta-feira, 23 de março de 2017 12:13:09 PDT Lisandro Damián Nicanor
Pérez Meyer wrote:
> > The point however is that if libstdc++ does break its ABI, then you'll
> > have
> > to rebuild half the world anyway. The few libraries and applications that
> > did use Qt and were not affected would
On lunes, 20 de marzo de 2017 12:11:17 -03 Thiago Macieira wrote:
> Em segunda-feira, 20 de março de 2017, às 11:53:50 PDT, Lisandro Damián
>
> Nicanor Pérez Meyer escreveu:
> > In the (2) case it will mean that we distro packagers will be forced to
> > change Qt's SONAME. Yeah, the whole of it.
>
Em segunda-feira, 20 de março de 2017, às 11:53:50 PDT, Lisandro Damián
Nicanor Pérez Meyer escreveu:
> In the (2) case it will mean that we distro packagers will be forced to
> change Qt's SONAME. Yeah, the whole of it.
Why? We're not changing our ABI. To be clear: we're not proposing replacing
On martes, 14 de marzo de 2017 11:32:39 -03 Olivier Goffart wrote:
[snip]
> So here are the choice:
>
> 1- Re-implement QFunction, with similar semantic as std::function.
>
> 2- Lift the constraint that we can't use the stdlib in our ABI
>
> 3- Do nothing and keep using awkward interface when
Em sexta-feira, 17 de março de 2017, às 09:25:04 PDT, Matthew Woehlke
escreveu:
> > We are not talking about security problems. What is wrong with running a
> > half-year, or worst case maybe even a two year old version of some library
> > as base for the bulk of the applications?
>
> No bug fixe
Em sexta-feira, 17 de março de 2017, às 13:02:36 PDT, Marc Mutz escreveu:
> On Friday 17 March 2017 17:16:39 Thiago Macieira wrote:
> > Em sexta-feira, 17 de março de 2017, às 03:31:23 PDT, Marc Mutz escreveu:
> > > provided the same external libraries, and the same toolchain are used to
> > > buil
On Friday 17 March 2017 17:16:39 Thiago Macieira wrote:
> Em sexta-feira, 17 de março de 2017, às 03:31:23 PDT, Marc Mutz escreveu:
> > provided the same external libraries, and the same toolchain are used to
> > build the two Qt releases.
> The problem is this line here. People expect to upgrade o
On 2017-03-17 12:17, Thiago Macieira wrote:
> Em sexta-feira, 17 de março de 2017, às 02:43:05 PDT, Tobias Hunger escreveu:
>> A distribution will not update the standard c++ library within a distro
>> release.
>> Neither will a distribution upgrade Qt minor versions within a
>> distro release.
>
On 2017-03-16 19:26, André Pönitz wrote:
> On Thu, Mar 16, 2017 at 01:23:55PM -0400, Matthew Woehlke wrote:
>> On 2017-03-14 13:33, André Pönitz wrote:
>>> In general, I am not overly sold on ABI compatibility promises. I personally
>>> could live without and find SC of more practical value. The mo
Em sexta-feira, 17 de março de 2017, às 02:43:05 PDT, Tobias Hunger escreveu:
> A distribution will not update the standard c++ library within a distro
> release.
> Neither will a distribution upgrade Qt minor versions within a
> distro release.
Both assertions are incorrect.
--
Thiago Macieira
Em sexta-feira, 17 de março de 2017, às 03:31:23 PDT, Marc Mutz escreveu:
> provided the same external libraries, and the same toolchain are used to
> build the two Qt releases.
The problem is this line here. People expect to upgrade other libraries. We
should say that we guarantee our ABI provid
On Friday 17 March 2017 10:19:10 Ulf Hermann wrote:
> Let's just allow standard library types in Qt, and document that the BC
> guarantee only extends across compatible standard libraries.
The Qt BC guarantee should only cover Qt. It should explicitly exclude
compiler switches, libc, stdlib, boos
On Thu, 2017-03-16 at 13:23 -0400, Matthew Woehlke wrote:
> On 2017-03-14 13:33, André Pönitz wrote:
> > In general, I am not overly sold on ABI compatibility promises. I personally
> > could live without and find SC of more practical value. The most important
> > "feature" of ABI compatibility gua
On 17.03.2017 06:39, Thiago Macieira wrote:
> Em quinta-feira, 16 de março de 2017, às 16:26:20 PDT, André Pönitz escreveu:
>> On Thu, Mar 16, 2017 at 01:23:55PM -0400, Matthew Woehlke wrote:
>>> On 2017-03-14 13:33, André Pönitz wrote:
In general, I am not overly sold on ABI compatibility pro
> All that more or less already applies to the standard library however
> (probably most distros don't accept a standard library BC break without
> a mass rebuild anyway), so Qt insulating against BC breaks in the
> standard library is maybe less necessary.
This is the important observation. Hardl
Em quinta-feira, 16 de março de 2017, às 16:26:20 PDT, André Pönitz escreveu:
> On Thu, Mar 16, 2017 at 01:23:55PM -0400, Matthew Woehlke wrote:
> > On 2017-03-14 13:33, André Pönitz wrote:
> > > In general, I am not overly sold on ABI compatibility promises. I
> > > personally could live without a
On Thu, Mar 16, 2017 at 01:23:55PM -0400, Matthew Woehlke wrote:
> On 2017-03-14 13:33, André Pönitz wrote:
> > In general, I am not overly sold on ABI compatibility promises. I personally
> > could live without and find SC of more practical value. The most important
> > "feature" of ABI compatibil
On 2017-03-14 13:33, André Pönitz wrote:
> In general, I am not overly sold on ABI compatibility promises. I personally
> could live without and find SC of more practical value. The most important
> "feature" of ABI compatibility guarantee for me is that it limits people from
> doing overly excessi
On Tue, Mar 14, 2017 at 08:54:06AM -0700, Thiago Macieira wrote:
> On terça-feira, 14 de março de 2017 02:33:44 PDT Simon Hausmann wrote:
> > Hi,
> >
> >
> > I understand that there are limitations (to put it mildly) regarding the use
> > of API from the C++ standard library in Qt API itself due
I feel the same: Let's limit our binary compatibility promise to the part that
we can control. That would be Qt itself.
Anyone attempting to build a system with a wider scope of binary compatibility
promises needs to also control the shipment of other components, such as
libstdc++/libc++, libgc
On terça-feira, 14 de março de 2017 09:01:25 PDT Ville Voutilainen wrote:
> Ahem, it's not like there weren't qualms about it, but doing it for
> std::string and std::list
> was eventually necessary. The libstdc++ developers (including myself)
> spend fair amounts
> of time and energy trying to avo
On 14 March 2017 at 17:54, Thiago Macieira wrote:
>> I understand that there are limitations (to put it mildly) regarding the use
>> of API from the C++ standard library in Qt API itself due to the inability
>> to extend our binary compatibility promise. I'm curious though whether
>> std::function
On terça-feira, 14 de março de 2017 03:32:39 PDT Olivier Goffart wrote:
> > I understand that we permit the use of std::function in Windows specific
> > API of QProcess, which may or may not be different. However I'm curious
> > about this in the context of API that is intended to be fully
> > cros
On terça-feira, 14 de março de 2017 02:33:44 PDT Simon Hausmann wrote:
> Hi,
>
>
> I understand that there are limitations (to put it mildly) regarding the use
> of API from the C++ standard library in Qt API itself due to the inability
> to extend our binary compatibility promise. I'm curious th
On Dienstag, 14. März 2017 10:33:44 CET Simon Hausmann wrote:
> Hi,
>
>
> I understand that there are limitations (to put it mildly) regarding the use
> of API from the C++ standard library in Qt API itself due to the inability
> to extend our binary compatibility promise. I'm curious though whet
Hi,
I understand that there are limitations (to put it mildly) regarding the use of
API from the C++ standard library in Qt API itself due to the inability to
extend our binary compatibility promise. I'm curious though whether
std::function falls under the same umbrella?
I understand that we
36 matches
Mail list logo
