How to build Love2d statically on Windows without dependency (single .exe)?

[desman]

Hi guys, I want to distribute my game as single .exe file (similar to old school flash games).

I've build Love from source (with megasource, VS2013, & DX2010), but it produce love.exe with dependency to (love.dll, Lua51.dll, msvcr120.dll, msvcp120.dll, OpenAL32.dll, SDL2.dll, mpg123.dll).

Is there a way to change Cmake behaviour so it can build Love statically (single exe file) ?

[zorg]

https://love2d.org/forums/viewtopic.php ... executable
https://love2d.org/forums/viewtopic.php ... le#p210123
For reference.

By the way, that's a faulty premise; swf files are like (obfuscated, contrast fla-s with non-obfuscated ones) .love files, not combined executables; you usually have a flash player installation on your computer that actually plays the swf files themselves; kinda like if you had löve installed elsewhere. And i'm willing to bet that that also has dll-s next to it.

[desman]

Flash player less than version 10 can create single exe projector files. And the game deployed with Flash projector file (.exe) doesn't need Flash player to be installed on the computer. I just tested these projector using depends.exe, it only require system files (kernel32.dll, user32.dll, gdi32.dll, etc), so it's actually stand alone program.

I know a indie game developer (Mojiken) from my country that use Construct2 in their game use single exe file (extractor) silently extract all other game files to temporary directories (these includes: NW.js+Chromium+Node+game data) but after the game exit, the single exe file (extractor) silently delete all the game files.
These techniques also used by Perl PAR pp, and maybe Python/Ruby have this stuff too.

So from the user perspectives, they can conveniently copy-paste the single exe file to their friends laptop using flashdisk without knowing the dependency and run it on the fly.

The majority of PC gamers don't even know what's the DLL files. They probably tried to copy only the Game.exe but later they found out it doesn't work (broken dependency/DLL hell).
I even experienced this DLL hell when I tried to build LOVE from source, installing DXSDK 2010 but return error S1023, because it doesn't forward compatible with C redistributable runtime version > 30319.

[zorg]

Okay, i'll agree with you on the "projector" flash programs, i did forget that those exist.

I'm not going to go into my personal thoughts about people's IT-related education, so let me give you a question that's specific to visibility instead: Which do you think a user would prefer more? Seeing that a game they extracted from a zip has dll files next to the executable, or them receiving one executable that potentially barfs those dll-s into temp directories that the extractor may or may not have access to, them may or may not know about, and may or may not be actually removed when the program exits? (Especially in the case if it abnormally aborts execution)

IMO people like memory hogging growing temp folders less than a few files next to an executable, optionally with a read.me or whatever explaining what those are, if one cares to do that, i mean.

As for portability, the fact that you are not using an installer is already miles in the right direction; zipping stuff up and/or putting the -containing folder- onto a flash drive would work just as nicely; i really hope people have at least that much common sense that they actually use directories on pendrives, and not just dump random .exe files into the root of it...

Also, consider the fact that löve projects write into a specific save directory you can't normally change to too many other places; unless the user knows about that, or you open the folder for them programmatically, chances are they wouldn't ever find it either; appdata folders are hidden by default, last i checked, and windows doesn't have the best of file browers; and i'm not expecting people like you mentioned to even care to install total commander or a similar file manager.

All i'm saying is that your löve project won't ever be truly portable, and you can blame that partially to the fact that giving write access to apps so that they could write into their own folders, wherever you put a "portable" program, is probably not going to work, unless you know what you're doing and are actively working against the OS, or its creators' intent.

tl;dr i highlighted the less-rant-y parts.

[desman]

Many games are targeted for kids. Most of them don't even know what's the difference between exe & dll. Some of them may try to click the dll.

Because in reality many people (including most of the adults) don't even know how to (install/uninstall/extract from zip file/run the exe) a regular Win32 program. Most of my non-tech friends always repeatedly asked me how to install photoshop/office/etc. I tried to teach how to install the program to them, but they always ask me again when they buy another laptop.

Even two of my friends with master degree doesn't even know how to extract files from zip file.

This is why exacly why iOS, Android, Win10 UWP has centralized App store to simplify the installation process and also has very simple uninstallation process. Software is created to make people life easier, not harder.

