Re: [Development] Qt 5.9 prebuild binary packages( was: Re: Qt 5.9)

[Andrew Knight]

Hi,


On 12/22/16 09:18, Oliver Wolff wrote:
> Can someone elaborate on how "one package per OS" reduces the testing
> burden significantly? We still have to check every
> platform/configuration that is inside the package. All that changes is
> that the testers install from one big package instead of smaller
> packages. I doubt that one person will check the whole windows package
> (for example). At least I will not volunteer to do that :X

I agree. If your goal is to have fewer people testing, combine the
installers. Then, people who don't have the time/bandwidth/disk space
for several 3.3GB snapshots will simply not test the packages.

As as a *former* Windows user, I may be out of sync with developer
expectations. Even so, I imagine you would be hard-pressed to find many
developers who use all of the ABIs listed in that hypothetical Windows
installer. I guess this will push those users to use the online
installer, which is probably what is desired...

I still have to deal with CI systems which download and install Qt
automatically, and they are especially sensitive to the
download/installation size issue. Until either installer provides a
supported way to script the installation (I've been using [0]), then
bloating the offline installer gets a -1 from me.

>
>
> On 21/12/2016 19:37, Jake Petroules wrote:
>> LET'S DO IT! And thank you for following through on this idea.
>>
>> This will reduce our package testing burden significantly which is
>> very important because it lowers the barrier to entry for us to
>> actually add new platforms/installers. For example, adding tvOS to
>> the combined macOS/iOS/Android package would be valuable.

This one sounds reasonable.

>>
>> I would omit the host architectures (it provides no useful value
>> since there are multiple host architectures in some cases) and target
>> platforms from the filenames, though (like -android, -qnx,
>> -android-ios), because they aren't there for the Windows package so
>> it would be more consistent. The download descriptions should detail
>> what each package contains.

Agreed.

>>
>> Also, can we simply subsume the QNX packages into the base enterprise
>> packages? i.e. combine qt-enterprise-linux-x64-android and
>> qt-enterprise-linux-x64-qnx? Or is there a licensing-related issue
>> around that? And why do we need different packages based on the
>> license, anyways?

I assume the enterprise components haven't been properly "sanitized" so
that they can be disabled for the open-source distribution. Combining
the installers certainly makes the most sense, and was something
promised already at last year's QtWS IIRC.


[0] https://github.com/benlau/qtci/blob/master/bin/extract-qt-installer

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

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Andrew Knight]

On 11/09/16 16:01, Oswald Buddenhagen wrote:
>
> i can offer meta/ as an alternative.

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

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Andrew Knight]

Hi,


On 09/21/16 12:34, Friedemann Kleint wrote:
> Hi,
>
> technically speaking: is using the .rst format set in stone? I find
> this difficult to handle; one needs a local web server to view it
> AFAIK. .md comes to mind as alternative?
>

We discussed this at QtCon and settled on ReStructured Text because it
results in a cleaner plaintext document (i.e. more document-like, less
markup-like) than markdown. It's also the format PIP uses, but note that
it doesn't necessarily matter: each QUIP can declare its MIME type in
the header.

Anyway, I don't think you need a web server to view the formatted RST
result. Docutils has examples on how to convert to HTML using Python:
http://docutils.sourceforge.net/docs/user/tools.html#rst2html-py

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

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Andrew Knight]

On 09/06/16 03:08, Thiago Macieira wrote:

Em segunda-feira, 5 de setembro de 2016, às 12:49:03 PDT, Andrew Knight
escreveu:

** General sentiment:
- As long as Qbs looks like a part of Qt, it is perceived as a Qt
product, and is less attractive to external users.
- Yet, there remains a conflict: "if Qt doesn't use it, I don't want to
use it" vs. "if it's not outside of Qt, I don't want to use it"

Sounds like the way to go for qbs is to decouple it, make it a separate
project, one that doesn't release in lockstep with Qt.


That's already the case. Apart from having a Qt dependency, and being 
somewhat influenced by Qt Creator development, it does not release in 
lockstep with either.




That puts an extra burden in Qbs development: it has to be ahead of Qt's own
development by at least two releases. Building a library should not require a
change in the buildsystem tool: the tool should already support it by the time
we get to that problem. That's unlike qmake, for which we make changes as we
need them in Qt.



That might become a burden if Qbs development starts using new Qt 
features, but that hasn't really been an issue so far. AFAIK Qbs still 
builds against Qt 5.2.


