This is a bit of an odd one, but files with $ in the name don't compile
correctly due to expansion being done on the $.
The culprit here is `make`, as the syntax '$x' is interpreted to mean to
insert the expansion of the variable 'x'. To avoid this behavior we have
to replace every single $ with $$. Make will interpret the $$ to mean it
should insert a single $ and not do any expansion, which is what we
want.
Fixes: #96
The new dialogs includes 5 settings:
1. Flag to turn on Optimization (off by default)
2. Flag to strip symbols (On by default)
3. String for extra compiler flags
4. String for extra linker flags
5. Setting for max compiler processes (default of 3)
Fixes: #65
Fixes: #40
- `qb64 -u` can be used during build to populate internal/help, it basically invokes the "Update all pages" action from the IDE's Help menu
- switch is not listed in -? usage help, as I consider it a hidden build-only option
Makefile's generally hate spaces in filenames, and it's largely
impossible to make them work. Due to that, with the change to use a
`Makefile` the `EXE=` parameter did not work with spaces, and programs
such as "foo bar.bas" would not compile because it produces "foo
bar.exe" which has a space in the name.
There were options here, but in this very specific case it is actually
possible to allow the Makefile to work with spaces. `EXE` is only a
single filename, so as long as we always quote it correctly and the
provided `EXE=` parameter escapes the spaces with `\` then it will work.
Thus, we modified the Makefile to always do the quoting, and modified
QB64 to automatically escape the spaces in the executable name provided
to the Makefile.
I also modified the `compile_tests` to test that spaces in filenames and
paths of the executable correctly compile.
Fixes: #80
Having two separate files for the compile output is just too confusing,
and it adds an extra file users need to look at and give us when there
are issues. This change simply makes qb64.bas send both the stdout and
stderr output to compilelog.txt.
Fixes: #61
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 resource file we create contains two separate values for FileVersion
and ProductVersion. Currently, they are actually represented by two
separate values in $VERSIONINFO and effectively require duplicating the
information between them.
My understanding is that the string values should always be the same as
the numerical versions, so to make $VERSIONINFO easier to use this
changes the logic so that setting the numerical version will
automatically also set the string version if values for them are not
provided.
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.
* Create `$NOPREFIX`-friendly version of `color0.bi`
* Create color32_noprefix.bi
* add conditional for noprefix $color
* oh. it was that easy?
* Update CHANGELOG.md
* Update help files [ci-skip]
Co-authored-by: all-other-usernames-were-taken <74026992+all-other-usernames-were-taken@users.noreply.github.com>
