Improve build for Linux using Makefile

[duhow]

While there is already cmake and also several make-linux.sh scripts, it should be best to use a Makefile, autoconf or another solution to allow user to customize the builds if needed, rather than defining hard-coded checks.

Changes:

• Migrate make-linux.sh to Makefile
• Define script make-macos.sh as executable in repo

[duhow]

@8bitbubsy any chance to review this PR? 🙇🏻

[8bitbubsy]

So here's the honest reason for why I didn't give this PR attention (I usually give at least a reply, but I guess I forgot): I'm not comfortable with the whole Linux build files thing as it's impossible to satisfy all people. It just won't happen, there will always be new complaints about the make files/scripts at one point. cmake was supposed to be the absolute best and most versatile option (I thought?), but I guess it's not? These files are almost like holy ground, I'm not comfortable touching them too much, especially because I'm not a Linux guy myself and I have gotten so many complaints about the make solution for the tracker clones over the years.

PS: why delete the existing .sh file? I'm sure it still works for most people. Marking it as executable in the repo is a good idea though, I didn't know it was possible! 👍

EDIT: Hmm, is it not possible to mark a file as executable with the GitHub Desktop client on Windows? How would I do this?

[siborg]

I never had issues building a pt2-clone on linux. The process is simple and never fails. S.

…

On Sat, 19 Jul 2025 at 11:01, Olav Sørensen ***@***.***> wrote: *8bitbubsy* left a comment (8bitbubsy/pt2-clone#43) <#43 (comment)> So here's the honest reason for why I didn't give this PR attention (I usually give at least a reply, but I guess I forgot): I'm not comfortable with the whole Linux build files thing as it's impossible to satisfy all people. It just won't happen, there will always be new complaints about the make files/scripts at one point. cmake was supposed to be the absolute best and most versatile option (I thought?), but I guess it's not? These files are almost like holy ground, I'm not comfortable touching them too much, especially because I'm not a Linux guy myself and I have gotten so many complaints about the make solution for the tracker clones over the years. PS: why delete the existing .sh file? I'm sure it still works for most people. Marking it as executable in the repo is a good idea though, I didn't know it was possible! 👍 — Reply to this email directly, view it on GitHub <#43 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQ6NUQIE3FPQNRVJWK4ZYT3JIJQTAVCNFSM6AAAAAB3OSFGDKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAOJSGIZDSNJVGE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[duhow]

@8bitbubsy thanks for your feedback!

Regarding the choice between make or scripts, for Linux users is very common to use make or cmake, as long as it is explained in the documentation with the required dependencies, there shouldn't be any other concern, plus the Makefile allows to customize the build options if needed, such as performing cross-compile (eg. build the program for ARM in x86 systems).
CMake integrates more options that allow you to check for package dependencies and further customize the builds with its syntax, I am not that familiar with creating the file, so I went straight for the Makefile as a simple solution.

The outcome of this PR is to keep the same behavior of building in Linux but using a more common tool 👍🏻 - it can even be used for Mac, but I don't have Mac devices around to further test this, and running GitHub Actions to playaround with this may take me a while longer than expected.

I'm not a Windows user since years, there are security permissions to modify the attributes of files to mark them as system, hidden or read-only, GPT says to do:

git update-index --chmod=+x file.sh