Over the weekend we had a number of discussions about bootstrapping Qbs 
(or even removing the Qt dependency altogether). So, I think this 
requirement is already used in practice and hasn't greatly burdened the 
project. The Qbs developers are interested in it being small, fast, and 
portable more than relying on any recent innovations in Qt.


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

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Andrew Knight]

Hi Steve,


On 09/05/16 15:40, Stephen Kelly wrote:

- (Stephen) "In reality, rewriting Qt's build system in CMake will
actually be a PITA, and will require changes to CMake to make everything
better"


I think something was lost in transit on this point. I don’t think it would be 
a PITA to write a CMake buildsystem for Qt. I recall the above point was in 
reference to ‘compiling host tools and using them in the build while cross 
compiling’. The way CMake makes that possible currently(!) is implemented 
separately to the core of CMake with the ExternalProject module.




You're right; I remember now that this was referring what you describe 
above, not the porting work in general. I actually found another quote 
from you in my notes saying "I'm not sure CMake would require a lot of 
effort for either CMake or Qt itself". Clearly, I need to work on my 
stenography...


Thanks for the clarification!

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

[Development] Notes on "Qt Build Systems" @ QtCon 2016

[Andrew Knight]

We had a vibrant discussion on Qt Build Systems, hosted by Kai.

tl;dr: Lots of discussion on the merits of which build system (CMake, 
Qbs) should replace qmake in building Qt; lots of supporters of CMake 
but no volunteers to do the work, many reasons to use Qbs as well. Some 
related discussions about how this impacts Qt Creator and the Qt 
offering in general.


* Updates from various departments

** qmake
- "Still undead"
- qmake parses c++ now (dependency scanner)
- configure system rewrite drove some qmake changes
-- The changes are "not much" ~1500 lines of code to parse and use 
formal configuration
-- These changes do not imply a commitment to qmake as Qt's permanent 
build system; the real work is done in configure.json and similar JSON 
files and can be ported to another build system
- (Kai) "The message we want to send is: qmake will be deprecated, but 
supported for a long time"


** Qbs
- Continues to be developed, mostly small incremental changes/releases
- Has been used to build Creator for a long time (alongside qmake). 
Support for building Creator with qmake might eventually be dropped.

- A WIP branch in qtbase (wip/qbs) demonstrates that Qbs can build Qt

** CMake
- (Tobias) Cmake is the "worst" system in Qt Creator because CMake 
doesn't give enough feedback to the IDE.
  We need first-class support for CMake in Qt Creator, though, so that 
is irrelevant to the discussion of which
  system we use to build Qt. If we build Qt with Qbs, we have to also 
have support in Creator. In other words,
  the more build systems we support, the more work Creator folks have 
to do to maintain it.



* Quick survey: which build system do you use (raise of hands by ~40 people)
- CMake ~70%
- qmake ~20%
- Qbs ~10%


* What should we use to build Qt in the future (qmake, Qbs, CMake)?

** Pro Qbs:
- (Kai) "We can do better than CMake"
- (Kai) "having our own build system is also about making a more "out of 
the box" experience for our users. Qt is more than a C++ library; we 
need to ship a good-quality build tool"
- (Rich/Stephen) Qbs might be better at doing host tools and 
cross-compiled builds than CMake
- Qbs doesn't have an intermediate step (i.e. makefile generation). 
Makefile generation has disadvantages for incremental builds and 
dependency tracking
-- (Ossi) "acompletely accurate build dependency tracking system with a 
meta build system is very expensive"


** Pro CMake:
- Much larger user base than Qbs, leading to possibly more contributions
-- (Stephen) Most people (in this room) use CMake.
- Qt is not in the business of creating a build tool
- Qbs is still not finished
- CMake is mature and widely used by Qt developers
- Using an external tool tends to benefit both projects better: the 
CMake community benefits from Qt's fixes to CMake, while Qt benefits 
from the CMake community's improvements to CMake.

- (Milian) CMakeis used by e.g. clang and it works for them
- CMake comes with support for hundreds of modules; Qbs only supports Qt 
and pkg-config currently.


** General comments:
- Do we really need to care what "outsiders" think of what we use in Qt?
-- Yes, because it is a statement about what tool is good for Qt 
development.
--- (Someone) "If Qbs is not used by Qt, why should I use it for my 
project? If Qt switches to Qbs, I will switch to it from CMake. With 
CMake, we don't have this problem: a lot of people are using it and it 
is evolving"
-- Yes, because it is a statement about what tool is supported by Qt, 
and we don't want that tool to go away.
--- (Eddy) "CMake will be there even if we lose interest. By using it in 
Qt, we shift the burden to someone else. If qmake's future is uncertain, 
it will make users uncomfortable

