Re: [Development] Using #pragma once

[Gunnar Roth]

Hi Lars,
I do not really object exclusive use of pragma once, without header 
guards  ( I use it myself), I just want to tell about my experience on 
Debian Stretch with gcc 6.3


1. Using precompiled header, you can run into trouble, if you use 
forward header , like qt does, and these do not contain pragma once too. 
I got double definition errors then, because pragam once was ignored 
somehow.


2. There is a , still unfixed, gcc bug since gcc 4.6.3 , where pragma 
once is ignored for files which start with a Utf8 BOM, when using 
precompiled headers.  see 
https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple&id=56549


3. #pragma once makes gcc much  slower according to Bug 58770 - GCC very 
slow compiling with #pragma once 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58770



Regards,
Gunnar Roth



-- Original Message --
From: "Lars Knoll" 
To: "Qt development mailing list" 
Sent: 07/10/2018 10:56:47
Subject: [Development] Using #pragma once


Hi,

Just a quick question: Does anybody have any good arguments against us 
starting to use #pragma once instead of header guards throughout our 
code base?


I’ve started using it implicitly when updating 3rd party code (the 
macro assembler) in qtdeclarative without any problems (so I’d 
supported by all our compilers). IMO #pragma once is both safer and 
nicer to use than classic header guards.


Cheers,
Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.10.0 RC out

[Gunnar Roth]

The wiki now says:

Release Candidate 2 Week 48 /2017 1.12.2017
Release Candidate 2 4.12.2017 
 
Why two dates for rc2?

Regards,
Gunnar Roth


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development[http://lists.qt-project.org/mailman/listinfo/development]
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New repository for WebGL Streaming QPA plugin

[Gunnar Roth]

When i klick on this I camoe to a login page of gitlab.

When trying to register I get


1 error prohibited this user from being saved:


	Email domain is not authorized for sign-up



 

I tried that with gmx.de and siemens.com

 


Regards,

Gunnar Roth


Gesendet: Mittwoch, 05. April 2017 um 15:01 Uhr
Von: "Jesus Fernandez" 
An: development@qt-project.org
Betreff: [Development] New repository for WebGL Streaming QPA plugin

Hi all!

I have been working on a QPA plugin to send the GLES2.0 calls from a host computer over the network to a WebGL capable browser. Now it's approaching a state in which it could be usable. For this, we'll need a new public repository.

Having a public and controlled repository could help the project to grow up significantly.

The name could be Qt WebGL Streaming (qt/qtwebglstreaming).
The current location of the project is https://git.qt.io/playground/qtwebglplugin

--

Best regards,
Jesus
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Gunnar Roth]

 
 


>> vcblog says: " Specifically, VS 2015 and VS “15” will have the same major>
>> compiler version (19) and their STLs will be binary-compatible, and this
>> compatible compiler and STL will remain available throughout the lifecycle
>> of VS “15”. This implies that the STL’s DLL will continue to be named
>> msvcp140.dll. (At some point in the future, we expect to have a compiler
>> version 20 and a binary-incompatible STL again.)"
>
>This needs to be tested. It's not only binary compatibility, it's also the way
>that Windows does DLLs -- especially the VC runtime ones. It's possible to
>load more than one with different manifest information, which by itself is
>problematic. But then you can't delete in one pointers new'ed by another,
>which is a much bigger problem.
>Maybe that's fixed. Maybe it isn't. Someone who knows more about DLLs,
>manifests, and VC needs to check this
well as the vcruntime is still called 140, a vs2017 runtime will supersede your 
2015 runtime,
if your manifest says use the latest. So there is no difference between the 
different vs2015 update versions. Ms needs to keep them compatible, especially 
the allocator.


>> yes dropping vs2015 build as using the latest 19.xx compiler will be binary
>> compatible to vs2015 code.

>We can't drop it from the CI. I don't think we can drop it from the build
>packages either, since usually you compile with the oldest you plan to use. So
>if you're correct and VS2017 is binary-compatible, then we are already
>providing the packages for VS2017.

Yes but then you do not have the many performancee optmisations ( better 
constexpr, better vector preformance, compiler optimisations) in the qt build.

>> > But we did make MSVC 2017 work with 5.8. We solved all build issues we
>> > could find.
>>
>> Well sadly that does not include 5.8.0, so now users have to wait at least
>> until may to get a vs2017 ( which will be released on March 9th).
>
>We had planned on having 5.8.1 before that release. Unfortunately, it's not
>going to happen, due to lack of resources. 5.8.1 is postponed indefinitely and
>will most likely not happen.

Actually I expected that, because that's Murphy's Law ;-)

But as I always build Qt myself to be able to add patches and to have release 
pdbs, I myself do not care so much,
I just think it would give Qt a better look for other users, to support 2017rc.


>The win32-msvc mkspecs have been dropped as of Qt 5.8.0. They're all now
>called "win32-msvc" and the actual versions are extracted from the compiler
>itself, to enable command-line options as needed. The plan was for 2017 to not
>get an mkspec of its own, but we had to add it for compatibility with Qt
>5.6.3, which apparently needed to get one of its own.

Hmm what do you mean? If i do a dir win32* in the mkspec folder of qtbase of Qt 
5.8.0, I get this:
24.01.2017  17:37  win32-clang-msvc2015
24.01.2017  17:37  win32-g++
24.01.2017  17:37  win32-icc
24.01.2017  17:37  win32-msvc2005
24.01.2017  17:37  win32-msvc2008
24.01.2017  17:37  win32-msvc2010
24.01.2017  17:37  win32-msvc2012
24.01.2017  17:37  win32-msvc2013
24.01.2017  17:37  win32-msvc2015
24.01.2017  17:37  win32-msvc2017

So there is lot of unsupported msvc versions (2005,2008,2010,2012), but no 
win32-msvc mkspec.

Regards,
Gunnar Roth.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Gunnar Roth]

> 
> We can't provide binaries because, with Visual Studio, the different releases 
> are not binary-compatible with each other. If we built our releases with the 
> RC, it may not run with your application that you compiled with the final. 
> And 
> since we promise to keep our compatibility forwards and backwards inside a 
> minor series, we don't like to update the MSVC version so you can just drop 
> in 
> the new release and not have to rebuild everything.
vcblog says: " Specifically, VS 2015 and VS “15” will have the same major 
compiler version (19) and their STLs will be binary-compatible, and this 
compatible compiler and STL will remain available throughout the lifecycle of 
VS “15”.  This implies that the STL’s DLL will continue to be named 
msvcp140.dll.  (At some point in the future, we expect to have a compiler 
version 20 and a binary-incompatible STL again.)"

> 
> Maybe we ought to revisit that.
> 
yes.

> The next problem is the load on the build servers and on the people doing the 
> testing that the generated binaries actually work. See the discussion we had 
> a 
> couple of months ago on what we'd release for 5.8 and 5.9. We need to keep 
> the 
> number of binaries to a constant number. So adding MSVC 2017 would mean 
> dropping something.
yes dropping vs2015 build as using the latest 19.xx compiler will be binary 
compatible to vs2015 code.


> But we did make MSVC 2017 work with 5.8. We solved all build issues we could 
> find.
Well sadly that does not include 5.8.0, so now users have to wait at least 
until may to get a vs2017 ( which will be released on March 9th).

> 
>> Under this proposal, Qt binaries would be available for MSVC++2018
>> when it is previewed, or at least most certainly when it goes to RC.
>> Waiting for it to deploy is *way* too late, as the new Microsoft
>> release model suggests that developers have been integrating the
>> compiler into their tooling for a year before Qt "shows up".
> 
> That's unlikely to happen.
> 
> How about asking Microsoft to follow up on their promise of keeping binary 
> compatibility instead? That way, the binaries built with MSVC 2017 will work 
> with 2018 and we don't have to rebuild.

How about Qt supports the binary compatibility bewegen cl19.00 and cl cl19.xx 
instead on making a win32-msvc2017?
mkspec should be based on the cl major version , instead of the IDE year. 
QtCreator complains when you try to use a qt with 2017 mkspec and a 2015 
compiler set.

Regards,
Gunnar Roth



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Announce] Qt 5.8.0 and Qt Creator 4.2.1 released

[Gunnar Roth]

>> 
> 
> No. There will be a 5.6.2, but not another 5.7.x.
Well, there IS already a 5.6.2 version.

Regals,
Gunnar Roth

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] invokeMethod() with function pointers

[Gunnar Roth]

> 
> I respect the fact that you rejected Qt::BlockingAutoConnection in 2014 
> because of its potential danger, but I'm not sure that it's better to let 
> people use the "QThread::currentThread() == this" pattern without being 
> warned rather than implementing Qt::BlockingAutoConnection, with a detailed 
> warning in the doc.
> 
> Moreover, I don't understand whi BlockingAutoConnection would be more 
> dangerous (if it were to be added) than BlockingQueuedConnection is currently 
> already dangerous.

I also don’t understand why adding  "QThread::currentThread() == this“ should 
make the method more dangerous, actually it makes it a bit more safe for the 
same thread case, the potential deadlock problem remains with or without.

Regards,
Gunnar Roth 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] git 5.8.0 build failure with vs 2017 rc error C3615: constexpr function 'QAlgorithmsPrivate::qt_builtin_ctz' cannot result in a constant exp ression

[Gunnar Roth]

Hi Thiago,
now  I get confused.
>That's not enough. You need to
>cd qtbase && git checkout 5.8.0
 
When I do this I get the old code which does  not compile.
Doing cd qtbase && git checkout 5.8 gives me the new code

 
>Possibly pull every now and again in there. If you need to be in the bleeding
>edge, git submodule update is the wrong tool.
So what is the right tool? Why is is mentioned in the qt5 wiki Building from 
git?
I also have seen that I didnt get qtvirtualkeyboard just an empty directory. 
using
perl init-repository --module-subset=qtvirtualkeyboard -f
i get it it, but also message that the other folder are removed.
doing
perl init-repository -f
again.

But how is it supposed to work? How do I get the code which will become  the 
release candidate? Do I need to wait for a label?

Regards,
Gunnar Roth
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] git 5.8.0 build failure with vs 2017 rc error C3615: constexpr function 'QAlgorithmsPrivate::qt_builtin_ctz' cannot result in a constant exp ression

[Gunnar Roth]

> Am 05.12.2016 um 20:07 schrieb Thiago Macieira :
> 
> Em segunda-feira, 5 de dezembro de 2016, às 15:42:25 PST, Gunnar Roth 
> escreveu:
>> Hello,
>> My try to build qt 5.8.0 from git using vs2017 rc (CL 19.10.24629) failed
>> already when building configure. (commit
>> 2c27ccd1c9a821edd071cae6336ecb2066ce2ab7) the qt 5.8 beta did work. Using
>> CL 19.00.24213.1 (vs2015 upd3 + kb) also works. does anyone have the same
>> problem? Probably constexpr was activated for this compiler but not tested.
> 
> 5.8 beta is too old. Pleaase upgrade to the latest 5.8.0 branch.
Sure thats why i tried using  the version from git.

> 
> From the other email:
>> Ok thank you Friedeman,
>> so
>> $ cd qt5
>> $ perl init-repository
>> $ git checkout 5.8.0
>> $ git submodule update
>> is not the correct way to get latest 5.8.0 from git?
>> 
>> But what is the correct way then?
> 
> It is, but it's possible that the qt5 link to qtbase is outdated due to 
> having 
> failed to integrate. You need to update qtbase to the 5.8.0 branch, even past 
> what qt5 requires of you.
i did git checkout 5.8 git submodule update  which compiled then.

> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] git 5.8.0 build failure with vs 2017 rc error C3615: constexpr function 'QAlgorithmsPrivate::qt_builtin_ctz' cannot result in a constant exp ression

[Gunnar Roth]

Ok thank you Friedeman,

so 


$ cd qt5
$ perl init-repository


$ git checkout 5.8.0
$ git submodule update




is not the correct way to get latest 5.8.0 from git?

 

But what is the correct way then?

 

Regards,

Gunnar Roth

 

 


Gesendet: Montag, 05. Dezember 2016 um 16:35 Uhr
Von: "Friedemann Kleint" 
An: development@qt-project.org
Betreff: Re: [Development] git 5.8.0 build failure with vs 2017 rc error C3615: constexpr function 'QAlgorithmsPrivate::qt_builtin_ctz' cannot result in a constant exp ression

Hi,

>My try to build qt 5.8.0 from git using vs2017 rc (CL 19.10.24629)
failed already when building configure. (commit
2c27ccd1c9a821edd071cae6336ecb2066ce2ab7)
>the qt 5.8 beta did work. Using CL 19.00.24213.1 (vs2015 upd3 + kb)
also works.
>does anyone have the same problem? Probably constexpr was activated
for this compiler but not tested.


Please make sure you have "Fixed build using Visual Studio 2017"
a103992f49045323a3aaa4970eb1ee5f65a378dd
https://codereview.qt-project.org/#/c/177743/ applied.

Regards, Friedemann

--
Friedemann Kleint
The Qt Company GmbH

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] git 5.8.0 build failure with vs 2017 rc error C3615: constexpr function 'QAlgorithmsPrivate::qt_builtin_ctz' cannot result in a constant exp ression

[Gunnar Roth]

./Qt580/qtbase/src/corelib/tools/qalgorithms.h(649): error C3615: constexpr function 'QAlgorithmsPrivate::qt_builtin_popcount' cannot result in a constan
t _expression_
c:\bldqt\5.8.0\win32-vs14-64\qtbase\include\qtcore\../../../../../../Qt580/qtbase/src/corelib/tools/qalgorithms.h(651): note: failure was caused by an illegal statement or _expression_
c:\bldqt\5.8.0\win32-vs14-64\qtbase\include\qtcore\../../../../../../Qt580/qtbase/src/corelib/tools/qalgorithms.h(655): error C3615: constexpr function 'QAlgorithmsPrivate::qt_builtin_popcountll' cannot result in a const
ant _expression_
c:\bldqt\5.8.0\win32-vs14-64\qtbase\include\qtcore\../../../../../../Qt580/qtbase/src/corelib/tools/qalgorithms.h(657): note: failure was caused by an illegal statement or _expression_
jom: C:\bldqt\5.8.0\WIN32-VS14-64\qtbase\tools\configure\Makefile [configure_pch.pch] Error 2

 

Regards,

Gunnar Roth
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] std::atomic

[Gunnar Roth]

 

Hello , i also tested the small sample


struct S {
    int i;
    constexpr S() : i(1) {}
};

struct T {
    S s[1];
    constexpr T() {}
};

T t;


 

with cl 19.00.24213.1 (upd3 + kb fix) and it fails.

The test with cl  19.10.24516 ( VS"15" preview 5) succeeds, just the linker says it is missing main().

 

Btw using  19.10.24516 angle does no longer crash for me in qt 5.7.0

 

Regards,

Gunnar Roth

 


Gesendet: Freitag, 21. Oktober 2016 um 00:37 Uhr
Von: "Henry Skoglund" 
An: development@qt-project.org
Cc: thiago.macie...@intel.com
Betreff: Re: [Development] std::atomic

On 2016-10-21 00:11, Sergio Martins wrote:
> On 2016-10-20 21:43, Thiago Macieira wrote:
>> Em quinta-feira, 20 de outubro de 2016, às 17:28:39 PDT, Philippe
>> escreveu:
>>> std::atomic is used as underlying implementation for the the Qt atomic
>>> API with CLang on Mac.
>>> But why not with Visual Studio 2015? You will certainly mention some
>>> bug,
>>> but then where is the problem? (shortly)
>>
>> Because the Microsoft compiler does not support constexpr properly. See
>> https://connect.microsoft.com/VisualStudio/feedback/details/2011648
>>
>> I haven't tested Update 3 to see if that is fixed.
>
> Do you have a testcase for this bug ?
> I couldn't reproduce with Update2 by using a class with constexpr ctor
> and an array member, so I think I'm not testing it correctly.

If you click on "DETAILS" there is a testcase attached. Also, I just
tested on Visual Studio 2015 Update 3 and it still fails. /Rgrds Henry


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Which changes are suitable for 5.6?

[Gunnar Roth]

Hi Thiago,
thanks for you answers.

> Am 13.08.2016 um 20:05 schrieb Thiago Macieira :
> 
> On sábado, 13 de agosto de 2016 18:08:16 PDT Gunnar Roth wrote:
>> 1. category is just adding code, which does not influence current
>> code. 
>> a. adding qAsConst in qgolbal.h. That is actually something i really
>> like to have in qt 5.6, because it is very useful and has no risk. 
> 
> Except that it's impossible. For the feature to work, we need rvalue 
> references to prevent wrong use. We can't do that in 5.6 because it doesn't 
> require C++11.
Hmm ok, as that works with vs 2012 ( and wec2013) I didn’t think about that. 
But even vs2010 has this.
But ok there may be other compilers , which I don’t have knowledge about then.
> 
>> b. adding EditorFont to qplatformtheme.h enumeration ,has  also no risk. 
> 
> Not allowed per Qt API compatibility promise: code compiled with Qt 5.6.x 
> must 
> run just fine with Qt 5.6.y even if y < x.
Well thats something I honestly di not know before. So that means something 
compiled 
with qt 5.6.2 is able to run with 5.6.0? 

> 
>> c. protect cleanup of QQmlEngine when removing from QQmlDebugConnector in
>> destructor, because quickcontrols2 instantiates it in  a way that it is not
>> registered, but on cleanup crashes when removing as there is no check if it
>> was added at all. I consider that a bug in Qt 5.6.1
> 
> I have no idea about this one.
> 
>>  d. adding QQuickItem::isAncestorOf function to qquickitem.* has also no
>> risk. 
> 
> But violates Qt API policy even worse than adding an enum because it would 
> cause dynamic linker errors.

As I thought API compatibility were like between 5.6 and 5.7 , I didn’t see the 
problem.

