coq/gramlib/dune, branch master The formal proof system [build] Split stdlib to it's own opam package. 2021-03-03T15:06:14+00:00 Emilio Jesus Gallego Arias 2020-06-22T15:52:18+00:00 ab98d847d237af3cd0e46edef42218be65cfc98f We introduce a new package structure for Coq: - `coq-core`: Coq's OCaml tools code and plugins - `coq-stdlib`: Coq's stdlib [.vo files] - `coq`: meta-package that pulls `coq-{core,stdlib}` This has several advantages, in particular it allows to install Coq without the stdlib which is useful in several scenarios, it also open the door towards a versioning of the stdlib at the package level. The main user-visible change is that Coq's ML development files now live in `$lib/coq-core`, for compatibility in the regular build we install a symlink and support both setups for a while. Note that plugin developers and even `coq_makefile` should actually rely on `ocamlfind` to locate Coq's OCaml libs as to be more robust. There is a transient state where we actually look for both `$coqlib/plugins` and `$coqlib/../coq-core/plugins` as to support the non-ocamlfind plus custom variables. This will be much improved once #13617 is merged (which requires this PR first), then, we will introduce a `coq.boot` library so finally `coqdep`, `coqchk`, etc... can share the same path setup code. IMHO the plan should work fine. 
We introduce a new package structure for Coq:

- `coq-core`: Coq's OCaml tools code and plugins
- `coq-stdlib`: Coq's stdlib [.vo files]
- `coq`: meta-package that pulls `coq-{core,stdlib}`

This has several advantages, in particular it allows to install Coq
without the stdlib which is useful in several scenarios, it also open
the door towards a versioning of the stdlib at the package level.

The main user-visible change is that Coq's ML development files now
live in `$lib/coq-core`, for compatibility in the regular build we
install a symlink and support both setups for a while.

Note that plugin developers and even `coq_makefile` should actually
rely on `ocamlfind` to locate Coq's OCaml libs as to be more robust.

There is a transient state where we actually look for both
`$coqlib/plugins` and `$coqlib/../coq-core/plugins` as to support
the non-ocamlfind plus custom variables.

This will be much improved once #13617 is merged (which requires this
PR first), then, we will introduce a `coq.boot` library so finally
`coqdep`, `coqchk`, etc... can share the same path setup code.

IMHO the plan should work fine.
[gramlib] Remove `Ploc.t` in favor of `Loc.t` 2018-11-30T21:35:05+00:00 Emilio Jesus Gallego Arias 2018-11-24T20:41:22+00:00 0422f7e67c6c87ab364212a267288afcc7313e90 The types are identical and we have no more reason for the split. Note the following TODOS: - discrepancy of `Ploc.after` with `CLexer.after` - discrepancy of `Ploc.comments` with `CLexer.comments` - `Ploc.dummy` vs `Loc.t option` 
The types are identical and we have no more reason for the split. Note
the following TODOS:

- discrepancy of `Ploc.after` with `CLexer.after`
- discrepancy of `Ploc.comments` with `CLexer.comments`
- `Ploc.dummy` vs `Loc.t option`
[gramlib] Wrap `Gramlib`. 2018-10-29T00:25:34+00:00 Emilio Jesus Gallego Arias 2018-10-08T14:09:49+00:00 cd8b8974e2d62a3c3c4d7572921b5a83cbb8642c This introduces a bit of noise in the Dune files but for now I think it is the best way to do it. 
This introduces a bit of noise in the Dune files but for now I think
it is the best way to do it.
[camlp5] Automatic conversion from revised syntax + parsers 2018-10-29T00:25:34+00:00 Emilio Jesus Gallego Arias 2018-10-07T05:01:05+00:00 503fa442869978a9e19e738be990ea8c7534962e `for i in *; do camlp5r pr_o.cmo $i > ../gramlib.auto/$i; done` 
`for i in *; do camlp5r pr_o.cmo $i > ../gramlib.auto/$i; done`