This isn't really useful anymore now that running the client in dev mode
(`client/bin/run`) builds the player as needed. I think I was imagining that CI
would call a top-level `bin/build` script to build both the client and the
player, but I ended up just invoking both `client/bin/build` and
`player/bin/build` in the CI pipeline instead.
This got pretty complicated, but I think out of necessity.
We have two programs, the client (`alda`) and the player (`alda-player`), and we
want to make sure that if you build both of them from the same commit of the
Alda repo, then they will each tell you that they're the same version.
We don't want to store the version in multiple places, because then it's
possible to accidentally have a client and player that will tell you they are
different versions, when in fact they were built from the same commit.
* The single source of truth about the current version is the file `VERSION` at
the top level of the repo.
* The player is a Kotlin (JVM) project, so I just added a symlink to `VERSION`
in the resource directory, and that allows us to bundle the file in the jar
file as a resource, and the player process can read that file at runtime to
get its version. Much simpler than the shenanigans I had to pull for the
client...
* Go's approach to stuff like this is pretty spartan. You can't really bundle
resource files into the executable. Instead, you have to do code gen to inject
whatever content you want into a generated Go source file.
So, there is now a gitignored `generated/` directory in the client project,
and a `gen/` directory containing a single source file, `gen/version/main.go`.
It generates a `generated/version.go` that looks like this:
```
package generated
// ClientVersion is the version of the Alda client.
const ClientVersion = "1.99.0"
```
main.go includes the directive `//go:generate go run gen/version/main.go`,
which runs the Go program that generates `generated/version.go`.
Go also makes you manually run `go generate` to get that to actually happen,
so I added that to `bin/build` to ensure that we'll always run `go generate`
before `go build`. I also made this clear in `main.go` and I will also make it
clear in the README, to help contributors avoid getting tripped up by this.
It'll probably still happen, but I don't know what else I can do. Go does not
hold your hand when it comes to stuff like this.
As more people are starting to become involved with the development in Alda, I think it will be easier to collaborate and discuss feature ideas, etc. through some combination of the wiki and the issue tracker. I've moved the ideas in the .idea folder to the wiki, and moved the midi-patch-demo script to the bin folder.