>> e. adding Q_QUICK_PRIVATE_EXPORT to  QQuickStateAction  class in
>> qquickstate_p.h
> 
> That's ok.
> 
>> 2. category is enhancing code but also modifies existing code.
>> 
>>  a.  enhance qml module lookup behavior in a way making things a lot
>> easier.
>> 
>>   qqmlimport.* is changed ( by merging simply the code from 5.7 to do a
>> lookup like this: For example, QtQml.Models 2.0:
>>   - base/QtQml/Models.2.0/qmldir
>>   - base/QtQml.2.0/Models/qmldir
>>   - base/QtQml/Models.2/qmldir
>>   - base/QtQml.2/Models/qmldir
>>   - base/QtQml/Models/qmldir
>>  This is very convenient. quickcontrols2 works without that but only
>> with the default style. quickcontrols1 is jumping through hoops to achieve
>> similar without change qtdeclarative.
> 
> No idea about this.
> 
>>  b. adding MovementDirection property  to QQuickPathView, i just copied
>> qquickpathview.* from qt 5.7. I assume a low risk, but qt 5.7 has the same
>> risk then.
> 
> API policy violation.


Sure now i know. 
Well ok then I will just maintain my patches privately.

Regards,
Gunnar Roth


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Which changes are suitable for 5.6?

[Gunnar Roth]

Hi Thiago,

to make qt 5.6.x support the quick controls2 there are only a few changes 
needed.
1. category is just adding code, which does not influence current code.
a. adding qAsConst in qgolbal.h. That is actually something i really like 
to have in qt 5.6, because it is very useful and has no risk. 
b. adding EditorFont to qplatformtheme.h enumeration ,has  also no risk.
c. protect cleanup of QQmlEngine when removing from QQmlDebugConnector in 
destructor, because quickcontrols2 instantiates 
it in  a way that it is not registered, but on cleanup crashes when 
removing as there is no check if it was added at all. I consider
that a bug in Qt 5.6.1
 
  d. adding QQuickItem::isAncestorOf function to qquickitem.* has also no risk.
  e. adding Q_QUICK_PRIVATE_EXPORT to  QQuickStateAction  class in 
qquickstate_p.h

2. category is enhancing code but also modifies existing code.

  a.  enhance qml module lookup behavior in a way making things a lot easier.

   qqmlimport.* is changed ( by merging simply the code from 5.7 to do a 
lookup like this:
   For example, QtQml.Models 2.0:
   - base/QtQml/Models.2.0/qmldir
   - base/QtQml.2.0/Models/qmldir
   - base/QtQml/Models.2/qmldir
   - base/QtQml.2/Models/qmldir
   - base/QtQml/Models/qmldir
  This is very convenient. quickcontrols2 works without that but only with 
the default style. quickcontrols1 is jumping 
  through hoops to achieve similar without change qtdeclarative.

  b. adding MovementDirection property  to QQuickPathView, i just copied 
qquickpathview.* from qt 5.7. I assume a low risk, 
  but qt 5.7 has the same risk then.

The changes in the quick controls itself are just a matter of changing some 7 
to a 6, 5.7.0 to 5.6.1 and 2.7 to 2.6

So actually I don’t see a dragon but maybe a dwarf lizard there ;-)

I can send the actual patches on request, they do not contain any code I wrote 
myself ( other than changing numbers)



Regards,
Gunnar Roth




> Am 12.08.2016 um 18:26 schrieb Thiago Macieira :
> 
> On sexta-feira, 12 de agosto de 2016 14:03:24 PDT Gunnar Roth wrote:
>> Does a request of  having qtquickcontrols2 and qtvirtualkeyboard 2.1
>> backported to 5.6. x have chance? Actually I managed to do this myself, but
>> an upstream solutuion is preferrable. The problem is that some important OS
>> is no longer supported in 5.7. 
> 
> Quite impossible. Those are defintely new features.
> 
> However, there's a compromise: we can have a branch for the unofficial 
> support. 
> Anyone using that will know "there be dragons"
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Which changes are suitable for 5.6?

[Gunnar Roth]

Does a request of  having qtquickcontrols2 and qtvirtualkeyboard 2.1 backported to 5.6. x have chance?

Actually I managed to do this myself, but an upstream solutuion is preferrable. The problem is that some important OS is no longer supported in 5.7.

 

Regards,

Gunnar

 

 

Gesendet: Freitag, 12. August 2016 um 13:18 Uhr
Von: "Lars Knoll" 
An: "Olivier Goffart" 
Cc: "Qt development mailing list" 
Betreff: Re: [Development] Which changes are suitable for 5.6?


> On 12 Aug 2016, at 12:01, Olivier Goffart  wrote:
>
> On Freitag, 12. August 2016 10:52:52 CEST Marc Mutz wrote:
>> Hi,
>>
>> I'd like to know what the rules are supposed to for submitting to 5.6 (LTS).
>>
>> Should we enforce the strict rules of other minor releases (only regressions
>> and P2+)?
>>
>> IMHO, 5.6 is not like 5.5. So with another 2+ years of 5.6 lifetime, more
>> relaxed rules should apply.
>
> In my interpretation, LTS means it's just a stable branch, but that will stay
> maintained longer, with the same criterias as normal stable branches.
> [https://wiki.qt.io/Branch_Guidelines#Where_to_push_a_change.3F]
> That is, we make sure it works longer with more recent compiler/platform and
> keep security patches or crashes patches.

Yes, same criteria as normal stable branches apply. The difference is that we might (but don't have to) do some additional work to ensure 5.6 works on newer OS versions if they come out during the lifetime of 5.6.
>
>> I'd like all bug-fixes to go to 5.6 first, even if the priority is not high,
>> and regressions cannot be ruled out (they never can, anyway).
>
> I think that's not a good definition of a stable branch. Bugfixes are risky as
> they touch working code.
> Why not also add all features? Features are less risky to break stuff as they
> add new code and are often not affecting the existing users.

Agree. Bug fixes go in if they are regressions or critical issues that can't be worked around easily.
>
>> I also think that dead code elimination should be in-scope for 5.6, to not
>> construct unessesary diffs between 5.6 and dev.
>
> Is the code really dead? Is that patch not going to cause even more merge
> conflicts as we merge through the branches?

We'll have enough diff between the branches anyway. Dead code removal and other cleanups should always happen in dev, never in stable branches. If the code is dead, nobody will touch it in 5.6 anyway, so it most likely won't cause merge conflicts neither.
>
>> And last, some authors target optimisations at 5.6, some at 5.7 and others
>> (me included, even though I sympathise with submitting to 5.6) at dev/5.8.
>> What's the stance on this?
>
> Optimisations are usually quite dangerous, and may cause regressions.

Those go to dev. There can be exceptions, if e.g. a certain algorithm is showing exponential behaviour (thus rendering Qt unusable with large sets of data), but not for a patch that just makes something a couple of percent faster or reduces memory consumption by some bytes.

Cheers,
Lars

>
> --
> Olivier
>
> Woboq - Qt services and support - https://woboq.com - https://code.woboq.org
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development




___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Dropping VS 2012 in Qt 5.7

[Gunnar Roth]

Hello,
 
>The OpenSSL patch seems to be no release blocker for 5.6.0 as well as
Well that patch is also non criticical, but if it only lands in 5.6.1 , that ok 
for me.
>the sqlite build problem can only be seen if -qt-sql-sqlite is getting
>passed to configure. If nothing is specified, it defaults to plugin and
>does not break the build.

My experience is different. It breaks the build and i do no pass -qt-sql-sqlite 
 to configure.
Afaik -qt-sql-sqlite  means use qt included sqlite and this is the default.
What do you mean defaults to plugin? The sqlite is used for the plugin. there 
is choice between qt provided sqlite 
and system provided sqlite, but for wince and windows there is no such a thing 
like system provided sqlite.

Regards,
Gunnar roth
Am 01.03.2016 um 14:50 schrieb Gunnar Roth:
>
> Well so be it, goodbye Qt from wec2013 Users.
> But who takes care that changes for wec2013 in 5.7 and dev are merged back to 
> 5.6.x?
>
> I know at least of
>
> configure: Fix (Open)SSL detection on WinCE 
> (Merged)[https://codereview.qt-project.org/122437]
> https://codereview.qt-project.org/#/c/122437/[https://codereview.qt-project.org/#/c/122437/]
>
>
> Fixing the SQLite3 build for WEC2013 again.
> https://codereview.qt-project.org/#/c/115571/5[https://codereview.qt-project.org/#/c/115571/5]
>
>
>
>
> furthermore wec2013 x86 needs at least 2 patches to build.
> 1. a problem with the fake OleInitialize and OleUninitialize in 
> qtbase\src\plugins\platforms\windows\qplatformfunctions_wince.h, probably due 
> to calling convention.
> 2. bitscan intrinsic
> --- a\qtbase\src\corelib\tools\qsimd_p.h
> +++ b\qtbase\src\corelib\tools\qsimd_p.h
> @@ -430,11 +430,17 @@
> #define qCpuHasFeature(feature) ((qCompilerCpuFeatures & (Q_UINT64_C(1) << 
> CpuFeature ## feature)) \
> || (qCpuFeatures() & (Q_UINT64_C(1) << CpuFeature ## feature)))
>
> #ifdef Q_PROCESSOR_X86
> // Bit scan functions for x86
> -# if defined(Q_CC_MSVC) && !defined(Q_OS_WINCE)
> +# if defined(Q_CC_MSVC)
> +#if defined _WIN32_WCE && _WIN32_WCE < 0x800
> +extern "C" unsigned char _BitScanForward(unsigned long* Index, unsigned long 
> Mask);
> +extern "C" unsigned char _BitScanReverse(unsigned long* Index, unsigned long 
> Mask);
> +#pragma intrinsic(_BitScanForward)
> +#pragma intrinsic(_BitScanReverse)
> +#endif
> // MSVC calls it _BitScanReverse and returns the carry flag, which we don't 
> need
> static __forceinline unsigned long _bit_scan_reverse(uint val)
> {
> unsigned long result;
> _BitScanReverse(&result, val);
>
>
>
>
> and all programs using native file dialogs simply crash, qmlscene.exe for 
> example.
>
> --- a\qtbase\src\plugins\platforms\windows\qwindowsintegration.cpp
> +++ b\qtbase\src\plugins\platforms\windows\qwindowsintegration.cpp
> @@ -173,6 +173,10 @@
>
> static inline unsigned parseOptions(const QStringList ¶mList,
> int *tabletAbsoluteRange,
> QtWindows::ProcessDpiAwareness *dpiAwareness)
> {
> +#if defined _WIN32_WCE && _WIN32_WCE >= 0x800
> + unsigned options = QWindowsIntegration::NoNativeDialogs;
> +#else
> unsigned options = 0;
> +#endif
>
>
> a problem with spdy protocol occurs for me:
> diff -r -U 5 -N -x '*.orig' -x '*.rej' -x '*.bak' -x .git -x doc -x tests -x 
> examples a\qtbase\src\network\access/qspdyprotocolhandler.cpp 
> b\qtbase\src\network\access/qspdyprotocolhandler.cpp
> --- a\qtbase\src\network\access/qspdyprotocolhandler.cpp
> +++ b\qtbase\src\network\access/qspdyprotocolhandler.cpp
> @@ -31,5 +31,6 @@
> ** $QT_END_LICENSE$
> **
> /
>
> #include 
> +#undef ZLIB_H // this makes qfunctions_wince.h line 201 stuff not break the 
> build for wince
>
>
> and a fix to allow to use sse2 ( and opensll):
> --- a\qtbase\tools\configure\configureapp.cpp
> +++ b\qtbase\tools\configure\configureapp.cpp
> @@ -1698,20 +1698,10 @@
> dictionary[ "STYLE_WINDOWSVISTA" ] = "no";
> dictionary[ "STYLE_FUSION" ] = "no";
> dictionary[ "STYLE_WINDOWSCE" ] = "yes";
> dictionary[ "STYLE_WINDOWSMOBILE" ] = "yes";
> dictionary[ "OPENGL" ] = "no";
> - dictionary[ "SSL" ] = "no";
> - dictionary[ "OPENSSL" ] = "no";
> - dictionary[ "RTTI" ] = "no";
> - dictionary[ "SSE2" ] = "no";
> - dictionary[ "SSE3" ] = "no";
> - dictionary[ "SSSE3" ] = "no";
> - dictionary[ "SSE4_1" ] = "no";
> - dictio

Re: [Development] debug symbols for official Qt releases

[Gunnar Roth]

>On 2016-03-01, Milian Wolff  wrote:
>> b) Apparently there are never any debug symbols shipped for the release build
>> fo Qt. Having debug symbols even for a release build is crucial for a good
>> profiling experience. Could we maybe get release builds in the future with -
>> force-debug-info to improve this situation? I'm aware that one can get some
>> sense out of a profiler when only the end-level application is build in that
>> way, but one can often get much more insight when the stack below (or even 
>> in-
>> between for the eventloop and signal/slot magic) also gets annotated stack
>> frames. Right now, I have to suggest people to build Qt themselves for the
>> sole purpose of profiling... A pity!
>
>This would be amazing. Also for getting better backtraces from crashes
>at users systems.

I normally use release build always even for debugging. It were also nice if Qt
would set the enhanced pdb option to get better release debugging experience,
/d2Zi+ option for vs2012 and /Zo for Vs2013 upd3 and VS2015.

As i have other reasons to always build Qt myself and maintain patches others 
than these,
i have no real problem with the current state, but would still be glad if pdb 
for release are build
and delivered with the enhanced pdb option.

Regards,
Gunnar Roth




 
 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Dropping VS 2012 in Qt 5.7

[Gunnar Roth]

Well so be it, goodbye Qt from wec2013 Users. 
But who takes care that changes for wec2013 in 5.7 and dev are merged back to 
5.6.x?
 
I know at least of

configure: Fix (Open)SSL detection on WinCE 
(Merged)[https://codereview.qt-project.org/122437]
https://codereview.qt-project.org/#/c/122437/

 
Fixing the SQLite3 build for WEC2013 again.
https://codereview.qt-project.org/#/c/115571/5
 
 


furthermore wec2013 x86 needs at least 2 patches to build.
1. a problem with the fake  OleInitialize and OleUninitialize in 
qtbase\src\plugins\platforms\windows\qplatformfunctions_wince.h, probably due 
to calling convention.
2. bitscan intrinsic
--- a\qtbase\src\corelib\tools\qsimd_p.h
+++ b\qtbase\src\corelib\tools\qsimd_p.h
@@ -430,11 +430,17 @@
 #define qCpuHasFeature(feature) ((qCompilerCpuFeatures & (Q_UINT64_C(1) << 
CpuFeature ## feature)) \
  || (qCpuFeatures() & (Q_UINT64_C(1) << 
CpuFeature ## feature)))
 
 #ifdef Q_PROCESSOR_X86
 // Bit scan functions for x86
-#  if defined(Q_CC_MSVC) && !defined(Q_OS_WINCE)
+#  if defined(Q_CC_MSVC) 
+#if defined _WIN32_WCE && _WIN32_WCE < 0x800
+extern "C" unsigned char _BitScanForward(unsigned long* Index, unsigned long 
Mask);
+extern "C" unsigned char _BitScanReverse(unsigned long* Index, unsigned long 
Mask);
+#pragma intrinsic(_BitScanForward)
+#pragma intrinsic(_BitScanReverse)
+#endif
 // MSVC calls it _BitScanReverse and returns the carry flag, which we don't 
need
 static __forceinline unsigned long _bit_scan_reverse(uint val)
 {
 unsigned long result;
 _BitScanReverse(&result, val);




and all programs using native file dialogs simply crash, qmlscene.exe for 
example.

--- a\qtbase\src\plugins\platforms\windows\qwindowsintegration.cpp
+++ b\qtbase\src\plugins\platforms\windows\qwindowsintegration.cpp
@@ -173,6 +173,10 @@
 
 static inline unsigned parseOptions(const QStringList ¶mList,
 int *tabletAbsoluteRange,
 QtWindows::ProcessDpiAwareness 
*dpiAwareness)
 {
+#if defined _WIN32_WCE && _WIN32_WCE >= 0x800
+unsigned options = QWindowsIntegration::NoNativeDialogs;
+#else
 unsigned options = 0;
+#endif


a problem with spdy protocol occurs for me:
diff -r -U 5 -N -x '*.orig' -x '*.rej' -x '*.bak' -x .git -x doc -x tests -x 
examples a\qtbase\src\network\access/qspdyprotocolhandler.cpp 
b\qtbase\src\network\access/qspdyprotocolhandler.cpp
--- a\qtbase\src\network\access/qspdyprotocolhandler.cpp
+++ b\qtbase\src\network\access/qspdyprotocolhandler.cpp
@@ -31,5 +31,6 @@
 ** $QT_END_LICENSE$
 **
 /
 
 #include 
+#undef ZLIB_H // this makes qfunctions_wince.h line 201 stuff not break the 
build for wince


and a fix to allow to use sse2 ( and opensll):
--- a\qtbase\tools\configure\configureapp.cpp
+++ b\qtbase\tools\configure\configureapp.cpp
@@ -1698,20 +1698,10 @@
 dictionary[ "STYLE_WINDOWSVISTA" ]  = "no";
 dictionary[ "STYLE_FUSION" ]= "no";
 dictionary[ "STYLE_WINDOWSCE" ] = "yes";
 dictionary[ "STYLE_WINDOWSMOBILE" ] = "yes";
 dictionary[ "OPENGL" ]  = "no";
-dictionary[ "SSL" ] = "no";
-dictionary[ "OPENSSL" ] = "no";
-dictionary[ "RTTI" ]= "no";
-dictionary[ "SSE2" ]= "no";
-dictionary[ "SSE3" ]= "no";
-dictionary[ "SSSE3" ]   = "no";
-dictionary[ "SSE4_1" ]  = "no";
-dictionary[ "SSE4_2" ]  = "no";
-dictionary[ "AVX" ] = "no";
-dictionary[ "AVX2" ]= "no";
 dictionary[ "CE_CRT" ]  = "yes";
 dictionary[ "LARGE_FILE" ]  = "no";
 dictionary[ "ANGLE" ]   = "no";
 dictionary[ "DYNAMICGL" ]   = "no";
 if (dictionary[ "XQMAKESPEC" ].startsWith("wincewm")) {



Regards,
Gunnar Roth


Gesendet: Dienstag, 01. März 2016 um 08:38 Uhr
Von: "Heikkinen Jani" 
An: "Thiago Macieira" , "development@qt-project.org" 

Betreff: Re: [Development] Dropping VS 2012 in Qt 5.7
Done, please review

Br,
Jani

>>-Original Message-
>>From: Development [mailto:development-
>>bounces+jani.heikkinen=theqtcompany@qt-project.org] On Behalf Of
>>Thiago 

Re: [Development] Supported platforms for Qt 5.8

[Gunnar Roth]

Hi,
I also like to add that  Win10 IoT is NOT THE successor for wec2013. MS will 
offer some porting tools,
but as you can see here 
http://embeddingwindowssuccess.blogspot.de/2015/03/the-future-of-windows-embedded-windows.html
 

the wec2013 line is continuing, while all other lines end into the windows10 
line. The reason is that none of the windows 10 editions has realtime support,
so if you want to (or have to ) use  a MS OS and you need realtime, wec2013 is 
what is left.

Regards,
Gunnar
PS.: We are asking our MS contact again because of the MSDN page statements.


> Am 23.02.2016 um 19:16 schrieb Andreas Holzammer :
> 
> Am 22.02.2016 um 23:52 schrieb Thiago Macieira:
>> On segunda-feira, 22 de fevereiro de 2016 21:08:12 PST Knoll Lars wrote:
>>> I can see the reasoning here, just as well as I see the reasoning of the
>>> people that would like to get rid of VS2012 as quickly as possible.
>> 
>> Why do we need to get rid of it? What are the problems with it, aside from 
>> lack of certain C++11 support?
>> 
> 
> Mostly yes we see a demand in getting new c++ features into Qt. As far
> as my knowlege goes is that WEC2013 bundles they compiler with the SDK
> which is produced by the Platform Builder. As of now I did not see any
> indication that this bundled compiler will be updated(right now they
> bundle the VS2012 compiler). All websites which I did read say if you
> read closely that they are supporting the new Visual Studio IDE, but
> will take the toolchain of the SDK which is provided.
> 
> Basically it means we are stuck with Visual Studio 2012 c++ featureset
> for Windows Embedded Compact 2013.
> 
> If we want to support newer C++ with Qt 5.8 we would need to drop the
> complete platform.
> 
> As of problems to support it in newer Qt Versions, I can say the market
> share right now is not very big, as also already indicated by someone
> else. Hardware vendors do release right now more experimental support
> for WEC2013, which means there might be years until they reach a decent
> market share.
> 
> Thank you
> 
> Andy
> 
> 
> 
> -- 
> Andreas Holzammer | andreas.holzam...@kdab.com | Senior Software Engineer
> KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
> Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
> KDAB - Qt Experts - Platform-independent software solutions
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Supported platforms for Qt 5.8

[Gunnar Roth]

This is a deja vu to me, somehow.

please have a look at this discussion https://www.mail-archive.com/search?l=development@qt-project.org&q=subject:%22Re%5C%3A+%5C%5BDevelopment%5C%5D+QtCS%5C%3A+Long+Term+Release+discussion%22&o=newest&f=1

 

To quote myself:

"
 Hi Björn, i had the assumption you could mean that, but thats not a
 knowledge base article. I think you mean Compact 2013 uses the Microsoft
 Visual Studio 2013 compiler,? That part was also sent to me by a colleage
 from another department when discussing v8 usage( as this has vs2013
 depedancy according to wiki).  So we startet a MS Request to clear this
 issue. The answer was that the arcticle is wrong here."

 

MS promised to fix that article but maybe they need some more years for that.



 

By the way I am strongly against droping wec2013 support after just one other version, actually support for wec2013

has not yet arrived yet. So this is probaly unique for a platform supported by qt , where the deprecation announcement comes before the release of the actual platform support.

 

There is also a some importat stuff missing for wec2013 in qt 5.6 beta like no quick2 controls support, no webkit/engine support  and no multimedia support, no neon intrinsics support, no openssl support, no sse2 support.

 

Regards,

Gunnar Roth

 

Gesendet: Montag, 22. Februar 2016 um 17:01 Uhr


Von: "Andrew Knight" 
An: development@qt-project.org
Betreff: Re: [Development] Supported platforms for Qt 5.8

On 02/22/2016 05:54 PM, Thiago Macieira wrote:
> On segunda-feira, 22 de fevereiro de 2016 14:59:52 PST Roger Briggen wrote:
>> WEC2013 is also supported by Visual Studio 2013 and Visual Studio 2015
>> (according to https://msdn.microsoft.com/en-us/library/gg154234.aspx)
>> because it uses now the ARM Desktop Compiler.
>> So dropping VS2012 must not be the end of WEC2013 support of Qt.
> Hi Roger
>
> That is IDE support using the compiler from VS2012. When we say we drop
> support for a compiler, we don't mean the IDE that you're using.
>

That link clearly states that the MSVC2013 compiler is now used with
WEC2013 Update 5 and 11, as is the latest C runtime. So, this indeed
looks like a compiler and C runtime upgrade, not simply the new IDE
targeting the old compiler.

Maybe someone with a WEC2013 installation can check this out in practice?

Andrew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QStringLiteral vs QLatin1String , foreach vs for range

[Gunnar Roth]

Thank you Thiago.

 


Actually I meant ucomparing a QString with a QStringLiteral when i said " both
strings being uft16 seems to be faster ".

So what i learned now on an x85 with avx support is should be no performance problem.

But what about a wec2013 with arm, as qt does not support neon for wec2013.

Qt does not even support sse2 for wec because configureap.cpp does always reset sse2 to no, even if i pass it to configure.

Same as the openssl problem, which was solved in dev branch. https://codereview.qt-project.org/#/c/122437/

 

Regards

Gunnar Roth


Gesendet: Montag, 18. Januar 2016 um 00:28 Uhr
Von: "Thiago Macieira" 
An: development@qt-project.org
Betreff: Re: [Development] QStringLiteral vs QLatin1String , foreach vs for range

On Sunday 17 January 2016 22:22:39 Gunnar Roth wrote:
> why is QLatin1String more efficient than QLiteralString in this case? both
> strings being uft16 seems to be faster for, you could use size_t chunks
> for comparison for example.

Your premise is wrong. The QLatin1String is not stored as UTF-16. It's stored
as Latin1.

If you're asking about runtime performance, it's because we have algorithms to
perform the operation without converting in the common case scenario.

Take the equality operator and QString::compare: sure it's more efficient to do
binary compares of two QChars, especially if you can unroll the loop and do
SIMD (like we do, see [1]). But if your initial data is Latin1, you'd need to
incur a performance penalty to allocate memory and then convert from Latin1 to
UTF-16 before doing the comparison. So QString has a UTF-16-to-Latin1
comparison, which is quite efficient (and also SIMD-enabled, see [2]).

Maybe in some cases the UTF16-to-Latin1 operation is slower than pure UTF-16,
but is almost always faster than the combined malloc+convert+operate+free. In
this particular case, the ucstrncmp for uchar is either as fast as the QChar
one, or in the case of AVX2, possibly even faster in longer strings (less
memory being read).

[1]
https://code.woboq.org/qt5/qtbase/src/corelib/tools/qstring.cpp.html#_ZL9ucstrncmpPK5QCharS1_i
[2]
https://code.woboq.org/qt5/qtbase/src/corelib/tools/qstring.cpp.html#_ZL9ucstrncmpPK5QCharPKhi
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QStringLiteral vs QLatin1String , foreach vs for range

[Gunnar Roth]

Hi, thanks for answering, but

> Am 17.01.2016 um 20:36 schrieb Thiago Macieira :
> 
> On Sunday 17 January 2016 19:13:44 Gunnar Roth wrote:
>> Hi,
>> I saw quite some changes like https://codereview.qt-project.org/#/c/145961/
>> <https://codereview.qt-project.org/#/c/145961/>  Replace QStringLiteral
>> with QLatin1String in QFileSelector. I also read about the problem of
>> QStringLiteral concerning plugins, but what is the idea behind these
>> changes ?
> 
> QLatin1String is more efficient if you're calling a method that has a 
> QLatin1String overload, like most methods in QString itself.
> 
why is QLatin1String more efficient than QLiteralString in this case? both 
strings  being uft16 seems to be faster for, you could use size_t chunks for 
comparison for example.

Regards,
Gunnar


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QStringLiteral vs QLatin1String , foreach vs for range

[Gunnar Roth]

Hi,
I saw quite some changes like https://codereview.qt-project.org/#/c/145961/ 
<https://codereview.qt-project.org/#/c/145961/>  Replace QStringLiteral with 
QLatin1String in QFileSelector.
I also read about the problem of QStringLiteral concerning plugins, but what is 
the idea behind these changes ? 

There is also a lot of replacing foreach with range for loops? What is the idea 
behind this? Any links to read?


Regards,
Gunnar Roth

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] wec2013 build fails with qt 5.6 beta in dbus.

[Gunnar Roth]

Sorry but
1. -no-dbus is sufficient for me.
2. i am on leave now and will return to work not before Epiphany 
<https://www.dict.cc/englisch-deutsch/Epiphany.html>. 

Regards,
Gunnar


> Am 22.12.2015 um 18:07 schrieb Bornemann Joerg 
> :
> 
> On Monday 21 December 2015 21:58:46 Gunnar Roth wrote:
> 
>> It's an unfortunate side effect of the configure.exe changes that enable 
>> QtDBus
>> on all platforms. The code does work on Windows CE, but you have to figure 
>> out
>> why windows.h got included when it shouldn't have or tell it to stop
>> #define'ing interface.
> 
> There's a  include in mkspecs/common/wince/qplatformdefs.h.
> All of this sounds a lot like we need something like 
> 32f957ccc68084fe11fcf23823c5094a1833a790 for this mkspec.
> Gunnar, does https://codereview.qt-project.org/#/c/144600/ fix the problem 
> for you?
> 
> 
> BR,
> 
> Joerg
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Solution for Build errors in Qt Commercial Charts module 2.1 in qt 5.6 beta

[Gunnar Roth]

moc tells me Error: Undefined interface

and he is right.

 

Charts\2.1\Src\charts\axis\polarchartaxis_p.h Charts\2.1\Src\charts\axis\cartesianchartaxis_p.h need

#include 

 

Charts\2.1\Src\charts\linechart\linechartitem_p.h Charts\2.1\Src\charts\splinechart\splinechartitem_p.h need


#include 


in Charts\2.1\Src\

create a directory .git else the Charts/2.1/Src/include/QtCharts/2.1.0 dir and files are not created and private header will not be found.

 

The experiences of today show me that the Qt Companies release process has some drawbacks in making sure that users making their own build of the products, actually have success.

 

 

Regards,

Gunnar

 


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.6.0 beta. win32 vs11 32 bit fails with uic.exe showing dialog qt5core.dll cannot be found.

[Gunnar Roth]

I am now using this qt_functions.prf and that works fine.

Regards,

Gunnar

 

Gesendet: Dienstag, 22. Dezember 2015 um 15:05 Uhr
Von: "Adam Light" 
An: Kein Empfänger
Cc: "development@qt-project.org" 
Betreff: Re: [Development] Qt 5.6.0 beta. win32 vs11 32 bit fails with uic.exe showing dialog qt5core.dll cannot be found.


 
 
On Tue, Dec 22, 2015 at 1:43 AM, Gunnar Roth <gunnar.r...@gmx.de> wrote:




Hello,

 

when i used jom i get this dialog with qt5core not found.

When using nmake i get this error:

 




 

For what it's worth, I created a bug report about this about a week ago at https://bugreports.qt.io/browse/QTBUG-49985.

 

Adam 



___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development



qt_functions.prf
Description: application/pics-rules
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] wec2013 build fails with qt 5.6 beta in dbus.

[Gunnar Roth]

You tested the code on wince with which dbus component?

 

windows.h probaly got included by the special qt wince headers.

 

I wonder why there is a CI for wec2012, which did not catch that problem. 

 


Regards,

Gunnar


Gesendet: Dienstag, 22. Dezember 2015 um 15:01 Uhr
Von: "Thiago Macieira" 
An: development@qt-project.org
Betreff: Re: [Development] wec2013 build fails with qt 5.6 beta in dbus.

On Monday 21 December 2015 21:58:46 Gunnar Roth wrote:
> How am I supposed know? It worked without that since 5.2.1. How should
> anybody know that now -no-dbus is needed.

It's an unfortunate side effect of the configure.exe changes that enable QtDBus
on all platforms. The code does work on Windows CE, but you have to figure out
why windows.h got included when it shouldn't have or tell it to stop
#define'ing interface.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.6.0 beta. win32 vs11 32 bit fails with uic.exe showing dialog qt5core.dll cannot be found.

[Gunnar Roth]

I found this change:

--- a/qtbase/mkspecs/features/qt_functions.prf
+++ a/qtbase/mkspecs/features/qt_functions.prf

 

# variable, default, [suffix for variable for system() use], [prepare primary variable for system() use]
 defineTest(qtPrepareTool) {
     cmd = $$eval(QT_TOOL.$${2}.binary)
@@ -261,15 +120,9 @@
     deps = $$replace($$2, -private$, _private)
     deps = $$resolve_depends(deps, "QT.", ".depends" ".run_depends")
     !isEmpty(deps) {
-        ptypes =
-        for(dep, deps) {
-            isEmpty(3): \
-                deppath += $$shell_path($$eval(QT.$${dep}.libs))
-            else: \
-                deppath += $$system_path($$eval(QT.$${dep}.libs))
-            ptypes += $$eval(QT.$${dep}.plugin_types)
-        }
+        libs = libs
         equals(QMAKE_HOST.os, Windows) {
+            libs = bins
             deppath.name = PATH
         } else:contains(QMAKE_HOST.os, Linux|FreeBSD|OpenBSD|NetBSD|DragonFly|SunOS|HP-UX|QNX|GNU) {
             deppath.name = LD_LIBRARY_PATH
@@ -284,6 +137,14 @@
             deppath.name = LIBPATH
         } else {
             error("Operating system not supported.")
+        }
+        ptypes =
+        for(dep, deps) {
+            isEmpty(3): \
+                deppath += $$shell_path($$eval(QT.$${dep}.$$libs))
+            else: \
+                deppath += $$system_path($$eval(QT.$${dep}.$$libs))
+            ptypes += $$eval(QT.$${dep}.plugin_types)
         }
         deppath.value = $$unique(deppath)
         deppath.CONFIG = prepend

 

 


         equals(QMAKE_HOST.os, Windows) {
+            libs = bins

looks very suspicios. git blame tells me:

9b2e9824 (Oswald Buddenhagen 2015-11-20 19:04:11 +0100 125)             libs = bins

 

the commit message says:


commit 9b2e98245a95bec9179edf648d7b562d2d1cb692
Author: Oswald Buddenhagen 
Date:   Fri Nov 20 19:04:11 2015 +0100

    use bindir instead of libdir when launching tools on windows

    longer term, the redundant .dlls from the libdir will hopefully
    disappear. short term, this is a workaround for CI brokenness.

    Change-Id: Ia30173355f3aca222d4ca40e7a38c2cf535bbc03
    Reviewed-by: Joerg Bornemann 

 

 

But for me the dlls in lib are not redundant, they are the only ones.

 

Googling the change id io found:




	
		
			Oswald Buddenhagen
			 
			Dec 11 2:51 PM
		
	




Patch Set 2:

this is actually full of fail, as it breaks *proper* prefix builds - they don't have the redundant .dlls in bin (the copy step is simply omitted). so we have yet another change (the revert of this) which depends on the CI doing the right thing ...






	
		
	
	
		
			 
			Maurice Kalinowski
			 
			Dec 11 2:53 PM
		
	




Patch Set 2:

Actually it was Kai who introduced skipping the copy. You can check with him to clean up ;)






	
		
	
	
		
			 
			Oswald Buddenhagen
			 
			Dec 14 4:28 PM
		
	




Patch Set 2:

it doesn't matter who did it - it was the right thing to do, and i certainly approved.

https://codereview.qt-project.org/143709 contains the revert, which blocks the 5.6 release (i think we actually shouldn't even release a beta before my three stalled p1 fixes are in, but ...).





 

So this issue is known since dez 14 and beta was released without the fix.


Revert "use bindir instead of libdir when launching tools on windows"

proper prefix builds don't have the redundant .dlls in bin (the copy
step is simply omitted), so this is broken. the change would have to be
done atomically with making DLLDESTDIR sane.


This reverts commit 9b2e98245a95bec9179edf648d7b562d2d1cb692.

 
Change-Id: I9ce0a2d1147a1a2d4bd2f22e619d5c737864a637

 

 

 

I have a prefix build, as everybody should IMO.


 

That makes me very sad...wasted hours of my life. 

 

Regards,

Gunnar

 

 

 



Gesendet: Dienstag, 22. Dezember 2015 um 12:53 Uhr
Von: "Tim Blechmann" 
An: development@qt-project.org
Betreff: Re: [Development] Qt 5.6.0 beta. win32 vs11 32 bit fails with uic.exe showing dialog qt5core.dll cannot be found.

> The thing is that in Qt 5.5.1, uic.exe and qlalr.exe were also build
> using qtcore dll, but there this was not a problem.
> In wec build they are always build statically, i think that should be
> made uniform.
>
> Now that I look closer i see the cause of the problem:
> set PATH=D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\bin
> vs.
> set PATH=D:\TFS\bld__GLOBAL\Qt5.5.1\WIN32-VS11-32\qtbase\lib
>
> So actually anyone who successfully build qt 5.6 beta on windows seems
> to have some directory containing a Qt5Core.dll in the PATH env variable.

... hmm ... i ran into this issue before with rcc (iirc), but not with
uic or qlalr ...

btw, qt's translation tools also fail to run for me:
https://codereview.qt-project.org/#/c/144558/

hope with these two patches, msvc/dll builds work again ...

cheers,
tim


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



___

Re: [Development] Qt 5.6.0 beta. win32 vs11 32 bit fails with uic.exe showing dialog qt5core.dll cannot be found.

[Gunnar Roth]

Hi Tim,

no you are not hallucinating , or you at least your are not the only one hallucinating ;-)

 

 


The thing is that in Qt 5.5.1, uic.exe and qlalr.exe were also build using qtcore dll, but there this was not a problem.

In wec build they are always build statically, i think that should be made uniform. 

 

Now that I look closer i see the cause of the problem:

set PATH=D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\bin

vs.

set PATH=D:\TFS\bld__GLOBAL\Qt5.5.1\WIN32-VS11-32\qtbase\lib

 

So actually anyone who successfully build qt 5.6 beta on windows seems to have some directory containing a Qt5Core.dll in the PATH env variable.

Regards,

Gunnar

 


Gesendet: Dienstag, 22. Dezember 2015 um 11:17 Uhr
Von: "Tim Blechmann" 
An: development@qt-project.org
Betreff: Re: [Development] Qt 5.6.0 beta. win32 vs11 32 bit fails with uic.exe showing dialog qt5core.dll cannot be found.

> I found out that the % is due to using jom in 5.5.1 and nmake in 5.6.1.
> I looked into the Makefiles and bot had the same term. When i use jom
> for 5.6 i see (set
> QT_PLUGIN_PATH=D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\plugins)
> & (set
> PATH=D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\bin;%%PATH:)=^)%%)
> & D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\bin\uic.exe
> D:\TFS\_Global\Shared\src\Qt\5.6.0\qt-src\qtbase\src\widgets\dialogs\qfiledialog.ui
> -o .uic\ui_qfiledialog.h
> which has also %%PATH:)=^)%% , so that is not the problem. wec2013 works
> because there uic.exe and qlarl.exe are build statically.

seems that i'm not hallucinating then:
https://codereview.qt-project.org/#/c/144550/

> Regards,
> Gunnar
>
> *Gesendet:* Dienstag, 22. Dezember 2015 um 10:43 Uhr
> *Von:* "Gunnar Roth" 
> *An:* "development@qt-project.org" 
> *Betreff:* [Development] Qt 5.6.0 beta. win32 vs11 32 bit fails with
> uic.exe showing dialog qt5core.dll cannot be found.
> Hello,
>
> when i used jom i get this dialog with qt5core not found.
> When using nmake i get this error:
> (set
> QT_PLUGIN_PATH=D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\plugins)
> & (set PATH=D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\bin;%PATH:)=^)%
> ) & D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\bin\uic.exe
> D:\TFS\_Global\Shared\src\Qt\5.6.0\qt-src\qtbase\src\widgets\dialogs\qfiledialog.ui
> -o .uic\ui_q
> filedialog.h
> NMAKE : fatal error U1077: '(set' : return code '0xc135'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> Studio 11.0\VC\BIN\nmake.exe"' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: 'cd' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: 'cd' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: 'cd' : return code '0x2'
>
>
> Looking into a successful 5.5.1 build log i see
>
> (set
> QT_PLUGIN_PATH=D:\TFS\bld__GLOBAL\Qt5.5.1\WIN32-VS11-32\qtbase\plugins)
> & (set
> PATH=D:\TFS\bld__GLOBAL\Qt5.5.1\WIN32-VS11-32\qtbase\lib;%%PATH:)=^)%%)
> & D:\TFS\bld__GLOBAL\Qt5.5.1\WIN32-VS11-32\qtbase\bin\uic.exe
> D:\TFS\_Global\Shared\src\Qt\5.5.1\qt-src\qtbase\src\widgets\dialogs\qfiledialog.ui
> -o .uic\ui_qfiledialog.h
> and in my 5.6.0 build
> (set
> QT_PLUGIN_PATH=D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\plugins)
> & (set
> PATH=D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\bin;%PATH:)=^)%) &
> D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\bin\uic.exe
> D:\TFS\_Global\Shared\src\Qt\5.6.0\qt-src\qtbase\src\widgets\dialogs\qfiledialog.ui
> -o .uic\ui_qfiledialog.h
>
> so %%PATH:)=^)%% is now %PATH:)=^)%.
>
> How did CI not catch that? Strange is my wec2013 build has worked after
> adding -no-dbus.
>
> Regards,
> Gunnar
>
> ___ Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.6.0 beta. win32 vs11 32 bit fails with uic.exe showing dialog qt5core.dll cannot be found.

