In 094a8c82 we added the ability to compile a source file relative to
_STARTDIR$ instead of the location of the qb64pe executable. This change
fixes `-o` so that it is also treated as relative to _STARTDIR$ when the
provided source file is.
Note that this is not a real behavior change because if the provided
source file is relative to the qb64pe executable then `-o` will be as
well, which matches the previous behavior. The cases where it is made
relative to _STARTDIR$ all produced errors until 094a8c82 was done, so
there was no previous defined behavior.
Fix was pulled from QB64Official/qb64#17 by Cory Smith, I just added
tests around it.
Most (all?) compilers allow you to run the compiler from a separate
directory than the compiler itself is located in and compile source
files relative to that directory. QB64-PE however does not allow that,
for a variety of reasons it always search for the provided source file
relative to the location of the QB64-PE compiler rather than the CWD it
was run from. This is pretty unexpected behavior in a lot of cases, and
also doesn't give very helpful error messages either.
This change has us check if the source file exists at the given CWD
location, and if it does we will prepend the CWD to produce the correct
path to the file.
To test that this behavior works as expected I modified
`compile_test.sh` to compile from within the test directories using a
relative path directly to the test file, this fails with current QB64-PE
versions because it can't find the source file.
Additionally, I was unsure of whether this would impact the behavior of
`'$include`, so I added some tests around include that uses various
combinations of paths relative to QB64-PE and relative to the source
file being compiled, and they all find the files as expected so I think
it's fine.
Overall this is fairly straight forward, `evaluateconst$` has type
information on the parameters for its expressions, but it's not actually
checking that both parameters have a proper type. The result is that
expressions with nonsense values such as undefined variable names end up
just trying to use that nonsense value as an integer.
Fixes: #177
_BLUE is one of the few functions that requires multiple parameters, but
it was not included in the list of functions that require them. The
result is that gets get parsed incorrectly and _BLUE did not work.
Adding it to the check of functions that accept multiple parameters
allows it to work as expected.
Fixes: #195
Fairly simple, the order of functions meant that `_RGBA` got picked up
as `_RGB` instead, with the `A` then considered invalid syntax. Fixing
the order allows `_RGBA` to work as expected.
Fixes: #194
These tests were intended to be added by #171, but the Linux build was
having problems. The issues with the build have since been resolved so
the tests are getting added back in.
Fixes: #173
A quick fix, but providing `DEPENDENCY_CONSOLE_ONLY` when compiling
audio.cpp tells `common.h` to avoid pulling in `freeglut.h`, which fixes
the linking issue.
Fixes: #172
The _DEVICES command pulls in some stuff that depends on `winmm`.
Normally this isn't a problem, but if `$CONSOLE:ONLY` is used then this
dependency can actually get removed from the `CXXLIBS` and cause linking
to fail.
It's easy enough to fix this by always adding `-lwinmm` if `_DEVICES` is
in use.
Fixes: #178
libz tests were missing, I added one to test the libz dependency.
Additionally $CONSOLE:ONLY creates many weird interactions and is
currently broken in some cases. This adds tests for all the dependencies
that can work with $CONSOLE:ONLY to verify that they compile correctly.
It's still not entirely clear what the underlying issue is, but the ALSA
device provided by pulseaudio stops working after so many tests use it.
I've tried various approaches, but simply restarting pulseaudio after
every test is a bruteforce but successful solution. In practice it also
doesn't have any noticeable performance penalty, so it seems like a file
solution.
The `CI_TESTING` environment variable is used to avoid restarting
pulseaudio if the tests aren't being run in the CI environment (we don't
want to restart your pulseaudio instance if you're running them locally!)
`sub__mousemove` is trying to use `x_scale`, `y_scale`, `x_offset`, and
`y_offset` to calculate where the mouse should be in the event the
window coordinates are different from the screen coordinates.
Unfortunately, all four of those variables are actually never set in the
program. The real scale values and offsets (in the event of
letterboxing) are stored in `environment_2d__` values. This change
switches `sub__mousemove` to simply use the correct values when
calculating the mouse position.
Because `x_scale` and `y_scale` are not used anywhere else I just
removed them completely. I wanted to remove `x_offset` and `y_offset` as
well but there are a few spots that make use of it. It must be a bug,
since they are never assigned values other than zero, but I'm not sure
if the correct fix for the other locations is to use the
`environment_2d__` value or do nothing, so I'm leaving them for now and
we can address them later.
Using single quotes in a file name wasn't working because the Makefile
was using single quotes itself to quote the filename when providing it
to the compiler. The Makefile was switched to use double quotes instead,
which work just as well but are allowed to contain single quotes inside
of them.
Since double quotes are a legal character to have in a file name on
Linux and Mac OS, I added extra logic to start escaping double quote
characters.
I added a test to verify that we can compile source files with single
quotes in the name. I could not add a test for double quotes since such
files cannot exist on Windows and thsu cannot easily be added to the
repository.
Changing midiaudio.h will make it harder to incorporate new versions
into QB64-PE as they come out. To fix that I have reverted all the
changes to midiaudio.h and moved the few private parts we were using
into a separate 'filepath' API that's part of libqb.
This adds compiler settings for each of the settings in the
'Compiler Settings' IDE dialog. This makes it easy to supply the
settings per compile without needing to use the IDE to change them (or
edit the `config.ini`).
Fixes: #162
