poked around with build systems again today and fixed docs for one.

i have to say i like please.build. it's like google's bazel but not a behemoth.

one silly thing please.build does is do all the building in a sandbox. it will symlink (?) in dependencies that are specifically tagged in to a rule. so if you say a file requires these headers and depends on that package, it will only hardlink in the listed headers and exports of the package.

so dependent files are always known in the build script.

it will also hash all of that shit in to the name of a target and it will also cache those results (incl. some fancy shared cache thing i haven’t messed with much.)

so you can end up if properly configured a situation where you just check out the git repo for the program, run please build and it will pull what it can from your local cache (ex. if the project downloads and builds GSL or Janet to do some scripting it will just reach out to the pre-compiled one you already have if you have one lying around) and run everything in little semi-isolated boxes.

i don’t like to think about the wear on the drive from making all those symlinks tho.

spending some time helping fix the docs for xmake because it runs on windows and seems very capable but things are a little too C++ centric and you're supposed to write lua blobs to support other things. it turns out it's not super hard to actually write those rules so its just a matter of contriving the examples, figuring out how to do it and then writing it up as a PR.

upstream says he can't satisfy everyone but i read it as there's basically 4 things a build system deals with:

- single input, single output
- multiple input, single output
- multiple input, multiple output
- single input, multiple output

there are two ways to do things in xmake (one uses a new batch API which is compatible with emitting makefiles which don't even need xmake to run!) so ... 8 good examples should cover everything. it's just a matter of communicating sufficiently these things so i can straight face someone like "oh yeah, this will compile all your textures to .dds files too :cirno_shrug: look here its easy"

right now i use manually written ninja files for those jobs (plan 9 mk is weird to run on msys.)
i think most games actually don't use makefiles for assets or they rely on the IDE (unity, godot)'s importers to do it. i remember when XNA came out people were making a huge deal out of the "pipeline" tool which was basically a glorified makefile system for "wowee turn all my .wav files in to .wmas so they run on xbox!" button
Follow

@icedquinn I use MonoGame (an open-source implementation of XNA) and the pipeline tool just seems pointless and cumbersome.

· · Web · 1 · 0 · 0
@xianc78 the IDE for your game engine does this job anymore. Godot used to even pack it all in to sprite sheets on export (but was removed in v3 because they decided "nobody needs sprite atlasses anymore")
Sign in to participate in the conversation
Game Liberty Mastodon

Mainly gaming/nerd instance for people who value free speech. Everyone is welcome.