windres has a handy feature of allowing us to feed it an executable and
it will give an error code depending on whether that executable has a
resource section or not. We can use that feature to create a quick test
to verify the distributable has the resource information on it.
Previously, the creation of the icon.rc file was restricted to be
Windows only because Windows is the only platform with a use for that
file. Unfortunately, this breaks a fundimental assumption about how the
QB64 C++ generation works, because we only have one set of
`./internal/source` files from which we build all versions of QB64 for
all platforms. Due to that, the built version needs to include all files
needed by all platforms, regardless of which one is doing the building.
So to that end, all platforms should produce the icon.rc, even if it
will not be used on that platform.
Additionally, the path to the icon file in `icon.rc` is problimatic
because it is made into an absolute path. This blocks `qb64.bas` from
using `$EXEICON` because the absolute path is not predictable, as
the location we create ./internal/source will be different from the
location we build ./internal/source. Effectively this means that the
`icon.rc` file in `./internal/source` would always be wrong.
The solution is to not use an absolute path, with the other option being
to have the icon in the same directory as the resource file. This is
actually relatively easy to acomplish since icon files are not terribly
large and we can simply copy it into the temp directory.
Thus, that is what this change does - the specified icon file is copied
into the temp directory as `icon.ico`, which allows use to use
`icon.ico` in the `icon.rc` file and have it always work regardless of
directory.
The internal logic was also cleaned up a bit. The creation of these
files is no longer Windows specific, and the $EXEICON parsing no longer
writes to the `icon.rc` file - rather, the entire thing is generated
together, with both the $VERSIONINFo and $EXEICON depending on which
were provided.
These tests use a variety of sample code (with some of the larger files
removed, so they are not complete!) and verifies that they all compile
successfully.
These tests check that we can compile programs that use a variety of
different sets of dependencies. Each program will only be compiled with
the set of dependencies it relies on.
Reset version number to 0.5.0.
Added "Phoenix Edition" to our name, so nobody will think we're still working with the old team of QB64, and mistakenly donate to the wrong Patreon, or buy merchandise wrongly thinking they were supporting us. :)
There's no need for all colors to end up with a new prefix for use between $COLOR and $NOPREFIX.
The only conflicts we have are with _Red, _Green, _Blue, so this fix appends a NP_ to the front of the those three color names so they won't conflict with the command names. (NP_ for NoPrefix_)
This imports the basic logic from the previous build. All it does is
compile a version of QB64 using ./internal/source, and then uses that
QB64 as a 'bootstrap' step to compile `qb64.bas` directly and produce a
proper version of qb64.
internal/c/c_compiler no longer contains anything, so git will not
create it. This change makes setup_win.bat create the directory if it's
not already there.
