(Which was commented out anyway)
Three scheme back ends is enough to maintain, and Gambit does the same
job as chicken (fast startup of the interpreter, generating via C) but
seems to deal with the code Idris generates better.
This has two main advantages: firstly, it actually makes the build slightly
faster and less memory intensive, because Idris doesn't fork a new
process and eat all the memory! Secondly, it means we can build a
distribution with the C file, for building on machines which don't have
Idris 1 available.
Also includes a script for building such a distribution.
I expect someone who is better a writing Makefiles than me can tidy this
up. There are almost certainly problems on Windows too - please help if
you can!
There are new Make targets 'all-fromc' and 'install-fromc' which don't
require building from Idris source, so that we can build with no Idris 1
available.
A small consequence: make install-exec no longer builds the idris2
executable, just installs it.
Not in generating install directories, otherwise we end up with loads of
new directories for every patch and the purpose is to make it easy to
see which version you're working with.
This is to help Idris2 codegen the correct scripts on NixOS where
Racket and Chicken aren't installed in the standard locations, and
the /usr/bin/env trampoline is disabled at package build time.
This now matches the existing Chez behavior.
Also, fixed the test runner to restore the correct working directory
after a failed test, and fixed the top-level Makefile to allow the
IDRIS2_VERSION variable to be queried without building the project.
This makes it easier for more complicated packages (e.g. network, which
needs to install a C shared library) to know where to put things without
having to work out the prefix themselves.
Since they'll be incompatible between different Idris2 versions, this
helps protect against importing the wrong thing by mistake. Also, it
means the canonical place for the version number is now the top level
Makefile.
You'll need to delete src/YafflePaths.idr before rebuilding, since it's
now generated slightly differently.
This is so that we can put other build artefacts (e.g. executables) in
properly organised subdirectories of build, e.g. build/bin/chez,
build/bin/js, etc.
This is for finding support libraries for code generators, e.g. the
shared objects that chez will load for glue code for foreign libraries.
It'll be used more shortly...
We can't nest delayed elaborators (this is an efficiency constraint, to
prevent excessive searching for ambiguous names) to run elaborator
immediately if delays aren't allowed in delayElab
With the --yaffle flag, you get the old behaviour which is to invoke the
checker for the core theory (and all the tests are updated appropriately
for this).
