| Commit message (Collapse) | Author | Age |
... | |
|\ \ \ \ \
| |/ / / /
|/| | | |
| | | | | |
in CArray
|
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The `ide` folder contains two different binaries, the language server
`coqidetop` and `coqide` itself.
Even if these binaries are in the same folder, the only thing they
have in common is that they link to the protocol files. In the OCaml
world, having "doubly" linked files in the same project is considered
a bit of an ugly practice, and some build tools such as Dune disallow it.q
Thus, to clean up the build, we move the common protocol files to its
own library `ideprotocol`.
This helps towards Dune integration and towards having an IDE
standalone target, such as the one that was implemented here:
https://github.com/ejgallego/coqide-exp
|
|\ \ \ \ |
|
| |/ / /
|/| | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This should hopefully alleviate memory problems on gitlab, by first
building the `lite` targets, and then building the remaining
not-that-big targets.
|
|\ \ \ \
| |/ / /
|/| | |
| | | | |
lib.cma).
|
| | | | |
|
|\ \ \ \
| |/ / /
|/| | | |
|
|\ \ \ \ |
|
|\ \ \ \ \ |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We turn coqtop "plugins" into standalone executables, which will be
installed in `COQBIN` and located using the standard `PATH`
mechanism. Using dynamic linking for `coqtop` customization didn't
make a lot of sense, given that only one of such "plugins" could be
loaded at a time. This cleans up some code and solves two problems:
- `coqtop` needing to locate plugins,
- dependency issues as plugins in `stm` depended on files in `toplevel`.
In order to implement this, we do some minor cleanup of the toplevel
API, making it functional, and implement uniform build rules. In
particular:
- `stm` and `toplevel` have become library-only directories,
- a new directory, `topbin`, contains the new executables,
- 4 new binaries have been introduced, for coqide and the stm.
- we provide a common and cleaned up way to locate toplevels.
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | | |
packaging scripts.
|
|\ \ \ \ \ \ \ |
|
|\ \ \ \ \ \ \ \ |
|
| |_|_|_|_|_|/ /
|/| | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
This process is expected to evolve in the future as we automate it more and more.
[ci skip]
|
| |/ / / / / /
|/| | | | | |
| | | | | | |
| | | | | | | |
We call configure to properly regenerate the Makefile and its dependencies.
|
| | | | | | | |
|
| |_|_|_|/ /
|/| | | | |
| | | | | |
| | | | | | |
This API is a bit strange, I expect it will change at some point.
|
| |_|/ / /
|/| | | | |
|
|\ \ \ \ \ |
|
|\ \ \ \ \ \ |
|
| |/ / / / /
|/| | | | | |
|
|\ \ \ \ \ \ |
|
|\ \ \ \ \ \ \ |
|
| |_|_|_|/ / /
|/| | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
As pointed out by @MSoegtropIMC
[here](https://github.com/coq/coq/pull/7522#issuecomment-389478963)
there are not needed to build the packages, so not building them will
save a couple of minutes.
|
| |_|/ / / /
|/| | | | | |
|
|\ \ \ \ \ \ |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
In the original Travis CI setup, the per-job time limit was an
issue. However, Gitlab has much improved this problem due to
a) Coq not being built for each contrib,
b) user-configurable time limit.
We thus disable the expensive builds from Travis:
`fiat-crypto`, `formal-topology`, `geocoq`, `iris-lambda-rust`,
`math-comp`, `unimath`, `vst`
and instruct Gitlab to build [`geocoq`, `math-comp`, `unimath`, `vst`]
in full.
We also update the `math-comp` script as the `odd-order` theorem lives
in a separate repository and it is a key CI case.
|
|\ \ \ \ \ \ \ |
|
|\ \ \ \ \ \ \ \ |
|
| |_|_|/ / / / /
|/| | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Simpler
|
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Actually there are more general instructions
|
| | |_|/ / / /
| |/| | | | | |
|
|\ \ \ \ \ \ \
| |/ / / / / /
|/| | | | | | |
|
|\ \ \ \ \ \ \ |
|
| |_|_|/ / / /
|/| | | | | | |
|
|\ \ \ \ \ \ \ |
|
|\ \ \ \ \ \ \ \ |
|
|\ \ \ \ \ \ \ \ \ |
|
| |_|_|_|_|/ / / /
|/| | | | | | | | |
|
| | | | | | | | | |
|
| |_|_|_|_|_|/ /
|/| | | | | | | |
|
|\ \ \ \ \ \ \ \
| |_|/ / / / / /
|/| | | | | | | |
|
| | | | | | | | |
|
| |/ / / / / /
|/| | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
We use a specific runner on Inria CloudStack. This allows us to have the
same build infrastructure setup for signed and unsigned binary packages.
The main Coq repository on Gitlab will produce unsigned binaries, using
a runner without secret. On my repository, a one-click operation will
sign the packages, making this part of the release process smoother.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
I followed the code for fiat-crypto / fiat-parsers. I hope I didn't
miss anything.
|
|/ / / / / /
| | | | | |
| | | | | |
| | | | | | |
OpenBSD mktemp fails with an error otherwise.
|
|\ \ \ \ \ \ |
|
| |_|_|_|/ /
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We move syntax for universes from `Misctypes` to `Glob_term`. There is
basically no reason that this type is there instead of the proper
file, as witnessed by the diff.
Unfortunately the change is not compatible due to moving a type to a
higher level in the hierarchy, but we expect few problems.
This change plus the related PR (#6515) moving universe declaration to
their proper place make `Misctypes` into basically an empty file save
for introduction patterns.
|