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
+1
Le mar. 31 juil. 2018 à 13:11, Sérgio Martins via Development <
development@qt-project.org> a écrit :
> On 2018-01-19 18:32, Thiago Macieira wrote:
> > On Friday, 19 January 2018 09:26:10 PST Edward Welbourne wrote:
> >> Jaroslaw Kobus (19 January 2018 17:09)
> >>
> >> > "give" may be
On Dienstag, 31. Juli 2018 14:25:21 CEST Edward Welbourne wrote:
> > My primary concern with this API is that it promotes an unclear
> > ownership model.
>
> hmm ... this is partly a symptom of most QAbstractCalendar instances
> being dataless. Each calendar has different code to implement its
>
Hi,
On 31/07/18 13:11, Sérgio Martins via Development wrote:
I would recommend however that our docs show T* instead of gsl::owner
and continue to include "Takes ownership of foo" in the text.
While I believe in self-documenting signatures I think it's too much
noise and hurts readability, and
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
Dear All,
I am new to Qt and trying to build it from source using MinGw_64. However, i am
getting an error as below,
qtbase/src/corelib/global/qglobal.cpp::5: error: '_wgetenv_s' was not
declared in this scope
_wgetenv_s(, 0, 0, wname.data());
^~
Please, don't introduce another type alias. It would loose the advantage of
static analysis like
http://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidelines-owning-memory.html
Le mar. 31 juil. 2018 à 14:52, Giuseppe D'Angelo via Development <
development@qt-project.org> a écrit :
> Hi,
>
>
Thanks, Simon!
--
Carry a towel
http://dataved.ru/
+7 916 562 8095
[1] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/
[2] Join Alexei Fedotov @facebook, http://www.facebook.com/openmeetings
[3] Start using Apache Openmeetings today, http://openmeetings.apache.org/
On Tue, Jul
On Monday, 30 July 2018 23:11:54 PDT Denis Shienkov wrote:
> As for me, is it prefferable variant will be *QBS* (it is best from the
> best).
>
> I'm do not like nor CMake, nor QMake, nor Autotools, nor something else.
I would say the only two options in the running are qbs and CMake.
--
it looks like https://bugreports.qt.io/browse/QTBUG-67443 what version of
mingw are you using ?
Le mar. 31 juil. 2018 à 17:00, Thiago Macieira
a écrit :
> On Tuesday, 31 July 2018 06:21:41 PDT Khuram Ali via Development wrote:
> > qglobal.cpp::5: error: '_wgetenv_s' was not declared in this
Dear All,
I am new to Qt and trying to build it from source using MinGw_64. However, i am
getting an error as below,
qtbase/src/corelib/global/qglobal.cpp::5: error: '_wgetenv_s' was not
declared in this scope
_wgetenv_s(, 0, 0, wname.data());
^~
While Liang has been away (he'll be back later this week):
Merges (various module owners; and I helped out a bit):
* qt5's last upmerge was 5.11->dev on July 12
* qtbase 5.11->dev, https://codereview.qt-project.org/233803 took 20
tries, but we got there in the end (July 17); we've not had
> 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
On Tuesday, 31 July 2018 06:21:41 PDT Khuram Ali via Development wrote:
> qglobal.cpp::5: error: '_wgetenv_s' was not declared in this scope
The problem is your MinGW headers and CRT. You need one that has _wgetenv_s.
In the MinGW-w64 headers I have, they exist. So check if you should erase
Hi,
You might be looking for the -extprefix parameter of configure :)
Simon
From: Development on
behalf of Alexei Fedotov
Sent: Tuesday, July 31, 2018 1:12:52 PM
To: Thiago Macieira
Cc: development@qt-project.org
Subject: Re: [Development] Fwd: qrandom.cpp
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
Hi,
I recall that when we first discovered this issue - many many years ago - we
introduced the tst_symbols auto-test (with Harald). Today it lives in the qtqa
repo and it's run for every module. It serves the purpose of verifying that we
don't have unprefixed exported symbols. Since this is
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
On Tue, Jul 31, 2018 at 09:01:43AM -0400, Khuram Ali via Development wrote:
>with correct subject line.
>
http://linux.sgms-centre.com/misc/netiquette.php#threading
___
Development mailing list
Development@qt-project.org
Hi,
I've said this also in the reviews, but perhaps it got lost:
My primary concern with this API is that it promotes an unclear ownership model.
Typically we have API that is either a sub-class of QObject (where the parent
may delete the children, such as QFile) or we have value based
On 2018-01-19 18:32, Thiago Macieira wrote:
On Friday, 19 January 2018 09:26:10 PST Edward Welbourne wrote:
Jaroslaw Kobus (19 January 2018 17:09)
> "give" may be confused with "get", which is usually an accessor. I may
> also think "Am I giving (to QCoreApplication)" or "The
>
Hi Thiago,
You wrote,
> you need a full, absolute Windows path for the prefix.
I tried the following:
./configure -developer-build -debug -shared -platform win32-g++
-prefix D:/Qt/5.11/arm -device linux-beagleboard-g++ -device-option
Simon Hausmann (31 July 2018 12:38)
> I've said this also in the reviews, but perhaps it got lost:
'fraid so. It's been a long review ... and gerrit's not good at helping
us find which comments haven't been addressed.
> My primary concern with this API is that it promotes an unclear
> ownership
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.
>
31.07.2018, 21:35, "Иван Комиссаров" :
> I prefer the solution from the thread "unique_ptr and Qt" about using smart
> pointers for transferring ownership explicitly. We can use std::observer_ptr
> from c++20 to indicate the places that do not take ownership.
> I think, using gsl::owner is a
-Original Message-
From: Development On
Behalf Of Thiago Macieira
Sent: Tuesday, July 31, 2018 11:41
To: development@qt-project.org
Subject: Re: [Development] Qt 6 buildsystem support requirements
On Tuesday, 31 July 2018 11:15:50 PDT Ville Voutilainen wrote:
> This provoked a
On 31 July 2018 at 22:33, Thiago Macieira wrote:
> On Tuesday, 31 July 2018 11:43:49 PDT Scott Bloom wrote:
>> Just a note.. for CMake, I find the -debug-output -trace and -trace-expand
>> as useful as the -d and -d -d .
>>
>> One other thing I use all the time for dependency analysis, is the
On Tuesday, 31 July 2018 11:43:49 PDT Scott Bloom wrote:
> Just a note.. for CMake, I find the -debug-output -trace and -trace-expand
> as useful as the -d and -d -d .
>
> One other thing I use all the time for dependency analysis, is the -graphviz
> switch.
Thanks, noted. I didn't know about
Thanks Thiago!
Yes you are right. i am using nuwen MinGW distribution and it doesn't contain
_wgetenv_s.
Regards,
Khuram Ali
-Original Message-
From: Thiago Macieira
To: development
Sent: Tue, Jul 31, 2018 5:00 pm
Subject: Re: [Development] Issue while compiling with MinGw_64
I prefer the solution from the thread "unique_ptr and Qt" about using smart
pointers for transferring ownership explicitly. We can use std::observer_ptr
from c++20 to indicate the places that do not take ownership.
I think, using gsl::owner is a wrong way of doing things, it's the way that can
On Tuesday, 31 July 2018 11:15:50 PDT Ville Voutilainen wrote:
> This provoked a thought in me, a way to make qbs worth all its effort:
> make debugging
> a build so staggeringly ridiculously good that it becomes attractive
> to use it. I don't know
> what debugging builds done with python-based
Иван Комиссаров
> 31 июля 2018 г., в 21:39, Konstantin Tokarev написал(а):
>
>
>
> 31.07.2018, 21:35, "Иван Комиссаров" :
>> I prefer the solution from the thread "unique_ptr and Qt" about using smart
>> pointers for transferring ownership explicitly. We can use std::observer_ptr
>> from
On 31 July 2018 at 20:49, Thiago Macieira wrote:
> I know CMake meets these requirements, but it has other problems and the fact
> that it currently does not build Qt. On that front, qbs is ahead. But qbs has
> a shorter track record. Since we're not switching buildsystems in the next 2
> years,
On Tuesday, 31 July 2018 09:35:42 PDT Lisandro Damián Nicanor Pérez Meyer
wrote:
> > I would say the only two options in the running are qbs and CMake.
>
> Just for curiosity I checked qbs' reverse dependencies (packages that
> require qbs installed in order to be built) in Debian. We currently
That is true. I am using newen distro.
Regards,
Khuram Ali
-Original Message-
From: Eric Lemanisser
To: Thiago Macieira
Cc: development
Sent: Tue, Jul 31, 2018 5:12 pm
Subject: Re: [Development] Issue while compiling with MinGw_64
it looks like
El martes, 31 de julio de 2018 11:41:15 -03 Thiago Macieira escribió:
> On Monday, 30 July 2018 23:11:54 PDT Denis Shienkov wrote:
> > As for me, is it prefferable variant will be *QBS* (it is best from the
> > best).
> >
> > I'm do not like nor CMake, nor QMake, nor Autotools, nor something
> I would say the only two options in the running are qbs and CMake.
About this, I don't know if C++ community acceptance is a criterion, but :
https://github.com/search?q=cmake
https://github.com/search?q=qbs
On Tue, Jul 31, 2018 at 4:41 PM, Thiago Macieira
wrote:
> On Monday, 30 July
End of last year I experimented with different “MinGW 64 bit compilers” for
compilation of boost and Qt libs.
I succeeded using MinGW 7.2.0 x86_64-7.2.0-posix-seh-rt_v5-rev1 from
http://mingw-w64.org on Qt 5.9.3. The most challenging part was the MinGW
interface for finding and installing the
Thank you! but it would be far easier if the fix from philippe dunski could be
added in official Qt distribution. It would be compatible with latest MinGW
distribution.
Regards,
Khuram Ali
-Original Message-
From: H-J Euler
To: Khuram Ali ; development
Sent: Tue, Jul 31, 2018
> 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
>
> -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 can avoid symbol clashes in static Qt
with correct subject line.
Regards,
Khuram Ali
-Original Message-
From: Khuram Ali via Development
To: development
Sent: Tue, Jul 31, 2018 3:00 pm
Subject: Re: [Development] Calendar classes: API review request
Dear All,
I am new to Qt and trying to build it from source using
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 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
With fix of philippe dunski, build seems to working. Thank you very much for
help!
Regards,
Khuram Ali
-Original Message-
From: Khuram Ali via Development
To: eric.lemanissier ; thiago.macieira
Cc: development
Sent: Tue, Jul 31, 2018 5:31 pm
Subject: Re: [Development] Issue
> On 31 Jul 2018, at 09:41, Иван Комиссаров wrote:
>
> QBS generates Qt Modules file depending on the information that QMake
> provides about modules installed in the system to make sure you won;t be able
> to import module that doesn’t exist on your system.
Files that were dynamically
QBS generates Qt Modules file depending on the information that QMake provides
about modules installed in the system to make sure you won;t be able to import
module that doesn’t exist on your system.
According to the fact that you can have multiple versions of Qt (i have 3 Qt
versions on my
> On 30 Jul 2018, at 22:30, Matthew Woehlke wrote:
>
> On a related note, "hermetic builds" is pretty ironic. Your *build*
> might be hermetic, but bazel itself is *far* from... it's very reliant
> on putting all its garbage in "magic locations" in your home directory,
> unlike most build tools
Hi guys,
Is there are any list of options from which it is possible to choose?
As for me, is it prefferable variant will be *QBS* (it is best from the
best).
I'm do not like nor CMake, nor QMake, nor Autotools, nor something else.
BR,
Denis
___
Feature freeze is drawing near, as Jani just reminded us,
and Soroush's work on calendar support is in a state that
looks (to me) ready to use.
Please would those with strong views on API design take
a look at [0] and speak up now, so that we don't end up
reworking it all during the API review
50 matches
Mail list logo
