Adds a new type of `require` which fetches package metadata from a
registry API endpoint (i.e., Reservoir) and then clones a Git package
using the information provided. To require such a dependency, the new
syntax is:
```lean
require <scope> / <pkg-name> [@ "git#<rev>"] -- e.g., require "leanprover" / "doc-gen4"
```
Or in TOML:
```toml
[[require]]
name = "<pkg-name>"
scope = "<scope>"
rev = "<rev>"
```
Unlike with Git dependencies, Lake can make use of the richer
information provided by the registry to determine the default branch of
the package. This means for repositories of packages like `doc-gen4`
which have a default branch that is not `master`, Lake will now use said
default branch (e.g., in `doc-gen4`'s case, `main`).
Lake also supports configuring the registry endpoint via an environment
variable: `RESERVIOR_API_URL`. Thus, any server providing a similar
interface to Reservoir can be used as the registry. Further
configuration options paralleling those of Cargo's [Alternative
Registries](https://doc.rust-lang.org/cargo/reference/registries.html)
and [Source
Replacement](https://doc.rust-lang.org/cargo/reference/source-replacement.html)
will come in the future.
Updated and split from #3174.
On Windows, we now compile all core `.o`s twice, once with and without
`dllexport`, for use in the shipped dynamic and static libraries,
respectively. On other platforms, we export always as before to avoid
the duplicate work.
---------
Co-authored-by: tydeu <tydeu@hatpress.net>
This is a temporary workaround for a limitation on Windows shared
libraries. We are getting errors of the form:
```
ld.lld: error: too many exported symbols (got 65572, max 65535)
```
The test is flaky due to the presence of a fixed 'sleep()'.
The LLVM backend has introduced a performance
regression in Lake which causes this test to fail, as the
current sleep duration of 3s is insufficient.
Further investigation into the performance regression is pending.
We decided to disable the `leanlaketest_116` entirely on account
of the test being flaky by construction
(https://github.com/leanprover/lean4/pull/2358#issuecomment-1655371232).
This adds `lean.h.bc`, a LLVM bitcode file of the Lean
runtime that is to be inlined. This is programatically generated.
1. This differs from the previous `libleanrt.ll`, since it produces an
LLVM bitcode file, versus a textual IR file. The bitcode file
is faster to parse and build an in-memory LLVM module from.
2. We build `lean.h.bc` by adding it as a target to `shell`,
which ensures that it is always built.
3. We eschew the need for:
```cpp
```
which causes breakage in the build, since changing the meaning of
`static` messes with definitions in the C++ headers.
Instead, we build `lean.h.bc` by copying everything in
`src/include/lean/lean.h`, renaming `inline` to
`__attribute__(alwaysinline)` [which forces LLVM to generate
`alwaysinline` annotations], then running the `-O3` pass pipeline
to get reasonably optimised IR, and will be perfectly inlined
when linked into the generated LLVM code by
`src/Lean/Compiler/IR/EmitLLVM.lean`.
Co-authored-by: Sebastian Ullrich <sebasti@nullri.ch>
I guess CMake might not actually be that painful if one was motivated to
learn it
```
sed -Ei 's/set\(([A-Z_]+) "\$\{\1\}/string(APPEND \1 "/' src/**/CMakeLists.txt
```
* fix msys2 windows build so the windows apps support utf-8 file paths.
* use windres to compile default-manifest.o
* windres is in binutils.
* stop modifying default-manifest.o
* copy to stage0
* fix semicolon joining of lists in add_custom_target
* undo changes to stage0 as per CR feedback.
* fix makefile
* fix: revert cmakelists.txt COMMAND_EXPAND_LISTS change
* fix: msys2 dependencies
* add unit test for decoding UTF-8 chars to prove "lean.exe" can read utf-8 encoded files where utf-8 is also used in the file name.
* fix: utf-8 test by using windows-2022
* fix: do we really need cmake 3.11 or will 3.10 do?
* nope, really does require cmake 11.
