This file was checked-in with Windows line endings, but it should have
Unix/Linux ones. Windows will automatically convert it into Windows line
endings when checking the file out, so it's not a problem in that case.
This adds logic for testing the new license generation functionality.
This is done by having the expected license for a variety of
tests that use different dependencies, and then comparing that against
the license QB64-PE actually produces when compiling these test files.
Note that because the actual used dependencies changes depending upon
the OS, we have separate expected licenses for each of Linux, Windows,
and Mac OS. This required some build changes to accomidate, in addition
to the testing logic changes themselves.
This gives QB64-PE the ability to automatically generate a text file
comprising all of the licenses that apply to your QB64 program. This
file can then be distributed with your program to meet the requirements
of those licenses, and also examined to understand what licenses apply
to your program.
The generation is controlled via a configuration flag, settable either
via the `Run` dialog, or via a new `-f` setting on the comamnd line.
Fixes: #145
There's some logic for handling `Bit * n` types that doesn't properly
handle NoPrefix. There's both a faulty error check which only works for
the `_` version (It was using `OR` so it always failed), and then also
the code that pulls out the number only works if the `_` is present.
Both of those are fixed in this commit.
The original issue comes from b87dde8. Fellippe was fixing using
NoPrefix types with Declare Library, which uses some of the same logic
as Static arrays. Unfortunately, his change broke the `String *n` syntax
and `Bit * n` syntax because he stopped using LEFT$() to check only the
prefix of the type. Cory fixed the issue over in QB64Official/qb64#35
by reverting the code to use LEFT$() again and I pulled some of that
logic in here.
Note that I've modified his solution a bit. During testing of that fix I
noticed that `_Unsigned Integer64` no longer worked, because is because
it aliases with `_Unsigned Integer` and the shorter type gets checked
first. This may have been what Fellippe was trying to fix (since
removing the LEFT$() avoids this issue) but it's hard to say.
I addressed that issue by only applying $LEFT() to the two types that
are allowed to have text after them (`Bit` and `String`). The rest of
the types continue to use the direct string comparison that requires an
exact match. Additionally I reorganized the checks a bit to make them
easier to read and also easier to confirm all combinations are checked.
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