[Gunnar Roth]

I found out that the % is due to using jom in 5.5.1 and nmake in 5.6.1. I looked into the Makefiles and bot had the same term. When i use jom for 5.6 i see (set QT_PLUGIN_PATH=D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\plugins) & (set PATH=D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\bin;%%PATH:)=^)%%) & D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\bin\uic.exe D:\TFS\_Global\Shared\src\Qt\5.6.0\qt-src\qtbase\src\widgets\dialogs\qfiledialog.ui -o .uic\ui_qfiledialog.h

which has also %%PATH:)=^)%% , so that is not the problem. wec2013 works because there uic.exe and qlarl.exe are build statically.

 


Regards,

Gunnar

 


Gesendet: Dienstag, 22. Dezember 2015 um 10:43 Uhr
Von: "Gunnar Roth" 
An: "development@qt-project.org" 
Betreff: [Development] Qt 5.6.0 beta. win32 vs11 32 bit fails with uic.exe showing dialog qt5core.dll cannot be found.



Hello,

 

when i used jom i get this dialog with qt5core not found.

When using nmake i get this error:

        (set QT_PLUGIN_PATH=D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\plugins) & (set PATH=D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\bin;%PATH:)=^)%
) & D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\bin\uic.exe D:\TFS\_Global\Shared\src\Qt\5.6.0\qt-src\qtbase\src\widgets\dialogs\qfiledialog.ui -o .uic\ui_q
filedialog.h
NMAKE : fatal error U1077: '(set' : return code '0xc135'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: 'cd' : return code '0x2'
Stop.
NMAKE : fatal error U1077: 'cd' : return code '0x2'
Stop.
NMAKE : fatal error U1077: 'cd' : return code '0x2'

 

 

Looking into a successful 5.5.1 build log i see

 

(set QT_PLUGIN_PATH=D:\TFS\bld__GLOBAL\Qt5.5.1\WIN32-VS11-32\qtbase\plugins) & (set PATH=D:\TFS\bld__GLOBAL\Qt5.5.1\WIN32-VS11-32\qtbase\lib;%%PATH:)=^)%%) & D:\TFS\bld__GLOBAL\Qt5.5.1\WIN32-VS11-32\qtbase\bin\uic.exe D:\TFS\_Global\Shared\src\Qt\5.5.1\qt-src\qtbase\src\widgets\dialogs\qfiledialog.ui -o .uic\ui_qfiledialog.h

and in my 5.6.0 build

(set QT_PLUGIN_PATH=D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\plugins) & (set PATH=D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\bin;%PATH:)=^)%) & D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\bin\uic.exe D:\TFS\_Global\Shared\src\Qt\5.6.0\qt-src\qtbase\src\widgets\dialogs\qfiledialog.ui -o .uic\ui_qfiledialog.h

 

so %%PATH:)=^)%% is now %PATH:)=^)%.

 

How did CI not catch that? Strange is  my wec2013 build has worked after adding -no-dbus.

 

Regards,

Gunnar

 

___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt 5.6.0 beta. win32 vs11 32 bit fails with uic.exe showing dialog qt5core.dll cannot be found.

[Gunnar Roth]

Hello,

 

when i used jom i get this dialog with qt5core not found.

When using nmake i get this error:

        (set QT_PLUGIN_PATH=D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\plugins) & (set PATH=D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\bin;%PATH:)=^)%
) & D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\bin\uic.exe D:\TFS\_Global\Shared\src\Qt\5.6.0\qt-src\qtbase\src\widgets\dialogs\qfiledialog.ui -o .uic\ui_q
filedialog.h
NMAKE : fatal error U1077: '(set' : return code '0xc135'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: 'cd' : return code '0x2'
Stop.
NMAKE : fatal error U1077: 'cd' : return code '0x2'
Stop.
NMAKE : fatal error U1077: 'cd' : return code '0x2'

 

 

Looking into a successful 5.5.1 build log i see

 

(set QT_PLUGIN_PATH=D:\TFS\bld__GLOBAL\Qt5.5.1\WIN32-VS11-32\qtbase\plugins) & (set PATH=D:\TFS\bld__GLOBAL\Qt5.5.1\WIN32-VS11-32\qtbase\lib;%%PATH:)=^)%%) & D:\TFS\bld__GLOBAL\Qt5.5.1\WIN32-VS11-32\qtbase\bin\uic.exe D:\TFS\_Global\Shared\src\Qt\5.5.1\qt-src\qtbase\src\widgets\dialogs\qfiledialog.ui -o .uic\ui_qfiledialog.h

and in my 5.6.0 build

(set QT_PLUGIN_PATH=D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\plugins) & (set PATH=D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\bin;%PATH:)=^)%) & D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\bin\uic.exe D:\TFS\_Global\Shared\src\Qt\5.6.0\qt-src\qtbase\src\widgets\dialogs\qfiledialog.ui -o .uic\ui_qfiledialog.h

 

so %%PATH:)=^)%% is now %PATH:)=^)%.

 

How did CI not catch that? Strange is  my wec2013 build has worked after adding -no-dbus.

 

Regards,

Gunnar

 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] wec2013 build fails with qt 5.6 beta in dbus.

[Gunnar Roth]

Hi Simon.
The conflict happens in a dozen files in qtbase/src/dbus/ and qttools/src/qdbus.

I just wrote my mail so other can save the time i spend on figuring out what is 
wrong with the new qt version.
As I wrote in another mail, for wince bus should be set to no by default, as it 
was before ( because it was no for windows but is runtime now, when no bus 
headers are found)
I know of no working dbus for wec2013 and i don’t need it either.

Regards,
Gunnar


> Am 21.12.2015 um 22:22 schrieb Hausmann Simon 
> :
> 
> We ran into similar issues in a few places and the established workaround is 
> a carefully placed #undef interface. Would you be able to tell us where the 
> conflict happened or maybe even make a patch? (see qtnetwork for a similar 
> #undef)
> 
> 
> Simon
> 
> From: Gunnar Roth
> Sent: Monday, December 21, 2015 17:44
> To: development@qt-project.org
> Subject: [Development] wec2013 build fails with qt 5.6 beta in dbus.
> 
> Hi,
> the problem is that dbus is set to runtime instead of no for windows from 
> configure when no dbus support is found. So it is being tried to build it, 
> which fails,
> mostly due to using 'interface' as identifier, which seems to be a define 
> somewhere in the wec2013 headers. I wil add -no-dbus to my configure line.
>  
> I assume there is no ci in place for wec2013?
>  
> Regards,
> Gunnar
>  
>  
>  

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] wec2013 build fails with qt 5.6 beta in dbus.

[Gunnar Roth]

Hi Thiago,
> Am 21.12.2015 um 19:46 schrieb Thiago Macieira :
> 
> On Monday 21 December 2015 17:44:19 Gunnar Roth wrote:
>> Hi,
>> the problem is that dbus is set to runtime instead of no for windows from
>> configure when no dbus support is found. So it is being tried to build it,
>> which fails, mostly due to using 'interface' as identifier, which seems to
>> be a define somewhere in the wec2013 headers. I wil add -no-dbus to my
>> configure line. 
>> I assume there is no ci in place for wec2013?
> 
> There is and it probably has -no-dbus.


How am I supposed know? It worked without that since 5.2.1.  How should anybody 
know that now -no-dbus is needed. Why has configure app.cpp so many special 
cases for ce, which disable ssl even if you give -openssl to configure ( fixed 
in dev) or disable sse(2) for ce, even if you give -sse2 to configure, which is 
a use case when having an x86 wec2013? But there is no bus disabling, which 
would actually make sense and the other before mentioned cases do not.


Regards,
Gunnar
 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] wec2013 build fails with qt 5.6 beta in dbus.

[Gunnar Roth]

Hi,

the problem is that dbus is set to runtime instead of no for windows from configure when no dbus support is found. So it is being tried to build it, which fails,

mostly due to using 'interface' as identifier, which seems to be a define somewhere in the wec2013 headers. I wil add -no-dbus to my configure line.

 

I assume there is no ci in place for wec2013?

 

Regards,

Gunnar

 

 

 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QT_NO_DRAGANDDROP qt 5.6 git build fails

[Gunnar Roth]

Hello Samuel and Giuseppe 

 

i am not capable to create a patch in qt gerrrit. i get an http 403 error as written in an previous mail.

So maybe one of you could do me the favour and create patches in gerrit for me?

I made some patch diff files gainst qt 5.6 for this issue and attached them to this mail.

 


Regards,

Gunnar Roth


Gesendet: Mittwoch, 02. September 2015 um 16:06 Uhr
Von: "Samuel Gaist" 
An: "Giuseppe D'Angelo" 
Cc: development@qt-project.org
Betreff: Re: [Development] QT_NO_DRAGANDDROP qt 5.6 git build fails


On 2 sept. 2015, at 15:35, Giuseppe D'Angelo  wrote:

> Il 02/09/2015 15:02, Gunnar Roth ha scritto:
>> If you wonder why i need that, its because of wc2013 it has no DnD
>> support ( as wec7 had).
>
> Submit a patch? :)
>
> Unfortunately Qt is not tested in all the possible -no-feature switches.
>
> Cheers,
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer
> KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
> KDAB - The Qt Experts
>

+1 for the patch but the problem is rather that QWidget has the corresponding methods surrounded by #ifndef QT_NO_DRAGANDDROP and not QGraphicsView so it would make more sense to do it also for that class and not only for the content of the implementation.

Cheers
Samuel

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



80_fix_non_dnd_no_clipboard_p0.diff
Description: Binary data


81_fix_non_dnd_no_clipboard_p1.diff
Description: Binary data


82_fix_non_dnd_no_clipboard_p2.diff
Description: Binary data


83_fix_non_dnd_no_clipboard_p3.diff
Description: Binary data


87_fix_no_dnd_widgets_fix_static.diff
Description: Binary data
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] gerrit https acess error

[Gunnar Roth]

Hello,

i am tring to create a gerrit code review.

i set all up as described in https://wiki.qt.io/Setting_up_Gerrit

especially 

" if you are behind a SSH-blocking firewall, use the https protocol:

$ git remote add gerrit https://codereview.qt-project.org/p/qt/qt


"

 

after creating my commit , i want to push it with:

D:\git\qt5\qtbase>git push gerrit HEAD:refs/for/5.6
Username for 'https://codereview.qt-project.org': gunnar.roth
Password for 'https://gunnar.r...@codereview.qt-project.org':
fatal: unable to access 'https://codereview.qt-project.org/p/qt/qtbase/': The requested URL returned error: 403

 

I used the http passwort generated in the gerrit webinterface.

 

 

What can i do?

 

Regards,

Gunnar Roth

 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QT_NO_DRAGANDDROP qt 5.6 git build fails

[Gunnar Roth]

I' d like to add that

qtbase/src/widgets/itemviews/qlistwidget.h(246) : error C3668: 'QListWidget::dropEvent' method with override specifier 'override' did not override any base class methods

shows the similar problem. But here the implemntaion if  not there because of

#ifndef QT_NO_DRAGANDDROP 

around the function not inside as in QGraphicsView

same problem in  qtreewidget.h and qtableview.h

 

If you wonder why i need that, its because of wc2013 it has no DnD support ( as wec7 had).

 

Regards,

Gunnar Roth

 

 

Gesendet: Mittwoch, 02. September 2015 um 14:26 Uhr
Von: "Gunnar Roth" 
An: "development@qt-project.org" 
Betreff: [Development] QT_NO_DRAGANDDROP qt 5.6 git build fails



Hello,

QT_NO_DRAGANDDROP qt defines to adapt qt at compile time is a nice feature.

Q_DECL_OVERRIDE is also somwehat nice.

 

But together they lead to build errors.

void QGraphicsView::dragEnterEvent(QDragEnterEvent *event)
{
#ifndef QT_NO_DRAGANDDROP

 

 

  void dragEnterEvent(QDragEnterEvent *event) Q_DECL_OVERRIDE;

 

lead to  

qgraphicsview.h(240) : error C3668: 'QGraphicsView::dragEnterEvent' : method with override specifier 'override' did not override any base class methods 

 

 

I solved that by removing Q_DECL_OVERRIDE for the DND functions here.

 

Any better ways?

 

Regards,

Gunnar

 

 

___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QT_NO_DRAGANDDROP qt 5.6 git build fails

[Gunnar Roth]

Hello,

QT_NO_DRAGANDDROP qt defines to adapt qt at compile time is a nice feature.

Q_DECL_OVERRIDE is also somwehat nice.

 

But together they lead to build errors.

void QGraphicsView::dragEnterEvent(QDragEnterEvent *event)
{
#ifndef QT_NO_DRAGANDDROP

 

 

  void dragEnterEvent(QDragEnterEvent *event) Q_DECL_OVERRIDE;

 

lead to  

qgraphicsview.h(240) : error C3668: 'QGraphicsView::dragEnterEvent' : method with override specifier 'override' did not override any base class methods 

 

 

I solved that by removing Q_DECL_OVERRIDE for the DND functions here.

 

Any better ways?

 

Regards,

Gunnar

 

 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] quickcontrols2 how to build?

[Gunnar Roth]

Hi Thiago
Yes i did checkout from git, but copied it to another location without the .git 
dir.
Creating an empty .git dir helped to solve the problem.

Thank you,
Gunnar Roth
 

Gesendet: Dienstag, 25. August 2015 um 08:08 Uhr
Von: "Thiago Macieira" 
An: development@qt-project.org
Betreff: Re: [Development] quickcontrols2 how to build?
On Tuesday 25 August 2015 07:28:32 Gunnar Roth wrote:
> i was able to build qc2 on windows 7 , a few weeks ago, by just doing qmake
> and jom in a shadow directory. Now i used the qc2 dev branch from git and
> tried to build it against my qt 5.6 git build. But i get errors that
> QuickControls/ headers are not being found. I think that has to do with
> syncqt not being run but i have no clue how to do this.
> So what is the right procedure to build this?

syncqt is run automatically if the build finds a .git dir (or file) next to the
.qmake.conf in your top-level dir.

Did you check out from Git?
 
 
 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] quickcontrols2 how to build?

[Gunnar Roth]

