Den ons 21 aug. 2019 kl 21:36 skrev Henry Skoglund <he...@tungware.se>: > > Yes, I also used app-local deployment, problem is that Microsoft has not > committed 100% to allow it (as far as I know), instead they have a > seesaw approach, saying "you can temporarily use app-local deployment but.." > > Anyway, my ultimate goal is to create and distribute my Qt apps the same > way as Qt's installation program (you can tell I really admire that > program a lot :-) > i.e. link *everything* statically and build myself a ~ 20 MB humongous > .exe file (which only needs msvcrt.dll). And that kind of linking, > Microsoft has never supported nor allowed it.
Alright, yes, your argument (and Kyle's) make sense I guess. I was mostly speaking from a practicality perspective (that deployment is really not that awkward with the right tools). I know that Microsoft once said it would no longer support app-local deployment of the Universal CRT, but then changed their mind back in 2015 (see the bullet point 6 in the list at https://devblogs.microsoft.com/cppblog/introducing-the-universal-crt/). I don't know if they've changed their mind again, which I think would be required to really call it a seesaw approach :) But yea, I too prefer the simplicity of an MIT licensed compiler to Microsofts agreement. Elvis > > > On 2019-08-21 21:22, Elvis Stansvik wrote: > > Den ons 21 aug. 2019 kl 20:52 skrev Henry Skoglund <he...@tungware.se>: > >> Please, don't drop MinGW, it's in my meaning the best compiler on Windows. > >> > >> I've switched from VS to MinGW, the #1 reason: I can distribute an .exe > >> file which is runnable directly on the user's desktop (no installation). > >> This is *verboten* when using VS, you have to send along the > >> distribution dlls (ucrtbase.dll etc.) and install them. > > Why not just ship those DLLs? I wouldn't call that "verboten" > > (forbidden), just a bit more to do for deployment. > > > > We do app-local deployment (putting the DLLs next to our application), > > which is still supported, and makes it possible for us to deliver a > > portable ZIP in addition to an installer. You don't have to go the > > route of launching the redistributables installer. > > > > To make it less inconvenient we use CMake's > > InstallRequiredSystemLibraries module along with setting > > CMAKE_INSTALL_UCRT_LIBRARIES to make sure the Universal CRT DLLs are > > also bundled. > > > > Elvis > > > >> Also, big wheels like Qt's installer program (MaintenanceTool.exe) have > >> also switched from using Visual Studio to MinGW. I believe for the same > >> reason as mine above, except MaintenanceTool.exe didn't include any VS > >> .dlls, so on early Windows 10 versions, MaintenanceTool.exe failed to > >> start, because no VS2015 runtime was installed. > >> > >> Nowadays MaintenanceTool.exe only requires the 32-bit MSVCRT.DLL to be > >> present, and tbat .dll always gonna be there (just like the VB6 runtime > >> etc.) > >> > >> This is one of the few places where Windows still shines: Qt's OOBE on > >> Windows. On that platform, you don't need any chmod +x or waiting for a > >> .dmg to unpack, just double-click on the .exe file. > >> > >> Rgrds Henry > >> > >> > >> > >> On 2019-08-21 20:35, Mathias Hasselmann wrote: > >>> Am 21.08.2019 um 19:38 schrieb Thiago Macieira: > >>>> PPS: can we drop MinGW support in Qt 6? > >>> What alternative do you propse? > >>> _______________________________________________ > >>> Development mailing list > >>> Development@qt-project.org > >>> https://lists.qt-project.org/listinfo/development > >> _______________________________________________ > >> Development mailing list > >> Development@qt-project.org > >> https://lists.qt-project.org/listinfo/development > _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
