[Development] wince and openssl
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] wince and openssl
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.
--
Andrew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please help me get my pending review count down
On Wednesday 29 July 2015 10:12:31 Marc Mutz wrote: On Tuesday 28 July 2015 23:51:49 Thiago Macieira wrote: - QVersion number changes: https://codereview.qt-project.org/95533 https://codereview.qt-project.org/96073 If you want QVN to be in 5.6, please lift your -2 on https://codereview.qt-project.org/97085 The -2 which is only there because the patch was too late for 5.4. Done -- 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
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) GmbHCo KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] wince and openssl
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
Re: [Development] wince and openssl
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 thiago.macie...@intel.com: 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] QtQuick TestCase with other top windows
Hi everyone this is my first post on the mailing list so please bear with me. Currently i'm trying to create some tests for the qtquick menuba. For achieving this i need to create an ApplicationWindow and sending events to it. Currently the TestCase qml component sends all the events to the Test window. This obviously doesn't fit my use case. I investigated a little how to fix that: 1) Add a battery of overloads for the mouseClick and keyPress functions that take a QWindow* parameter. Pros: the current tests are not effected by the change and it's a more general approach (useful in some particular cases like mine). Cons: a new set of functions. In particular from the qml side we will have the pairs [keyPress, keyPressInWindow], [mouseClick, mouseClickInWindow] etc. 2) Make the TestCase send the events to the window where a particular item belongs. However this works with the functions that take a QQuickItem as a parameter (like mouseClick(item, x, y, ...) but not for keyPress(...) since it doesn't have a QQuickItem argument. The idea is to forward the key events to the currently active window (so the one that has the keyboard focus). Pros: no API bloat Cons: i implemented it and a lot of test cases broke. Basically most of them rely to the current TestCase behaviour to send events to the testcase window. This change broke some test where we have popups, like in the ComboBox tests. 3) Make a standalone C++ app for making such tests without touching the TestCase code. Pros: Current tests are not effected. Cons: Some code duplication. Furthermore, currently, most of classes inside the QtQuickControls plugin aren't exported so even if my app is linked to it i cannot use them. To be honest, i basically tried all the previous 3 options and if i'm the one to choose i would go with the option (1) since i don't want to break everyone's code. -- Filippo Cucchetto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] CI links to build results broken
On Wednesday 29 of July 2015 10:31:01 Marc Mutz wrote: Hi, Example: https://codereview.qt-project.org/95533 Output link posted there: http://testresults.qt.io/logs/qt/qtbase/98ca8036c6d5b37be676503e463c49e8dcc9 c5de/windows8x86_64winrt8x86_64msvc2013developer- build_release_disable-tests/da39a3ee5e6b4b0d3255bfef95601890afd80709/buildl og.txt.gz But that gives a 404. Can someone please have a look? Thanks, Marc Hi, Probably CI was restarted during logs upload time, and the log was not uploaded. It is a known, but not that common bug, which will be fixed soonish. Cheers, Jędrek ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] CI links to build results broken
Hi, Example: https://codereview.qt-project.org/95533 Output link posted there: http://testresults.qt.io/logs/qt/qtbase/98ca8036c6d5b37be676503e463c49e8dcc9c5de/windows8x86_64winrt8x86_64msvc2013developer- build_release_disable-tests/da39a3ee5e6b4b0d3255bfef95601890afd80709/buildlog.txt.gz But that gives a 404. Can someone please have a look? Thanks, Marc -- Marc Mutz marc.m...@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
Re: [Development] Please help me get my pending review count down
On Wed, Jul 29, 2015 at 11:47 AM, Marc Mutz marc.m...@kdab.com wrote: On Wednesday 29 July 2015 09:04:42 Martin Klapetek wrote: Can you perhaps create a single diff against 5.5/dev/master which could be easily applied? That should make things much easier to help :) Assuming you're talking about the dbus changes, wouldn't you actually want to cherry-pick them one by one and see which one breaks? Perhaps that should be done as well, yes, although Thiago requested the /whole set of changes/ to be tested: I need someone to take the whole set of changes, apply to their Qt 5.5 build and test KF5-powered applications to see what gets broken and why. Please provide patches to either QtDBus, KF5 or the applications. Which would be much simpler with a single diff. Cheers -- Martin Klapetek | KDE Developer ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please help me get my pending review count down
On Wednesday 29 July 2015 09:04:42 Martin Klapetek wrote: Can you perhaps create a single diff against 5.5/dev/master which could be easily applied? That should make things much easier to help :) Assuming you're talking about the dbus changes, wouldn't you actually want to cherry-pick them one by one and see which one breaks? -- Marc Mutz marc.m...@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
Re: [Development] Please help me get my pending review count down
Can you perhaps create a single diff against 5.5/dev/master which could be easily applied? That should make things much easier to help :) Cheers -- Martin Klapetek | KDE Developer ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5
On Tuesday 28. July 2015 12:24:16 Thiago Macieira wrote: I don't think I am underestimating the annoyance to those people nor that I am overestimating the benefit. You have also take into account that a great majority of source code is written in English and for those cases this feature is a net win. Anyway, I'm waiting for Lars to make a decision. Lars, you can either make your choices below or you may request consensus and then make your decision: I know this is not a vote. But here is my opinion: 1) qDebug for QStrings should a) escape everything non-US-ASCII (5.5.0 behaviour) b) escape everything that isn't QChar::isPrint c) escape only US-ASCII control characters (0 to 31), backslash and quote d) escape only NUL, backslash and quote e) escape nothing (5.0 through 5.4 behaviour) [I haven't included option f) mangle irrevocably (4.x behaviour)] I'd say b. (or c if you think b is too slow, but maybe you can optimize and not call isPrint for ascii) 2) ditto for qDebug for QByteArrays, except that for: b1) escape everything that isn't isprint() from ctype.h (locale dependent) b2) escape everything that isn't printable under Latin 1 Note that QByteArray::toUpper and toLower do not and have never used ctype.h and are instead fixed to Latin 1. For QByteArray I think a. is ok (escape everything non ascii) We don't know if the encoding is utf-8 or latin-1 so we can just escape everything. 3) QtTest should a) follow qDebug and be consistent b) do it differently, in which case we need to select which of the options above QtTest printer do not have to be consistant. But both behaviour would be acceptable as far as I am concerned. 4) when to apply those changes, which are technically behaviour changes a) 5.5.1 b) 5.6.0 5.5.1 for qDebug because it is a regression. Note that the QtTest QString change happened in 5.4.0, so I advise against changing QTest::toString(QString) in 5.5.1, if a change is to happen. I agree. Obviously my preference has already been stated. If we eliminate 1a, my preferences are: 1c and 2a. I do not want QChar::isPrint to be used because it's expensive. Anything except 1e will still change C:\Users to C:\\Users in the output, which was one of the complaints listed. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please help me get my pending review count down
On Tuesday 28 July 2015 23:51:49 Thiago Macieira wrote: - QVersion number changes: https://codereview.qt-project.org/95533 https://codereview.qt-project.org/96073 If you want QVN to be in 5.6, please lift your -2 on https://codereview.qt-project.org/97085 The -2 which is only there because the patch was too late for 5.4. Thanks, Marc -- Marc Mutz marc.m...@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
Re: [Development] Please help me get my pending review count down
On Wednesday, July 29, 2015 11:03:15 AM Martin Klapetek wrote: On Wed, Jul 29, 2015 at 11:47 AM, Marc Mutz marc.m...@kdab.com wrote: On Wednesday 29 July 2015 09:04:42 Martin Klapetek wrote: Can you perhaps create a single diff against 5.5/dev/master which could be easily applied? That should make things much easier to help :) Assuming you're talking about the dbus changes, wouldn't you actually want to cherry-pick them one by one and see which one breaks? Perhaps that should be done as well, yes, although Thiago requested the /whole set of changes/ to be tested: I need someone to take the whole set of changes, apply to their Qt 5.5 build and test KF5-powered applications to see what gets broken and why. Please provide patches to either QtDBus, KF5 or the applications. Which would be much simpler with a single diff. Gerrit gives you a git command to copy'n'paste and you can pull the changeset and test it. That's much better than manually applying some plaintext diff. Bye -- Milian Wolff | milian.wo...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
