MSBuild is slow, and its output is hard to parse visually
(it's all interwoven, like Make without `--output-sync`).
Since we use CMake anyway, we don't care about the build system.
We can, so let's not ask if we should!
More realistically, we can right now so it's nice to mark that we do, but this is subject to be re-evaluated if any later changes conflicts with this.
Note also that this only affects the binaries we distribute with our releases!
It may very well be possible to compile RGBDS on even older versions of Mac OS X if you have the appropriate compiler setup;
we're just not testing it nor offering such binaries ourselves, but third-party packagers are welcome to do so.
(Looking at you, TigerBrew! ;)
Automatically grabs and compiles libpng, and avoids having hacky lines in our Makefile
(the compiler specification *should* be orthogonal to the build target!)
Also move the MinGW package install to the `install_deps.sh` script,
to move logic off of the YAML.
Besides the immediate performance improvement, reducing
the frequency of downloads should make spurious
failures (network, rate-limiting...) less bothersome.
`FetchContent` respects existing installs, and downloads and compiles the libs
if they aren't found.
This is admittedly a little finicky, since this ignores the usual `Find*`
modules provided by CMake, requiring a bit of glue on our side.
But, one upside is that this moves that logic from our CI into the build system,
which can thus benefit other downstream users.
This also opens the door to some improvements in upcoming commits.
Doing this with Bison turned out to be much more painful, however, due to
`FindBISON` providing the specific `bison_target` command; thus, it remains
installed externally, so that it can be picked up by `FindBISON`.
This also bumps our CMake version requirement slightly, though it's
possible that older versions keep working, or could be supported with small patches;
however, our CI doesn't provide anything below 3.31, so we can't check.
Note that the DLL name created by CMake with `BUILD_SHARED_LIBS`
has changed from `zlib1.dll` to `z.dll`. This was caused by the
"Continued rewrite of CMake build [Vollstrecker]" from its
changelog <https://zlib.net/ChangeLog.txt>, and has been reported
in <https://github.com/madler/zlib/issues/1181>.
The MinGW package `libz-mingw-w64-dev` still calls it `libz1.dll`.
fix#1157 for the following source code
```
section "hSAVE_locals",HRAM
func3.hSpam: ds 1 ; no longer produces an error
;.hEggs: ds 1 ; uncomment this to see the new error
section "demo",ROM0
func3:
ldh a, [.hSpam]
ret
```
Remove two errors:
- `Not currently in the scope of 'func3'`
- `Local label 'func3.hSpam' in main scope`
Add one error:
- `Relative local label '.hSpam' in main scope`
Co-authored-by: Rangi <35663410+Rangi42@users.noreply.github.com>
ISSOtm
Eldred Habert
Rangi
vulcandth
Rangi
Rangi42
Damian Yerrick