NUT for Windows build is huge and sparse

[jimklimov]

According to recent CI runs, the tarball for consumers is nearing 3GB in size (but compresses down to 100Mb over 10 minutes of 1-hour time slot on Appveyor):

Sun, Feb  9, 2025  1:26:51 PM
cd .inst
7z a ../NUT-for-Windows-x86_64-SNAPSHOT-%APPVEYOR_BUILD_VERSION%.7z NUT*
7-Zip 24.08 (x64) : Copyright (c) 1999-2024 Igor Pavlov : 2024-08-11
Scanning the drive:
34 folders, 482 files, 2840422626 bytes (2709 MiB)
Creating archive: ../NUT-for-Windows-x86_64-SNAPSHOT-2.8.2.2734-master.7z
Add new data to archive: 34 folders, 482 files, 2840422626 bytes (2709 MiB)
Files read from disk: 482
Archive size: 107839478 bytes (103 MiB)
Everything is Ok
Sun, Feb  9, 2025  1:35:42 PM

This is too much by whatever metric we can imagine (one sixth of the CI run time, huge storage footprint for whoever wants to try it out). Part of the problem may be duplication of dependency DLLs, however many NUT driver binaries are in 30-50Mb range each, as if they are all statically linked despite the presence of many shared objects in the loop?

• Check if builds ARE dynamic?
• Check if debug information is present (and can account for such size) in the binaries? Can it be stripped or externalized (PDB files etc.)?
  • Note it could well be there even by design of experimental CI builds, to help debug them as N4W is a recent newcomer to the ecosystem. But at what cost...