| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
propagated
`dune subst` is broken on unicode files, see
https://github.com/ocaml/dune/pull/3879 and
https://github.com/ocaml/dune/pull/3879
This is a frequent problem, introduced by
https://github.com/coq/coq/pull/13374 , so disabling pending on dune
2.8 being released.
|
|
- closes #12376 : dune version is now consistent as suggested
- cc #12858 : coqide and coqide-server do no depend on ocamlfind
when built this way.
- closes #13372 : more precision in the license identifier
|
|
This is the minimal set of changes requires for Coq to build under 2.0
mode. We may likely take advantage of some more new features.
Note that Dune 2.0 requires OCaml >= 4.06.0, OPAM allows to use Dune
in older versions as it will install a secondary compiler.
|
|
"dev" was not implied, and this can cause the following issues:
--8<---------------cut here---------------start------------->8---
$ docker run --rm -it coqorg/base:latest
coq@…:~$ opam update
coq@…:~$ git clone https://github.com/coq/coq.git
Cloning into 'coq'...
coq@…:~$ cd coq
coq@…:~/coq$ opam pin add -n -k path coq .
[coq.8.10.1] synchronised from file:///home/coq/coq
coq is now pinned to file:///home/coq/coq (version 8.10.1)
# issue 1. opam picks the first version he finds for coq from repos…
coq@…:~/coq$ mv coq.opam foo.opam
coq@…:~/coq$ opam pin add -n -k path foo .
Package foo does not exist, create as a NEW package? [Y/n] y
[foo.~dev] synchronised from file:///home/coq/coq
foo is now pinned to file:///home/coq/coq (version ~dev)
# issue 2. if none is found, opam sticks to some "~dev" version…
--8<---------------cut here---------------end--------------->8---
|
|
We use the `(coq.pp ...)` dune directive which will produce correct
error messages for `.mlg` files.
Unfortunately we cannot yet use the automatic opam generation features
of Dune 1.10, as this does require a fully native Dune build.
Dune 1.6-1.10 has quite a few other improvements that could be used by
Coq, for example for promote modes.
I have fixed a couple of documentation issues. `Drop` and `ocamldebug`
have been tested in this version.
|
|
I copied this from Ralf Jung's submission to the Coq Package index,
let's see if it works.
|
|
- Update Docker images to install compatible version of lablgtk3
- We remove unnecesary variables from configure.
- We fix path detection of GTK libs in makefile
|
|
|
|
We need to update in Docker:
- dune to 1.4.0: as it honors `-p` on test stanzas
- dune-release to 1.1.0: support for OPAM 2.0 + fixes
This makes `dune-release distrib` / `dune-release opam pkg` work.
TODO: we need to figure out what is going on with the
versioning. Should we do `dune subst` on `pinned`?
|
|
Even if `fake_ide` was under tools, it depended on libraries from
`ide`. Thus, we move `fake_ide` to `ide`, and make it "private" to the
test-suite [this means `test-suite` depends on the `ide` folder then].
In the Dune side, we reorganize libraries so `fake_ide` doesn't depend
on GTK anymore, this allows to run the test-suite when GTK is not
available.
In order to achieve this, we had to split the `coqide` package in a
server and client version.
|
|
After some discussion upstream, I think that for the current a
multi-package setup in a single repository this setup saves a bit
work.
The most problematic bit is the `-rectypes` flag; its status is not
saved per-library so we must either duplicate the flags in the coqide
scope (scope == dune-project file), or unify its scope with Coq. We do
this last option as this seems like the easiest thing for now.
Changes:
- Move coqide.opam file to the root, use a single scope/`dune-project` file.
- Remove `dune-workspace`, this should be owned by the developer / user.
|