--- (David) "Either something changes, or it dies"
-- No, because Qt should support all major build systems anyway
- Does Qbs support dependency tracking like CMake does
-- Answer: Yes
- (Stephen) "In reality, rewriting Qt's build system in CMake will 
actually be a PITA, and will require changes to CMake to make everything 
better"
- (Rich) "Isn't the time better spent improving CMake than build a new 
build system?"

- There is work to do to make Qt generate better CMake files
- (Andreas) "I love that Qbs is declarative. I really love how Qbs can 
bind dependencies and rules on how I generate artifacts"
- (Someone)"The beauty of Qbs is that it is accessible and it is clear 
how the separation between the declarative stops and the imperative begins."
- (Someone) "Qbs doesn't seem very active, and Qt doesn't use it. This 
scares us. CMake is the best tool we have right now, but it isn't perfect."

- (Eddy) Why are we using this ancient tool? (Referring to make)
- (Andreas) "Every big project ends up building their own system. Qbs is 
a possibility to create a new build system. If it stays in the Qt 
Project, less people will use it."


** General sentiment:
- As long as Qbs looks like a part of Qt, it is perceived as a Qt 
product, and is less 

[Development] Proposing Maurice Kalinowski as the Qt for Windows Runtime (winrt) Platform Maintainer

[Andrew Knight]

The Windows Runtime port of Qt covers the platform-specific code in Qt, 
most of it in the "winrt" platform plugin, which enables Qt to run as 
Windows 8/10 Store Apps, on Windows Phone 8/10, and Windows IoT Core.


As the standing Windows Runtime Platform Maintainer, I hereby step down 
from my post. Over the past year, my contributions to the port have 
wained, and I simply do not have time to keep up with Windows 
development. It would be in the best interest of the Qt Project to 
nominate a new Maintainer.


That said, I would like to propose Maurice Kalinowski as the new Windows 
Runtime Platform Maintainer. He has been active for the entire existence 
of the port, and has been the primary contributor to it for at least the 
past six months. He is continuously staying informed of the state of 
Microsoft's OS technologies, testing Qt on different devices (including 
the HoloLens!), and making the port better in general. In many ways, he 
is the acting maintainer already.



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

[Development] Proposing Oliver Wolff as QtANGLE maintainer

[Andrew Knight]

ANGLE is an important third-party library used in Qt for Windows 
applications, and keeping the dependency up-to-date over the releases is 
an important and challenging task. It involves testing on a sea of 
Windows configurations, creating/maintaining patches for Qt, and 
upstreaming those to the ANGLE project (part of Chromium).


Until recently, I was the acting maintainer of this dependency. Now, 
Oliver Wolff has taken the lead over this part of Qt, upgrading ANGLE 
for Qt 5.7, and continuing to dutifully patch it as bugs are uncovered.


Although this is not an official Qt module or platform, I propose Oliver 
as the new (Qt) ANGLE maintainer. He deserves a badge of honor for 
taking on this often less-than-satisfying, yet crucial, task within the 
Qt Project.



Cheers,

Andrew

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

Re: [Development] Heads up! Fixing the build system on Windows

[Andrew Knight]

I totally applaud the initiative. Should we go a step further, and make
Windows 10 a requirement for building Qt for any platform? The OS ships on
most new PCs, and cross-compilers and sysroots for other platform targets
are pretty much ubiquitous nowadays. I realize there may be a slight
transition period getting all developers over to Windows 10 as their
primary development environment, but surely this won't take long now that
Microsoft has provided all the necessary tools to do so.

On 1 April 2016 at 08:16, Tvete Paul  wrote:

>
> As you may know, Lars is leading an effort to modularize the build
> system. One of the big headaches we have is that Windows uses a completely
> separate configure.exe, leading to a lot of duplicated effort.
>
> With the latest announcement from Microsoft, everything changes. Now that
> bash is natively supported, we will remove the ugly hack, and standardize
> on
> using the configure script for all platforms. The requirement for
> Windows 10 should not be a problem, since the upgrade is free anyway.
>
> We are finalizing the changes now, and aim to go live from 5.6.1. As a
> bonus,
> this should speed up the CI system for everyone, since we no longer have to
> test the obsolete Windows versions.
> ___
> 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