Hello,
i was able to build qc2 on windows 7 , a few weeks ago, by just doing qmake and 
jom in a shadow directory.
Now i used the qc2 dev branch from git and tried to build it against my qt 5.6 
git build.
But i get errors that QuickControls/ headers are not being found. I think that 
has to do with syncqt not being run
but i have no clue how to do this.
So what is the right procedure to build this?

Regards,
Gunnar Roth
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Found wince info in Gerrit ,which makes me panic

[Gunnar Roth]

> Am 17.08.2015 um 11:27 schrieb Blasche Alexander 
> :
> 
>> I agree that the commit message looks a bit uninformed, given that Qt
>> should still support WEC (if only 2013+) in Qt 5.7 and beyond. The new
>> CI has a WEC7 stage, so one would expect that this gets replaced by a
>> WEC2013 stage at some point in the future.
> 
> This assessment is spot on. It's a change driven by getting the integration 
> for the serialbus module into the new CI and the module doesn't care for 
> VS2008 based wince.
> 
> If you want to add wince for VS2008 feel free to fix the problem. There was 
> not meant to be a hidden WEC2013 comment in there beyond the fact that the 
> module doesn't support this either at this stage.
> 
No i don’t care for CE < 08x00
So it just about confusing use of terms. Qt use Q_OS_WINCE for all CE versions  
, wec2013 too.  
To differentiate between CE versions the _WIN32_WCE macro value is used also 
for wec2013, which happens to be 0x800, while for WEC7 is is 0x700 , so 
internally wec2013 is WEC8.


Regards,
Gunnar Roth
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] status of exception handling on windows and mdvc compiler

[Gunnar Roth]

Hi Jörg.
> Am 07.08.2015 um 23:33 schrieb Joerg Bornemann 
> :
> 
> On 07-Aug-15 15:30, Gunnar Roth wrote:
> 
>> i accidentally stumbled over this:
>> https://codereview.qt-project.org/#/c/122584/
>> 
>> MSVC2015: Disable warning C4577 ('noexcept' used with no exception handling 
>> mode specified).
> [...]
>> When compiling qt.5.5 with vs2015 i saw these many errors myself. But is
>> it the real solution to disable that warning instead not using noexcept
>> when exceptions are off ( using a  Q_NOEXCEPT macro)
> 
> If this warning would help catching any bugs then I'd agree. But it's useless 
> for code that should build with and without exception support.
> 
Is this so? When i use exception features, and i have not switched on exception 
a warning is appreciated.

 is QMAKE_CXXFLAGS_WARN_ON also used by qmake based user projects? So every 
warning switched off there i also get switched off?
So this would be a second way for warnings be switched off , next to global.h. 
Actually this is something i would not like so much.


>> If not using exceptions on msvc how are you  able to detect new
>> failures? Is qt linking to nothrow.obj?
> 
> Qt is not linking to nothrow.obj and does not handle out of memory situations.
Really? Not even for big allocation as they  can happen in QImage?

> 
>> as a side topic i found
>> http://blogs.msdn.com/b/vcblog/archive/2015/08/06/new-in-vs-2015-zc-throwingnew.aspx
>> and this arises the qustion how am i supposed to add my own option?
>> making my own mkspec?
> 

> See https://codereview.qt-project.org/#/c/122939/ 
> <https://codereview.qt-project.org/#/c/122939/>
OK nice.

> You could create a new mkspec or modify an existing one
Ok the latter I did, as i maintain quite some patches for our Qt 5 build, so 
one more doesn’t matter.
> .
> For your own projects you can modify QMAKE_CXXFLAGS in your .pro file.
> 
Sure. But my question was solely about Qt build.

But still my question about exception handling on/off default is unanswered.

Ragrds,
Gunnar Roth

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] status of exception handling on windows and mdvc compiler

[Gunnar Roth]

Hi,
i accidentally stumbled over this: 
https://codereview.qt-project.org/#/c/122584/ 
<https://codereview.qt-project.org/#/c/122584/>
MSVC2015: Disable warning C4577 ('noexcept' used with no exception handling 
mode specified).

Fix the flood of warnings:

src/corelib/global/qflags.h(52): warning C4577: 'noexcept' used with no 
exception handling mode specified; termination on exception is not guaranteed. 
Specify /EHsc

now occurring since we don't have exception handling enabled.


When compiling qt.5.5 with vs2015 i saw these many errors myself. But is it the 
real solution to disable that warning instead not using noexcept when 
exceptions are off ( using a  Q_NOEXCEPT macro)
I was under the impression that exception handling is enabled by default on 
windows using mdvc. I also tried configure.exe with -exceptions switch but got 
an error, that this option is unknown.

If not using exceptions on msvc how are you  able to detect new failures? Is qt 
linking to nothrow.obj?  

as a side topic i found 
http://blogs.msdn.com/b/vcblog/archive/2015/08/06/new-in-vs-2015-zc-throwingnew.aspx
 
<http://blogs.msdn.com/b/vcblog/archive/2015/08/06/new-in-vs-2015-zc-throwingnew.aspx>
and this arises the qustion how am i supposed to add my own option? making my 
own mkspec?


Thanks in advance for your answers.
Gunnar Roth


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Found wince info in Gerrit ,which makes me panic

[Gunnar Roth]

And I read this thread.actually I wrote quite some messages in that. Seems not 
to be The case for qt company employees.

Am 31.07.2015 20:21 schrieb Thiago Macieira :
>
> On Friday 31 July 2015 18:40:02 Gunnar Roth wrote: 
> > Hi. 
> > I found https://codereview.qt-project.org/#/c/122523/ 
> > Which says 
> > This library is not supported on WINCE. 
> > The target is to disappear from Qt very soon anyway. 
> > This is written by alexander.blasche@theqtcompany 
> > So is there some secret decison made at The qt company? 
> > But I thought wince will stay around much longer. 
>
> There's no secret decision. Please see the thread "Qt LTS & C++11 plans". 
>
> WinCE / EC 6, 7 and 8 will be dropped from Qt 5.7. WinEC 2013 will still 
> work, 
> as it is a target from MSVC 2012. 
>
> That doesn't mean it will work for QtSerialBus. Given Alex's change, it most 
> likely won't. 
>
> > Iwould also like to know why qtserialbus is not supported in MS realtime 
> > system. 
>
> The "RT" in WinRT is stands for "runtime", not "real time". 
>
> Almost everything for WinRT needs to be reimplemented from scratch, as the 
> normal Win32 API is not available for applications. 
>
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com 
>   Software Architect - Intel Open Source Technology Center 
>
> ___ 
> Development mailing list 
> Development@qt-project.org 
> http://lists.qt-project.org/mailman/listinfo/development 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Found wince info in Gerrit ,which makes me panic

[Gunnar Roth]

I am not talking about winrt AS this RT does not mean realtime, fair enough. 
BUT i am talking about wince,thought I made that clear.

Am 31.07.2015 20:21 schrieb Thiago Macieira :
>
> On Friday 31 July 2015 18:40:02 Gunnar Roth wrote: 
> > Hi. 
> > I found https://codereview.qt-project.org/#/c/122523/ 
> > Which says 
> > This library is not supported on WINCE. 
> > The target is to disappear from Qt very soon anyway. 
> > This is written by alexander.blasche@theqtcompany 
> > So is there some secret decison made at The qt company? 
> > But I thought wince will stay around much longer. 
>
> There's no secret decision. Please see the thread "Qt LTS & C++11 plans". 
>
> WinCE / EC 6, 7 and 8 will be dropped from Qt 5.7. WinEC 2013 will still 
> work, 
> as it is a target from MSVC 2012. 
>
> That doesn't mean it will work for QtSerialBus. Given Alex's change, it most 
> likely won't. 
>
> > Iwould also like to know why qtserialbus is not supported in MS realtime 
> > system. 
>
> The "RT" in WinRT is stands for "runtime", not "real time". 
>
> Almost everything for WinRT needs to be reimplemented from scratch, as the 
> normal Win32 API is not available for applications. 
>
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com 
>   Software Architect - Intel Open Source Technology Center 
>
> ___ 
> Development mailing list 
> Development@qt-project.org 
> http://lists.qt-project.org/mailman/listinfo/development 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Found wince info in Gerrit ,which makes me panic

[Gunnar Roth]

Hi.
I found https://codereview.qt-project.org/#/c/122523/
Which says
This library is not supported on WINCE.
The target is to disappear from Qt very soon anyway.
This is written by alexander.blasche@theqtcompany
So is there some secret decison made at The qt company?
But I thought wince will stay around much longer.

Iwould also like to know why qtserialbus is not supported in MS realtime system.

Regards 
Gunnar Roth
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] wince and openssl

[Gunnar Roth]

Hello Andreas,

maybe you read my mail to fast. Especially , you seem to have skipped the

>> SSL support.no
>> OpenSSL support.yes

and 


> I assume this this is with -openssl passed to configure? From my reading
> of the code, that's the only possibility. Is "openssl" in your
 

parts.

 

So yes i actually did pass -openssl. But as you can learn from reading my mail carefully,

this does not work out as ssl is still NO. If i remove 

>> dictionary[ "SSL" ] = "no";
>> dictionary[ "OPENSSL" ] = "no";
lines then it works and i get yes for openssl and yes for ssl, when passing -openssl. 

 

Andy Shaw was so kind to make a patch at gerrit

https://codereview.qt-project.org/#/c/122437/

please have a look at it.

 

Regards,

Gunnar

 

 


Gesendet: Mittwoch, 29. Juli 2015 um 18:17 Uhr
Von: "Andreas Holzammer" 
An: development@qt-project.org
Betreff: Re: [Development] wince and openssl