[zorg]

Before anything, please know that i myself enjoy this, hopefully friendly, banter; but it's ultimately irrelevant to the topic, and i'm not trying to convince you of anything, just sharing my experiences.

Many games are targeted for kids. Most of them don't even know what's the difference between exe & dll. Some of them may try to click the dll.

Well then it won't work, will it? Maybe they will give up and move on, or maybe they'll bruteforce it until they make the connection that the .exe files are the executables... or they'll learn to ask for help. Lacking knowledge is not a good reason for modifying anything, and learning these technical things is helpful, especially since they're things they will use later in life. (just so i can avoid the "but they'll never use it in the real world, like algebra" argument )

Because in reality many people (including most of the adults) don't even know how to (install/uninstall/extract from zip file/run the exe) a regular Win32 program. Most of my non-tech friends always repeatedly asked me how to install photoshop/office/etc. I tried to teach how to install the program to them, but they always ask me again when they buy another laptop.

They also probably don't know why their programs won't run after they copy the lnk files from their desktop to their pendrives and try to execute them on other computers, and so on and so on. I agree that not everyone is tech savvy, and some may never learn, but still, that one's kinda on you for enabling them to go for the path of least resistance and so they never learn, just bug you to reinstall everything always. I know you said you tried to teach them, but saying yes to doing it after is the part you shouldn't do.

Even two of my friends with master degree doesn't even know how to extract files from zip file.

People having a degree isn't completely correlated with tech savvyness, you know; not even if they have a masters in an IT related field.

This is why exacly why iOS, Android, Win10 UWP has centralized App store to simplify the installation process and also has very simple uninstallation process. Software is created to make people life easier, not harder.

Easiness is subjective, you know.
For me, it would be infinitely easier if windows didn't have stuff like 50 different versions of shared visual c++ redistributable dlls in every folder where a program requires it, if programs would not have installers that i need to keep around with the actual installed files as well, since that's extra space it's taking up (i do prefer my unzippable portable stuff; ones prepackaged with an executables aren't my favourite either), not to mention all the "hidden" stuff installers do like registry entries, temp files that may linger on, start menu folders, etc...
And it would also be easier if the system wouldn't try to stop me from deleting stuff i know nothing needs; needed to give myself permission to edit my whole C drive and everything on it, seriously...
Same deal with write access for programs; let me decide where i want to have stuff, they only get one folder, they should use only that folder. For me, this would be the simplest.

But yeah, this veered very off-topic, so let's get back to the original question. I suppose you already read the other two threads, so maybe someone else will be able to tell you how to set it up to statically link the dll-s with the executable, as long as your project will be released under an LGPL license, but here's another view of things; kids may also play games on steam on their computers; ever seen those games' directories? almost none of them have just a single exe file in them, either the assets, some middleware, or both, are separate, either in singular "lib" files, or in tons of separate smaller files in folders. I don't think that stops people from playing games.

[desman]

Yes this is off topic, but what Steam doing is exactly same like App Store/Play Store/Windows Store. It simplify the installation, uninstallation, and updates. It's much easier to most people to install/uninstall apps from App Store than to extract & run a game from zip file.

Compared to zip files with many files in it, single exe have advantages because it only have 1 file and it doesn't need to be decompressed manually.

Single exe file is actually has been used for decades as single "Setup.exe", except it ask the user where to install the software permanently and often this trivial task confuse the users.
Mojiken approach is to simplify installation process without asking the user where to install the game. Perhaps Mojiken do this to circumvent the GPL/LGPL restriction as single binary?.. But their approach using self extractor actually doesn't violate GPL/LPGL as it also used by Perl PAR.

or them receiving one executable that potentially barfs those dll-s into temp directories that the extractor may or may not have access to, them may or may not know about, and may or may not be actually removed when the program exits? (Especially in the case if it abnormally aborts execution)

In case of that, the extractor-launcher is actually a program (with hidden window) that extract game.exe to temp directory. If the game crash, the extractor will still always active in the background and will do the clean up. After the clean up the extractor-launcer program will safely exit.

[slime]

Building love with static library dependencies is not necessary for making a self-extracting executable. You can do the latter without the former (or without even rebuilding love at all, as far as I know).