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? Cheers, Hannah On 23/05/2017 20:43, Thomas Friedrichsmeier wrote: > On Sun, 21 May 2017 21:14:53 +0200 > Thomas Friedrichsmeier <thomas.friedrichsme...@ruhr-uni-bochum.de> > wrote: >> Hannah von Reth <vonr...@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
Description: OpenPGP digital signature
