* Allow Idris2 to bootstrap with "make -j"
"linear" should explicitly depend on "base" so that "base" is built before
"linear", otherwise it can fail with:
> Error: Module Data.Nat not found
>
> Data.Linear.Copies:5:1--5:16
> 1 | module Data.Linear.Copies
> 2 |
> 3 | import Data.Linear.Bifunctor
> 4 | import Data.Linear.Notation
> 5 | import Data.Nat
> ^^^^^^^^^^^^^^^
* Allow Idris2 to build with "make -j all"
"all: ${TARGET} libs" is bad because it means "${TARGET}" and "libs" can be
built independently. So "make -j" attempts to build them parallelly and
fail.
* Create a separate Makefile for the Idris 2 support libraries.
* Update INSTALL.md
* satisfy natural language linter
* Add to CHANGELOG
* Update CHANGELOG.md
A common issue for users is that the behaviour of the various repl
commands are not documented anywhere despite some of them having complex
behaviour (e.g. `:set` which accepts a specific set of options). This
implements the ability to call `:?|:h|:help` on repl commands to request
detailed help for a specific repl command, while preserving the
behaviour that calling the help command without any arguments prints the
general help text.
Generic help is defined as the first line of the help text.
Detailed help is defined as the entire help text.
This means that `:help :t`, for example, does not error (there is no
detailed help) but instead just prints the single line of help text.
* [ repl ] Use unlines for detailed help (see #2087)
Ideally, the lines affected should be multiline strings. But for some
arcane reason, newlines in those get swallowed in Nix and Windows
**CI** only Ô.o
This was already documented in issue #2087.
* [ new ] --except for golden testing lib
To allow CI to pass despite #2087
Co-authored-by: Guillaume Allais <guillaume.allais@ens-lyon.org>
Without this change install-libs will not install the .so files, and
consequentially the test 'chez/chez033' fails with 'Error: INTERNAL
ERROR: Missing .so:Prelude/Cast.so' when it is run by an installed
executable.
Also add a test-installed makefile target to run the tests using the
installed executable.
* Update version numbers and bootstrap scheme
* Use wall clock time for search timeouts
That was always the intention in any case, rather than the process time.
... instead of `bootstrap` which contains source files. Make it easier to understand
how build works, and in particular, which files are sources and
which files are generated.
This adds a new flag '--inc <backend>' which, if set, compiles all
modules incrementally, and for executables, links the incrementally
compiled modules rather than building the whole program.
Also, adds an environment variable IDRIS2_INC_CGS for providing a comma
separated list of backends to use for incremental builds.
Also, adds '--whole-program', which overrides incremental builds for an
executable.
Incremental builds are much faster if there's nothing to recompile, but
for the Chez backend, generate code which runs at about half the speed.
Currently only works for Chez - other backends ignore the flag.
Also, incremental building of an executable will only work if *all*
required modules have been built incrementally for the backend in use.
Why:
* To implement robust cross-project go-to-definition in LSP
i.e you can jump to definition of any global name coming
from library dependencies, as well as from the local project files.
What it does:
* Modify `FC`s to carry `ModuleIdent` for .idr sources,
file name for .ipkg sources or nothing for interactive runs.
* Add `--install-with-src` to install the source code alongside
the ttc binaries. The source is installed into the same directory
as the corresponding ttc file. Installed sources are made read-only.
* As we install the sources pinned to the related ttc files we gain
the versioning of sources for free.
* Banners for test pools
* Summary with the list of failing tests at the end
* Option to write the list of failing tests to a file
* Option to read the list of tests to run from a file
* Using these two latest features to add a new make target to rerun precisely the tests that failed last time
Rather than tracking how far we are from the project root in the various
Makefile commands, it's much easier to reference the build target with
with an absolute path.
