Package & link dlls as part of `fyne package` (Windows)

[sandalwoodbox]

I'm working on a fyne GUI for interacting with OpenCV, and ran into issues at distribution time because the binary isn't statically linked to OpenCV and the necessary dlls aren't present on the users' windows machines. #109 covers the same issue for MacOS.

Based on some quick internet searching, it sounds like the easiest solution is to bundle the exe in a directory with all the dlls you need.

I think this should be possible for me to do manually in my GitHub workflow, but it would be even nicer if fyne did it automatically as part of fyne package.

[andydotxyz]

The result of a Fyne build on Windows is a .exe file - so budling libraries would require a whole other packaging format - and probably an installer as well.

Personally I am pushing to avoid the need for installers - Go is great for relocatable apps and following the macOS/Android idea that apps are installed just by coping them over is the preferred approach.

[sandalwoodbox]

I'm not sure about android, but on MacOS the .app is actually a folder that can contain dylibs (the MacOS equivalent of dlls) and this seems to be the way to distribute apps that rely on dynamically linked libraries that aren't present on the user's computer.

As far as I can tell, doing something similar with fyne would similarly mean copying the dlls into the same directory as the executable (so that they're picked up automatically.) I don't think an installer is necessary.

That said, I do think being able to ship a single thing that the OS recognizes as a file is preferable in general! I'm currently exploring static-linking my project to get around this problem.

The big issue with the current mechanism is that fyne packages something that looks right but actually fails to run for users (because it relies on dlls that aren't present on their system.) If there were some way to flag that & fail instead of appearing to succeed, that would also be preferable IMO. (Recognizing this may not be feasible.)

[andydotxyz]

I'm not sure about android, but on MacOS the .app is actually a folder that can contain dylibs (the MacOS equivalent of dlls) and this seems to be the way to distribute apps that rely on dynamically linked libraries that aren't present on the user's computer.

Yes I am aware - macOS apps are special folders and can be distributed as .zip and Safari will automatically expand them on download. My point was not that it wasn't possible with macOS - we were talking about Windows.
On the Microsoft OS the way to bundle additional files is with an installer, which we don't build for reasons outlined above.

If there were some way to flag that & fail instead of appearing to succeed, that would also be preferable IMO. (Recognizing this may not be feasible.)

I'm not super familiar but I would imagine there is indeed some C flag you can pass that states no external libraries should be linked. It's not something I think Fyne builds should enforce as if a developer pulls in a library in their code won't they manage the dependency?

Any dependency that Fyne requires is linked statically or bundled in a way to be completely transparent so this is not a problem.

[dweymouth]

@sandalwoodbox If you want to create a Windows installer for your app I recommend looking into Inno Setup. It is scriptable and can even run in a Github Actions workflow. I use it in my project and you can see my script here which includes bundling 2 DLLs into the installer.

I also distribute my app for Windows as a .zip which contains the EXE from fyne package, as well as the 2 DLLs.