Open jimklimov opened 2 years ago
Now build-mingw-nut.sh
has a couple of routines to do a recursive walk to fetch many (open-source third-party) DLLs from mingw build environment. In the end they are dumped to bin
dir (for drivers and tools), with links added later into sbin
dir per needs of system daemons, because run-time DLLs must be near EXE (if not in system paths).
This logic can be extracted to standalone script to use in package (or other bundling) preparation.
Check with comments in:
Loosely related to
One stumbling block with making sense of older recipes was the use of GUIDs in them. Per sources like:
...such component GUIDs effectively encode the full packaged path to installed file (whatever version), to the point that "*"
or "\*"
might be used for WIX to generate one unambiguously. They should not be updated for newer releases of the component files, if they land to the same location. There are also product GUIDs that should differ for each release (each build from separate source revisions?) and can also be generated by an asterisk. So one big headache less here.
There is also a recently revived effort for WixEdit GUI editor to help with the package recipe maintenance:
...and a number of other editors (mostly plugins for Windows-based IDEs) listed at https://robmensching.com/blog/posts/2007/11/20/wix-editors/ (old post, regularly updated)
Also took a quick look at other popular options, e.g.:
Setup.exe
style distributions (MSI made by WIX is allegedly better integrated for corporate automated installations/updates across many systems, which may be fairly important for NUT in a Windows-centric data center).
Did not touch this yet, no idea what we have or how to use it. This state is something to change :)
UPDATE: See also: https://wixtoolset.org/ (used in those recipes)