Central mk.sh script by mcarans · Pull Request #688 · OoliteProject/oolite

mcarans · 2026-06-27T22:13:53Z

Versions and build dates all obtained once in meson setup project function
Everything passed by parameter not env var (with necessary exception for Flatpak where host passes env vars in YAML)
Use bash functions rather than scripts where possible
Targets now named deployment, dev, test and debug (no snapshot etc.)
Updated compiler flags to use the same naming for consistency and clarity
Remove Makefile

Fixes #684
Fixes #671

See usage of mk.sh in README: https://github.com/mcarans/oolite/blob/mk_script/README.md
You can type ./mk.sh help for help on the actions, targets and options

Remove Makefile

Align builds to end filenames

Fix Windows

mcarans · 2026-06-27T22:51:47Z

Builds are here: https://github.com/OoliteProject/oolite/actions/runs/28303563872/attempts/1
(I forgot that release is skipped for PRs and reran the release job unnecessarily)

I've tested on Windows and Linux and looks good to me.

EDIT: builds are here https://github.com/OoliteProject/oolite/actions/runs/28349179837?pr=688

Add missing help descriptions

phkb · 2026-06-29T05:32:04Z

I noticed the "Schemata" folder is not being copied into the Resources folder. Which means the verifyOXP option will have difficulty doing anything. I think this has been the case for a little while now, certainly before this PR. I'm happy to create a separate issue to track the resolution, though.

mcarans · 2026-06-29T05:45:17Z

@phkb Good you noticed that. Yes please create a separate issue as it's a bug that precedes this PR. Let me know if you see any other problems.

mcarans · 2026-06-30T08:42:36Z

@phkb @oocube this PR is ready for review

oocube · 2026-07-01T20:58:28Z

I'd rather finish a design discussion on the forum first.

Ensure install depends on build

mcarans · 2026-07-04T22:25:12Z

I've set this to draft. While this works well on the command line, I think that there could be problems with IDEs so I'm going to try to move the single version creation into the meson to follow the meson way and be consistent.

