Runtime packaging

Hannah von Reth vonreth at kde.org
Tue May 23 22:00:26 UTC 2017


I hope its working :P

https://cgit.kde.org/craft.git/commit/?id=8e1cfcf995b325e119904990e5dd13c78b93e605

https://cgit.kde.org/craft.git/commit/?id=da91c6cb5b1708c6aeb5545d06d753d63f30a045


On 23/05/2017 22:09, Thomas Friedrichsmeier wrote:
> Hi,
>
> On Tue, 23 May 2017 21:34:06 +0200
> Hannah von Reth <vonreth at kde.org> wrote:
>> Well, yes it is a bit messy.
>>
>> This difference is that with msvc, when you have installed the
>> compiler the runtime is already installed.
>>
>> Providing the redist is also a bit cleaner than grapping dlls from
>> somewhere in the system.
>>
>> Additionally you need runtime on mingw to be able to run crafted
>> applications outside of the craft env.
>>
>> I guess one solution would be to drop the msvc code in runtime.py and
>> make virtual/base depend on runtime so that is always installed?
> Sounds reasonable (and easy!). Just to mention one downside:
> Installation of the vcredist.exe is still specific to the NSIS
> packager, so far. Any other present or future packager would still
> require custom code for including the VC runtime. Not sure how
> important that is to you. (Personally, I'm perfectly fine with one
> functional installer type, whichever it may be.)
>
> Regards
> Thomas
>
>>
>> Cheers,
>>
>> Hannah
>>
>>
>> On 23/05/2017 20:43, Thomas Friedrichsmeier wrote:
>>> On Sun, 21 May 2017 21:14:53 +0200
>>> Thomas Friedrichsmeier <thomas.friedrichsmeier at ruhr-uni-bochum.de>
>>> wrote:  
>>>> Hannah von Reth <vonreth at kde.org> wrote:  
>>>>> Regarding the runtime, pls add a dependency to lib/runtime to
>>>>> rkward, it would be probably reasonable to only set the dep if the
>>>>> compiler is mingw, as we have a different solution with NSIS to
>>>>> provide the runtime with msvc.    
>>>> Ok, thanks for the hint about the lib/runtime dependency. Solves
>>>> the first issue, well. (Although I'll try to remember to look into
>>>> providing a patch for NullsoftInstallerPackager.py; seems odd that
>>>> I would have to specify extra dependencies just for packaging).  
>>> Hm. Now I found out that I already did, once:
>>> https://cgit.kde.org/craft.git/commit/bin/Packager/NullsoftInstallerPackager.py?h=2017.05&id=e1e82b5d3a75d27635c474f76d38090be069939e
>>>
>>> But you removed it, some time later:
>>> https://cgit.kde.org/craft.git/commit/bin/Packager/NullsoftInstallerPackager.py?h=2017.05&id=8e0ee6b658912f34aa80f45fb65d3fd4cd5399a6
>>>
>>> Well, ok, I can see that libs/runtime handles this much cleaner,
>>> but at the same time, having to add such a basic dependency,
>>> explicitly, _and_ only for packaging (meaning, I'll look in all the
>>> wrong places, first), _and_ in a compiler-specific way, just seems
>>> really messy.
>>>
>>> I think:
>>> a) Since the problem is relevant for packaging, only, it should be
>>> handled by the Packager.
>>> CollectionPackagerBase::internalCreatePackage() (or one of its
>>> helpers), would seem a good place where the runtime could be
>>> injected). This could in fact be done by pulling in libs/runtime.
>>> b) I really don't understand why this should be handled in a
>>> compiler-specific way, and I suspect the only reason for this is
>>> historic. libs/runtime does appear to cover the VC-redistributable
>>> files. However, NullsoftInstallerPackager still adds considerable
>>> code in order to detect the correct version of vcredist.exe, pass
>>> it to NSIS, and unpack it, from inside the installer.
>>>
>>> So - is there any particular reason to prefer the current way of
>>> packaging the VC-runtime? Otherwise I'd look into providing patch to
>>> include libs/runtime at packaging time, automatically, for both
>>> compilers.
>>>
>>> Regards
>>> Thomas  
>>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kde-windows/attachments/20170524/08a73555/attachment.sig>


More information about the Kde-windows mailing list