A major gripe about free software games.

[Jastiv]

It has source code so now you can change and modify the source code.....
Except you can't!
Why? because you have no idea how to compile it.
I still remember the days I tried to read all those gnu autotools manuals.
It was awful, I never really understood it. It was a build system, it was supposed to make compiling easy, instead it just came with a bunch of esoteric stuff to learn.
So, everyone hates gnu autotools, fast forward to now, cmake, scons, gradle, etc. and don't forget the famous dependency hunt, where you rely on libraries not in your disto with no clear instructions about how to install them to get the game working.
So, not all games are like this some games I can actually get to compile and run others I can't, and I just give up...
Do they really want people to actually play it, or is it just some developer toy for people who are serious about reading autotools manuals and other such things?
Yes, I know I'm just stupid and not like people who study build systems for fun.

[dulsi]

Packaging is hard. From my understanding part of the complexity of autotools is because it supports cross compiling. When autotools was created, building tools for platforms they didn't physically have was an important thing. To my knowledge none of the build tools attempt this. (Not saying that excuses the mess that is autotools.)

The bigger question is how do you want to solve it. Do you feel distros need to do more to package all needed libraries? Do you feel the libraries are already packaged but you don't know what to install? Is the problem just too many distros and the instructions only provide how to install on one distro? Do the build tools need modification to better inform what libraries are needed? Have you asked the developer? They may not know that building is a problem.

I can't say I've had a lot of problems with this. I've had problems with code suffering bitrot and can't compile because of library/compiler changes. Or simply having too many dependencies for me to attempt to install. (I'd like to look at opensurge but haven't tried to build it for that reason.)

[drummyfish]

Well I could join in on the rant and tell you the same is gonna happen with cmake in the future, and also stuff like flatpak etc. Don't forget this is a consumer society in which building something that lasts has no value. What matters is now -- your program is either successful, in which case it will continue being actively maintained and will conform to change in build systems etc., or it is not successful and no one gives a damn it will die along with its dependencies over time.

I would be really glad if people started making programs that last, but we do everything we can to encourage the opposite. JS and npm is a great example of this horror, when they have tons of libraries for every trivial thing, under layers and layers of abstraction (read dependencies).

If you want to build a program that lasts, make it have as few dependencies as possible AND make sure these dependencies are likely to survive -- e.g. having a C compiler as a dependency is pretty safe. Dependencies are everything that's needed to compile and run the program, including file formats, APIs, OS, hardware etc. Make all parts of your program easily replaceable. If you can avoid cmake, do it. If you can avoid a library that makes your program a little more shiny but makes it more likely to die, don't freaking use it.

That's the moral of the story, and why I prefer the suckless philosophy.

[Julius]

If you want to build a program that lasts, make it have as few dependencies as possible

Hmm, but wouldn't that be sort of the opposite of the unix philosophy idea you promoted in the other post?

[Julius]

On the topic of building code... as I wrote here on the forum previously, I think the way forward is reproducible builds in containers (Docker etc.). Yes, in a way this adds another layer of complexity, but the same time it incentives developers to simplify their build environment (as it becomes part of the build process). It also makes it pretty easy to spot where the issue in the build environment might be instead of blindly trying to chase down some obscure dependency problem.

Of course it might also just become another type of automated build process that pulls in hundreds of dependencies automatically... and which spits out a binary in the end but the process of how it got there is buried under so many layers of complexity that it isn't really possible to reproduce except with this specific docker compose file and referenced docker images... I have seen that happen and it reminded me of the bad old days of dependency hell

[drummyfish]

If you want to build a program that lasts, make it have as few dependencies as possible

Hmm, but wouldn't that be sort of the opposite of the unix philosophy idea you promoted in the other post?

Not at all, Unix philosophy is about programs working together, not depending on each other.

Of course it might also just become another type of automated build process that pulls in hundreds of dependencies automatically... and which spits out a binary in the end but the process of how it got there is buried under so many layers of complexity that it isn't really possible to reproduce except with this specific docker compose file and referenced docker images... I have seen that happen and it reminded me of the bad old days of dependency hell

