| Age | Commit message (Collapse) | Author |
|---|
|
|
|
"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---
|
|
I copied this from Ralf Jung's submission to the Coq Package index,
let's see if it works.
|
|
This is a reduced version of #8503 as to provide a way to build the
reference manual with Dune.
Dune 1.6 supports (experimentally) directories as targets, thus we
introduce a rule that will call `sphinx` to build the manual.
This only provides build, however generation of `.install` rules is
not done, it will be hopefully addressed in #8503.
Note that we set `expire: 1 month` for all the artifacts we build with
Dune. IMHO this makes most sense as not to abuse Gitlab's hosting,
however of course we could consider a different deployment strategy if
wanted.
|