[Andrew Knight]

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

Re: [Development] Stepping down as Windows Embedded Compact port maintainer

[Andrew Knight]

On 10/23/2015 11:45 AM, Björn Breitmeyer wrote:
> Hi everybody,
>
> since I am changing my employer I will step down, from the position as WEC
> platform maintainer and I propose that Andreas Holzammer will succeed me in
> this position.
>
> He has been working with me on WEC issues for a long time and is also a long
> term contributor to Qt.

+1

Note, though, that Andy is not yet an Approver (at least he is not 
listed as one in Gerrit). Should you first nominate him for that?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] ANGLE upgrade plans for 5.6/5.7

[Andrew Knight]

Hi,

On 09/21/2015 02:04 PM, Andreas Holzammer wrote:
> Hi,
>
> Am 21.09.2015 um 12:49 schrieb Knoll Lars:
> 
>> I’d only like to get a confirmation from the WEC maintainers, that they
>> are ok with this plan as well.
> So for WEC angle is not build nor used. As on WEC Direct X would be
> build with OpenGL ES2 and yeah angle then would do it the other way
> around, so OpenGL ES2 is used in the first place. But what we do use is
> the Windows OpenGL ES2 interface which was made for Angle, so that part
> we need, but certainly not the library Angle.

Yes, the EGL interaction in the Windows QPA plugin is independent of the 
ANGLE DLLs.

So, I think this is settled - no need to support ANGLE in VS2012 builds.

>
> Thank you
>
> Andy
>
>
>
>> Cheers,
>> Lars
>>
>> On 21/09/15 11:50, "Andrew Knight" <andrew.kni...@intopalo.com> wrote:
>>
>>> Hello,
>>>
>>> tl;dr: I propose that the copy of ANGLE currently in the 5.6 branch of
>>> qtbase be maintained without being upgraded for the next minor release
>>> of Qt (5.6). For Qt 5.7 and beyond, we should upgrade ANGLE from
>>> upstream while dropping support for VS2010 and VS2012.
>>>
>>> Around each minor Qt release someone (usually me) updates the
>>> third-party ANGLE sources in qtbase. The last time this happened was for
>>> Qt 5.5, imported from Chromium branch 2356, dated 01 April 2015.
>>>
>>> Since then (and including a good chunk of code up to that commit), the
>>> Chromium project has adopted C++11 and C99 usage in its codebase (due to
>>> switching to VS2013 as the minimum Microsoft compiler). That means a
>>> great deal of code no longer builds with older VS versions, and we
>>> already patched ANGLE for VS2010/VS2012 in Qt 5.5 to deal with some of
>>> these issues. Due to the invasiveness and backward thinking of such
>>> patches, they will not be accepted upstream.
>>>
>>> Since then, the amount of such required changes to upstream ANGLE has
>>> exploded; the upkeep required here is truly non-trivial. Therefore, I
>>> now propose that we *do not* upgrade ANGLE for 5.6. Post-5.6, we will no
>>> longer apply patches to support older compilers. The version in Qt 5.6
>>> will be maintained as any other third-party library in Qt (receiving
>>> patches as needed), while Qt 5.7 will only support VS2013 and newer (as
>>> well as recent versions of MinGW, but that is tangential to this
>>> discussion).
>>>
>>> As Qt 5.7 will already drop support for VS2010, I believe the only
>>> supported compiler this affects is VS2012. This compiler is supported
>>> for Windows Embedded purposes, a platform which does not use ANGLE
>>> anyway (see opengl.prf for details; a WinCE SDK normally provides its
>>> own GL stack). For keeping VS2012 Desktop binaries building, we will
>>> need to forcefully disable ANGLE for that compiler. I think this is a
>>> fair trade-off, and one which has already has a precedent set by Qt
>>> WebEngine.
>>>
>>> Now is the time to speak up (I'm looking at you, Windows and WinCE
>>> maintainers) if there is something wrong with the above proposal. Of
>>> course, inaction will probably lead to the same result: ANGLE will not
>>> be upgraded for 5.6, and we can revisit the issue nearer to the 5.7
>>> release when it's time to upgrade again.
>>>
>>> That said, any ANGLE-specific bugs can be assigned to me and I will do
>>> my best to fix them or back-port the relevant changes from upstream as
>>> needed.
>>>
>>> Cheers,
>>> 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
>>
>
>
>
> ___
> 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] ANGLE upgrade plans for 5.6/5.7