I still don't really get what Docker is, but it sounds exactly like this -- another thing that enslaves and in the future probably kills your programs. I've never needed it, and I don't ever want to feel like needing it.

I've personally started using only a shell script for building my programs. It just runs the compiler with the right flags. With more complex programs that could take long to compile this way I'd consider a makefile.

[fluffrabbit]

Personally, I'm more comfortable with makefiles than shell scripts because I find makefiles slightly easier to read, plus they fit into the Windows philosophy better because they're not shell scripts, which compete with batch files, and you can always run mingw32-make regardless of which MinGW distribution you have. Yeah I know, Windows. I don't use Windows anymore, but I think about it all the time.

As for Docker, I would not call it "the way forward", more like a stopgap measure to build for platforms that have unreasonably complex build systems. Ugh. I do this for Emscripten and it works well. I'm trying to find a Docker image for Android that is up-to-date, relatively small, and contains Gradle and the NDK, but I have not had any luck after downloading 40 GB of shit these last couple of days. Android just sucks as a development platform. I might have to compose my own Docker image, but that would take time.

[Julius]

I still don't really get what Docker is, but it sounds exactly like this -- another thing that enslaves and in the future probably kills your programs. I've never needed it, and I don't ever want to feel like needing it.

What fluffrabbit describes is an example of a really bad situation improved a bit by the use of docker... but him having to chase down a usable docker image was exactly the anti-pattern I was referring to.

In general, docker is a way to create a new virtual computer on your machine (in an more efficient way that re-utilizes your existing linux kernel and is thus very low overhead). It is mainly used in web-server applications to allow easier deployment and clustering on cloud services... but that is another topic.

In effect the so called "docker file" is a make file for building a Linux system. So you can for example tell your computer to download the latest Ubuntu LTS release, then install via apt-get the needed dev-packages and afterwards pull your sourcecode via git & compile everything in a completely clutter-free build environment. All this is described in an easy to understand text-file that you can share with others (or even include with your game's source code) who can then replicate the exact same process with ease.

I previously posted this link which goes into more detail: https://sweetcode.io/using-docker-repro ... ironments/

[fluffrabbit]

All this is described in an easy to understand text-file that you can share with others

Actually, Android has found a way to break this pattern. With the Android tools, you actually have to log into the Docker container and "accept" a "license" (non-free EULA) using a terminal GUI that can't be scripted. Then you can upload your docker, but figuring out what's in it would require some reverse-engineering at that point.

That's how thyrlian/android-sdk did it, and I'm currently forking it to include the NDK, which will might require me to interact with the terminal GUI to make the docker.

with ease

Maybe for the end user, but not the people making dockers.

[fluffrabbit]

Heh.

[Lyberta]

Deleted.

[fluffrabbit]

Secure, audited, deterministic, signed, hashed, bulletproof builds. Can those be done with your current build system, or does it just pull whatever from Conan?

[Lyberta]

Deleted.

[fluffrabbit]

Or keep the hashes of the individual dependencies in a file and check them with a script, then you can download them from remote. And yeah, it's probably a very good idea to specify versions. The Debian and Ubuntu release schedules are slow enough that developers can keep up, but AFAIK Conan stays pretty in sync with upstream so the best practice would be to specify a specific version.

[Lyberta]

Deleted.

[fluffrabbit]

Whether or not upstream provides Conan packages, nobody really audits them. They just go up, like PIP. I wouldn't trust my life support system to run on Conan any more than I would trust it to run on Android.

[Lyberta]

Deleted.

[fluffrabbit]

But PIP is 10 times better than APT though.

Well, I think we can agree to disagree.

[charlie]

If you want to build a program that lasts, make it have as few dependencies as possible

Hmm, but wouldn't that be sort of the opposite of the unix philosophy idea you promoted in the other post?

Not at all, Unix philosophy is about programs working together, not depending on each other.

This is an understated point. People conflate 'one tool for 1 job' with 'one install/instance of one tool for 1 job'. They are not the same thing.