Hi,
Apparently, this recent change results in an error message like "cc1: fatal
error: .pch/release-shared/QtGui: No such file or directory" on ARM (but at
least on raspberry pi and Harmattan):
https://codereview.qt-project.org/#change,33006
The assembly file (.S) was added directly to the SOURCE
You can add -std=c++11 in mkspecs/win32-g++/qmake.conf / CXXFLAGS by
yourself.
On Linux, These patchs should works well for support -std=c++11 using cross
compilation.
https://codereview.qt-project.org/#change,33044
https://codereview.qt-project.org/#change,33078
2012/8/26 Thiago Macieira
> > S
Am 26.08.2012 16:23, schrieb Stephen Chu:
> On 8/26/12 10:03 AM, Stephen Chu wrote:
>
>>
>> Thanks for pointing out the build differences. I didn't realize there
>> are so many different builds of the same MinGW version. Switching to
>> mingw-builds get me further. But then I got this error:
>>
>>
On 26.08.2012 20:14, Peter Kümmel wrote:
> http://doc-snapshot.qt-project.org/5.0/qtplugin.html#Q_PLUGIN_METADATA
>
> When Q_PLUGIN_METADATA() is used with a FILE name which doesn't
> exist, moc throws an error, but when FILE isn't present at all
> moc silently doesn't generate the pluginMetaData[]
http://doc-snapshot.qt-project.org/5.0/qtplugin.html#Q_PLUGIN_METADATA
When Q_PLUGIN_METADATA() is used with a FILE name which doesn't
exist, moc throws an error, but when FILE isn't present at all
moc silently doesn't generate the pluginMetaData[]s.
Isn't this a bug?
Peter
__
And another nice thing might be to have the C++ classes and QML types
as child-nodes, and then have the QML types navigable from that tree too.
On Sun, Aug 26, 2012 at 11:04 AM, Alan Ezust wrote:
> In the "contents" tab, there is a tree node for "classes" just below
> "qt reference documentation
In the "contents" tab, there is a tree node for "classes" just below
"qt reference documentation".
When I click on it, it says
The page could not be found. 'qthelp://com.trolltech.qt.500/qdoc/'
There is another page that has all classes.
qthelp://com.trolltech.qt.500/qdoc/classes.html
I think click
make qch_docs (on linux) works for me now too!
thanks!
On Fri, Aug 24, 2012 at 9:42 PM, Loaden wrote:
> I can using 'make docs' to create qt.qch for now.
> Thanks!
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mai
On 26.08.2012 18:16, Thiago Macieira wrote:
> On domingo, 26 de agosto de 2012 17.31.07, Peter Kümmel wrote:
>> When building plugins, moc generates files with '#ifdef QT_NO_DEBUG'
>> but the lib/cmake modules doesn't add QT_NO_DEBUG for release builds.
>> A bug?
>
> What are you talking about?
A
On domingo, 26 de agosto de 2012 18.23.48, Olivier Goffart wrote:
> The design of the current QMutex is so that it is free in the non contended
> case, so we can use in libraries and it does not have much overhead on code
> that we want to make thread safe, but will most likely not be used with
> t
On Sunday 26 August 2012 15:47:31 Thiago Macieira wrote:
> On domingo, 26 de agosto de 2012 15.44.05, Thiago Macieira wrote:
> > With a Double CAS, it might be possible to do that for the Windows and Mac
> > semaphore solutions. PThread also allows for static initialisation, but it
> > requires a d
On domingo, 26 de agosto de 2012 15.44.11, lars.kn...@nokia.com wrote:
> Which is why I'm asking whether they shouldn't be separate classes sharing
> as much of the implementation as possible.
So the question I need Olivier to answer is:
What are the conditions you envision for casting a QMutex t
On domingo, 26 de agosto de 2012 17.31.07, Peter Kümmel wrote:
> When building plugins, moc generates files with '#ifdef QT_NO_DEBUG'
> but the lib/cmake modules doesn't add QT_NO_DEBUG for release builds.
> A bug?
What are you talking about?
The moc program is the same, regardless of your builds
On Aug 26, 2012, at 3:47 PM, ext Thiago Macieira
wrote:
> On domingo, 26 de agosto de 2012 15.44.05, Thiago Macieira wrote:
>> With a Double CAS, it might be possible to do that for the Windows and Mac
>> semaphore solutions. PThread also allows for static initialisation, but it
>> requires a
When building plugins, moc generates files with '#ifdef QT_NO_DEBUG'
but the lib/cmake modules doesn't add QT_NO_DEBUG for release builds.
A bug?
Peter
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinf
On domingo, 26 de agosto de 2012 10.23.17, Stephen Chu wrote:
> qt5_tool requires git in PATH so I'll just have to remember changing
> PATH back and forth between clean up/update and configure.
git.exe in PATH is fine. sh.exe in PATH isn't.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Sof
On 8/26/12 10:03 AM, Stephen Chu wrote:
>
> Thanks for pointing out the build differences. I didn't realize there
> are so many different builds of the same MinGW version. Switching to
> mingw-builds get me further. But then I got this error:
>
> cp qmake.exe C:\Qt\5.0\qtbase\bin\qmake.exe
> g++:
On domingo, 26 de agosto de 2012 10.03.33, Stephen Chu wrote:
> Thanks for pointing out the build differences. I didn't realize there
> are so many different builds of the same MinGW version. Switching to
> mingw-builds get me further. But then I got this error:
>
> cp qmake.exe C:\Qt\5.0\qtbase\bi
On 8/26/12 7:13 AM, Lukas Geyer wrote:
> Am 26.08.2012 09:31, schrieb Thiago Macieira:
>> Yes: make has a bug and it's hitting that.
>
> VPATH is also broken [1] in some mingw-w64 builds (eg. rubenvb).
>
>> You can upgrade, downgrade, "sidegrade", rebuild make with different
>> optimisation flags.
On domingo, 26 de agosto de 2012 15.44.05, Thiago Macieira wrote:
> With a Double CAS, it might be possible to do that for the Windows and Mac
> semaphore solutions. PThread also allows for static initialisation, but it
> requires a destruction call if the mutex is used
And all of this is so we do
On domingo, 26 de agosto de 2012 15.13.30, Olivier Goffart wrote:
> The freelist is O(1) and only used when we actually block. The freelist
> should only become a bottleneck if it is itself contented. Which only
> happen in a benchmark which does nothing but locking and unlocking
> mutexes. Any c
On terça-feira, 21 de agosto de 2012 22.36.38, Thiago Macieira wrote:
> Conclusion: I'm glad I use Linux and that we have futex.
By the way, it looks like Windows 8 supports something akin to futexes. At
least the two basic operations are present:
http://msdn.microsoft.com/en-us/library/windows/d
On Sunday 26 August 2012 12:12:18 lars.kn...@nokia.com wrote:
> On Aug 26, 2012, at 12:26 PM, ext Thiago Macieira
wrote:
> > On domingo, 26 de agosto de 2012 11.10.10, Olivier Goffart wrote:
> >> I was in vacation last week without proper internet access.
> >> Many of the changes already had a +2
On domingo, 26 de agosto de 2012 14.47.24, Olivier Goffart wrote:
> > That only applies if you use std::string.
> >
> >
> >
> > So don't use std::string. Qt doesn't.
>
> I'm not aware of any problem with std::string. I don't understand your
> comment. Using std::string should remain safe.
libstdc
On Sunday 26 August 2012 13:52:28 Thiago Macieira wrote:
> On domingo, 26 de agosto de 2012 13.13.32, Lukas Geyer wrote:
> > You can theoretically create C++11 applications using C++98 Qt
> > libraries. The problem is that GCC C++11 is not fully binary compatible
> > with GCC C++98. But I'm quite s
On Aug 26, 2012, at 12:26 PM, ext Thiago Macieira
wrote:
> On domingo, 26 de agosto de 2012 11.10.10, Olivier Goffart wrote:
>> I was in vacation last week without proper internet access.
>> Many of the changes already had a +2 from me before, but it went away as you
>> rebased or refreshed the
On domingo, 26 de agosto de 2012 10.45.31, Olivier Goffart wrote:
> The problem is that
> pthread mutex can't do timed lock, so we need to be smart in order to allow
> tryLock(timeout)
By the way:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_timedlock.html
Since POSIX.
On domingo, 26 de agosto de 2012 13.13.32, Lukas Geyer wrote:
> You can theoretically create C++11 applications using C++98 Qt
> libraries. The problem is that GCC C++11 is not fully binary compatible
> with GCC C++98. But I'm quite sure Thiago can clarify on how this
> affects Qt binary compatibil
I've checked all of qtnetwork and everything already had the \inmodule.
Rich.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Am 26.08.2012 09:31, schrieb Thiago Macieira:
> Yes: make has a bug and it's hitting that.
VPATH is also broken [1] in some mingw-w64 builds (eg. rubenvb).
> You can upgrade, downgrade, "sidegrade", rebuild make with different
> optimisation flags. Or even fix the bug.
I have made positive exper
On domingo, 26 de agosto de 2012 11.10.10, Olivier Goffart wrote:
> I was in vacation last week without proper internet access.
> Many of the changes already had a +2 from me before, but it went away as you
> rebased or refreshed the changes. This show a problem with the gerrit tool
> and a major
On domingo, 26 de agosto de 2012 10.45.31, Olivier Goffart wrote:
> Keep in mind that the micro benchmark really stress the mutexes, and is not
> really realistic: The benchmark do nothing outside the lock.
> In a typical scenario, if you use multiple thread, it is because you want to
> paralellize
On Saturday 25 August 2012 09:40:07 Thiago Macieira wrote:
> Hello
>
> While the discussion on the change to the commit policy is ongoing, I'd like
> to use some of the provisions I made there:
>
> "a Maintainer may self-approve a change even if there are no +1s at all,
> provided that there are
On Tuesday 21 August 2012 22:36:38 Thiago Macieira wrote:
> Hello
>
> I've just done some benchmarking of QMutex on Linux, using the pthread
> implementation instead of the futex one.
>
> Conclusions first:
>
> QMutex is optimised for uncontended case. It does that by keeping the d
> pointer at
On sábado, 25 de agosto de 2012 23.59.25, Stephen Chu wrote:
> I am trying to build Qt 5 from git using MinGW 4.7. It fails at
> bootstrapping configure:
>
> C:\Qt\5.0>configure -developer-build -opensource -confirm-license
> + C:/Qt/5.0/qtbase/configure -developer-build -opensource -confirm-licens
35 matches
Mail list logo
