- 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.
