Orkuncakilkaya
6bcb5f4ae1
They were the macOS layout on every platform - the comment above them even said
"macOS/BSD layout" - so a game built on Linux wrote its saves to
~/Library/Application Support, a directory that means nothing there. Naming the
right directory is the entire reason a program calls these instead of joining a
path itself.
macOS save/config ~/Library/Application Support/<app>
cache ~/Library/Caches/<app>
Linux save $XDG_DATA_HOME or ~/.local/share/<app>
config $XDG_CONFIG_HOME or ~/.config/<app>
cache $XDG_CACHE_HOME or ~/.cache/<app>
macOS is unchanged to the byte, deliberately. save_dir and config_dir stay the
same directory there: Apple's home for a config file that is not an
NSUserDefaults plist is Application Support too, and a shipped game's settings
must not move out from under it. On Linux XDG separates the two and so does this.
An XDG variable that is set but EMPTY falls back to the default, which is what
the spec says and what an exported-but-unset variable looks like from a shell.
uname is read once and remembered rather than per call, because save_dir is
called on every save.
Verified on both branches. macOS by running it; the Linux branch by building the
probe's IR with the cached platform flag pinned, which exercises the emitted XDG
code exactly - unset, set, and set-but-empty all resolve as the spec says. The
suite's own case asserts the HOST's convention, so a macOS box covers the Apple
branch and CI covers XDG.
This is a backend change, so selfhost/ludicc.seed.ll is reseeded with it: the
bootstrap fixpoint (gen2 == gen3) and the C-free rebuild from the seed both pass.
|
||
|---|---|---|
| .. | ||
| os-known-folders.md | ||
| README.md | ||
Changesets
A changeset is one small Markdown file describing a single user-facing change,
dropped in this directory. ludic-dev release consumes every changeset here into a new
CHANGELOG.md section, bumps VERSION, and deletes the consumed files.
Format
bump: minor
type: feat
One or more lines describing the change, in the past-agnostic imperative used in
the changelog. Markdown is fine.
bump:—major,minor, orpatch(SemVer). The release version is bumped by the highest level among the pending changesets (unlessludic-dev release <level>overrides it).type:— the Conventional Commit type (feat,fix,perf,docs, …). It decides which group the change lands in:feat→ Features,fix→ Fixes,perf→ Performance, and so on, in that order. A type with no known heading gets one named after itself.
Writing the body
The body is markdown and reaches the changelog as markdown: it becomes one list item, with continuation lines indented to stay inside it. Nested bullets, blank lines between paragraphs and inline code all survive.
bump: minor
type: feat
**Tiled map support** — load and draw Tiled maps.
- **TMX/TSX** — the XML formats, decoded to the same intermediate as JSON.
- **Collision** — the `collision` layer projects onto the engine tilemap.
Lead with the thing that changed, not with the mechanism. A reader scanning the release should be able to stop after your first clause.
Adding one
Create a file with a short, unique name, e.g. changes/regex-namespace.md. Any
filename works except this README.md, which the release step always skips.
Preview how the next release will read before cutting it — this writes nothing:
ludic-dev release --dry-run