1

I need to use a library in GitHub different from Coq's standard library. But I do not know how to manually set it up so that I can use it in CoqIDE.

I need to use this library in CoqIDE. I have downloaded and saved the folder to my computer, but when I open CoqIDE and write "Require Import StringEq", where StringEq is the name of a Coq file from the library, I get the error message "Unable to locate library StringEq".

Is there any way I can manually set up this libray so that I can use it with CoqIDE? (There are no instructions on the READme file on the library's GitHub page.)

LyX2394
  • 121
  • 1
  • 5

1 Answers1

2

The official usage seems to be add kami to the $COQPATH environment variable.

On Linux, add this line to .bashrc or .zshrc or whatever initialization your shell uses and restart your shell:

export COQPATH=/path/to/kami:$COQPATH
# That path must be so that `/path/to/kami/Kami/Lib/StringEq.v` is the path to `StringEq` for example

Below is another way I am using.
It doesn't seem like intended usage. Maybe I'm just resistant to changing my ways, but I also prefer being explicit about my dependencies, and I'm not sure the COQPATH environment variable makes it as easy to have different versions of the same library in different projects.

Add a _CoqProject that tells CoqIDE where to find kami.

Here's an example layout:

kami/           # The Kami repository
myproject/      # Your workspace
  _CoqProject
  theories/
    MyProject.v

Where myproject/_CoqProject contains:

-Q ../kami/Kami Kami
# and possibly other options

Either way, remember to build Kami:

cd kami/
make
Li-yao Xia
  • 31,896
  • 2
  • 33
  • 56
  • 1
    I was told that the dependencies were not supposed to be listed in the _CoqProject file, but instead chosen using the COQPATH environment variable (see [this discussion](https://github.com/coq/coq/issues/4990#issuecomment-344672293) or [this post](https://coq.discourse.group/t/proposal-a-custom-build-tool-for-coq-projects/239/6)). – eponier Aug 19 '19 at 09:55
  • Oh, that's interesting. Thanks, I'll make a new answer! – Li-yao Xia Aug 19 '19 at 11:13
  • Actually I'm stuck at explaining where to put the `export COQPATH` line (because nobody wants to have to fix COQPATH everyday), there seems to be quite some variety depending on your shell (`.bashrc`? `.zshrc`?) or OS (Windows?). – Li-yao Xia Aug 19 '19 at 11:41
  • So I can't explain this workflow without it becoming a tutorial on how to manage your environment variables, which I believe is going to be lost on most new users anyway. I may be missing something obvious. The inconvenience is compounded by the fact that some existing libraries do not follow the right structure for this: they put their files in `theories/` or `src/`. This could arguably be considered a bug in those libs, but it is not quite clear to me that this envvar-based workflow is best in the first place. So I'll give this task up to someone more knowledgeable. – Li-yao Xia Aug 19 '19 at 11:56
  • 1
    Maybe the simplest answer is then to install the dependency in the `user-contrib`sub-directory of the Coq installation that is always in the Coq path. This is done by the `install` target of the Makefile generated by `coq_makefile`. This can be seen as polluting your system, though. – eponier Aug 19 '19 at 13:22
  • I added a `$COQPATH` solution to my answer. Let's hope that will just work for OP and other people, or it will encourage improvements to documentation and tooling. I feel like it merely hides a very deep rabbit hole but I could also be overthinking this. – Li-yao Xia Aug 19 '19 at 13:58