[Andrew Knight]

Hello,

tl;dr: I propose that the copy of ANGLE currently in the 5.6 branch of 
qtbase be maintained without being upgraded for the next minor release 
of Qt (5.6). For Qt 5.7 and beyond, we should upgrade ANGLE from 
upstream while dropping support for VS2010 and VS2012.

Around each minor Qt release someone (usually me) updates the 
third-party ANGLE sources in qtbase. The last time this happened was for 
Qt 5.5, imported from Chromium branch 2356, dated 01 April 2015.

Since then (and including a good chunk of code up to that commit), the 
Chromium project has adopted C++11 and C99 usage in its codebase (due to 
switching to VS2013 as the minimum Microsoft compiler). That means a 
great deal of code no longer builds with older VS versions, and we 
already patched ANGLE for VS2010/VS2012 in Qt 5.5 to deal with some of 
these issues. Due to the invasiveness and backward thinking of such 
patches, they will not be accepted upstream.

Since then, the amount of such required changes to upstream ANGLE has 
exploded; the upkeep required here is truly non-trivial. Therefore, I 
now propose that we *do not* upgrade ANGLE for 5.6. Post-5.6, we will no 
longer apply patches to support older compilers. The version in Qt 5.6 
will be maintained as any other third-party library in Qt (receiving 
patches as needed), while Qt 5.7 will only support VS2013 and newer (as 
well as recent versions of MinGW, but that is tangential to this 
discussion).

As Qt 5.7 will already drop support for VS2010, I believe the only 
supported compiler this affects is VS2012. This compiler is supported 
for Windows Embedded purposes, a platform which does not use ANGLE 
anyway (see opengl.prf for details; a WinCE SDK normally provides its 
own GL stack). For keeping VS2012 Desktop binaries building, we will 
need to forcefully disable ANGLE for that compiler. I think this is a 
fair trade-off, and one which has already has a precedent set by Qt 
WebEngine.

Now is the time to speak up (I'm looking at you, Windows and WinCE 
maintainers) if there is something wrong with the above proposal. Of 
course, inaction will probably lead to the same result: ANGLE will not 
be upgraded for 5.6, and we can revisit the issue nearer to the 5.7 
release when it's time to upgrade again.

That said, any ANGLE-specific bugs can be assigned to me and I will do 
my best to fix them or back-port the relevant changes from upstream as 
needed.

Cheers,
Andrew
___
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

[Andrew Knight]

On 07/31/2015 07:40 PM, 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.

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

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.

That said, I imagine Alex was simply trying to save CI from the trouble 
of trying to build this module on an unsupported platform (WEC7) that 
will indeed be dropped from the Qt dev CI after 5.6 has been branched. 
That has nothing to do with the fact that the module would make perfect 
sense for Windows Embedded (given its presence in the automotive 
industry), it just means that no one is actively trying to support 
building it there (in this case, WEC2013). Maybe the guys from KDAB (or 
you, Gunnar) will step up to add support for this module on that platform.

Perhaps one of the QtSerialBus developers can shed some more light on 
this decision.

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

Re: [Development] wince and openssl

[Andrew Knight]

On 07/30/2015 12:16 AM, Gunnar Roth wrote:
 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.

Give this a shot: https://codereview.qt-project.org/122437

I don't know about the SIMD autodetection, but it's probably a similar 
case of removing some old lines in configure.



 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 mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] wince and openssl

[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.

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

Re: [Development] Contribute to the Qt

[Andrew Knight]

Hi Edi,

On 07/24/2015 06:11 AM, Edi Anderson wrote:
 Hello guys I'm a programmer and would like to gain more experience in large
 projects, so I would contribute to Qt.

That's wonderful; welcome to the Qt Project!

   I have time available and just need
 someone to tell me what to do and how to start. Can someone help me ?.

I can try. You should first read http://wiki.qt.io/Contribute and 
http://www.qt.io/contribute/

To get the most out of your experience, join #qt-labs on IRC and pitch 
in to the discussion. Once you have some code to contribute, push it to 
code review (http://wiki.qt.io/Gerrit_Introduction) and start adding 
reviewers. Git log/blame to find out who to add as a reviewer, or 
otherwise ask in IRC about who might be able to help.

We look forward to your code :-)

   And
 sorry for bad English, I began to study English in three months.

No need to apologize. Perfect English is the exception to the rule 
around these parts ;-)

Cheers,
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