NSIS PATH too long, how to use EnVar plugin?

I’ve built a Windows installer using NSIS, cross compiling from Linux using MinGW and the Linux nsis package (Ubuntu 19.10). This works great, but if the user’s PATH exceeds 1024 characters the application cannot be added to PATH due to a limitation of NSIS.

On https://nsis.sourceforge.io/Path_Manipulation it is advised to use the EnVar plugin as a work around. I guess this implies modifying NSIS.template.in, Function AddToPath? If so, I have some questions:

  • Should this not be added to CMake/CPack?
  • If not, how to best proceed? Copy this file to my project and edit it? That seems rather fragile when updating to new versions of CMake, no?
  • Anyone who done this (or has another work-around)?

Thanks — Jan

Is there an upstream for the plugin or is it really just a tarball dump on a wiki? If we do ship it, I don’t know that we want to end up de facto maintaining it forever; I don’t think there are many NSIS experts just hanging around the CMake community (though I’m willing to be wrong). A link from the docs to the wiki page you have there may be better.

Other Windows package generators may behave better here too (WiX and QtIFW come to mind) if those are suitable replacements.

After a little search I found this GitHub - GsNSIS/EnVar: EnVar plugin for NSIS

I have no opinion on which package generator to use especially as CMake/CPack hides most of the details. My only requirement is that I can use it in a cross-compilation setting (from Linux). I used NSIS before migrating to CPack, so this was the obvious first choice.

Is there an overview of CPack supported package generators for Windows, preferably with some indication of features and stability?

This looks promising (especially now that they’ve restored the original license). However, I recommend investigating another packager if that is suitable rather than this as a preferable path.

I don’t know of one, sorry. @craig.scott? CMake itself is using an MSI generator for its Windows installers these days. QtIFW it seems if I’m not mistaken. So that one is at least that stable. It might work in cross-compilation too, but that needs some research.

I wrote up this summary a while back, but it doesn’t consider the cross-compilation case. I’m not sure what would work well for that scenario, I haven’t really explored cross-compile packaging in any great depth.

1 Like

Thanks. I think I should have a look at WIX. Anyone knows whether it can be used with cross compilation using MinGW and possibly using Wine to run native WIX executables?