The -no-pie flag tells the compiler not to make a Position Independent
Executable. We don't really care which it chooses to make, but some file
explorers consider PIE executables to be shared objects and won't allow
you to run them directly. To avoid this, we're compiling with -no-pie.
Fixes: #142
- 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
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.
This sets up a few different flags we'll need for the conditional
compiling, and also sets the C++ standard to gnu++11, which effectively
just matches what we were implicitly using before.
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
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
The symbol file was intended to just make the executable name with
".sym" and be located in ./internal/temp. Unfortunately I forgot to
remove the directory from the EXE name, so it ended up producing an
incorrect filename for the ".sym" file.
Make already provide a `notdir` function, so we can use that to get just
the executable name.
The contents of the qbx.o being compiled is dependent on the contents of
./internal/temp* related to that qbx.o. The paticular ./internal/temp*
to use is controled by TEMP_ID.
Unfortunately TEMP_ID is omitted from the path used to generate the
dependency list, which means the `qbx.o` may not get recompiled when
code changes are made and multiple IDE instances are being used.
Fixes: #81
The `objcopy` logic to produce a symbol file doesn't work on OSX, and it
seems it needs different lgoic to produce debug information, so for now
we're just going to skip it.
BUILD_QB64=y sets the default EXE name to 'qb64', which is actually
wrong on Windows because it does not include the `.exe` extention. It
also works anyway but `objcopy` doesn't recognize the file without the
extension present.
The symbol file is a file that aids in debugging by allowing a crash
dump from a stripped executable to have it's symbols applied to it. The
file itself ends up in ./internal/temp after compilation and is called
`EXEFILE.sym`.
FIxes: #53
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.