| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
| |
... in favor of having Public/Internal sub modules in each and
every module grouping functions according to their intended client.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Up to this point the `lib` directory contained two different library
archives, `clib.cma` and `lib.cma`, which a rough splitting between
Coq-specific libraries and general-purpose ones.
We know split the directory in two, as to make the distinction clear:
- `clib`: contains libraries that are not Coq specific and implement
common data structures and programming patterns. These libraries
could be eventually replace with external dependencies and the rest
of the code base wouldn't notice much.
- `lib`: contains Coq-specific common libraries in widespread use
along the codebase, but that are not considered part of other
components. Examples are printing, error handling, or flags.
In some cases we have coupling due to utility files depending on Coq
specific flags, however this commit doesn't modify any files, but only
moves them around, further cleanup is welcome, as indeed a few files
in `lib` should likely be placed in `clib`.
Also note that `Deque` is not used ATM.
|
| |
|
|
|
|
|
|
|
|
| |
- In ocamlfind-based byte builds, link the VM statically as in native
builds. This is the best way to get reliable, path-independent
self-contained executables.
- In `make install`, install the `.cmx` files for plugins too. To
statically link Coq plugins in native mode, both the `.cmx` and `.o`
files must be present.
|
| | |
|
| | |
|
| |
|
|
| |
linking chain.
|
| | |
|
| | |
|
| |
|
|
| |
This makes sense for clients willing to link to richpp.
|
| |
|
|
| |
This makes the dll path consistent both in `-local` and non-local Coq install.
|
| | |
|
| | |
|
| | |
|
| | |
|
|
|
This allows building SerAPI and jsCoq using ocamlbuild.
|
Enrico Tassi
Emilio Jesus Gallego Arias
Matej Kosik
Théo Zimmermann