* Add missing Schemata (OoliteProject#691) * appimage working * Remove --clean option as there is a clean target * Flatpak working locally * Fix workflows * Fix Windows * Output meson log on failure * Output parent process Bash parent * Try different way of getting parent process * Try different way of getting parent process 2 * echo $(ps -p $PPID) * echo $(ps -W -p $PPID) * echo $(ps -W -p $(ps -p $PPID -o winpid= | tr -d ' ')) * print lots of debug * print lots of debug * print lots of debug * print lots of debug * print lots of debug * print lots of debug * gwmi debug * gwmi debug 2 * gwmi debug 3 * Fix meson logging * Fix latest clang breaks Windows build due to conflict with ceil function used by SDL3 and Obj-C (OoliteProject#694) * Targeted SDL3 includes * Fix GitHub rate limiting curl * Fix meson folder * ver quad * Maybe we can do this without realpath * Maybe we can do this without realpath * Fix Windows * Wrong path * ver_githash * better flag handling * Echo ver quad * Version quad * Update meson.build to include version variables * Refactor post_build.sh to update version parameters * Rename version variables in generate_manifest function * Remove version_quad echo from manifest script Removed echo statement for version_quad in manifest generation. * Remove echo for ver_quad in create_nsis_fn.sh Remove echo statement for ver_quad variable.

Add configure action to mk.sh Update README

# Conflicts: # .github/workflows/test_builds.yaml # Resources/Schemata/demoshipsSchema.plist # Resources/Schemata/hudSchema.plist # Resources/Schemata/plistschema.plist # Resources/Schemata/shipyardSchema.plist

mcarans · 2026-07-12T23:43:59Z

This is now ready for review

phkb · 2026-07-13T06:11:45Z

I tried just running
./mk.sh build deployment
but it failed.
I then did

./mk.sh clean deployment
./mk.sh build deployment

And that did the build. I assume this is because in the first instance I had some previous build in the deployment folder and the script wasn't able to work with it. It might be worth mentioning in the instructions somewhere. (ie "You should always do a 'clean' before doing a 'build'", or whatever makes more sense)

Is the "./" prefix for all the commands necessary? It feels like we're going backwards when the previous iterations were like:

make deployment
make debug=no

mcarans · 2026-07-13T08:03:00Z

@phkb On clean before build, usually that shouldn't be necessary, but maybe the changes in this PR are large enough that existing build folders won't work. Once the build settles down to something that doesn't change much (hopefully once this PR is merged), running build without clean should be fine.

There are a couple of possibilities for avoiding ./:

Bash alias that can be added to ~/.bashrc eg.

> alias build="./mk.sh build"
mcarans@Holly [~/Code/OoliteRelated/oolite_fixes] ± mk_script → origin {1} ?:11 ✗                                                                                                                                                                                  [py-'python'] [19:53:35]
> build deployment
--> Running Meson setup for: deployment
...

Here I have aliased both the command and a specific action, but you may prefer to just alias the command, for example alias mk="./mk.sh"

Add project folder to path using absolute path for security reasons

EDIT: edited alias to not alias make (which would cause conflict if system make is needed)

mcarans · 2026-07-13T19:13:42Z

@phkb I've updated the README with:

If for some reason the build fails, you can try cleaning the build folder first, although meson should not usually
require this step:

./mk.sh clean dev

oocube · 2026-07-13T19:43:09Z

Is the "./" prefix for all the commands necessary? It feels like we're going backwards when the previous iterations were like:

Windows and Linux are not that much different. Here is an article that explains:
https://www.howtogeek.com/current-directory-isnt-in-path-why-not-and-should-you-fix-it/

The reason why Linux is more aware of security is simply the history of being a multi user system where DOS/Windows used to be a single user system.

mcarans · 2026-07-13T19:49:16Z

Is the "./" prefix for all the commands necessary? It feels like we're going backwards when the previous iterations were like:

Windows and Linux are not that much different. Here is an article that explains: https://www.howtogeek.com/current-directory-isnt-in-path-why-not-and-should-you-fix-it/

The reason why Linux is more aware of security is simply the history of being a multi user system where DOS/Windows used to be a single user system.

I think the alias with relative path is the better option as it is specific to the script. That way if you have two project folders, it will run the mk.sh in the current working directory of the specific project.

On Windows, this could be added to the script that sets up MSYS2 if desired much like how the sourcing of the GNUstep.sh used to be added to .bashrc in that script.

phkb · 2026-07-14T11:48:46Z

I understand this is a difference in the way Linux works (well, I guess it's "bash" really, but still) to how Windows works. Being a long-time Windows user, I'm used to the expectation that, if a app or script is in my current folder, I can simply type the name to execute it. There's just a disconnect between being on a Windows PC, typing a command into a command line, and not getting what I expect.

I also appreciate that we don't want to keep making things work differently on different OS's. The fewer differences, the easier it is to maintain.

Do I like having to use "./" in front of the command? No.
Can I get used to it? Well, you can get used to anything, right? 😃

The point being, as long as the instructions are clear, I'm good.

mcarans · 2026-07-14T19:47:11Z

@phkb I'm happy to add the alias for Windows if it makes things easier. I can also document how to add it on Linux for consistency. That way you could type mk instead of ./mk.sh for example. (Note that with the alias, you would only be able to type mk if the current directory is the project root, whereas you can type the path to mk.sh from any folder and the script automatically changes directory to the project root.)

I would prefer to do that in a separate PR to avoid adding to this already large PR. Please make an issue for it if you'd like that feature (assuming this PR is merged).

oocube · 2026-07-14T20:52:33Z

@mcarans thank you for trying to separate issues

phkb · 2026-07-14T21:36:12Z

No, leave it for now. It's a pretty small issue in the grand scheme of things. There are much bigger fish to fry.

phkb

I know I'm just a Windows user here, and my needs are "Can I compile a working game?" rather than anything more complex. But this looks fine to me.

mcarans added 11 commits June 24, 2026 14:02

Add mk.sh script

9702579

Call as functions from mk.sh

63b9cbf

Remove Makefile

mk.sh orchestrates everything

da65cea

Align builds to end filenames

Fix test

4a9e977

Fix Windows

Try to install gitversion for flatpak build

0f975f3

Try to install gitversion for flatpak build

abb006c

Try to fix Windows path

efbc83e

Windows locally builds. Try fix CI

4a1bdfa

Force bash on Windows in CI

5ede762

Explicitly find bash in meson

b31e571

Explicitly find bash in meson

dd2fb55

mcarans requested review from AnotherCommander, Kaks, KonstantinosSykas, dsalt, ericwalch, jobi-wan, kanthoney, mwerle, oocube and phkb as code owners June 27, 2026 22:13

mcarans added 2 commits June 28, 2026 10:18

update README

92b318a

update README

9dcaaf4

mcarans added 4 commits June 29, 2026 07:03

Fix README.md

ca72ee6

Add missing help descriptions

Make help columns line up perfectly

decdf5e

Fix README

ebfc664

Fix install_deps.sh

05ebaeb

mcarans added 2 commits July 2, 2026 14:33

Make an install Gitversion function for Linux to avoid copy paste coding

beec7c5

Rename function meson_compile

59e3b02

Ensure install depends on build

mcarans marked this pull request as draft July 4, 2026 22:23

mcarans and others added 4 commits July 11, 2026 17:08

Ensure debug symbols get copied in install

0b15129

Add configure action to mk.sh Update README

Merge remote-tracking branch 'origin/master' into mk_script

b6d7af1

# Conflicts: # .github/workflows/test_builds.yaml # Resources/Schemata/demoshipsSchema.plist # Resources/Schemata/hudSchema.plist # Resources/Schemata/plistschema.plist # Resources/Schemata/shipyardSchema.plist

Fix release

be7bf02

mcarans marked this pull request as ready for review July 12, 2026 23:43

Update README for clean step

570a595

phkb approved these changes Jul 14, 2026

View reviewed changes

oocube approved these changes Jul 15, 2026

View reviewed changes

mcarans merged commit a8818f5 into OoliteProject:master Jul 15, 2026
12 checks passed

LW-archlinux mentioned this pull request Jul 15, 2026

#688 breaks chroot build on archlinux #696

Open

Uh oh!

Conversation

mcarans commented Jun 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mcarans commented Jun 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

phkb commented Jun 29, 2026

Uh oh!

mcarans commented Jun 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mcarans commented Jun 30, 2026

Uh oh!

oocube commented Jul 1, 2026

Uh oh!

mcarans commented Jul 4, 2026

Uh oh!

mcarans commented Jul 12, 2026

Uh oh!

phkb commented Jul 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mcarans commented Jul 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mcarans commented Jul 13, 2026

Uh oh!

oocube commented Jul 13, 2026

Uh oh!

mcarans commented Jul 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

phkb commented Jul 14, 2026

Uh oh!

mcarans commented Jul 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

oocube commented Jul 14, 2026

Uh oh!

phkb commented Jul 14, 2026

Uh oh!

phkb left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

mcarans commented Jun 27, 2026 •

edited

Loading

mcarans commented Jun 27, 2026 •

edited

Loading

mcarans commented Jun 29, 2026 •

edited

Loading

phkb commented Jul 13, 2026 •

edited

Loading

mcarans commented Jul 13, 2026 •

edited

Loading

mcarans commented Jul 13, 2026 •

edited

Loading

mcarans commented Jul 14, 2026 •

edited

Loading