I have created a library in order to create Excel files based on nimlibxlsxwriter. You can find it here: xlsxwriter.
I would like to get a self-contained binary in Windows.
I think that the only dependencies are: libxlsxwriter and zlib. The files that I got from msys2 are:
I have those files colocated with my ex01.nim file.
I don't know how to use those *.dll.a files. I tried something like SDL2 static compilation but without success:
nim c --dynlibOverride:libxlsxwriter --passL:"-static -L./ -lxlsxwriter -lz -mwindows -Wl,--no-undefined -Wl,--dynamicbase -Wl,--nxcompat -Wl,--high-entropy-va" ex01
Any idea about the apropriate options?
I would like to get a self-contained binary in Windows.
You can simply ship a self-contained directory in Windows.
Here is my list of "self-contained" binaries I personally use on Windows all the time because nothing else works: []. Yes, it's empty.
Tried adding: --passL:"-I ./libxlsxwriter.dll.a -I libz.dll.a ...... Now ld.exe complains about undefined reference to the functions in the bindings:
C:/Users/me/Documents/instalado/msys2/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\me\nimcache\sar_d\@m..@s..@[email protected]@[email protected]@[email protected]:@m..@s..@[email protected]@[email protected]@[email protected]:(.text+0x16c): undefined reference to `workbook_new'
....
Dunno, seems Go is rather good at it. My self-contained list.filter(it.pl = Go) is [RClone, Hugo, Kopia]
The best (in terms of mileage and long-lasting impression) piece of statically-linked software for me is probably ffmpeg. Works on Windows just fine.
At least it demonstrates it's achievable and the aspiration is justified, so I wouldn't dismiss it right away.
When people tinker with linker options and have so much trouble with it that they post here, it's entirely justified to dismiss it -- and the way Golang does it has no benefits on Windows, the aspiration is not justified.
I mostly agree that self-contained directory is not far from self-contained executable. But imagine a normie trying to figure out why their application broke, when they just moved this little tiny file to another directory for convenience.
Another story is that it is really hard to extract an archive and use it. You extract it, hope that it is inside a directory and not going to be dispersed across your desktop. Then you open this directory and blindly click on every executable file in hope that one of them is going to work. Sometimes there's a readme where you have to go through 5 installation steps (5 more than you are capable of following). That's a matter of how the programmer packages stuff, but there're already enough bad programmers who made bad impression about this kind of installation.
Single file is dumb and simple, you can't deny that people constantly want it, we even have a Memblib wrapper now yay. I also chose a static compilation for gaming library wrapper for this reason.
all the criticism you gave is only relevant is the person packing the archive was trying to inconveniece end user.
I also chose a static compilation for gaming library wrapper for this reason.
this is even less relevant in case of a game since usually you also going to distrubute game assets.
if the person packing the archive was trying to inconveniece end user.
Earlier in my life I tried my best to write software. And my best back then was eternal pain and suffering for the end user.
distrubute game assets.
I think you would also want to pack all the assets into the same file if you are not doing AAA game? I don't know then why people ask to pack SDL bindings. Even for simple desktop applications, not games, you usually still have some assets
And my best back then was eternal pain and suffering for the end user.
For end users you usually create an installer... Or a self extracting zip file, 7z supports it too and is free. Yes, I know Nim itself uses a non-standard solution for this, but for good reasons (the dependency on Mingw is not trivial to handle) and our target audience are programmers.