Ekdohibs
/
ocaml
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

HACKING.adoc: using dune to get merlin's support (#9468) 

Co-authored-by: Gabriel Scherer <gabriel.scherer@gmail.com>
master
Thomas Refis 2020-06-25 14:11:21 +02:00 committed by GitHub
parent 1f9be49f02
commit 2d3bc0eb22
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 48 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Changes
View File

@ -147,6 +147,8 @@ Working version
### Manual and documentation:
- #9468: HACKING.adoc: using dune to get merlin's support
(Thomas Refis, review by Gabriel Scherer)
### Compiler user-interface and warnings:

46
HACKING.adoc
View File

@ -304,6 +304,52 @@ If `boot/ocamlc` changes (e.g. because you ran `make bootstrap`), then
the build will revert to the slower bytecode-compiled `ocamlc` until
you do the above step again.
=== Using merlin
During the development of the compiler, the internal format of compiled object
files evolves, and quickly becomes incompatible with the format of the last
OCaml release. In particular, even an up-to-date merlin will be unable to use
them during most of the development cycle: opening a compiler source file with
merlin gives a frustrating error message.
To use merlin on the compiler, you want to build the compiler with an older
version of itself. One easy way to do this is to use the experimental build
rules for Dune, which are distributed with the compiler (with no guarantees that
the build will work all the time). Assuming you already have a recent OCaml
version installed with merlin and dune, you can just run the following from the
compiler sources:
----
./configure # if not already done
make clean && dune build @libs
----
which will do a bytecode build of all the distribution (without linking
the executables), using your OCaml compiler, and generate a .merlin
file.
Merlin will be looking at the artefacts generated by dune (in `_build`), rather
than trying to open the incompatible artefacts produced by a Makefile build. In
particular, you need to repeat the dune build everytime you change the interface
of some compilation unit, so that merlin is aware of the new interface.
You only need to run `configure` once, but you will need to run `make clean`
everytime you want to run `dune` after you built something with `make`;
otherwise dune will complain that build artefacts are present among the sources.
Finally, there will be times where the compiler simply cannot be built with an
older version of itself. One example of this is when a new primitive is added to
the runtime, and then used in the standard library straightaway, since the rest
of the compiler requires the `stdlib` library to build, nothing can be build. In
such situations, you will have to either live without merlin, or develop on an
older branch of the compiler, for example the maintenance branch of the last
released version. Developing a patch from a release branch can later introduce a
substantial amount of extra work, when you rebase to the current development
version. But it also makes it a lot easier to test the impact of your work on
third-party code, by installing a local <<opam-switch,opam switch>>: opam
packages tend to be compatible with released versions of the compiler, whereas
most packages are incompatible with the in-progress development version.
=== Continuous integration
==== Github's CI: Travis and AppVeyor