libbet now uses `py -3` if the `py` binary exists, instead of if
`COMSPEC` is defined. So we don't need to `unset COMSPEC`, we just
need to avoid Windows' `py` launcher from being in Cygwin's `PATH`.
It turns out that `C:\cygwin\bin\env.exe CYGWIN_NOWINPATH=1 ...`
was not effectively preventing Windows' `PATH` from being inherited
by Cygwin's `PATH`, because to take effect it needs to run Cygwin's
`/etc/profile` script. The simple way to do that is using a login
shell. So we don't need the `PREFIX`/`--prefix` from the previous
commit after all.
We need to pass `-e` to Cygwin `bash` explicitly, since specifying
it as the non-default `shell:` no longer automatically adds `-e`
behavior to `run` blocks.
We also need to install to `/usr/bin` (which `cygwin-install-action`
automatically adds to the `PATH`), not `/usr/local/bin` (which is not
in the default `PATH`). This tests our `PREFIX`/`--prefix` handling.
This value "has no impact unless `INSTALL_PARALLEL` is enabled",
and since our install procedure is so simple, I don't think we need
to add that. (The `make install` commands don't use `-j` either.)
We shouldn't assume how the user wants to install things.
In particular, `--break-system-packages` is egregious.
---------
Co-authored-by: Rangi <[email protected]>
This will let us use C++20 features that GCC 9's experimental
C++20 support did not yet cover, such as "concepts".
This reverts some commits:
- 6bcd79b997
- d5ce5329ea
- 728d14879b
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.