If set, when compiling this generates an executable which generates
profiling data. Currently supported by Racket and Chez, other backends
silently ignore it.
This builds a .o from the generated C, and statically links with the
libidris2_support library. It doesn't yet dynamically link with any
additional libraries.
The output directory was previously called the executable directory, but I changed it because the output is not always an executable (depending on the code generator).
The code generators can now distinguish between where to place the (temporary) build files and the resulting output files.
Racket appears to have a different notion of current directory than the
system does, so we need to tell it which directory we think we're in
when reading and writing bytevectors using the scheme file functions.
Instead of dumping the required dynamic libraries in the working
directly, where the executable won't necessarily find them, take the
same approach as the Chez backend and create a subdirectory for the
required runtime files and use a shell script to start up with the right
library paths.