Am 29.07.2015 um 18:04 schrieb Andrew Knight:
> Hi,
>
> On 07/29/2015 06:49 PM, Gunnar Roth wrote:
>> Hi,
>> i am trying to make a wec2013 build with openssl support and got weird
>> errors.
>
> What kind of errors?
>
>> then i just found this in configureapp.cpp
>> } else if (dictionary.value("XQMAKESPEC").startsWith("wince")) {
>> dictionary[ "STYLE_WINDOWSXP" ] = "no";
>> dictionary[ "STYLE_WINDOWSVISTA" ] = "no";
>> dictionary[ "STYLE_FUSION" ] = "no";
>> dictionary[ "STYLE_WINDOWSCE" ] = "yes";
>> dictionary[ "STYLE_WINDOWSMOBILE" ] = "yes";
>> dictionary[ "OPENGL" ] = "no";
>> dictionary[ "SSL" ] = "no";
>> dictionary[ "OPENSSL" ] = "no";
>> Why is that? Why did configure not warn me?
>> Hmm ok now i found:
>> SSL support.no
>> OpenSSL support.yes
>> in my output... thats strange. ..
>
> I assume this this is with -openssl passed to configure? From my reading
> of the code, that's the only possibility. Is "openssl" in your
> config.summary or the contents of mkspecs/qconfig.pri?
>
>> but hmm then i saw:
>> if (dictionary["SSL"] == "auto") {
>> if (platform() == WINDOWS_RT) {
>> dictionary["SSL"] = "yes";
>> } else {
>> // On Desktop Windows openssl and ssl always have the same
>> value (for now). OpenSSL is
>> // the only backend and if it is available and should be
>> built, that also means that
>> // SSL support in general is enabled.
>> if (dictionary["OPENSSL"] == "auto")
>> dictionary["OPENSSL"] = checkAvailability("OPENSSL") ?
>> "yes" : "no";
>> dictionary["SSL"] = dictionary["OPENSSL"];
>> }
>> }
>> and i found that the default is:
>> dictionary[ "SSL" ] = "auto";
>> dictionary[ "OPENSSL" ] = "auto";
>> so fo any mkspec which start with wince ssl is set from auto to NO.
>> But why? And why is there no error when is goive openssl option to
>> configure?
>> Bug?
>
> Not necessarily, because FWICT it is just defaulting to "no" instead of
> "auto". Maybe that's just a bad default, or maybe OpenSSL is (or was)
> known to not work properly on WEC.
>

I can agree on that its just that the default is to off. You just need
to pass -openssl to configure and be good with it. Its default is to no
because a normal windows ce user does not use openssl, so its just
taking care of the normal usecase and not the cornercases. The default
would mean that every CE user will need to run the configure check if
its there, you will most likely need to pass additional include and lib
folders anyhow to configure in order to make openssl linking possible,
so its I think ok to require to pass -openssl to configure in order to
switch it on.

Thank you

Andy


--
Andreas Holzammer | andreas.holzam...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebEngine and VS 2015

[Gunnar Roth]

Hmmm ok, but for me it looks lije it is supported in master,
https://chromium.googlesource.com/chromium/src/+/master/build/vs_toolchain.py

1. def_VersionNumber():
2. """Gets the standard version number ('120', '140', etc.) based on
3. GYP_MSVS_VERSION."""
4. ifos.environ['GYP_MSVS_VERSION']=='2013':
5. return'120'
6. elifos.environ['GYP_MSVS_VERSION']=='2015':
7. return'140'
8. else:
9. raiseValueError('Unexpected GYP_MSVS_VERSION')


Regards,
Gunnar


Am 30.07.2015 um 11:43 schrieb Allan Sandfeld Jensen:

On Thursday 30 July 2015, Gunnar Roth wrote:

Hello,
does anybody now if and when QtWebEngine will build with VS1025?


When Chromium starts supporting building with VS2015. So far it doesn't looks
like it will be in 5.6

`Allan


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QtWebEngine and VS 2015

[Gunnar Roth]

Hello,
does anybody now if and when QtWebEngine will build with VS1025?

I build Qt 5.5.0 for win32 64 bit but in th ened there was no 
qtwebengine build.

I discovered qtwebengine\tools\qmake\mkspecs\features\functions.prf
and added win32-msvc2015
to the line linux-g++*|win32-msvc2013|macx-clang: return(true)
so it trys to start the build but fails in gyp.
using python: c:\python27\python.exe version: 2.7.9
Using extra options found in 
c:\rtil\shared\qt\5.5.0\qt-src\qtwebengine\src\core\qtwebengine_extras.gypi

Updating projects from gyp files...
Traceback (most recent call last):
  File 
"C:/RTIL/Shared/Qt/5.5.0/qt-src/qtwebengine/tools/buildscripts/gyp_qtwebengine", 
line 167, in 

sys.exit(gyp.main(args))
  File 
"c:\rtil\shared\qt\5.5.0\qt-src\qtwebengine\src\3rdparty\chromium\tools\gyp\pylib\gyp\__init__.py", 
line 525, in

main
return gyp_main(args)
  File 
"c:\rtil\shared\qt\5.5.0\qt-src\qtwebengine\src\3rdparty\chromium\tools\gyp\pylib\gyp\__init__.py", 
line 510, in

gyp_main
generator.GenerateOutput(flat_list, targets, data, params)
  File 
"c:\rtil\shared\qt\5.5.0\qt-src\qtwebengine\src\3rdparty\chromium\tools\gyp\pylib\gyp\generator\ninja.py", 
line 2

420, in GenerateOutput
config_name)
  File 
"c:\rtil\shared\qt\5.5.0\qt-src\qtwebengine\src\3rdparty\chromium\tools\gyp\pylib\gyp\generator\ninja.py", 
line 2

325, in GenerateOutputForConfig
target = writer.WriteSpec(spec, config_name, generator_flags)
  File 
"c:\rtil\shared\qt\5.5.0\qt-src\qtwebengine\src\3rdparty\chromium\tools\gyp\pylib\gyp\generator\ninja.py", 
line 4

71, in WriteSpec
spec)
  File 
"c:\rtil\shared\qt\5.5.0\qt-src\qtwebengine\src\3rdparty\chromium\tools\gyp\pylib\gyp\generator\ninja.py", 
line 8

70, in WriteSources
precompiled_header, spec)
  File 
"c:\rtil\shared\qt\5.5.0\qt-src\qtwebengine\src\3rdparty\chromium\tools\gyp\pylib\gyp\generator\ninja.py", 
line 9

41, in WriteSourcesForArch
for i in include_dirs])
  File 
"c:\rtil\shared\qt\5.5.0\qt-src\qtwebengine\src\3rdparty\chromium\tools\gyp\pylib\gyp\generator\ninja.py", 
line 3

12, in GypPathToNinja
assert '$' not in path, path
AssertionError: $(VSInstallDir)/VC/atlmfc/include
Project MESSAGE: Running gyp_qtwebengine 
"C:/RTIL/Shared/Qt/5.5.0/bld/WIN32-VS14-64/qtwebengine/src/core" -D 
qt_cross_co
mpile=0 -D qt_os="win32" -I config/windows.gypi -D 
qtwe_chromium_obj_dir="C:/RTIL/Shared/Qt/5.5.0/bld/WIN32-VS14-64/qtwe
bengine/src/core/Debug_x64/obj/src/3rdparty/chromium" -D 
perl_exe="perl.exe" -D bison_exe="bison.exe" -D gperf_exe="gper
f.exe" --no-parallel -D qt_gl="opengl" -D disable_nacl=1 -D remoting=0 
-D use_ash=0 -D disable_glibcxx_debug=1 -D remove
_webcore_debug_symbols=1 -D win_release_extra_cflags=-Zi -D 
target_arch=x64...

Project ERROR: -- running gyp_qtwebengine failed --


What to do here?
$(VSInstallDir)/VC/atlmfc/include is there i even set VSINSTALLDIR by 
hand without success.



Regards,
Gunnar Roth

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] wince and openssl

[Gunnar Roth]

My effect is that QT_NO_SSL is defined which leads to 100’s of errors.

And i did pass -openssl to configure. I patched configureapp.cpp by removing 
that no’s for opens and ssl ( the result i can see tomorrow)
and by the way i  think the sse2/3/4 no’s are also incorrect, i think you guys 
only think arm when thinking about wince.
So you also disable -sse2 flag to configure when i compile for a intel or and 
wec2013 platform. At least i know about this this now.
When compiling crossplatform you should trust the configure parameters.


Regards
Gunnar Roth




> Am 29.07.2015 um 18:46 schrieb Thiago Macieira :
> 
> On Wednesday 29 July 2015 18:17:38 Andreas Holzammer wrote:
>> I can agree on that its just that the default is to off. You just need
>> to pass -openssl to configure and be good with it. Its default is to no
>> because a normal windows ce user does not use openssl, so its just
>> taking care of the normal usecase and not the cornercases. The default
>> would mean that every CE user will need to run the configure check if
>> its there, you will most likely need to pass additional include and lib
>> folders anyhow to configure in order to make openssl linking possible,
>> so its I think ok to require to pass -openssl to configure in order to
>> switch it on.
> 
> I don't agree with that. Just leave the default to auto and it will change to 
> "yes" if it finds the headers. The -openssl option changes it to "yes" 
> without 
> checking the headers, so the link may build later because it's missing 
> compiler flags.
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] wince and openssl

[Gunnar Roth]

Hi,

i am trying to make a wec2013 build with openssl support and got weird errors.

 

then i just found this in configureapp.cpp

 } else if (dictionary.value("XQMAKESPEC").startsWith("wince")) {
        dictionary[ "STYLE_WINDOWSXP" ]     = "no";
        dictionary[ "STYLE_WINDOWSVISTA" ]  = "no";
        dictionary[ "STYLE_FUSION" ]        = "no";
        dictionary[ "STYLE_WINDOWSCE" ]     = "yes";
        dictionary[ "STYLE_WINDOWSMOBILE" ] = "yes";
        dictionary[ "OPENGL" ]              = "no";
        dictionary[ "SSL" ]                 = "no";
        dictionary[ "OPENSSL" ]             = "no";

 

Why is that? Why did configure not warn me?

 

 

Hmm ok  now i found:

SSL support.no
OpenSSL support.yes

in my output... thats strange. ..

 

but hmm then i saw:

   if (dictionary["SSL"] == "auto") {
        if (platform() == WINDOWS_RT) {
            dictionary["SSL"] = "yes";
        } else {
            // On Desktop Windows openssl and ssl always have the same value (for now). OpenSSL is
            // the only backend and if it is available and should be built, that also means that
            // SSL support in general is enabled.
            if (dictionary["OPENSSL"] == "auto")
                dictionary["OPENSSL"] = checkAvailability("OPENSSL") ? "yes" : "no";
            dictionary["SSL"] = dictionary["OPENSSL"];
        }
    }

 

 

and i found that the default is:

  dictionary[ "SSL" ]             = "auto";
  dictionary[ "OPENSSL" ]         = "auto";
 

so fo any mkspec which start with wince ssl is set from auto to NO. 

But why? And why is there no error when is goive openssl option to configure?

Bug?

 

 

Regards,

Gunnar Roth

 

 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QVector now has rvalue push_back

[Gunnar Roth]

Hi,

so Am i wrong or not? By saying: " i don’t think there is any difference between
push_back(QPen(Qt::red,1.5f)) and emplace_back(Qt::red,1,5f))" with this implemention.

 

 



Gesendet: Mittwoch, 22. Juli 2015 um 10:34 Uhr
Von: "Marc Mutz" 
An: development@qt-project.org
Betreff: Re: [Development] QVector now has rvalue push_back

On Wednesday 22 July 2015 09:09:50 Julien Blanc wrote:
> Le mardi 21 juillet 2015 à 19:00 +0200, Gunnar Roth a écrit :
> > Hello,
> > Out of curiosity i just looked at the Xcode 6.4 headers for the
> > implementation of std::vector::emplace_back,
> > and i don’t think there is any difference between
> > push_back(QPen(Qt::red,1.5f)) and emplace_back(Qt::red,1,5f))
> >
> > The implementation is like this:
> > template 
> > _LIBCPP_INLINE_VISIBILITY void emplace_back(_Args&&... __args)
> >
> > { push_back ( value_type ( _VSTD::forward<_Args>(__args)... )); }
> >
> > Am i wrong?
>
> That’s a suboptimal but valid implementation (there’s no requirement
> about not constructing a temporary object in the C++11 standard).
>
> gnu stl does the opposite : implement push_back in terms of
> emplace_back, which is better.

Seeing as one is implemented by Howard Hinnant and the other suffers from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60621, I wouldn't pass judgement
so quickly...

 

 

 

 

 


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QVector now has rvalue push_back (was: Re: HEADS UP: potential trouble from a recent QVector change)

[Gunnar Roth]

> Am 21.07.2015 um 20:11 schrieb Bubke Marco :
> 
> 
> Gunnar Roth 
>>> 
>>> void push_back(T &&t) {
>>> ensureCapacity(size() + 1);
>>> new (m_end) T(std::move(t));// move-construct from t
>>> ++m_end;
>> why is std::move needed here? Afaik std::move(t) converts t into a rvalue 
>> ref, but t is already an r-value ref.
> 
> If T would be not a template t is binding to a rvalue reference but it is not 
> itself a rvalue reference but an lvalue.
> If T is a template like in this case it is more complicated because it is a 
> universal or forward reference. For a 
> forward reference it could be an lvalue reference like (T&) or a lvalue(T) 
> depending as the argument is a rvalue,
> lvalue or lvalue reference. 
> T&& -> T
> T& -> T&
> T -> T
> 
> std::forward would be of better use than std::move: 
> http://en.cppreference.com/w/cpp/utility/forward
> 

Well std::forward is the right thing to do here not std::move ( std::move just 
does accidentally the same. the forward  is needed because of the way T is 
deduced from the passed parameter.

Regards,
Gunnar Roth
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QVector now has rvalue push_back (was: Re: HEADS UP: potential trouble from a recent QVector change)

[Gunnar Roth]

> Am 21.07.2015 um 19:58 schrieb Milian Wolff :
> 
> On Tuesday 21 July 2015 19:49:13 Gunnar Roth wrote:
>>> void push_back(T &&t) {
>>> 
>>> ensureCapacity(size() + 1);
>>> new (m_end) T(std::move(t));// move-construct
>>> from t
>>> ++m_end;
>> 
>> why is std::move needed here? Afaik std::move(t) converts t into a rvalue
>> ref, but t is already an r-value ref.
> 
> Yes, it is an r-value ref, but itself it's an lvalue. So for perfect 
> forwarding, you need to move it. Or something like that, Scott Meyers wrote a 
> chapter on that afaik but I have to admit that I forgot most of it already.
> 

I think what you mean is  std::forward 
<http://en.cppreference.com/w/cpp/utility/forward>()
Regards,
Gunnar


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] xcode emplace_back (was: QVector now has rvalue push_back)

[Gunnar Roth]

> Am 21.07.2015 um 19:14 schrieb Matthew Woehlke :
> 
> Ergo, that implementation looks... suspicious, and *may* even be
> non-conforming. (Unless push_back is doing something really funky, which
> I somewhat doubt.) You may want to file a bug against that implementation.
this is the push_back implementaion, nothing special afaic see. Besides it s 
using move() for a rvalue ref which is don’t know why.
template 
inline _LIBCPP_INLINE_VISIBILITY
void
vector<_Tp, _Allocator>::push_back(value_type&& __x)
{
if (this->__end_ < this->__end_cap())
{
__annotate_increase(1);
__alloc_traits::construct(this->__alloc(),
  _VSTD::__to_raw_pointer(this->__end_),
  _VSTD::move(__x));
++this->__end_;
}
else
__push_back_slow_path(_VSTD::move(__x));
}


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt LTS & C++11 plans (CopperSpice)

[Gunnar Roth]

Hi Ansel.
> Am 21.07.2015 um 19:06 schrieb Ansel Sermersheim :
> 
> gives the Qt Project the freedom to take any and all submissions and 
> incorporate them into the closed source version

Do not mix up commercial license with closed source, all code you contribute 
will be licensed under GPL,LGPL V2.1 or V3 for newer modules AND the commercial 
license.
Btw.  It is not Qt Project , it is Qt Company. 


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QVector now has rvalue push_back (was: Re: HEADS UP: potential trouble from a recent QVector change)

[Gunnar Roth]

> 
>  void push_back(T &&t) {
>  ensureCapacity(size() + 1);
>  new (m_end) T(std::move(t));// move-construct from t
>  ++m_end;
why is std::move needed here? Afaik std::move(t) converts t into a rvalue ref, 
but t is already an r-value ref.

Regards,
Gunnar Roth

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QVector now has rvalue push_back

[Gunnar Roth]

Hello,
Out of curiosity i just looked at the Xcode 6.4 headers for the implementation 
of std::vector::emplace_back,
and i don’t think there is any difference between push_back(QPen(Qt::red,1.5f)) 
and emplace_back(Qt::red,1,5f))

The implementation is like this:
template 
_LIBCPP_INLINE_VISIBILITY void emplace_back(_Args&&... __args)
{ push_back ( value_type ( _VSTD::forward<_Args>(__args)... )); }


Am i wrong?

Regards,
Gunnar

> Am 21.07.2015 um 18:53 schrieb Thiago Macieira :
> 
> On Tuesday 21 July 2015 12:22:36 Matthew Woehlke wrote:
>>  std::vector list;
>> 
>>  // less efficient
>>  auto&& pen = QPen{Qt::red, 1.5f};
>>  list.push_back(pen);
>> 
>>  // more efficient
>>  list.emplace_back(Qt::blue, 2.0f);
> 
> This is a lot clearer. Thanks!
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Gunnar Roth]

Hi Julian
> Am 16.07.2015 um 23:43 schrieb Julien Blanc :
> 
> Le jeudi 16 juillet 2015 à 23:09 +0200, Gunnar Roth a écrit :
> 
>> 
>> The vector classes are now very bad in this case. QHash is considerable 
>> better than any other.
>>  
>> So I deduce from this test that for a container with up to 100 elements , 
>> std::vector is the best choice , if you want fastest lookup, but Vector 
>> should be avoided. For larger container QHash should be used for best lookup 
>> performance.
> 
> Unless your vector content changes often, you should use a sorted vector and 
> a dichotomic search for that use case. Also note that hash are usually 
> subject to hash collision issues, which may be a security concern in certain 
> context : i wouldn’t recommend such a container for general purpose.

I assume dichotomic search is the same as binary search.
Well my tests show that vector is only good with up to 100 elements, at least 
from 1000 and above it  is a lot worse than QHash. What security concern do you 
mean when hash collide for a hash based container.
Have you some links about this topic? A google search for: hash container 
security
gave no results in this direction.

Regards,
Gunnar


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Gunnar Roth]

 -- 1000 „, "WalltimeMilliseconds",3.5
"qfasthash_find -- 1000 „,  "WalltimeMilliseconds“,4.15625

std::vector also falls behind now being 60% slower than the winner QHash,Vector 
is even nearly 2 times slower than std::vector.

1 elements (1 container)

"QHash_constFind -- 1 „, "WalltimeMilliseconds“,1.15625
"boostunordered_find -- 1 „, "WalltimeMilliseconds",1.578125
"stdunordered_find -- 1 „, "WalltimeMilliseconds“,1.609375
"qfasthash_find -- 1 „,"WalltimeMilliseconds",2.03125
"stdvector_lowerbound -- 1 ","WalltimeMilliseconds",3.4375
"QMap_constFind -- 1 „,  "WalltimeMilliseconds“,3.9375
"stdmap_find -- 1 „,   "WalltimeMilliseconds",4.1875
"QVector_lowerbound -- 1 „,  "WalltimeMilliseconds",4.1875

The vector classes are now very bad in this case. QHash is considerable better 
than any other.
 
So I deduce from this test that for a container with up to 100 elements , 
std::vector is the best choice , if you want fastest lookup, but Vector should 
be avoided. For larger container QHash should be used for best lookup 
performance.


> About QFastHash: that is WIP. It's the very rudimentary beginnings of an open-
> addressing hash container (a hash container using consecutive memory, not 
> nodes).
> 
What was the idea behind it? Is so much slower than any other that I can just 
see why anyone should want to have this? What is the advantage?
> 
> QHash is slower than std::unordered because std::hash is inline and 
> qHash(double) is out-of-line.
May I ask why? 
Is this valid for all qHash()?


> QVector is slower than std::vector because it 
> has a d-pointer, so construction of iterators is more complicated (see my 
> blog 
> post for disassembly of a simple QVector vs. std::vector iteration - the 
> loops 
> are identical, but QVector has more complex setup code).
> 

Well Vector is considerable slower than std::vector in my test. QVector has no 
advantage  over  hash based container,
while std::vector has for small sets.

Regards,
Gunnar Roth

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Gunnar Roth]

Hi Thiago
> Am 12.07.2015 um 19:42 schrieb Thiago Macieira :
> 
> On Sunday 12 July 2015 16:57:39 Gunnar Roth wrote:
>> "QMap_insert  -- 1   ","WalltimeMilliseconds",0.625,80,128
> 
> Please run with -perf -minimumvalue 100. The CPU cycles counter is much 
> more accurate and more representative.
> 

There is no -perf option, i think you maybe meant the -tickcount option. So 
this is the result.

"QMap_insert  -- 1   ","CPUTicks",3407433,3407433,1
"QHash_insert -- 1   ","CPUTicks",1767885,1767885,1
"stdmap_insert-- 1   ","CPUTicks",3060120,3060120,1
"stdvector_pb_sort-- 1   ","CPUTicks",1146499.5,2292999,2
"stdunordered_insert  -- 1   ","CPUTicks",2521209,2521209,1
"qfasthash_insert -- 1   ","CPUTicks",1977711,1977711,1
"boostunordered_inser -- 1   ","CPUTicks",2301750,2301750,1
"QMap_find-- 1   ","CPUTicks",1781553,1781553,1
"QMap_constFind   -- 1   ","CPUTicks",1172022,1172022,1
"QHash_find   -- 1   ","CPUTicks",231001.5,1848012,8
"QHash_constFind  -- 1   ","CPUTicks",141855.75,1134846,8
"QVector_lowerbound   -- 1   ","CPUTicks",1196103,1196103,1
"stdvector_lowerbound -- 1   ","CPUTicks",1159581,1159581,1
"stdmap_find  -- 1   ","CPUTicks",1531323,1531323,1
"stdunordered_find-- 1   ","CPUTicks",258110.25,1032441,4
"qfasthash_find   -- 1   ","CPUTicks",332802,1331208,4
"boostunordered_find  -- 1   ","CPUTicks",334885.5,2679084,8

Hmm now the insertion cost for vector is a lot less and even the fastest. Any 
clue why?

But QHash_constFind still the best and about 8 times faster than QVector.

> You can also try -perfcounter l1d-cache-loads or l1d-cache-load-misses (you 
> want to remove the -minimumvalue option) to see if there's more L1 cache miss 
> ratio.
> 

Ah i googled and this are option only available on linux,
but as i wrote i am doing these benchmarks on OS X. I have no linux 
installation but in a VM and not at home.

Regards,
Gunnar


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Gunnar Roth]

Hi Milian, hi Marc

> Am 12.07.2015 um 16:06 schrieb Milian Wolff :
> 
> On Sunday, July 12, 2015 04:58:01 PM Marc Mutz wrote:
>> On Sunday 12 July 2015 15:05:51 Gunnar Roth wrote:
>>> Hi Marc,
>>> 
>>>> Better provide a benchmark into which users can easily plug their own
>>>> types and that plots relative performance of various containers at
>>>> various sizes. Then they can use that on their platform, on their type,
>>>> with their access patterns to determine which container to choose.
>>> 
>>> I tried to write a container benchmark for testing qt , std and boost
>>> containers. I did that already a while ago, but had not collected enough
>>> energy to post about it until now . ;-) This is not including QList
>>> because the benchmark is made to test how fast i can lookup something in a
>>> container.
>>> 
>>> It can be found at https://github.com/gunrot/qtcontainerbench
>>> <https://github.com/gunrot/qtcontainerbench> I got irritating results from
>>> it , concerning all the praise i read on the qt mailings list for Vector
>>> instead of map or hash.
>> 
>> That's because your benchmark runs entirely in L1.
>> 
>> If you want to test containers of 10, 100, 1000 and 1 elements each,
>> then make
>> - one run over 1×N containers of 1 elements each,
>> - one run over 10×N containers of 1000 elements each,
>> - one run over 100×N containers of 100 elements each,
>> - one run over 1000×N containers of 10 elements each.
>> 
>> You need to use a working set size large enough to not hit L1 all the time,
>> because it's just not the usual case that a lookup table is completely in
>> L1. But you can start with a small working set. As you increase the working
>> set size, you should see how each individual test (at constant number of
>> elements) increases in runtime. And you will see that the contiguous
>> containers don't loose as much as the node-based.
> 
Ok i understand your concern about the influence of the L1 cache,the size of my 
L1 cache is 64 kb, but shouldn’t continuoscontainer like vector benefit even 
more from that than non contagious like map or hash?




the test of  1 container of 1 items i can easily produce. I added a 
std::vector push_back and sort testcase.

The result is:
"QMap_insert  -- 1   ","WalltimeMilliseconds",0.625,80,128
"QHash_insert -- 1   ","WalltimeMilliseconds",0.099609375,51,512
"stdmap_insert-- 1   ","WalltimeMilliseconds",0.4921875,63,128
"stdvector_pb_sort-- 1   ","WalltimeMilliseconds",2.4375,78,32
"stdunordered_insert  -- 1   ","WalltimeMilliseconds",0.2109375,54,256
"qfasthash_insert -- 1   ","WalltimeMilliseconds",0.14453125,74,512
"boostunordered_inser -- 1   ","WalltimeMilliseconds",0.140625,72,512
"QMap_find-- 1   ","WalltimeMilliseconds",0.65625,84,128
"QMap_constFind   -- 1   ","WalltimeMilliseconds",0.5546875,71,128
"QHash_find   -- 1   
","WalltimeMilliseconds",0.0830078125,85,1024
"QHash_constFind  -- 1   ","WalltimeMilliseconds",0.05859375,60,1024
"QVector_lowerbound   -- 1   ","WalltimeMilliseconds",0.5078125,65,128
"stdvector_lowerbound -- 1   ","WalltimeMilliseconds",0.484375,62,128
"stdmap_find  -- 1   ","WalltimeMilliseconds",0.5546875,71,128
"stdunordered_find-- 1   ","WalltimeMilliseconds",0.111328125,57,512
"qfasthash_find   -- 1   ","WalltimeMilliseconds",0.162109375,83,512
"boostunordered_find  -- 1   ","WalltimeMilliseconds",0.103515625,53,512

so here inserting 1 elements QHash is the fastest and std::vector the 
slowest. Its by a factor of 25 slower

for looking up items QHash constFind is the fastest , being faster by at least 
a factor of 2, against std:vector is wins by a factor of 5.


> 
> 
> In addition to that, you should additionally benchmark the setup cost for the 
> containers. I have often seen code that was slow, not because finding items 
> in 
> it was slow, but rather because the lists where temporary and thus the setup 
> cost never amortized. Then, the cost of malloc & free is significant, often 
> orders of magnitude more expensive than actually finding the elements. There, 
> QVarLengthArray (if possible) or at least QVector/std::vector _really_ shines.
> 

Hmm std::vector at least does not shine here

Best regards,
Gunnar  Roth

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Gunnar Roth]

001506805419922
stdunordered_find   0.0002021789550781
qfasthash_find  0.0003166198730469
boostunordered_find 0.0002021789550781

Well this is a change. Now at least constFind it faster than find.
As before QFastHAsh is the slowest one, but QHash ::constFind is king now, but 
QMap constfind and std::map and std::vector are not that far away.   

So now look at the speed with 5 items:

TypeWalltimeMilliseconds
QMap_find   3.957748413086e-05
QMap_constFind  3.862380981445e-05
QHash_find  4.673004150391e-05
QHash_constFind 4.005432128906e-05
QVector_lowerbound  3.528594970703e-05
stdvector_lowerbound3.147125244141e-05
stdmap_find 3.862380981445e-05
stdunordered_find   5.531311035156e-05
qfasthash_find  8.678436279297e-05
boostunordered_find 5.531311035156e-05

std::vector wins here closely followed byQVector and QMap::constFind, but do 
you think the difference is worth choosing vector over map/qhash?
And with 20 items vector falls behind. ( Actually my tests show that vector  
with 10 items falls behind map/qhash already)



And for 100 items we have this results:

TypeWalltimeMilliseconds
QMap_find   0.001144409179688
QMap_constFind  0.00128173828125
QHash_find  0.001617431640625
QHash_constFind 0.0013427734375
QVector_lowerbound  0.001495361328125
stdvector_lowerbound0.0010986328125
stdmap_find 0.001083374023438
stdunordered_find   0.001129150390625
qfasthash_find  0.002716064453125
boostunordered_find 0.001007080078125

Hmm QMap constFind is again slower than find. The winner here is by a tiny 
amount boost::unordered, on par are std::map and std::vector.


So from this results , i would choose std::map for a container of about 100 
items where i need fast lookup. For 1000 and more , QHash is getting faster and 
faster but not for double as key, as suppose thats because the qHash() for 
double is not implemented well, as std::unordered and boost::unordered do a lot 
better job here.


But doing all these measurements with an int key and an int value changes the 
picture.

5   items QHash_constFind  3,433227539062e-05  stdmap_find  
3,194808959961e-05 stdvector_lowerbound 3,147125244141e-05
7   items QHash_constFind  4,863739013672e-05  stdmap_find  
5,197525024414e-05 stdvector_lowerbound 4,196166992188e-05
10  items QHash_constFind  6,675720214844e-05  stdmap_find  
6,961822509766e-05 stdvector_lowerbound 6,866455078125e-05
20  items QHash_constFind  0.0001335144042969  stdmap_find  
0.0001544952392578 stdvector_lowerbound 0.000152587890625
100 items QHash_constFind  0.0006332397460938  stdmap_find  
0.001113891601562  stdvector_lowerbound 0.001068115234375


So for a simple int as key QHash is faster starting from 7 Items and gains 
speed by increasing items, being considerably faster at 100 items.

So what I learn here that there is:
1. is a hight dependency on the key type for a container being slower or faster 
in lookup time. 
2. Something with fast in its name can actually be lowest one by far.

> If you want to update the docs, as a first approximation, write that QVector 
> is _the_ default seqential (and, if it wasn't so awkward to use, also _the_ 
> default associative) container (even though it's not currently reflected in 
> the Qt API). All other containers (incl. QMap, QSet, ..., but maybe not 
> QHash) 
> should only be used after very careful profiling and QList should not be used 
> by mere mortals at all.
> 

So what does my benchmark measure wrong? Because if you are right in saying 
QVector should be the default associative container, then my benchmark must be 
wrong.


Best regards,
Gunnar Roth

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Move ctors for q_declare_shared types

[Gunnar Roth]

Hi Marc

Gesendet: Freitag, 26. Juni 2015 um 17:25 Uhr
Von: "Marc Mutz" 
An: development@qt-project.org
Betreff: Re: [Development] Move ctors for q_declare_shared types

 

Marc are you from the future ? Or is just your  clock wrong ?


 

>> According to the fundamental C++
> > principle "Don't pay for what you don't use", not clearing target is the
> > correct thing to do. 

 

You are sure that principle can be applied here? IMO this means that no feature should be added to the language , which adds a load to other features. For exmple adding move constructors should not make copy constructors slower.

 

IMHO i find it very unexspected that after f(std::move(a)); 

a can be non-empty. I actually thought  there is a rule for && parameter functions, to make these empty. But maybe  there is not. At least Scott Meyers seems to have a similar opinion

http://scottmeyers.blogspot.de/2014/06/the-drawbacks-of-implementing-move.html

 

Wyh can you do this inline?  

 QFoo &operator=(QFoo &&other) { swap(other);QFoo<>().swap(other); return *this; }

would not work ?

 

 

 

Regards,

Gunnar

 

 

 


Gesendet: Freitag, 26. Juni 2015 um 17:25 Uhr
Von: "Marc Mutz" 
An: development@qt-project.org
Betreff: Re: [Development] Move ctors for q_declare_shared types

On Friday 26 June 2015 15:55:04 Daniel Teske wrote:
> On Friday 26 Jun 2015 16:45:18 Marc Mutz wrote:
> > On Friday 26 June 2015 12:34:31 Daniel Teske wrote:
> > > > Most of our implicitly shared types already had a move-assignment
> > > > operator, because it's just
> > > >
> > > > QFoo &operator=(QForr &&other) { swap(other); return *this; }
> > >
> > > And that's indeed how QVector's move assignment is implemented.
> > >
> > > It's also broken.
> >
> > It isn't. Other is left in an unspecified, but valid state. It's not even
> > partially formed, as many move operators leave their source.
>
> It's nice that you follow up the denial by a statement that is entirely and
> completely irrelevant to the discussion.

Unspecified, but valid state is the wording in the standard. I was merely
pointing out that it's acceptable, generally, according to the std, that a
moved-from object is left in an unspecified state. It just has to be valid.

> > > Just because other is a rvalue reference does not mean that it is a
> > > temporary and thus the is no guarantee that other's dtor gets called.
> > >
> > > And thus, this line:
> > >
> > > QVector vector = std::move(something);
> > >
> > > does not gurantees that the dtors for the old contents of vector are
> > > called.
> >
> > It does. It doesn't say when (when something is going out of scope), but
> > saying that dtors aren't called is wrong.
> >
> > The problem you have is that you want immediate resource release. If you
> >
> > want that, swap something with a new object:
> > QVector().swap(something);
> >
> > (or call clear(), but that's Qt-specific). You're never holding more
> > memory at any given time (if you do this), than with an
> > immidiate-release move operation. According to the fundamental C++
> > principle "Don't pay for what you don't use", not clearing target is the
> > correct thing to do. The standard should be fixed.
>
> The standard requires immediate release for a reason. If you don't want
> that, just use a swap instead. Implementing move assignment as a swap
> destroys a fundamental guarantee of assignment. The old value is
> destroyed.

That all resources of a are released after an assignment is not a fundamental
guarantee. If you assign to a QRegExp, the state lives on in some internal
cache.

The fundamental guarantee of assignment is that a == b after a = b (at least
for Regular Types, and QVector is Regular).

And you keep that in all detectable cases, unless you use std::move to turn an
lvalue into an xvalue. As soon as you do this, the (real) fundamental
guarantee of assignment is already violated.

> > > "All existing elements of a are either move assigned to or destroyed,"
> > >
> > > I do not see any reason why our containers should not give the same
> > > guarantee for move assignment and consider this a bug.
> >
> > I guess then you also consider it a bug that Qt containers don't meet the
> > std container complexity guarantees (b/c/o CoW) and don't meet the std
> > container thread safety guarantees (b/c/o the omission of a non-sharable
> > state when handing out references to internal state by way of op[] or
> > mutable iterators), or that they don't have range-ctor or range-insert,
> > or emplace, or allocator support.
>
> Nope those are documented and there was a good reason for implementing them
> like that. Some of the omissions are surely only oversights.
>
> If there's a reason for implementing move assignment differently from the
> standard containers, then you need to provide it.

I did. Please re-read my mail.

Thanks,
Marc

--
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
_

Re: [Development] QtCS: Long Term Release discussion

[Gunnar Roth]

Yes thats wrong, proved by practice and ms support finally. This arcticle will be changed as MS promised that to us, but until this task bubbles up inside MS  can take a while.

 

Regards,

Gunnar

 

 

Gesendet: Montag, 22. Juni 2015 um 15:02 Uhr
Von: "Al-Khanji Louai" 
An: "Gunnar Roth" , "Knoll Lars" 
Cc: "development@qt-project.org" , "Thiago Macieira" 
Betreff: RE: [Development] QtCS: Long Term Release discussion

So this bit in the article is not factual?

"Windows Embedded Compact no longer provides its own tool chain (compiler, assembler, and make), but instead use the same tools as desktop development."

Louai


> -Original Message-
> From: development-bounces+louai.al-khanji=theqtcompany.com@qt-
> project.org [mailto:development-bounces+louai.al-
> khanji=theqtcompany@qt-project.org] On Behalf Of Gunnar Roth
> Sent: Friday, June 19, 2015 7:50 PM
> To: Knoll Lars
> Cc: development@qt-project.org; Thiago Macieira
> Subject: Re: [Development] QtCS: Long Term Release discussion
>
>
> > Am 19.06.2015 um 18:38 schrieb Knoll Lars
> :
> >
> >
> > There was never an intention to remove it after 5.6. But I was hoping
> that we could be using VC++ 2013 (and support wec2013 with it). Looks
> like that is unfortunately not the case. That implies that our new
> compiler baseline will stay with 2012 for some time :/
> >
>
> Thanks a lot for your answer. That is a big relief.
>
> Regards,
> Gunnar
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCS: Long Term Release discussion

[Gunnar Roth]

> Am 19.06.2015 um 18:38 schrieb Knoll Lars :
> 
> 
> There was never an intention to remove it after 5.6. But I was hoping that we 
> could be using VC++ 2013 (and support wec2013 with it). Looks like that is 
> unfortunately not the case. That implies that our new compiler baseline will 
> stay with 2012 for some time :/
> 

Thanks a lot for your answer. That is a big relief.

Regards,
Gunnar

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCS: Long Term Release discussion

[Gunnar Roth]

Hi Björn,
i am really glad this discussion will come to an end ;-), it already took 
considerable time, internally and externally.
> Am 19.06.2015 um 17:51 schrieb Björn Breitmeyer :
> 
> Hi Gunnar,
> 
> sadly i have to agree. I finally had the time to setup a Visual Studio 2013 
> with the recent Platform Builder and sadly the generated SDK's still have
> the Compiler Version 17.xx and says Visual Studio 2012. So the link indeed
> gets us to wrong assumptions. It is a bit sad since there is a working arm 
> compiler as you said.
> 

Yes there is, and as i wrote it can be used to compile c99 code and create a 
working executable by just setting /subsystem to windowsce in the linker step.
This is because wec2013 and winrt both use thumb2 and the arm eabi 2. So the 
problem is the missing std c++ library for wec2013 and this v18.00 compiler and 
that it is not supported by MS.


> But we can't force our users to try unsupported crude workarounds. So i hope
> we can find a consenus on having Visual Studio 2012 as a baseline. As 
> otherwise we would drop Embedded Compact 2013 support directly after 
> introducing it.
That would make me and the company really sad


I would appreciate  a clear answer ( or better commitment) from the Qt Company 
to continue supporting wec2013 beyond  qt 5.6. 

Regards, 
Gunnar
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCS: Long Term Release discussion

[Gunnar Roth]

Hi Björn, i had the assumption you could mean that, but thats not a knowledge base article.

I think you mean "Compact 2013 uses the Microsoft Visual Studio 2013 compiler,"? That part was also sent to me by a colleage from another department when discussing v8 usage( as this has vs2013 depedancy according to wiki).  So we startet a MS Request to clear this issue.

The answer was that the arcticle is wrong here.

 

Where should the newer stdc++ lib for wec 2013 come from? 

 

As a side note, we were able to compile ffmpeg for wec2013 with the cl v18.00 arm compiler as this has sufficient c99 support.

But that is not supported and c++ relies heavily on its stdc++ lib where we dont have a fitting version.

 

Regards,

Gunnar

 

 

 

Gesendet: Donnerstag, 18. Juni 2015 um 11:48 Uhr
Von: "Björn Breitmeyer" 
An: "Gunnar Roth" 
Cc: development@qt-project.org, "Thiago Macieira" 
Betreff: Re: Aw: Re: [Development] QtCS: Long Term Release discussion

That would be this one,

https://msdn.microsoft.com/en-us/library/gg154234.aspx

btw, i would assume the use of the newer libstdc++ if i got it right, as that
one comes from the sdk too. But maybe i am wrong, didn't gave this a lot of
time yet, which is why i couldn't test it yet.

--
Björn Breitmeyer | bjoern.breitme...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Germany: +49-30-521325470, Sweden (HQ): +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
Am Donnerstag, 18. Juni 2015, 11:00:30 schrieb Gunnar Roth:
> Hi Björn,
> what is "the knowledgebase article"? Would you mind to share a link?
>
> And even if there would be a v18.00 compiler, what about the standard c++
> library (headers, libs and dlls) where do they come from? Or would then a
> mix of newer compiler and older std c++ libary be used? That could be quite
> problematic haven such a mix leading to unpredictable behaviour from a
> programmers view. Qt could then not say, vs2013 is the base, but only
> vs2013 compiler with vs12012 std libary. Sound crazy...
> Regards,
> Gunnar
>
>
>
> Gesendet: Donnerstag, 18. Juni 2015 um 10:41 Uhr
> Von: "Björn Breitmeyer" 
> An: development@qt-project.org
> Cc: "Gunnar Roth" , "Thiago Macieira"
>  Betreff: Re: [Development] QtCS: Long Term
> Release discussion
> Hello Gunnar,
>
> i still hadn't time to verify this, but. There is a platform builder for
> WEC2013, if you generate the SDk with that one it should have the Visual
> Studio 2013 compiler, at least thats how i read the knowledgebase article.
> Its on my TODO list to verify this, but i still didn't had the time to do
> so.
>
> Best regards
> Björn Breitmeyer
>
> --
> Björn Breitmeyer | bjoern.breitme...@kdab.com | Senior Software Engineer
> KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
> Germany: +49-30-521325470, Sweden (HQ): +46-563-540090
> KDAB - Qt Experts - Platform-independent software solutions
>
> Am Donnerstag, 18. Juni 2015, 10:16:49 schrieb Gunnar Roth:
> > Gesendet: Donnerstag, 18. Juni 2015 um 08:43 Uhr
> > Von: "Thiago Macieira" 
> > An: development@qt-project.org
> > Betreff: Re: [Development] QtCS: Long Term Release discussion
> >
> > On Thursday 18 June 2015 08:23:52 Gunnar Roth wrote:
> > > > Am 17.06.2015 um 22:35 schrieb Thiago Macieira
> > > >
> > > > :
> > >> > On Wednesday 17 June 2015 19:30:25 Gunnar Roth wrote:
> > >> >> Yes that would make us (as a commercial user using a self made port
> > >> >> of
> > >> >> qt
> > >> >> 5.4.1 to wec2013 ) very unhappy. This means 5.6 will be the last
> > >> >> version
> > >> >> wec2013 would be supported and you would go straight to making a
> > >> >> back
> > >> >> port
> > >> >> very hard or even impossible.
> > >> >
> > >> > WEC 2013 was never considered deprecated. The deprecation applies to
> > >> > WEC 7
> > >> > only.
> > >>
> > >> Well ok, but how does Lars Knoll’s sentence "we could make
> > >> VS2013 the compiler baseline for 5.7.“ fit into this? As the only
> > >> supported
> > >> compiler for wec2013 is a cl with v 17.00 aka vs2012.
> > >
> > >Apparently VS2013 can also be used for WEC2013.
> >
> > IDE: yes
> > Compiler: No
> >
> > This was recently confirmed to as by microsoft. The used compiler comes
> > from the platfrombuilder wince800 tree, which is independent from the
> > used IDE. The sdk wec2013 c

Re: [Development] QtCS: Long Term Release discussion

[Gunnar Roth]

Hi Björn,

what is "the knowledgebase article"? Would you mind to share a link?

 

And even if there would be a v18.00 compiler, what about the standard c++ library (headers, libs and dlls) where do they come from?

Or would then a mix of newer compiler and older std c++ libary be used? That could be quite problematic haven such a mix leading to unpredictable behaviour from a programmers view. Qt could then not say, vs2013 is the base, but only vs2013 compiler with vs12012 std libary. Sound crazy...

 

Regards,

Gunnar

 

 

 

Gesendet: Donnerstag, 18. Juni 2015 um 10:41 Uhr
Von: "Björn Breitmeyer" 
An: development@qt-project.org
Cc: "Gunnar Roth" , "Thiago Macieira" 
Betreff: Re: [Development] QtCS: Long Term Release discussion

Hello Gunnar,

i still hadn't time to verify this, but. There is a platform builder for
WEC2013, if you generate the SDk with that one it should have the Visual
Studio 2013 compiler, at least thats how i read the knowledgebase article.
Its on my TODO list to verify this, but i still didn't had the time to do so.

Best regards
Björn Breitmeyer

--
Björn Breitmeyer | bjoern.breitme...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Germany: +49-30-521325470, Sweden (HQ): +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
Am Donnerstag, 18. Juni 2015, 10:16:49 schrieb Gunnar Roth:
> Gesendet: Donnerstag, 18. Juni 2015 um 08:43 Uhr
> Von: "Thiago Macieira" 
> An: development@qt-project.org
> Betreff: Re: [Development] QtCS: Long Term Release discussion
>
> On Thursday 18 June 2015 08:23:52 Gunnar Roth wrote:
> > > Am 17.06.2015 um 22:35 schrieb Thiago Macieira
> > >
> > > :
> >> > On Wednesday 17 June 2015 19:30:25 Gunnar Roth wrote:
> >> >> Yes that would make us (as a commercial user using a self made port of
> >> >> qt
> >> >> 5.4.1 to wec2013 ) very unhappy. This means 5.6 will be the last
> >> >> version
> >> >> wec2013 would be supported and you would go straight to making a back
> >> >> port
> >> >> very hard or even impossible.
> >> >
> >> > WEC 2013 was never considered deprecated. The deprecation applies to
> >> > WEC 7
> >> > only.
> >>
> >> Well ok, but how does Lars Knoll’s sentence "we could make
> >> VS2013 the compiler baseline for 5.7.“ fit into this? As the only
> >> supported
> >> compiler for wec2013 is a cl with v 17.00 aka vs2012.
> >
> >Apparently VS2013 can also be used for WEC2013.
>
> IDE: yes
> Compiler: No
>
> This was recently confirmed to as by microsoft. The used compiler comes from
> the platfrombuilder wince800 tree, which is independent from the used IDE.
> The sdk wec2013 compiler form wec2013 qfe M08 has this version: Microsoft
> (R) C/C++ Optimizing Compiler Version 17.00.50728.6 for ARM
>
> the vs2012 arm compiler ( which is meant for win pohne and winrt) has :
> Microsoft (R) C/C++ Optimizing Compiler Version 17.00.61030 for ARM
>
> I don't think the possible usage of the vs2013 ide has any impact on qt
> development.
> Regards,
> Gunnar
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCS: Long Term Release discussion

[Gunnar Roth]

 
 

Gesendet: Donnerstag, 18. Juni 2015 um 08:43 Uhr
Von: "Thiago Macieira" 
An: development@qt-project.org
Betreff: Re: [Development] QtCS: Long Term Release discussion
On Thursday 18 June 2015 08:23:52 Gunnar Roth wrote:
> > Am 17.06.2015 um 22:35 schrieb Thiago Macieira
> > :
> >
>> > On Wednesday 17 June 2015 19:30:25 Gunnar Roth wrote:
>> >> Yes that would make us (as a commercial user using a self made port of
>> >> qt
>> >> 5.4.1 to wec2013 ) very unhappy. This means 5.6 will be the last version
>> >> wec2013 would be supported and you would go straight to making a back
>> >> port
>> >> very hard or even impossible.
>> >
>> > WEC 2013 was never considered deprecated. The deprecation applies to WEC 7
>> > only.
>>
>> Well ok, but how does Lars Knoll’s sentence "we could make
>> VS2013 the compiler baseline for 5.7.“ fit into this? As the only supported
>> compiler for wec2013 is a cl with v 17.00 aka vs2012.

>Apparently VS2013 can also be used for WEC2013.

IDE: yes
Compiler: No

This was recently confirmed to as by microsoft. The used compiler comes from 
the platfrombuilder wince800 tree, which is independent from the used IDE. The 
sdk wec2013 compiler form wec2013 qfe M08 has this version:
Microsoft (R) C/C++ Optimizing Compiler Version 17.00.50728.6 for ARM

the vs2012 arm compiler ( which is meant  for win pohne and winrt) has :
Microsoft (R) C/C++ Optimizing Compiler Version 17.00.61030 for ARM

I don't think the possible usage of the vs2013 ide has any impact on qt 
development.
 
Regards,
Gunnar
 
 
 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCS: Long Term Release discussion

[Gunnar Roth]

 

Puh i this is a recurrent topic...

 

Ok in  https://codereview.qt-project.org/#/c/113276/ says Björn Breitmayer "That explains why the SDK that was generated with Visual Studio 2012 ship a 2013 compiler" I have no clue how that could happen.

How should an sdk created by a vs2012 include a vs2013 compiler? Addionally, the compiler is always taken  ( to my knowledge) from the wince800 tree installed by platfrombuilder installation and that is an v17.00 compiler ( which has an earlier subversion than the vs2012 compiler actually), so the compiler is never taken from the ide. This was confirmed last week by microsoft to us. But please share your additionall knowledge with us, we would be very thankful.

 

regards,

Gunnar

 


Gesendet: Donnerstag, 18. Juni 2015 um 08:45 Uhr
Von: "Kalinowski Maurice" 
An: "Thiago Macieira" , "development@qt-project.org" 
Betreff: Re: [Development] QtCS: Long Term Release discussion

> On Thursday 18 June 2015 08:23:52 Gunnar Roth wrote:
> > > Am 17.06.2015 um 22:35 schrieb Thiago Macieira
> > > :
> > >
> > > On Wednesday 17 June 2015 19:30:25 Gunnar Roth wrote:
> > >> Yes that would make us (as a commercial user using a self made
> > >> port of qt
> > >> 5.4.1 to wec2013 ) very unhappy. This means 5.6 will be the last
> > >> version
> > >> wec2013 would be supported and you would go straight to making a
> > >> back port very hard or even impossible.
> > >
> > > WEC 2013 was never considered deprecated. The deprecation applies to
> > > WEC 7 only.
> >
> > Well ok, but how does Lars Knoll’s sentence "we could make
> > VS2013 the compiler baseline for 5.7.“ fit into this? As the only
> > supported compiler for wec2013 is a cl with v 17.00 aka vs2012.
>
> Apparently VS2013 can also be used for WEC2013.

[Kalinowski Maurice]
Correct, check the discussion here: https://codereview.qt-project.org/#/c/113276/

As a summary, SDK makers / board vendors can select to include the VS2013 compiler into their package even though the IDE is VS2012 based. However, that puts quite some requirement on the vendor side and that needs to be evaluated.

Maurice

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCS: Long Term Release discussion

[Gunnar Roth]

> Am 17.06.2015 um 22:35 schrieb Thiago Macieira :
> 
> On Wednesday 17 June 2015 19:30:25 Gunnar Roth wrote:
>> Yes that would make us (as a commercial user  using a self made port of qt
>> 5.4.1 to wec2013 ) very unhappy. This means 5.6 will be the last version
>> wec2013 would be supported and you would go straight to making a back port
>> very hard or even impossible.
> 
> WEC 2013 was never considered deprecated. The deprecation applies to WEC 7 
> only.


Well ok, but how does Lars Knoll’s sentence  "we could make
VS2013 the compiler baseline for 5.7.“ fit into this? As the only supported 
compiler for wec2013 is a cl with  v 17.00 aka vs2012. 


Regards, 
Gunnar

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCS: Notes from Modern C++ session

[Gunnar Roth]

> Am 16.06.2015 um 22:49 schrieb Ziller Eike :
> 
> 
>> On Jun 16, 2015, at 16:52, Matthew Woehlke  
>> wrote:
>> 
>> On 2015-06-12 17:45, Thiago Macieira wrote:
>>> On Friday 12 June 2015 10:49:38 Matthew Woehlke wrote:
> On Friday 12 June 2015 08:08:51 André Somers wrote:
>> Not available for use are:
>> * = default,
>> * = deleted,
 
> 
> Actually this is not supported in VS2012
> https://msdn.microsoft.com/en-us/library/hh567368.aspx
> 
> And Thiago’s link actually lists it under VS2013 as well :)
> 
> http://code.woboq.org/qt5/qtbase/src/corelib/global/qcompilerdetection.h.html#851
Thanks Eike, saved my writing that myself.
I thought Thiago is testing me somehow… ;-)

Regards,
Gunnar
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCS: Long Term Release discussion

[Gunnar Roth]

Hello Lars,
> Am 17.06.2015 um 12:27 schrieb Knoll Lars :
> 
> * We make Qt 5.6 an LTS release

> * We could then have both WEC7 and WEC2013 (on VS2012) supported on 5.6.
> This would solve all problems for Windows Embedded and we could make
> VS2013 the compiler baseline for 5.7.
> we’d keep people on older compilers/OSes happy and we could move
> a lot more aggressively towards C++11 in the dev branch directly after
> summer vacations (from the beginning of August).
> 
> Opinions?
> 
Yes that would make us (as a commercial user  using a self made port of qt 
5.4.1 to wec2013 ) very unhappy. This means 5.6 will be the last version 
wec2013 would be supported and you would go straight to making a back port very 
hard or even impossible. Actually we somehow assumed on vs2012  being supported 
for Qt 5. As we use Qml/QtQuick we would be cut off of this development.

Regards,
Gunnar

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCS: Notes from Modern C++ session

[Gunnar Roth]

> 
 Not available for use are:
 * = default,
 * = deleted,
>> 
>> Where are these not supported? I have code that (AFAIK) has been using
>> these already, and IIRC our compiler requirements are lower.
> 
> GCC requires 4.7 for this. I think we were discussing whether our minimum is 
> 4.6 or 4.7.
> 
I am quite sure that this only works since vs 2013, Would be glad if proven 
wrong.
see https://msdn.microsoft.com/en-us/library/dn457344.aspx 


Regards,
Gunnar


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Problem with embedded fonts

[Gunnar Roth]

> 
> 
> And why don't we hear about this problem more often? Strange.
> 

Everytime i have a programming  or computer problem, which nobody else has, 
where you can’t find next to nothing or really nothing on the internet, its 
because i did some very foolish thing ;-)

Regards,
Gunnar


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Building Modules

[Gunnar Roth]

Looks like you removed the directory AFTER configure. But you should remove it 
before.

Regards,
Gunnar
> Am 22.04.2015 um 13:44 schrieb rpzrpz...@gmail.com:
> 
> 
> Thiago:
> 
> Unfortunately, your suggestion of removing the directory and/or its
> contents did not yield a positive result.
> 
> How does one successfully remove a sub-module from the build process?
> 
> Copied below is the nmake output after removing the contents of the
> qlalr directory and the directory itself as a second test.
> 
> Thank you,
> 
> md
> 
>  nmake -f Makefile.Release
> 
> Microsoft (R) Program Maintenance Utility Version 12.00.21005.1
> Copyright (C) Microsoft Corporation.  All rights reserved.
> 
>  cd tools\qlalr\ && ( if not exist Makefile
> C:\qt5\qtbase\bin\qmake C:\qt5\qtbase\src\tools\qlalr\qlalr.pro
>  -o Makefile ) && nmake -f Makefile
> Cannot find file: C:\qt5\qtbase\src\tools\qlalr\qlalr.pro
> .
> NMAKE : fatal error U1077: 'cd' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: 'cd' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: 'cd' : return code '0x2'
> Stop.
> 
> On 4/18/2015 3:00 PM, Thiago Macieira wrote:
>> On Saturday 18 April 2015 09:47:28 mark diener wrote:
>>> Hello:
>>> 
>>> How does one remove a submodule from a  git repository build?
>>> 
>>> (even if I already downloaded it)
>>> 
>>> In this case, I want qlalr submodule to be removed from the build process.
>>> 
>>> Qlalr does not build on Windows
>> 
>> rm -rf qlalr
>> 
> 
> -- 
> No spell checkers were harmed during the creation of this message.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] git://code.qt.io availability

[Gunnar Roth]

Hi

>> + git config remote.origin.url https://code.qt.io/cgit/qt/qt3d.git
>>
>this definitely doesn't look right (the git repos are not served under
>cgit/, at least not intentionally). fix the remote of qt5.git and retry.
 
Without cgit it does not work for https last time i tried. See my mail from 
31.03.2015 12:18 

My problem was different as it was due to a interrupted transfer as i know now,
i could fix that with the help of 
http://stackoverflow.com/questions/10671638/how-to-fix-git-repository-broken-by-interrupted-git-fetch
by deleting offending *.pack.temp in .git/objects/pack and corresponding idx 
file.
Now it works again ( with cgit )

Regards,
Gunnar
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] git://code.qt.io availability

[Gunnar Roth]

Hi,

i try to ge update from git but get this error.

i dit git pull and after that id do:

D:\git\qt5>perl init-repository -f
+ git submodule init qt3d qtactiveqt qtandroidextras qtbase qtcanvas3d qtconnectivity qtdeclarative qtdoc qtenginio qtgraphicaleffects qtimageformats qtlocation
 qtmacextras qtmultimedia qtqa qtquick1 qtquickcontrols qtrepotools qtscript qtsensors qtserialport qtsvg qttools qttranslations qtwayland qtwebchannel qtwebeng
ine qtwebkit qtwebkit-examples qtwebsockets qtwinextras qtx11extras qtxmlpatterns
+ git config commit.template D:/git/qt5/.commit-template
+ git config remote.origin.url https://code.qt.io/cgit/qt/qt3d.git
+ git fetch origin
error: Unable to find 075c0298d1c75dd2d61849b559edcb357d638689 under https://code.qt.io/cgit/qt/qt3d.git
Cannot obtain needed object 075c0298d1c75dd2d61849b559edcb357d638689
error: Fetch failed.
git fetch origin exited with status 32768 at init-repository line 221
        Qt::InitRepository::exe('Qt::InitRepository=HASH(0x78cfd4)', 'git', 'fetch', 'origin') called at init-repository line 489
        Qt::InitRepository::git_clone_one_submodule('Qt::InitRepository=HASH(0x78cfd4)', 'qt3d', 'qt/qt3d.git', 5.5) called at init-repository line 378
        Qt::InitRepository::git_clone_all_submodules('Qt::InitRepository=HASH(0x78cfd4)', 'qt/qt5', 0, 'default') called at init-repository line 565
        Qt::InitRepository::run('Qt::InitRepository=HASH(0x78cfd4)') called at init-repository line 576

 

 

 

Any idea what's wrong?

Regards,

Gunnar

 

Gesendet: Donnerstag, 02. April 2015 um 13:01 Uhr
Von: "Oswald Buddenhagen" 
An: "Hirvonen Olli" 
Cc: "Hiekkamäki Mika" , "development@qt-project.org" 
Betreff: Re: [Development] git://code.qt.io availability

On Thu, Apr 02, 2015 at 10:09:18AM +, Hirvonen Olli wrote:
> Thanks Kai for noticing...Mika (CC) tries to find a reason and fix.
>
that should be fixed now, at least for the time being.

> -Olli
>
> -Original Message-
> From: Koehne Kai
> Sent: 2. huhtikuuta 2015 12:03
> To: Hirvonen Olli; development@qt-project.org
> Subject: git://code.qt.io availability
>
> Hi,
>
> Since a few days code.qt.io seems to be quite unreliable: Fetching changes via git:// often fail with "fatal: read error: Invalid argument" (Windows) or "fatal: read error: Connection reset by peer" (Linux).
>
> Is someone already looking into this? Should we rather clone from the github mirror to reduce the load?
>
> Regards
>
> Kai
>
> 
> Kai Köhne, Senior Software Engineer | The Qt Company
>
> Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
> Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
>
> Email: kai.koe...@theqtcompany.com | Mobile: + 49 151 55155601 | Phone: +49 30 63 92 3255 www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @Qtproject | Facebook: www.facebook.com/qt
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] "Add tests for detach on setDevicePixelRatio()" commits in qtbase

[Gunnar Roth]

Sorry somehow i clicked on the wrong mail to answer.
 

Gesendet: Mittwoch, 08. April 2015 um 12:55 Uhr
Von: "Gunnar Roth" 
An: "Oswald Buddenhagen" 
Cc: development@qt-project.org
Betreff: Re: [Development] "Add tests for detach on setDevicePixelRatio()" commits in qtbase




Hi,

i try to ge update from git but get this error.

i dit git pull and after that id do:

D:\git\qt5>perl init-repository -f
+ git submodule init qt3d qtactiveqt qtandroidextras qtbase qtcanvas3d qtconnectivity qtdeclarative qtdoc qtenginio qtgraphicaleffects qtimageformats qtlocation
 qtmacextras qtmultimedia qtqa qtquick1 qtquickcontrols qtrepotools qtscript qtsensors qtserialport qtsvg qttools qttranslations qtwayland qtwebchannel qtwebeng
ine qtwebkit qtwebkit-examples qtwebsockets qtwinextras qtx11extras qtxmlpatterns
+ git config commit.template D:/git/qt5/.commit-template
+ git config remote.origin.url https://code.qt.io/cgit/qt/qt3d.git
+ git fetch origin
error: Unable to find 075c0298d1c75dd2d61849b559edcb357d638689 under https://code.qt.io/cgit/qt/qt3d.git
Cannot obtain needed object 075c0298d1c75dd2d61849b559edcb357d638689
error: Fetch failed.
git fetch origin exited with status 32768 at init-repository line 221
        Qt::InitRepository::exe('Qt::InitRepository=HASH(0x78cfd4)', 'git', 'fetch', 'origin') called at init-repository line 489
        Qt::InitRepository::git_clone_one_submodule('Qt::InitRepository=HASH(0x78cfd4)', 'qt3d', 'qt/qt3d.git', 5.5) called at init-repository line 378
        Qt::InitRepository::git_clone_all_submodules('Qt::InitRepository=HASH(0x78cfd4)', 'qt/qt5', 0, 'default') called at init-repository line 565
        Qt::InitRepository::run('Qt::InitRepository=HASH(0x78cfd4)') called at init-repository line 576

 

 

 

Any idea what's wrong?

Regards,

Gunnar

 

 

Gesendet: Dienstag, 07. April 2015 um 17:13 Uhr
Von: "Oswald Buddenhagen" 
An: development@qt-project.org
Betreff: Re: [Development] "Add tests for detach on setDevicePixelRatio()" commits in qtbase

On Tue, Apr 07, 2015 at 04:59:20PM +0200, Stephen Kelly wrote:
> Something 'funny' is going on with
>
> https://codereview.qt-project.org/#/c/106855/
>
apparently, it wasn't properly "tagged" after a manual fixup.
i hacked the database now.
everybody should check whether they don't have changes in a similarly
unholy state.

obviously, gerrit should refuse to create empty cherry-picks. that's a
rather long-standing issue ...

> See qtbase commits
>
> * 0b6bfe8c448179ccf9272a309d6b9ddbdc055960
> * d9437af198726e80d68ae4d95108cb08602d07f9
> * 22b5e178e5a32988f8c23170288ef3d48df5f00d
> * 558c9cadddacea37669c28ec2abe62c8f5726e8e
> * 6dcbaa487d222440c2aeeb5f0ad3bc6337d52f5d
> * 23330d498d8b9b247fede83351a9843094540743
> * 57c399c3e65d1339cf3c273adf840801686fb4da
> * 0b440e1498699d0fa37114453dce3f463f0752fb
> * b0c58c2bb4cde616302f98e4c64549ae2ae028cf
>
> at least, all of which are empty, and
>
> 72854081b2e3831ab6619a9c2e7f4ba0a6a1d316
>
> which is not empty. The gerrit commit is 'staged' again even now.
>
> What's going on? Is anything being done about this already? It's
> making a messy history and it should be stopped.
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development




___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] "Add tests for detach on setDevicePixelRatio()" commits in qtbase

[Gunnar Roth]

Hi,

i try to ge update from git but get this error.

i dit git pull and after that id do:

D:\git\qt5>perl init-repository -f
+ git submodule init qt3d qtactiveqt qtandroidextras qtbase qtcanvas3d qtconnectivity qtdeclarative qtdoc qtenginio qtgraphicaleffects qtimageformats qtlocation
 qtmacextras qtmultimedia qtqa qtquick1 qtquickcontrols qtrepotools qtscript qtsensors qtserialport qtsvg qttools qttranslations qtwayland qtwebchannel qtwebeng
ine qtwebkit qtwebkit-examples qtwebsockets qtwinextras qtx11extras qtxmlpatterns
+ git config commit.template D:/git/qt5/.commit-template
+ git config remote.origin.url https://code.qt.io/cgit/qt/qt3d.git
+ git fetch origin
error: Unable to find 075c0298d1c75dd2d61849b559edcb357d638689 under https://code.qt.io/cgit/qt/qt3d.git
Cannot obtain needed object 075c0298d1c75dd2d61849b559edcb357d638689
error: Fetch failed.
git fetch origin exited with status 32768 at init-repository line 221
        Qt::InitRepository::exe('Qt::InitRepository=HASH(0x78cfd4)', 'git', 'fetch', 'origin') called at init-repository line 489
        Qt::InitRepository::git_clone_one_submodule('Qt::InitRepository=HASH(0x78cfd4)', 'qt3d', 'qt/qt3d.git', 5.5) called at init-repository line 378
        Qt::InitRepository::git_clone_all_submodules('Qt::InitRepository=HASH(0x78cfd4)', 'qt/qt5', 0, 'default') called at init-repository line 565
        Qt::InitRepository::run('Qt::InitRepository=HASH(0x78cfd4)') called at init-repository line 576

 

 

 

Any idea what's wrong?

Regards,

Gunnar

 

 

Gesendet: Dienstag, 07. April 2015 um 17:13 Uhr
Von: "Oswald Buddenhagen" 
An: development@qt-project.org
Betreff: Re: [Development] "Add tests for detach on setDevicePixelRatio()" commits in qtbase

On Tue, Apr 07, 2015 at 04:59:20PM +0200, Stephen Kelly wrote:
> Something 'funny' is going on with
>
> https://codereview.qt-project.org/#/c/106855/
>
apparently, it wasn't properly "tagged" after a manual fixup.
i hacked the database now.
everybody should check whether they don't have changes in a similarly
unholy state.

obviously, gerrit should refuse to create empty cherry-picks. that's a
rather long-standing issue ...

> See qtbase commits
>
> * 0b6bfe8c448179ccf9272a309d6b9ddbdc055960
> * d9437af198726e80d68ae4d95108cb08602d07f9
> * 22b5e178e5a32988f8c23170288ef3d48df5f00d
> * 558c9cadddacea37669c28ec2abe62c8f5726e8e
> * 6dcbaa487d222440c2aeeb5f0ad3bc6337d52f5d
> * 23330d498d8b9b247fede83351a9843094540743
> * 57c399c3e65d1339cf3c273adf840801686fb4da
> * 0b440e1498699d0fa37114453dce3f463f0752fb
> * b0c58c2bb4cde616302f98e4c64549ae2ae028cf
>
> at least, all of which are empty, and
>
> 72854081b2e3831ab6619a9c2e7f4ba0a6a1d316
>
> which is not empty. The gerrit commit is 'staged' again even now.
>
> What's going on? Is anything being done about this already? It's
> making a messy history and it should be stopped.
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] quickcontrols has now a hard dependancy on widgets.

[Gunnar Roth]

Hello,
it has been quite some time since this thread, but yesterday i tried the 
approach using no_desktop just to find out, the the qtsvg imageformat plugin,
has ( of course) a dependency on qtsvg, which in turn does also depend on 
widgets.
Ok so i thought i use -no-widgets when configuring, but my wec 2013 build using 
qt 5.5 git failed. By the nature of the problem, i think a win32 build would 
have failed too.
Note: that i am dong shadow builds and no -developer-build
This modifications made the build compile:
--- a\qtbase\src\plugins\platforms\windows/accessible/iaccessible2.cpp    
2015-03-12 15:49:39.698271300 +0100
+++ b\qtbase\src\plugins\platforms\windows/accessible/iaccessible2.cpp    
2015-04-01 13:18:29.368083400 +0200
@@ -36,11 +36,11 @@
 #include "iaccessible2.h"
 #include "qwindowsaccessibility.h"
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 QT_BEGIN_NAMESPACE
 
--- 
a\qtbase\src\plugins\platforms\windows/accessible/qwindowsmsaaaccessible.cpp    
2015-03-12 15:49:39.706271300 +0100
+++ 
b\qtbase\src\plugins\platforms\windows/accessible/qwindowsmsaaaccessible.cpp    
2015-04-01 13:04:14.062083400 +0200
@@ -37,24 +37,21 @@
 #include "qwindowsmsaaaccessible.h"
 #include "qwindowsaccessibility.h"
 #include 
 #include 
 #include 
 #include "comutils.h"
 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
+
 
 //#include 
 #ifndef UiaRootObjectId
 #define UiaRootObjectId-25
 #endif 

Regards,
Gunnar Roth



Gesendet: Mittwoch, 17. Dezember 2014 um 14:02 Uhr
Von: "deDietrich Gabriel" 
An: "development@qt-project.org" 
Cc: "Gunnar Roth" , "gun...@sletta.org" 
, "Nurmi J-P" 
Betreff: Re: Re: [Development] quickcontrols has now a hard dependancy on 
widgets.

Qt Quick Controls do depend on QtWidgets because of styling on desktop. This 
may be solved in the future as we plan on having separate plugins for styles. 
(Notice that Qt Quick Controls are not integral part of Qt Quick but a separate 
module.)
 
If you're writing an embedded app, then you most likely have a cross-built 
version of Qt (I'm assuming that's the case for WEC2013, of which I don't know 
much), and that version probably doesn't need widgets. So you can do as Gunnar 
S. proposed. Otherwise, your only solution, as I said earlier, is to build Qt 
Quick Controls with CONFIG += no_desktop. The only feature you'll miss by doing 
so is the desktop native-looking style, but that wouldn't make sense on WCE2013 
either, AFAICT.
 

Best regards,
 
Dr. Gabriel de Dietrich
Senior Software Developer
The Qt Company — www.qt.io[http://www.qt.io]
 


From: Gunnar Roth 
Sent: Tuesday, December 16, 2014 4:15 PM
To: gun...@sletta.org
Cc: deDietrich Gabriel; development@qt-project.org
Subject: Aw: Re: [Development] quickcontrols has now a hard dependancy on 
widgets.
 

Well, i know that leaving out widgets from configure would also solve this 
problem ,but as i wrote i also need widgets in my build for other programs.
I just dont understand that i get widgets dependency by just using 
quickcontrols. And QtQuick does NOT depend on widgets as you say. I just look 
with depends.exe
and qt5quick does only depend on gui,qml,network and core. qml  does depend on 
network and core only.
 
Regards,
Gunnar (Roth)
 

Gesendet: Dienstag, 16. Dezember 2014 um 09:00 Uhr
Von: gun...@sletta.org
An: "Gunnar Roth" 
Cc: gabriel.dedietr...@theqtcompany.com, development@qt-project.org
Betreff: Re: [Development] quickcontrols has now a hard dependancy on widgets.
Configure qtbase with "-no-widgets" and all widget dependencies should be gone 
from both Qt Quick and from Controls.


--- gunnar.r...@gmx.de wrote:

From: "Gunnar Roth" 
To: "deDietrich Gabriel" 
Cc: "development@qt-project.org" 
Subject: Re: [Development] quickcontrols has now a hard dependancy on widgets.
Date: Mon, 15 Dec 2014 14:01:41 +0100



HI Gabriel,
I didn't know that, but i don't want any widgets dependency for a qml 
application, neither on desktop nor anywhere else.
 
Regards,
Gunnar
 
 

Gesendet: Montag, 15. Dezember 2014 um 12:04 Uhr
Von: "deDietrich Gabriel" 
An: "Gunnar Roth" , "development@qt-project.org" 

Betreff: Re: [Development] quickcontrols has now a hard dependancy on widgets.
Hi Gunnar,

You can always rebuild QtQuick Controls making sure you add CONFIG += 
no_desktop in the .pro file. The widgets dependency is automatic if widgets are 
present except on mobile platforms (which, paradoxically, exclude embedded).

Best regards,

Dr. Gabriel de Dietrich
Senior Software Developer
The Qt Company — www.qt.io[http://www.qt.io][http://www.qt.io[http://www.qt.io]]


__

Re: [Development] Switching remote url for qt5 git clone

[Gunnar Roth]

Now wiki says 
git clone git://code.qt.io/qt/qt5.git

But i am quite sure it must be 
git clone git://code.qt.io/cgit/qt/qt5.git



Because otherwise i got an error: fatal: repository 'https://code.qt.io/qt/qt5.git/' not found

Regards,

Gunnar Roth


Gesendet: Dienstag, 31. März 2015 um 07:21 Uhr
Von: "Blasche Alexander" 
An: "" 
Betreff: Re: [Development] Switching remote url for qt5 git clone

It is an oversight. I fixed it. Thank you for pointing it out.

--
Alex


From: development-bounces+alexander.blasche=theqtcompany@qt-project.org  on behalf of Harri Porten 
Sent: Monday, March 30, 2015 18:31
To: 
Subject: Re: [Development] Switching remote url for qt5 git clone

On Thu, 26 Mar 2015, Adam Light wrote:

> I'd like to move my checkout to git://code.io.qt.

I got reminded of your mail when I just did a new clone:

http://wiki.qt.io/Building_Qt_5_from_Git suggests the usage of:

git clone git://code.qt.io/git/qt/qt5.git

but the /git/ part is probably just an oversight?

Harri.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] msvc warning policy in qt

[Gunnar Roth]

Well after some tests I learned that my original prolog is best. Adding #define QT_CC_WARNINGS
#include  actually lead to warnings as is inlcuding a lot more than i thought. But this warnins are swicth off only later in the file.

There is not any benefit in my changes so i simplke removed them and all is well again.

just to let you know...

Regards,

Gunnar Roth


Gesendet: Montag, 09. März 2015 um 10:08 Uhr
Von: "Gunnar Roth" 
An: "development@qt-project.org" 
Betreff: [Development] msvc warning policy in qt



Hello,

we have an in-house policy to use warning level 4 and warnings-as-errors with our projects.

The problem is that qt headers are generating warnings when using this level. 

We switch off some silly warnings like  "unreferenced inline function has been removed", which are just informal and cant be removed by us.

I created a Qt_prolog.h and an Qt_epilog.h which have to be included before and after every Qt Header.

 

prolog is this:

#  pragma warning (push)
#  pragma warning( disable : 4201 ) // nonstandard extension used : nameless struct/union    
#  pragma warning( disable : 4127 ) // conditional _expression_ is constant
#  pragma warning( disable : 4510 ) // default constructor cannot be generated
#  pragma warning( disable : 4512 ) // assignment operator could not be generated
#  pragma warning( disable : 4244 ) // conversion from 'int/double/float/long' to 'qreal', possible loss of data
#  pragma warning( disable : 4251 ) // class needs to have dll-interface to be used by clients of class 
#  pragma warning( disable : 4800 ) // 'BOOL' : forcing value to bool 'true' or 'false' (performance warning)
#  pragma warning( disable : 4245 ) //  'initializing' : conversion from 'int' to 'unsigned short', signed/unsigned mismatch
#  pragma warning( disable : 4251 ) //  class 'QExplicitlySharedDataPointer' needs to have dll-interface to be used by clients of class
#  pragma warning( disable : 4231 ) //   nonstandard extension used : 'extern' before template explicit instantiation
#  pragma warning( disable : 4275 ) //  non dll-interface class 'x' used as base for dll-interface class 'y'
#  pragma warning( disable : 4995 ) //  'method' name was marked as #pragma deprecated
#  pragma warning( disable : 4718 ) //  recursive call has no side effects, deleting

 

 

epilog is just

#  pragma warning (pop)

 

 

actually there are some warnings i would myself never switch off like "conversion from 'int/double/float/long' to 'qreal', possible loss of data" or 'initializing' : conversion from 'int' to 'unsigned short', signed/unsigned mismatch", but without that i get a warning ( and an error)#

 

now i found out that qglobal.h does disable warnings in its own globally, so it pollutes my warning level by that.

it even disables the imho very important warnings "assignment within conditional _expression_"  and  "C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc ".

Especially "assignment within conditional _expression_" is a live saver. you can easyly suppress it by writing if((a=open())  if the = is your real intent.

"C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc " is a strong idication you are using exceptions but in case of one thrown you are not unwinding stack getting memory leaks and other problems.

 

Luckily you can disable the warnings disabling, by defining QT_CC_WARNINGS

so i added 

#define QT_CC_WARNINGS
#include 

 

after the #  pragma warning (push) and added all warning disabling from qglobal.h to the end of the prolog file, whiuch are:

// copied from qglobale.h
#    pragma warning(disable: 4251) /* class 'type' needs to have dll-interface to be used by clients of class 'type2' */
#    pragma warning(disable: 4244) /* conversion from 'type1' to 'type2', possible loss of data */
#    pragma warning(disable: 4275) /* non - DLL-interface classkey 'identifier' used as base for DLL-interface classkey 'identifier' */
#    pragma warning(disable: 4514) /* unreferenced inline function has been removed */
#    pragma warning(disable: 4800) /* 'type' : forcing value to bool 'true' or 'false' (performance warning) */
#    pragma warning(disable: 4097) /* typedef-name 'identifier1' used as synonym for class-name 'identifier2' */
#    pragma warning(disable: 4706) /* assignment within conditional _expression_ */
#    if _MSC_VER <= 1310 // MSVC 2003
#      pragma warning(disable: 4786) /* 'identifier' : identifier was truncated to 'number' characters in the debug information */
#    endif
#    pragma warning(disable: 4355) /* &#

[Development] msvc warning policy in qt

[Gunnar Roth]

 warning 'function' : inconsistent DLL linkage'  Two definitions in a file differ in their use of dllimport.

 

so i added 

#ifdef UNDER_CE
#include 
#endif // UNDER_CE

 

to my prolog after my #include 

 


My problems are solved this way ,but i would rather like that qt takes care of this itself, meaning allowing setting warninglevel to 4 and warnings as errors and applications compile out of the box,

maybe by using  my prolog/epilog approach.

 

Regards,

Gunnar Roth

 

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] license question, bds 4 clause license text in qtbase\src\corelib\tools\qdatetime.cpp qt5.4.1 found

[Gunnar Roth]

Ok i now finally also found /doc/src/legal/licenses.qdoc which is compiled into 
qtdoc.qch 

There i can find Copyright (C) 2004, 2005 Daniel M. Duley
under  
Parts of the codecs implemented by Qt ( meaning TextCodecs)
But not for his code used in image scaling.

The thing that i am picking on that all is because i am and will be picked by 
our legal department.
I am trying since March 2014 to figure things out with Digia ( now Qt Company) 
, The first of my requests were simply closed after a while with out a reason. 
Reopened it in June same thing happened then.
The 3rd i started on monday  and in paralleli wrote to this mailing list 
and out of a sudden things are getting momentum. So hopefully this burden
will get less and less for me. I am a strong advocate of using commercial qt 
licensing in  my department, so it was a bit disappointing for me to not get 
the support i had hoped for initially.

Thanks for reading,
Gunnar Roth.



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] license question, bds 4 clause license text in qtbase\src\corelib\tools\qdatetime.cpp qt5.4.1 found

[Gunnar Roth]

> Am 28.02.2015 um 08:10 schrieb Sune Vuorela :
> 
>> Well https://www.gnu.org/licenses/license-list.en.html says
>> Original BSD license (#OriginalBSD)
>> This license is also sometimes called the “4-clause BSD license”.
>> 
>> This is a lax, permissive non-copyleft free software license with a serious 
>> flaw: the “obnoxious BSD advertising clause”. The flaw is not fatal; that 
>> is, it does not render the software nonfree. But it does cause practical 
>> problems, including incompatibility with the GNU GPL.
>> 
>> but ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change says
>> Effective immediately, licensees and distributors are no longer required to
>> include the acknowledgement within advertising materials.  Accordingly, the
>> foregoing paragraph of those BSD Unix files containing it is hereby deleted
>> in its entirety.
>> 
>> But does the week number code fall under the category  BSD Unix files ?
>> 
>> So who is right her? GNU.org, Thiago ?  I am not a lawyer( thank god :-) ) 
>> or judge to decide this.
> 
> Everybody is right. 4-clause-BSD is incompatible with BSD, but as you
> write yourself, the university of california has removed the obnoxious
> clause from all their software, so it is just 3-clause licensed, even if
> you have a old copy of it.
> 
 UC writes  BSD Unix files not about general source code.
And why does gnu,org not update their website,but till insists on  
incompatibility with the GNU GPL?

Regards,
Gunnar


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] license question, bds 4 clause license text in qtbase\src\corelib\tools\qdatetime.cpp qt5.4.1 found

[Gunnar Roth]

Hi Tuuka

> There is no requirement to mention use of Qt if you have a commercial 
> license. Of course you do need to mention 3rd party open-source components, 
> to the extent you use them. Documentation contains a listing of these per 
> module to make it easier.
> 

Okay there is  http://doc.qt.io/qt-5/3rdparty.html 
but this page does not mention Copyright (C) 2004, 2005 Daniel M. Duley
for scaling code in qimage, nor  copyright regents of california when using 
qtcore ( it does mention it for use of liftoff) . So if i use qimage(qt5gui.dll 
or qt5core.dll)  i would have to add this to my documentation.
Either commercial user or not. but show me any program using qimage which 
really does this.



> There is some 3rd party code that is used very little any more, and we have 
> been continuously working to remove the ones that are non-permissive, when 
> possible. We are very happy to accept your help in pointing these out, or for 
> re-implementing the functionality to remove the 3rd party dependency.

Thats a good thing to do. as there is 3party code used n code which i have 
shown which is not directly recognizable as third party code.

> It should be noted that we disagree with your claim that having items with 
> original BSD clause would prevent releasing Qt under GPL.
> 

Well https://www.gnu.org/licenses/license-list.en.html says
Original BSD license (#OriginalBSD)
This license is also sometimes called the “4-clause BSD license”.

This is a lax, permissive non-copyleft free software license with a serious 
flaw: the “obnoxious BSD advertising clause”. The flaw is not fatal; that is, 
it does not render the software nonfree. But it does cause practical problems, 
including incompatibility with the GNU GPL.
 
but ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change says
Effective immediately, licensees and distributors are no longer required to
include the acknowledgement within advertising materials.  Accordingly, the
foregoing paragraph of those BSD Unix files containing it is hereby deleted
in its entirety.

But does the week number code fall under the category  BSD Unix files ?

So who is right her? GNU.org, Thiago ?  I am not a lawyer( thank god :-) ) or 
judge to decide this.


Regards,
Gunnar Roth

> Yours,
> 
>Tuukka
> 
> 
> Lähettäjä: development-bounces+tuukka.turunen=theqtcompany@qt-project.org 
>  
> käyttäjän  puolestaGunnar Roth 
> Lähetetty: 27. helmikuuta 2015 20:40
> Vastaanottaja: Thiago Macieira
> Kopio: development@qt-project.org
> Aihe: Re: [Development] license question,   bds 4 clause license text in 
> qtbase\src\corelib\tools\qdatetime.cpp qt5.4.1 found
> 
> Hi Thiago,
> should i just take your word or do you also have a link for this?
> 
> the requirement to document this  is also more than qt company tells 
> commercial customers. they they if you use modules which are under commrcial 
> license
> as qtcore pretends to be, you can be silent about anything used in there.
> 
> and while i am at it, there is also
>• \legalese
>•  Copyright (C) 2004, 2005 Daniel M. Duley
>•
>•  Redistribution and use in source and binary forms, with or 
> without
>• modification, are permitted provided that the following 
> conditions
>• are met:
>•
>•  1. Redistributions of source code must retain the above 
> copyright
>• notice, this list of conditions and the following disclaimer.
>•  2. Redistributions in binary form must reproduce the above 
> copyright
>• notice, this list of conditions and the following disclaimer 
> in the
>• documentation and/or other materials provided with the 
> distribution.
> in qtbase/src/gui/image/qimage.cpp, which i found accidentally today, so also 
> for this a commercial customer(and even a lpgl or gal user) has to reproduce
> copyright (C) 2004, 2005 Daniel M. Duley
> in his documentation.
> I am quite sure nobody does this. http://doc.qt.io/qt-5/3rdparty.html is also 
> not mentioning this.
> 
> The Digia legal counsel Topi Ruotsalainen tells in 
> https://devdays.kdab.com/wp-content/uploads/2012/Qt_license_options_FINAL_20121114.pdf
>  page  14
> 
> Qt Commercial can be used „silently‟ to create products ● No need to mention 
> in documentation, end-user license, to provide source code etc. that LGPL 
> requires
> 
> 
> Well that then seems to not be true…
> 
> Regards,
> Gunnar
> 
> Ps.: And then there is also the modified freetype code in qtgui’s raster code 
> which also has the freetype license and one need to mention freetype in your 
> documentation, even if you don’t use th

Re: [Development] license question, bds 4 clause license text in qtbase\src\corelib\tools\qdatetime.cpp qt5.4.1 found

[Gunnar Roth]

Hi Thiago

> 
>> the requirement to document this  is also more than qt company tells
>> commercial customers. they they if you use modules which are under
>> commrcial license as qtcore pretends to be, you can be silent about
>> anything used in there.
> 
> There's a page in the Qt documentation that lists all the documentation 
> requirements.

Yes that is the page . http://doc.qt.io/qt-5/3rdparty.html 
  i mentioned and as i wrote this page 
does not contain
the Copyright (C) 2004, 2005 Daniel M. Duley 
so how should a customer know he needs to mention it?


> 
>> The Digia legal counsel Topi Ruotsalainen tells in
>> https://devdays.kdab.com/wp-content/uploads/2012/Qt_license_options_FINAL_2
>> 0121114.pdf page 14
>> 
>> Qt Commercial can be used „silently‟ to create products ● t is No need to 
>> mention
>> in documentation, end-user license, to provide source code etc. that LGPL
>> requires

> Because it's not LGPL requirement.
> 

What is NOT lpgl requirement?

> You still have to observe the BSD 2- and 3-clause requirement to reproduce 
> the 
> copyright notice.
> 

Well i read it like this: 
Qt Commercial can be used „silently‟ to create products. No need to mention 
documentation.
So how is that silent if i need to add a lot of copyright notices which i also 
have to find myself by scanning the qtbase source code?


Regards,
Gunnar



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] license question, bds 4 clause license text in qtbase\src\corelib\tools\qdatetime.cpp qt5.4.1 found

[Gunnar Roth]

Hi Thiago,
should i just take your word or do you also have a link for this?

the requirement to document this  is also more than qt company tells commercial 
customers. they they if you use modules which are under commrcial license
as qtcore pretends to be, you can be silent about anything used in there.

and while i am at it, there is also
• \legalese
•  Copyright (C) 2004, 2005 Daniel M. Duley
•  
•  Redistribution and use in source and binary forms, with or 
without
• modification, are permitted provided that the following 
conditions
• are met:
•  
•  1. Redistributions of source code must retain the above copyright
• notice, this list of conditions and the following disclaimer.
•  2. Redistributions in binary form must reproduce the above 
copyright
• notice, this list of conditions and the following disclaimer 
in the
• documentation and/or other materials provided with the 
distribution.
in qtbase/src/gui/image/qimage.cpp, which i found accidentally today, so also 
for this a commercial customer(and even a lpgl or gal user) has to reproduce 
copyright (C) 2004, 2005 Daniel M. Duley
 in his documentation.
I am quite sure nobody does this. http://doc.qt.io/qt-5/3rdparty.html is also 
not mentioning this.

The Digia legal counsel Topi Ruotsalainen tells in 
https://devdays.kdab.com/wp-content/uploads/2012/Qt_license_options_FINAL_20121114.pdf
 page  14

Qt Commercial can be used „silently‟ to create products ● No need to mention in 
documentation, end-user license, to provide source code etc. that LGPL requires


Well that then seems to not be true…

Regards,
Gunnar

Ps.: And then there is also the modified freetype code in qtgui’s raster code 
which also has the freetype license and one need to mention freetype in your 
documentation, even if you don’t use the 3rdparte ferrotype lib provided by qt 
( on windows you don’t need this for example  ) 


> Am 27.02.2015 um 18:29 schrieb Thiago Macieira :
> 
> On Friday 27 February 2015 08:40:21 Gunnar Roth wrote:
>> is the so called adevrtising clause which is know to not be kompatible with
>> GPL or LPGL, so how can it be that i find this kind of license in qt source
>> code? What are the obligations to follow when using commercial license?
> 
> The University of California has revoked the clause that causes 
> incompatibility in all code that it owns the copyright for. Therefore, 4-
> clause BSD by UC == 3-clause BSD.
> 
> There's no incompatibility, but the requirement to document remains.
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCore missing check for memory allocation

[Gunnar Roth]

Hi,

>  in fact both C++11 and C++14 have improved the ways in which the new/delete 
> operators can be overridden.

can you give me some links describing these improvements?

regards,
Gunnar Roth
 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] license question, bds 4 clause license text in qtbase\src\corelib\tools\qdatetime.cpp qt5.4.1 found

[Gunnar Roth]

Hi all,

i have a question according license compatibilty.

In qtbase\src\corelib\tools\qdatetime.cpp above line 601 in qt5.4.1 i found this:


  \legalese
    Copyright (c) 1989 The Regents of the University of California.
    All rights reserved.

    Redistribution and use in source and binary forms are permitted
    provided that the above copyright notice and this paragraph are
    duplicated in all such forms and that any documentation,
    advertising materials, and other materials related to such
    distribution and use acknowledge that the software was developed
    by the University of California, Berkeley.  The name of the
    University may not be used to endorse or promote products derived
    from this software without specific prior written permission.
    THIS SOFTWARE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR
    IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
    WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

    \sa isValid()
*/

int QDate::weekNumber(int *yearNumber) const
{

 

 

advertising materials, and other materials related to such
    distribution and use acknowledge that the software was developed
    by the University of California, Berkeley. 

is the so called adevrtising clause which is know to not be kompatible with GPL or LPGL, so how can it be that i find this kind of license in qt source code?

What are the obligations to follow when using commercial license?

 

Regards,

Gunnar Roth

 

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] trying to build qt 5.5 git branch. Missing qtbase\include dir and content.

[Gunnar Roth]

Hi Thiago,

that was the right hint. I had to create the .git dir in every module dir.

I did get the code by using git, but i have a copy script which copies the relevant parts of the qt src code and i ignored the .git directories.

So thank you very much for your help.

 

Regards,

Gunnar

 

 

Gesendet: Dienstag, 24. Februar 2015 um 18:56 Uhr
Von: "Thiago Macieira" 
An: development@qt-project.org
Betreff: Re: [Development] trying to build qt 5.5 git branch. Missing qtbase\include dir and content.

On Tuesday 24 February 2015 07:42:16 Gunnar Roth wrote:
> Hello,
> i am trying to build qt5.5 from git on windows . i do not want to make a
> deveolper build but want to build the code as i normally do. After creating
> the configure.exe, configureing and starting the build, qtcore build fails
> because it cannot find headers, which normally reside in qtbase\include but
> this is completely missing in the git src code. what do i need to do to
> create the source code in a form like it is in released tar.gz files?

How did you obtain the source code?

If you used git clone, this should not be happening.

If you used git archive or downloaded an archive from the web interfaces, then
this is the root cause. Create a directory called .git inside qtbase to fool
the Qt buildsystem into thinking you have a clone.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] trying to build qt 5.5 git branch. Missing qtbase\include dir and content.

[Gunnar Roth]

I now started all over, i can find qt-src\qtbase\include\QtCore now. But build fails with

        cl -c -nologo -Zm200 -Zc:wchar_t -O2 -MD -Zi -D_HAS_EXCEPTIONS=0 -MP -GR -GL -W3 -w34100 -w34189 -w44996 /Fd..\..\..\lib\Qt5BootstrapRTIL.pdb -DUNICODE
-DWIN32 -DQT_BOOTSTRAPPED -DQT_LITE_UNICODE -DQT_NO_CAST_TO_ASCII -DQT_NO_CODECS -DQT_NO_DATASTREAM -DQT_NO_LIBRARY -DQT_NO_QOBJECT -DQT_NO_SYSTEMLOCALE -DQT_NO
_THREAD -DQT_NO_UNICODETABLES -DQT_NO_USING_NAMESPACE -DQT_NO_DEPRECATED -DQT_NO_TRANSLATION -DQT_QMAKE_LOCATION=\"C:/RTIL/Shared/Qt/5.5.0/bld/WIN32-VS11-32/qtb
ase/bin/qmake\" -DQT_CRYPTOGRAPHICHASH_ONLY_SHA1 -DQT_NO_CAST_FROM_ASCII -DQT_BUILD_BOOTSTRAP_LIB -DQT_BUILDING_QT -D_CRT_SECURE_NO_WARNINGS -D_USE_MATH_DEFINES
 -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x040800 -DQT_NO_EXCEPTIONS -DQT_NO_DE
BUG -DNDEBUG -I"C:\RTIL\Shared\Qt\5.5.0\qt-src\qtbase\src\tools\bootstrap" -I"." -I"C:\RTIL\Shared\Qt\5.5.0\qt-src\qtbase\src\3rdparty\zlib" -I"C:\RTIL\Shared\Q
t\5.5.0\qt-src\qtbase\include" -I"C:\RTIL\Shared\Qt\5.5.0\qt-src\qtbase\include\QtCore" -I"C:\RTIL\Shared\Qt\5.5.0\qt-src\qtbase\include\QtXml" -I"C:\RTIL\Share
d\Qt\5.5.0\qt-src\qtbase\include\QtCore\5.5.0" -I"C:\RTIL\Shared\Qt\5.5.0\qt-src\qtbase\include\QtCore\5.5.0\QtCore" -I"C:\RTIL\Shared\Qt\5.5.0\qt-src\qtbase\in
clude\QtXml\5.5.0" -I"C:\RTIL\Shared\Qt\5.5.0\qt-src\qtbase\include\QtXml\5.5.0\QtXml" -I"..\..\..\include" -I"..\..\..\include\QtCore" -I"C:\RTIL\Shared\Qt\5.5
.0\bld\WIN32-VS11-32\qtbase\include\QtXml" -I"tmp" -I"C:\RTIL\Shared\Qt\5.5.0\qt-src\qtbase\mkspecs\win32-msvc2012" -Fo.obj\release\ @C:\Users\adrogu1\AppData\L
ocal\Temp\qdom.obj.6168.17472.jom
qdom.cpp
C:\RTIL\Shared\Qt\5.5.0\qt-src\qtbase\src\xml\dom\qdom.cpp(35) : fatal error C1083: Cannot open include file: 'qdom.h': No such file or directory

 

thats would be in  qt-src\qtbase\include\QtXml  but does not exist.

 

i also see now that this is Qt5BootstrapRTIL which is being build.

 

but still got no clue whats wrong actually.

 

Regards,

Gunnar

 

 

 

Gesendet: Dienstag, 24. Februar 2015 um 10:34 Uhr
Von: "Gunnar Roth" 
An: "Konstantin Ritt" 
Cc: "development@qt-project.org" 
Betreff: Re: [Development] trying to build qt 5.5 git branch. Missing qtbase\include dir and content.



Yes, as i wrote "After creating the configure.exe, configuring [..]"


 

from the log:

Starting Qt configuring for win32-vs11-32 
+ cd qtbase
+ C:\RTIL\Shared\Qt\5.5.0\qt-src\qtbase\configure.bat -top-level -prefix C:\RTIL\SharedBin\Qt\5.5.0\WIN32-VS11-32 -platform win32-msvc2012  -debug-and-release -rtti -force-debug-info -mp -ltcg -qtlibinfix RTIL -opensource -confirm-license -nomake examples -nomake tests -system-libjpeg -opengl dynamic -directwrite -direct2d

 

 

Regards,

Gunnar


Gesendet: Dienstag, 24. Februar 2015 um 09:56 Uhr
Von: "Konstantin Ritt" 
An: "Gunnar Roth" 
Cc: "development@qt-project.org" 
Betreff: Re: [Development] trying to build qt 5.5 git branch. Missing qtbase\include dir and content.


How did you configure it? Did you run configure.bat?

 

Regards,
Konstantin

 

2015-02-24 10:42 GMT+04:00 Gunnar Roth <gunnar.r...@gmx.de>:




Hello,

i am trying to build qt5.5 from git on windows . i do not want to make a deveolper build but want to build the code as i normally do.

After creating the configure.exe, configureing and starting the build, qtcore build fails because it cannot find headers, which normally reside in qtbase\include but this is completely missing in the git src code.

what do i need to do to create the source code in a form like it is in released tar.gz files?

 

Thank you in advance,

Gunnar Roth

 



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
 







___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] trying to build qt 5.5 git branch. Missing qtbase\include dir and content.

[Gunnar Roth]

Yes, as i wrote "After creating the configure.exe, configuring [..]"


 

from the log:

Starting Qt configuring for win32-vs11-32 
+ cd qtbase
+ C:\RTIL\Shared\Qt\5.5.0\qt-src\qtbase\configure.bat -top-level -prefix C:\RTIL\SharedBin\Qt\5.5.0\WIN32-VS11-32 -platform win32-msvc2012  -debug-and-release -rtti -force-debug-info -mp -ltcg -qtlibinfix RTIL -opensource -confirm-license -nomake examples -nomake tests -system-libjpeg -opengl dynamic -directwrite -direct2d

 

 

Regards,

Gunnar


Gesendet: Dienstag, 24. Februar 2015 um 09:56 Uhr
Von: "Konstantin Ritt" 
An: "Gunnar Roth" 
Cc: "development@qt-project.org" 
Betreff: Re: [Development] trying to build qt 5.5 git branch. Missing qtbase\include dir and content.


How did you configure it? Did you run configure.bat?

 

Regards,
Konstantin

 

2015-02-24 10:42 GMT+04:00 Gunnar Roth <gunnar.r...@gmx.de>:




Hello,

i am trying to build qt5.5 from git on windows . i do not want to make a deveolper build but want to build the code as i normally do.

After creating the configure.exe, configureing and starting the build, qtcore build fails because it cannot find headers, which normally reside in qtbase\include but this is completely missing in the git src code.

what do i need to do to create the source code in a form like it is in released tar.gz files?

 

Thank you in advance,

Gunnar Roth

 



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
 






___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] trying to build qt 5.5 git branch. Missing qtbase\include dir and content.

[Gunnar Roth]

Hello,

i am trying to build qt5.5 from git on windows . i do not want to make a deveolper build but want to build the code as i normally do.

After creating the configure.exe, configureing and starting the build, qtcore build fails because it cannot find headers, which normally reside in qtbase\include but this is completely missing in the git src code.

what do i need to do to create the source code in a form like it is in released tar.gz files?

 

Thank you in advance,

Gunnar Roth

 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Item creation time in QML

[Gunnar Roth]

Hello Gunnar
yes i meant y-axis. 
ok so it is operations/frame and i assume a modern pc is used for Robin 
Burchells measurements as you did with using you MacBook Pro. 
After my vacation I will try to do execute  your benchmarking measurements on 
our wec2013 imx6 device, using 5.4 and qt 5.5 git. so i can see if we all see 
improvements here.
( I will ask a colleague to do similar on our im6 and omap linux devices)

but how do i get 5.5 git ? 
can i simply use :

git clone https://git.gitorious.org/qt/qt5.git qt5
cd qt5
git checkout 5.5
perl init-repository

??

Thank you very much for your efforts in making qml better and faster (again) . 
We had asked digia a long time for benchmarks, but did not get any good 
information
, then i found your blog last year giving us want we needed, an insightful 
designed benchmarking suite.well for some testcase we got a crash fair but all 
in all it was a good start.
we get involved with dig again with our results but … we will see.

Best regards,
Gunnar Roth


> Am 12.02.2015 um 19:25 schrieb Gunnar Sletta :
> 
> 
>> On 12 Feb 2015, at 18:03, Gunnar Roth  wrote:
>> 
>> Hi,
>> after downloading it to my cell phone and picking it with usb connection, i 
>> was finally able to read pdf document.
>> I am curious what the unit of the x-axis is in your diagrams, i fugure 
>> higher is better, but what is measured there?
> 
> Hi Gunnar :)
> 
> The x-axis is Qt version, did you perhaps mean y-axis? :)
> 
> From my original mail: 
> 
> How the benchmark works is that the it tries to figure out how many 
> operations of a given type is possible each frame (not per second) while 
> sustaining a perfect 60 fps (or whatever other fps you target). For these 
> numbers, we’re looking at delegation creation and destruction. You can look 
> at the content of each specific benchmark here: 
> https://github.com/sletta/stuff/tree/master/qml/benchmarks/benchmark/creation.
>  
> 
> 
>> IMO QuickItemText is too complicated for the simple case, which is 
>> "displaying a single line of plain text of about 15 characters", as this is 
>> the most common case in a UI. So having a QuickSimpleText item, which can 
>> only do the simple case should be much faster to create. Not having a 
>> QTextDocument and all that many members for all this many features. Of 
>> course even with most of this feratures it was faster in 5.1, but still 
>> could be a lot more , i think for the simple case.
> 
> It still needs to do shaping and all that though, so some involvement with 
> the text engine is required. However, I believe there is huge room for 
> improvement there. There is https://bugreports.qt.io/browse/QTBUG-42853 which 
> covers some ideas around writing a faster implementation.
> 
>>  
>> I am very interested in solving issue as in our environment we are hit by 
>> the degration and our product has to stay at 5.1 for now.
>> So keep on the good work!
>>  
>> Best regards,
>> Gunnar Roth
>>  
>> Gesendet: Donnerstag, 12. Februar 2015 um 11:56 Uhr
>> Von: "Robin Burchell" 
>> An: "Rutledge Shawn" 
>> Cc: "development@qt-project.org" 
>> Betreff: Re: [Development] Item creation time in QML
>> On Wed, Feb 11, 2015 at 2:49 PM, Rutledge Shawn
>>  wrote:
>> >> Being able to do 500+items rectangles in one frame is decent, but not 
>> >> awesome. Being able todo 130 text items in one frame, is less than ideal, 
>> >> given that we often use several text items per cell in a list or table. 
>> >> Text is probably the most important UI element we have. Being able to do 
>> >> 10 buttons is, well, unfortunate :) If we look at Button, we see that it 
>> >> is a fairly complex QML beast. Hierarchy is
>> >>
>> >> Button -> BasicButton -> Control -> FocusScope
>> >>
>> >> and there are quite a bit of stuff on every level, including the dynamic 
>> >> style handling which will in turn create a StyleItem.
>> >>
>> >> And keep in mind that even though this isn’t the most high-end mac, it is 
>> >> sitll a pretty decent computer, Qt is supposed to run on much worse 
>> >> hardware than this.
>> >>
>> >> —
>> >>
>> >> There have been a few changes going into 5.5 which make these numbers 
>> >> better than 5.4, but I still think we got quite a ways to go.
>> >
>> > That’s very interesting.
>> >
>> > Do you think it was ever better in past versions?
>> 
>> I'm glad you asked: http://rburchell.com/QtQuickPerformance.pdf
>> 

Re: [Development] Item creation time in QML

[Gunnar Roth]

Hi,
after downloading it to my cell phone and picking it with usb connection, i was 
finally able to read pdf document.
I am curious what the unit of the x-axis is in your diagrams, i fugure higher 
is better, but what is measured there?
 
IMO QuickItemText is too complicated for the simple case, which is "displaying 
a single line of plain text of about 15 characters", as this is the most common 
case in a UI. So having a QuickSimpleText item, which can only do the simple 
case should be much faster to create. Not having a QTextDocument and all that 
many members for all this many features. Of course even with most of this 
feratures it was faster in 5.1, but still could be a lot more , i think for the 
simple case.
 
I am very interested in solving issue as in our environment we are hit by the 
degration and our product has to stay at 5.1 for now.
So keep on the good work!
 
Best regards,
Gunnar Roth
 
Gesendet: Donnerstag, 12. Februar 2015 um 11:56 Uhr
Von: "Robin Burchell" 
An: "Rutledge Shawn" 
Cc: "development@qt-project.org" 
Betreff: Re: [Development] Item creation time in QML
On Wed, Feb 11, 2015 at 2:49 PM, Rutledge Shawn
 wrote:
>> Being able to do 500+items rectangles in one frame is decent, but not 
>> awesome. Being able todo 130 text items in one frame, is less than ideal, 
>> given that we often use several text items per cell in a list or table. Text 
>> is probably the most important UI element we have. Being able to do 10 
>> buttons is, well, unfortunate :) If we look at Button, we see that it is a 
>> fairly complex QML beast. Hierarchy is
>>
>> Button -> BasicButton -> Control -> FocusScope
>>
>> and there are quite a bit of stuff on every level, including the dynamic 
>> style handling which will in turn create a StyleItem.
>>
>> And keep in mind that even though this isn’t the most high-end mac, it is 
>> sitll a pretty decent computer, Qt is supposed to run on much worse hardware 
>> than this.
>>
>> —
>>
>> There have been a few changes going into 5.5 which make these numbers better 
>> than 5.4, but I still think we got quite a ways to go.
>
> That’s very interesting.
>
> Do you think it was ever better in past versions?

I'm glad you asked: http://rburchell.com/QtQuickPerformance.pdf 
<http://rburchell.com/QtQuickPerformance.pdf>

> What do you think we should do about it? Mainly focus on trying to create 
> fewer objects, or is there still a lot of headroom for making the creation 
> more efficient? Is creation expensive because of constructor code, making too 
> many signal/slot connections, or something else?

I think there's plenty that can be done, because it *used* to be
better. We should aim for matching the performance we used to have at
the very least, ideally, for exceeding that.

I'd say that one very particular case that needs attention is text
performance. It's pretty bad.

As for why, specifically, it's slow, I did some profiling in the past,
but I don't have those results now. I plan to spend some time on that,
maybe on the weekend, and send some more information once that's done.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development 
<http://lists.qt-project.org/mailman/listinfo/development>___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Deprecating modules with 5.5

[Gunnar Roth]

> Am 08.02.2015 um 21:25 schrieb Olivier Goffart :
> 
> On Sunday 08 February 2015 19:15:18 Giuseppe D'Angelo wrote:
>> Il 08/02/2015 17:58, Thiago Macieira ha scritto:
>>> So we come back to this question again and again: if you can't upgrade the
>>> OS and upgrade the compiler, why do you want to upgrade Qt?
>> 
>> Because people want to use the latest features / bugfixes for developing
>> their product, and yet they need to target such platforms...
> 
> If Qt 5.5 is LTS, some bugs fixes could be backported.
> As for the new feature, if they can cope with an old system and compiler, 
> they 
> can also cope with old Qt. Even if that implies re-inventing a few wheels.
> 
> So the question is:
> If we were to drop MSVC2008, about how many companies or developers do you 
> think will choose not to use Qt because of that instead of using it?
> 
> Is there perhaps a lot of paying customer using it who would stop paying 
> licenses?
> 
> When is the end of life of Windows CE?

Hi all,

According to 
http://www.microsoft.com/windowsembedded/en-us/product-lifecycles.aspx
MS does support WEC 7 until April 13, 2021, which is more than 6 six years.
But dropping wec 7 support would mean dropping complete ce support as the 
successor wec2013 is not supported by qt and qt 5.x needs quite some patches to 
build ( and building things like quick controls need some hacky patches, as it 
depends on accessibility.)

Wec2013  is using a prerelease forked version of 17.00 Compiler (as used in vs 
2012)  compile OS and applications.
The support runs till October 10, 2023.
MS is actually fixing bugs in this compiler (which is delivered with wec 2013)  
and has done so on our request ( i remember some optimisation internal compiler 
error when building qtwebkit from qt 4.8.5)
 
We are using qt 4.8.x on ce 6 and wec 2013 and we use qt 5.4 on wec2013. We 
skipped wec 7 so being able to use newer c++ compiler features  but in 
hindsight it was a pain, so i understand that many people stick with wec 7.


Regards,
Gunnar

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt 5.4 breaks binary compatibility on windows for builds using vs2010 and above

[Gunnar Roth]

Hi,

ms compiler uses access property of class methods for building the mangled name, so you should not change this between versions.

 

In Qt\5.4.0\qt-src\qtbase\src\corelib\kernel\qmetatype.h:643

you find   this code

#ifndef Q_NO_TEMPLATE_FRIENDS
#ifndef Q_QDOC
    template
    friend bool qRegisterSequentialConverter();
    template friend struct QtPrivate::ValueTypeIsMetaType;
    template friend struct QtPrivate::ConverterMemberFunction;
    template friend struct QtPrivate::ConverterMemberFunctionOk;
    template friend struct QtPrivate::ConverterFunctor;
    template
    friend bool qRegisterAssociativeConverter();
    template friend struct QtPrivate::AssociativeValueTypeIsMetaType;
    template friend struct QtPrivate::IsMetaTypePair;
    template friend struct QtPrivate::MetaTypeSmartPointerHelper;
#endif
#else
public:
#endif
    static bool registerConverterFunction(const QtPrivate::AbstractConverterFunction *f, int from, int to);
    static void unregisterConverterFunction(int from, int to);

 

you can see public access  depends on Q_NO_TEMPLATE_FRIENDS being defined.

 

if you look at Qt\5.3.2\qt-src\qtbase\src\corelib\global\qcompilerdetection.h:88

you see 

#elif defined(_MSC_VER)
#  define Q_CC_MSVC
#  define Q_CC_MSVC_NET
#  define Q_OUTOFLINE_TEMPLATE inline
#  define Q_NO_TEMPLATE_FRIENDS

 

so Q_NO_TEMPLATE_FRIENDS is defined for every ms compiler.

 

in Qt\5.4.0\qt-src\qtbase\src\corelib\global\qcompilerdetection.h:80

you can see a change:

#elif defined(_MSC_VER)
#  define Q_CC_MSVC (_MSC_VER)
#  define Q_CC_MSVC_NET
#  define Q_OUTOFLINE_TEMPLATE inline
#  if _MSC_VER < 1600
#    define Q_NO_TEMPLATE_FRIENDS
#  endif

 

so in 5.4 registerConverterFunction and unregisterConverterFunction arenow private when build with vs 2010 and above.

 

I have noticed that problem today with an own application ( build with qt before 5.4)  where i get 

The procedure entry point ?unregisterConverterFunction@QMetaType@@SAXHH@Z could not be located in the dynamic link library Qt5Core.dll. 

when looking with depends.exe into the dll i cann only find a ?unregisterConverterFunction@QMetaType@@CAXHH@Z ( note the S/C differnce).

 

making public etc. depend on a define is imho a very bad idea and now we have the result broken binary compatibility, something which i think is taken a lot care of to NOT happen in Qt.

 

 

Regards,

Gunnar

 

 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development