This adds the libqb_http API, which is designed to support HTTP and
HTTPS usage from QB64-PE source.
The design consists of a single thread which services all the HTTP(s)
connections. There are then various libqb_http APIs exposed that allow
interacting with this thread to create a new connection, query
connection status, read data, or close the connection.
Internally the thread makes use of the curl_multi interface to allow a
single thread to service multiple HTTP(s) connections in parallel. This
means you can _OPENCLIENT() multiple HTTP connection in a row and all of
them will be serviced at the same time in whatever order data is
available.
HTTP is optional and selected via a Makefile setting. A stub is swapped
in if HTTP support is not used, which avoids need to add another build
flag to libqb.cpp.
Functionally it doesn't matter what kind of images we store for the
tests, as _LOADIMAGE() will open them exactly the same. png however has
the advantages of being substantially smaller, and also viewable
directly on GitHub in PRs, making them easier to review.
I broke this by accident in 5031de2, likely by misreading the $0. What
the line was intended to do was change to the directory the script is
located in when the script starts, this allows the script to be started
from any location.
Typically this isn't necessary functionality, but for Mac OS it's
important because if you double-click the script (the typical way to run
it) it is started from the user's home directory. Due to this I also
updated the Mac OS distribution test to run the script in this way so
that it's closer to how a user will run it.
Fixes: #218
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.
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.
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
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!)
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.
This adds MIDI support to the language as a new unstable feature. There
are two new metacommands that come with this:
$Unstable: Midi
$MidiSoundFont: [Default|"filename"]
The $Unstable command is required to be able to use any of the other
commands, and just signifies that this is not a full part of the
language yet and may change in breaking ways before the API is
finalized.
The $MidiSoundFont command enables MIDI support in the compiled program,
and also specifies what sound font to use to play MIDI files. "Default"
will make use of the soundfont placed at
'./internal/support/default_soundfont.sf2', and otherwise a filename can
be specified to use any soundfont wanted.
In either case, the selected sound font is compiled into the executable
and then loaded at runtime.
Fixes: #115
This adds support for tests of the error output of QB64-PE. The tests
are in the form of a `.bas` file that does not compile, and a `.err`
file containing the expected output of QB64-PE when producing an error
for that file.
Additionally the `compile_tests` now support multiple tests in a single
folder, via using multiple `.bas` files with different names.
- checks all remaining occurrences of the term 'qb64', some remain untouched, some are renamed according to context
- also added new logo for README.md
- this step does finalize the 'Phoenix Edition' re-branding
In QB64, when linking with an external static library `nm.exe` is used
to determine whether the symbol being used is either a C or C++ symbol,
which determines how the function should be declared in the C++ code.
Unfortunately on Windows the `SHELL` command for `nm.exe` is missing the
`cmd /c`, which means the redirection does not work and consequently
we're unable to find the function declaration via `nm.exe`, which causes
the compilation to fail.
In addition to fixing this, I added tests for `DECLARE STATIC LIBRARY`
for all supported platforms.
Fixes: #112
This is a very simple testing framework for writing and running tests
for C++. The basic idea is that a `struct unit_test` is defined for
every test function to run, and then the test framework simply runs them
one at a time, printing various information about the tests out as ti
goes.
There are also various 'test_assert*()` macros to assert the value of
things while running the tests. They verify a value is equal to an
expected value, and if not it fails the tests. The more specific
assertions like the `ints` and `buffers` ones also print out useful
information on what the expected and actual values were, to aide in
debugging.
This is a fairly flexable build framework for building C++ test
executables. The executables are defined in a list and each can be given
its own set of source files, compiler flags, linker flags, etc. The
test source files are compiled together at the same time to allow any
necessary files to get applied at compile time.
Later a script will run through the test executables.
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 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.
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.
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.
