On Fri, Aug 03, 2018 at 08:27:50AM +0200, Olivier Goffart wrote:
> > The problem we had with a namespaced Qt were: using external Qt
> > based libraries, which never tried to use a namespaced build, did
> > not build due to forward declarations, so I had to patch some of
> > them. But then, not al
On Thursday, 2 August 2018 23:03:06 PDT Martin Koller wrote:
> QT_FORWARD_DECLARE_CLASS(QTimer)
Easier to just put QT_BEGIN_NAMESPACE before and QT_END_NAMESPACE after. It's
more verbose, but it's actually easier to read.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect
On 2018-08-03 08:03, Martin Koller wrote:
On Donnerstag, 2. August 2018 15:45:00 CEST Simon Hausmann wrote:
Hi,
Before concluding that a namespaced Qt is a terrible idea, I recommend trying
out the feature.
It is intended to work transparently and not require any changes to the
application
On Donnerstag, 2. August 2018 15:45:00 CEST Simon Hausmann wrote:
> Hi,
>
>
> Before concluding that a namespaced Qt is a terrible idea, I recommend trying
> out the feature.
>
>
> It is intended to work transparently and not require any changes to the
> application, nothing like having to ty
:45 PM
To: development@qt-project.org
Subject: Re: [Development] Symbol clashes with static Qt libraries
Am 31.07.2018 um 14:58 schrieb Edward Welbourne:
> Giuseppe D'Angelo (31 July 2018 14:38)
>> It will likely break every single application that has never used a
>> namespace
Am 31.07.2018 um 14:58 schrieb Edward Welbourne:
Giuseppe D'Angelo (31 July 2018 14:38)
It will likely break every single application that has never used a
namespaced build of Qt. Which is a significant percentage of all the Qt
apps out there...
I'm guessing you mean "... used a static buil
On Tuesday, 31 July 2018 07:52:37 PDT Thiago Macieira wrote:
> Well, it could be much worse. There are a couple of low-hanging fruits
> there that we can easily fix. I'll take a look later today on those
> applying to QtCore.
Done almost all for qtbase, from Kai's listing:
https://codereview.qt-
On Wednesday, 1 August 2018 06:48:40 PDT Tor Arne Vestbø wrote:
> > On 1 Aug 2018, at 15:45, Kai Koehne wrote:
> >
> > Alright, so it seems we have to prefix the symbols we can't hide by static
> > or anonymous namespaces ...
> > For logging categories, I'd like to start using 'qlc' as prefix.
t: Tuesday, July 31, 2018 4:58 PM
>> To: development@qt-project.org
>> Subject: Re: [Development] Symbol clashes with static Qt libraries
>>
>> On Tuesday, 31 July 2018 05:46:44 PDT Simon Hausmann wrote:
>>> I favor (a) along with the existing test, because of the issu
Of Thiago Macieira
> Sent: Tuesday, July 31, 2018 4:58 PM
> To: development@qt-project.org
> Subject: Re: [Development] Symbol clashes with static Qt libraries
>
> On Tuesday, 31 July 2018 05:46:44 PDT Simon Hausmann wrote:
> > I favor (a) along with the existing test, becau
On Tuesday, 31 July 2018 05:46:44 PDT Simon Hausmann wrote:
> I favor (a) along with the existing test, because of the issues Giuseppe
> outlined with (b) and I'm sceptical about how realistic (c) is for us.
We will not be able to get (c) working everywhere. I remember trying objcopy
some years a
On Tuesday, 31 July 2018 04:43:36 PDT Kai Koehne wrote:
> Note also that the logging categories are by far not the only non-prefixed
> symbols that might cause clashes when statically linking. See
> https://paste.kde.org/poeiwjlw3 for all symbols in qtbase/lib/Qt5*.a that
> don't contain a q or Q ,
> On 31 Jul 2018, at 15:58, Konstantin Shegunov wrote:
>
> On Tue, Jul 31, 2018 at 2:43 PM, Kai Koehne wrote:
> Hi,
>
> I'm wondering how we can avoid symbol clashes in static Qt libs + user code.
>
> a) Prefix all symbols with 'q', like we do for exported symbols.
>
> This requires some b
On Tue, Jul 31, 2018 at 2:43 PM, Kai Koehne wrote:
> Hi,
>
> I'm wondering how we can avoid symbol clashes in static Qt libs + user
> code.
>
> a) Prefix all symbols with 'q', like we do for exported symbols.
>
> This requires some bigger patches. See e.g. https://codereview.qt-project.
> org/#/c
On 31/07/18 14:58, Edward Welbourne wrote:
I can believe static-built apps are common; and I guess apps using them
would need to make source changes in order to switch to their namespaced
form, or override the default of them being namespaced. What other
problem(s) had you in mind ?
Exactly th
Kai Koehne (Tuesday, 31 July 2018 1:44 PM)
>>> b) Advise people to always configure static Qt in a namespace (-
>>> qtnamespace).
>>>
>>> This should fix it for symbols at least in our own code. Maybe we should
>>> make it even the default for static builds in Qt 6?
On 31/07/18 14:06, Mitch Curtis
Kai Koehne
Sent: Tuesday, July 31, 2018 1:43:36 PM
To: development@qt-project.org
Subject: [Development] Symbol clashes with static Qt libraries
Hi,
I'm wondering how we can avoid symbol clashes in static Qt libs + user code.
Reason why I'm looking into this is https://bugreports.qt.io
On 31/07/18 14:06, Mitch Curtis wrote:
This one is a nice compromise, in that it's just an extra argument to pass to
configure. Though, like you said, the issue is making people aware of it.
Are there any downsides to doing this by default?
It will likely break every single application that h
> -Original Message-
> From: Development project.org> On Behalf Of Kai Koehne
> Sent: Tuesday, 31 July 2018 1:44 PM
> To: development@qt-project.org
> Subject: [Development] Symbol clashes with static Qt libraries
>
> Hi,
>
> I'm wondering how we ca
> On 31 Jul 2018, at 13:43, Kai Koehne wrote:
>
> I can think of 3 approaches to tackle this:
>
> a) Prefix all symbols with 'q', like we do for exported symbols.
>
> This requires some bigger patches. See e.g.
> https://codereview.qt-project.org/#/c/235631/ for renaming all logging
> categ
Hi,
I'm wondering how we can avoid symbol clashes in static Qt libs + user code.
Reason why I'm looking into this is https://bugreports.qt.io/browse/QTBUG-67692
: We have the convention to name logging categories (which are actually
functions) with 'lc', such as 'lcCanvas'. Since logging catego
21 matches
Mail list logo