[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-windows
Subject:    Re: Runtime packaging
From:       Hannah von Reth <vonreth () kde ! org>
Date:       2017-05-23 22:00:26
Message-ID: 839ea318-7390-1341-9df4-03a5c6496678 () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/mixed)]


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@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@ruhr-uni-bochum.de>
> > > wrote:  
> > > > Hannah von Reth <vonreth@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  
> > 


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]