Fixes the issue as brought up on the forums here: https://qb64phoenix.com/forum/showthread.php?tid=408
Also added a small set of logic so we don't end up inside an endless loop if the screen is hidden (via _SCREENHIDE), or if it doesn't exist for whatever reason.
Missing files during the clean get reported on stderr. These are
expected so we're just ignoring them. Functionally it's the compilation
step that matters anyway.
The `objcopy` logic to produce a symbol file doesn't work on OSX, and it
seems it needs different lgoic to produce debug information, so for now
we're just going to skip it.
BUILD_QB64=y sets the default EXE name to 'qb64', which is actually
wrong on Windows because it does not include the `.exe` extention. It
also works anyway but `objcopy` doesn't recognize the file without the
extension present.
This issue was fixed in 4d61ff79, but due to how ./internal/source is
updated the new ./internal/source files were compiled using a QB64
without the fix, producing files with the wrong quoting. Previously this
was worked around because the build process overwrote these files, but
the `Makefile` build requires them to be fixed.
./internal/source itself is fine, so it's easy enough to simply fix the
files by hand. Since ./internal/source now contains a compiled QB64 that
contains the fix from 4d61ff79 it's generated files will have proper
quoting and won't need to be manually updated.
On Windows we don't distribute the ./setup_win.bat, so the contents of
./internal/source are not actually relevant for them. Since the QB64
symbol file will be located in it though, it is important that they get
an updated copy. It does also just make basic sense that if we're
distributing an ./internal/source with the Windows version it should
match whatever QB64 it was shipped with.
The symbol file is a file that aids in debugging by allowing a crash
dump from a stripped executable to have it's symbols applied to it. The
file itself ends up in ./internal/temp after compilation and is called
`EXEFILE.sym`.
FIxes: #53
The Makefile was incorrectly tying together _ICON and icon.rc, making it
impossible to use one without the other. To fix this we introduce a new
DEP_ICON_RC flag, which indicates we need to use the icon.rc file (in
addition to regular icon support). DEP_ICON now only indicates we need
to support _ICON, and does not attempt to build the resource
information.
The purpose of moving the EXEs is so that they are not captured in the
build artifacts. They would be nice to have, but they end up being a few
hundred MBs in size so much too large to bother saving.