[Releasing] Binary packages for Qt 5.4 / Qt WebEngine 1.0

Knight Andrew Andrew.Knight at digia.com
Tue Sep 9 12:51:15 CEST 2014


Hi again,

Tony just informed me that we already do what I described below. So, I stand corrected.

As a side note, CI is migrating to a setup where the vcvars is not even used, but the 
LIBPATH/INCLUDEPATH/PATH are set by the configuration, so this becomes even less relevant
in the future.

Installer packages work a bit differently, but I think it can be done exactly as we do for WinRT,
with the vcvars set manually by the configuration script (producing e.g. 32-bit binaries on a 64-bit OS).

-Andrew

________________________________________
From: releasing-bounces+andrew.knight=digia.com at qt-project.org [releasing-bounces+andrew.knight=digia.com at qt-project.org] on behalf of Knight Andrew [Andrew.Knight at digia.com]
Sent: Tuesday, September 09, 2014 1:24 PM
To: Koehne Kai; Albisser Zeno; releasing at qt-project.org
Subject: Re: [Releasing] Binary packages for Qt 5.4 / Qt WebEngine 1.0

> > -----Original Message-----
> > From: releasing-bounces+kai.koehne=digia.com at qt-project.org
> > [...]
> > So, you are not alone in this requirement. It's a matter of changing the
> > configure scripts to allow building from a non-x64 command prompt within
> > the 64-bit environment. If we made this a hard requirement across the
> > board, we could even drop the win-msvc2013-x86 stage *nodes*, and just
> > make sure the relevant stages are executing with the correct (x86, ARM, X64)
> > vcvars.
>
> Isn't this just a matter of executing
>
> "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat x86_amd64"
>
> instead of
>
> "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat amd64"
>
> In the setup phase? I don't think the Qt configure scripts itself needs any tweaking. Or have you meant exactly this?

That's exactly what I meant (except that you have your first argument wrong -- we don't want to run the x64 cross-compiler, we want to run the x86 native compiler). It's just that the CI scripts make assumptions of which vcvars to use based on which OS is in use, and that we have the seemingly unnecessary 32-bit Windows installations.  We could be building for x86, x64, ARM all from the same machines, and not require separate installations of 32-bit and 64-bit Windows. I understand that they might be there for test coverage reasons, but I have never seen a case where a 32-bit machine caught an error that a 64-bit machine missed. Those types of errors (pointer size, alignment, etc.) are normally caught by the compiler or auto-tests.

> Regards
>
> Kai
>
> > Cheers,
> > Andrew
> >
> ________________________________________
> From: releasing-bounces+andrew.knight=digia.com at qt-project.org
> [releasing-bounces+andrew.knight=digia.com at qt-project.org] on behalf of
> Albisser Zeno [Zeno.Albisser at digia.com]
> Sent: Monday, September 08, 2014 2:56 PM
> To: releasing at qt-project.org
> Subject: [Releasing] Binary packages for Qt 5.4 / Qt WebEngine 1.0
>
> Hi all,
>
> As you might already know, Qt WebEngine for Windows can only be built on
> a 64bit machine. This is a strict requirement imposed by Chromium. However
> Chromium used to build 32bit binaries only for quite a long time, and
> Windows 64bit support has only been added very recently.
> Further requirements on Windows are ANGLE and msvc2013.
>
> Matching this with our packaging infrastructure leaves us with a single build
> to produce packages: win-msvc2013-Windows8.1-x64_ANGLE Assuming that
> the x64 in the name resembles both host and target operating system.
>
> This also means that we will not have 32bit Windows packages that include
> QtWebEngine. And I think this is something we might want to change.
>
> I believe the only change necessary to allow building 32bit Windows packages
> is to change the configuration win-msvc2013-Windows8.1-x86_ANGLE to be
> actually running on a Windows x64 installation. Do you think this change is
> feasible?
>
> Best Regards,
>
> Zeno Albisser
>
> _______________________________________________
> Releasing mailing list
> Releasing at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/releasing
> _______________________________________________
> Releasing mailing list
> Releasing at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/releasing
_______________________________________________
Releasing mailing list
Releasing at qt-project.org
http://lists.qt-project.org/mailman/listinfo/releasing



More information about the Releasing mailing list