Alice the Caml

Alice v0.5.0

2026-02-25T00:00:00+00:00

Announcing the release of Alice v0.5.0</a>!</p>

This change introduces parallel builds</a> of packages.</p>

On all platforms that support opam</a>, install Alice v0.5.0 with:</p>

opam update </span>&& </span>opam install alice.0.5.0
</span></code></pre>
</div>
On Windows, Alice v0.5.0 can be installed with WinGet</a>:</p>

winget install OCaml.Alice --version 0.5.0
</span></code></pre>
</div>
On macOS and Linux, the latest version of Alice can be installed with Homebrew</a>:</p>

brew install alicecaml/homebrew-tap/alice
</span></code></pre>
</div>
Alternatively, on macOS and Linux, Alice v0.5.0 can be installed by running the install script</a>:</p>

curl -fsSL https://alicecaml.org/install.sh </span>| </span>sh -s</span> --</span> 0.5.0
</span></code></pre>
</div>
On NixOS, Alice v0.5.0 can be installed via the flake
github:alicecaml/alice#alice_0_5_0.default</code>, e.g.:</p>

nix shell github:alicecaml/alice#alice_0_5_0.default
</span></code></pre>
</div>
Read more about installing Alice here</a>.</p>
Release Notes</a></h2>
Changed</a></h3>

Parallel builds</li>
</ul>



Parallel Alice without Eio
2026-02-25T00:00:00+00:00
In my previous post</a> I wrote about adding
support for parallel builds to Alice using concurrency primitives from the
Eio</a> library.
Eio doesn’t support spawning processes on Windows, and depending on Eio meant
that I could no longer build Alice on Windows using Dune package management,
which complicated development and CI workflows.
It’s important to me that Windows users aren’t treated as second-class citizens,
so I’ve dropped Eio as a dependency and implemented some parallel subprocess
management logic directly in Alice.</p>
As described in my previous post there are two places in Alice where it runs a
lot of external processes: computing inter-file dependencies with ocamldep</code> and
compiling OCaml code with ocamlopt</code>.</p>
Computing dependencies is embarrassingly parallel. The ocamldep</code> program needs
to be run on each source file in the project, and the order doesn’t matter.
We need to make sure the number of simultaneously running processes doesn’t
exceed the maximum number of jobs (the argument to -j</code>), and the standard
output of each process needs to be collected and parsed so Alice can find out
inter-file dependencies. The strategy will be to start as many processes as is
permitted by the maximum number of jobs, and then whenever a process completes,
start a new process in its place.</p>
To check if a process has completed, the standard library has a function:</p>
val </span>waitpid : </span>wait_flag list </span>-> </span>int </span>-> </span>int * process_status
</span></code></pre>
Passing WNOHANG</code> in the list of wait_flag</code>s causes the function to return
immediately with a (non-existent) pid of 0 if the process is still running.
Alice needs to monitor the status of multiple concurrent processes so it can’t
block until any specific process completes. It spins in a loop, continuously
checking the status of all running processes, with a short pause in between each
iteration via Unix.sleepf</code> so your computer doesn’t get too hot.</p>
Actively polling the status of each running process in a loop feels a bit
inefficient, and the standard library does provide an alternative way to wait
until any child process completes:</p>
  </span>val </span>wait : </span>unit </span>-> </span>int * process_status
</span>  </span>(** Wait until one of the children processes die, and return its pid
</span>     and termination status.
</span>
</span>     @raise Invalid_argument on Windows. Use {!waitpid} instead. *)
</span></code></pre>
But unfortunately it’s not available on Windows, so actively polling will have
to do.</p>
To parallelize computing dependencies I implemented the above strategy for
scheduling processes, and refactored the logic around it to compute all
dependencies as a single batch. This is less ergonomic than using Eio since I
can no longer write straight-line code and mostly pretend it’s synchronous.</p>
Next I parallelized compiling OCaml code. This was more complicated because
invocations of the compiler are constrained by a partial order, with some
commands needing to have completed before others can start. Alice
computes a DAG representing the build plan which exactly captures these
relationships between commands already, and this DAG can be used to schedule
processes in a correct order.</p>
The strategy will be similar to computing dependencies, except we need to be
careful to only start processes when they’re ready. Each node in the DAG
represents a command for which a process will be spawned. Initially just the
leaves of the DAG (the nodes with no children) can be started. When a process
completes, check each of its parents to see if any of them are now ready to
start. Add all the ready parents to a “ready” queue, and start as many processes
from this queue as are allowed by the user-specified maximum number of jobs.</p>
The main difficulty was due to technical debt. My DAG implementation didn’t have
a way to access tho parents of a node, and initially each node in the build plan
represented a file to be built rather than a command. Nodes knew
the command that would create their file, but since commands can generate
multiple files, commands were effectively duplicated between multiple nodes (all
the nodes whose files the command would create). When scheduling processes it’s
much easier to think of nodes as commands, and not duplicate commands, so it was
DAG-refactoring o’clock which meant updating the logic for generating build
plans and dependency graphs which share the same underlying DAG representation
despite being unrelated to the work I set out to do parallelizing Alice.</p>
Now that parallel Alice works on Windows I can add an additional set of
benchmarks to the comparison with
Dune</a> from my previous post.</p>
</p>


Parallel Alice
2026-02-01T00:00:00+00:00
</p>
I added support for parallel builds to the Alice build system.</p>
Alice runs external commands to build OCaml projects.
While computing the build plan it runs the OCaml compiler to
determine dependencies between object files, and then of course
while executing the build plan it runs the compiler to compile OCaml code.
Many invocations of the compiler are independent from one another
presenting an opportunity to do them in parallel.</p>
I used the library eio</a> which contains
effects-based IO and concurrency primitives. All the concurrent OCaml I’ve written
until now used a concurrency monad (e.g. lwt</a>),
but doing so requires threading monadic control flow throughout the code.
A useful property of effects is that any function can “perform” an effect without
changing its type signature, as long as an appropriate effect handler is installed.
You can write straight-line synchronous-looking code, but when it does IO, instead of
blocking the thread, it performs (raises sort of) an effect to the effect handler.
In the case of eio, the handler runs the IO operation asynchronously and schedules
other OCaml code or IO to run at the same time. When the IO completes, the original
function is resumed with the result of the IO.</p>
Here’s an example. This is the signature for the Eio.Fiber.pair</code> functions which runs
a pair of “fibers” concurrently, returning both of their results. In eio a fiber is
just a function that may perform effects which are handled by eio’s effect handler.</p>
val </span>pair : (</span>unit </span>-> </span>'a</span>) -> (</span>unit </span>-> </span>'b</span>) -> </span>'a * 'b
</span></code></pre>
Contrast this with lwt, which uses monadic concurrency. Here’s the signature of Lwt.both</code>:</p>
val </span>both : </span>'a t </span>-> </span>'b t </span>-> (</span>'a * 'b</span>) </span>t
</span></code></pre>
Here the type constructor 'a t</code> is a promise that resolves to a value of type 'a</code>.
In code written with monadic concurrency it’s common for most functions to return
a _ t</code>, since if one function calls a second function that returns a _ t</code>, the only
way to make the types work out will often be for that first function to also return a _ t</code>,
and thus the type constructor spreads throughout the code.</p>
The strategy for introducing parallel builds into Alice will be to use eio to run external
commands in parallel, but continue using a single OCaml thread (technically a single domain</em>).
There are two different points in the build process where parallelism will be introduced:</p>

running ocamldep</code> to determine dependencies between object files</li>
running the compiler to compile the code</li>
</ul>
Determining Dependencies between Object Files</a></h2>
An OCaml source file can only be compiled into an object file if all the modules
it refers to have already been compiled. There’s a partial order on the source files
of a project that requires certain files be built before certain other files.
The OCaml toolchain contains a tool ocamldep</code> which prints the dependencies of a given
source file, and Alice runs this program for each source file in the project to construct
the build plan.</p>
This step is trivial to parallelise since ocamldep</code> can be run on files in any
order without affecting the results.</p>
The first step was wrapping the build process in a call to Eio_main.run</code> which installs
an effect handler. To spawn processes with eio we need a “process manager” which is part
of the eio environment.</p>
  Eio_main.run (</span>fun </span>env ->
</span>    </span>let </span>proc_mgr </span>= </span>Eio.Stdenv.process_mgr env </span>in
</span>    </span>(* ... build the project *)
</span>  )
</span></code></pre>
Next I changed the logic for running ocamldep</code> from calling Unix.create_process</code>
to Eio.Process.parse_out</code>. There’s a function in Alice called Ocamldep_cache.get_deps</code>
which tries to load a cached ocamldep</code> result for a given file, and runs ocamldep</code>
if it’s not found in the cache. This function is just called in a loop over every source
file in the project, and in eio concurrency parlance we can now think of this function as
a fiber which can be run concurrently with other fibers.</p>
So now just run all the fibers concurrently and collect their results using a helper function
from Eio.Fiber</code>. There’s Eio.Fiber.all</code>:</p>
val </span>all : (</span>unit </span>-> </span>unit</span>) </span>list </span>-> </span>unit
</span></code></pre>
But that won’t work because my fibers compute results.
Unless I missed something there’s no built-in way to run a list of fibers and return
a list of their results.
I could have used Eio.Fiber.all</code> to run a fiber that populates a ref</code> cell with the output
of ocamldep</code> for each source file but that seemed messy. Instead in the end I implemented my own
all_values</code> function based on Eio.Fiber.pair</code>.</p>
let rec </span>all_values </span>fs </span>=
</span>  </span>match</span> fs </span>with
</span>  </span>| </span>[] </span>-> </span>[]
</span>  </span>| </span>[ x ] -> [ x </span>() </span>]
</span>  </span>| </span>[ a; b ] ->
</span>    </span>let</span> a, b </span>= </span>Eio.Fiber.pair a b </span>in
</span>    [ a; b ]
</span>  </span>| </span>x :: xs ->
</span>    </span>let</span> x, xs </span>= </span>Eio.Fiber.pair x (</span>fun </span>() -> all_values xs) </span>in
</span>    x :: xs
</span></code></pre>
I’m really curious if I missed something or if there’s a reason for not using fibers like this.</p>
Compiling OCaml Code</a></h2>
Alice has some logic for scheduling calls to the compiler so that files are compiled
in an order that satisfies the dependencies between files as determined by ocamldep</code>.
When parallelizing calls to the compiler we need to make sure that they still satisfy
the dependencies. My strategy is to think of each call to the compiler as a fiber, and have
each fiber keep track of the other fibers that must complete before it can start.
Concretely, use a condition variable per file, and when a call to the compiler completes it
broadcasts on the condition variables of each file it just created. Before any given call
to the compiler, first wait on the condition variable of each file that must exist before
that particular call to the compiler.</p>
Alice’s logic for evaluating build plans originally interspersed running the
compiler with traversing the build plan. To parallelize calls to the compiler, I changed it
to produce a list of fibers with the above logic for waiting and broadcasting on
per-file condition variables. Finally I just ran all the fibers concurrently with Eio.Fiber.all</code>
(this time my fibers don’t return a value).</p>
Limited Parallelism with -j</code></a></h2>
When -j <number></code> is passed to alice build</code> and friends, Alice uses a global semaphore
to limit the number of parallel calls to the compiler.</p>
Windows Complications</a></h2>
Alice uses Dune’s package management features to manage its dependencies for local
development and when running tests in CI. It’s a little known fact that Dune package
management mostly works on Windows as long as your entire dependency closure builds with Dune
and you use ocaml-system</code> as your compiler. Alice ticked all these boxes so developing
it on Windows was possible with Dune package management. Unfortunately, eio depends on
some packages that don’t build with Dune.</p>
Initially I tried to work around the problem by manually modifying the
lockfiles using some
tricks</a>
I learnt while getting Alice’s dev tools working on Windows.
This actually worked fine for local development, but I started running into issues in CI
that I couldn’t reproduce locally, and it took 15 minutes to run CI so the try/fail loop
would be painfully long.</p>
File "dune.lock/topkg.1.1.1.pkg", line 7, characters 5-7:
</span>7 |      sh
</span>         ^^
</span>Error: Logs for package topkg
</span>ocamlfind: Package `threads' not found
</span>Warning: WARNING] OCaml host-os conf:  cmd ["ocamlfind" "ocamlc" "-config"]: exited with 2
</span>Warning: WARNING] OCaml host-os conf: key native: undefined, stdlib dir not found for discovery
</span>                  using false
</span>Warning: WARNING] OCaml host-os conf: key natdynlink: undefined, stdlib dir not found for discovery
</span>                  using false
</span>Warning: WARNING] OCaml host-os conf: key supports_shared_libraries: undefined, stdlib dir not found for discovery
</span>                  using false
</span>Warning: WARNING] OCaml host-os conf: key ext_obj: undefined, using ".o"
</span>Warning: WARNING] OCaml host-os conf: key ext_lib: undefined, using ".a"
</span>Warning: WARNING] OCaml host-os conf: key ext_dll: undefined, using ".so"
</span>Warning: WARNING] OCaml host-os conf: key ext_exe: undefined and
</span>                  no C toolchain detected, using ""
</span>ocamlfind: Package `threads' not found
</span>ocamlfind: Package `threads' not found
</span>Error: : The library directory where ocamlbuild was originally installed (D:\a\alice\alice\_build/.sandbox/1e137b948d479f5e3d8239d05c7f7865/_private/default/.pkg/ocamlbuild/target/lib\ocamlbuild) either no longer exists, or does not contain a copy of the ocamlbuild library. Guessing that the correct library directory is D:\a\alice\alice\_build\_private\default\.pkg\ocamlbuild\target\lib\ocamlbuild because a copy of the ocamlbuild library exists at that location, and because it is located at the expected path relative to the current ocamlbuild executable. This can happen if ocamlbuild's files are moved from the location where they were originally installed.pkg.ml: [ERROR] cmd ["ocamlbuild" "-use-ocamlfind" "-classic-display" "-j" "4" "-tag" "debug"
</span>     "-build-dir" "_build" "pkg.otarget"]: exited with 2
</span>
</span>Error: Process completed with exit code 1.
</span></code></pre>
Getting to this point required manual changes to lockdirs, forking and patching
both ocamlfind</code> and dune</code> itself. So I admitted defeat and concede that Dune
package management doesn’t work on Windows yet, and switched to opam for local
development of Alice and CI on Windows which mostly works, except that now when
I run tests I get this error:</p>
Fatal error: exception Failure("process operations not supported on Windows yet")
</span></code></pre>
This is an error from eio stating that support for managing processes isn’t
implemented on Windows.
So for now Alice on Windows doesn’t support parallel builds and falls back to
blocking process management. I might revisit this in the future or experiment
with using lwt instead.</p>
Benchmarks</a></h2>
For these experiments I built the library climate</a>
with both Alice and Dune with different levels of parallelism by passing different values
to the -j</code> argument of their respective build commands. The comparison isn’t a perfectly
apples-to-apples comparison since I couldn’t figure out how to prevent Dune from
building bytecode object files (in addition to native object files) whereas Alice only
compiles code natively. The comparison is to show that Alice and Dune are in the same
ballpark, not that one tool meaningfully outperforms the other.</p>
Each benchmark was performed 32 times, and the means are plotted with
the standard deviation indicated with error bars.</p>
To build the package with Dune I used the command dune build -p climate</code> rather than simply
dune build</code> as the former was consistently faster.</p>


</p>
Next Steps</a></h2>
This post covered parallelising the builds of individual files within a single
Alice package, but I’m yet to allow building multiple packages in parallel.
There’s also more IO which Alice performs, mostly related to generating and copying
files, which could possibly be parallelised.</p>
</p>


Alice v0.4.0
2026-01-05T00:00:00+00:00
Announcing the release of Alice v0.4.0</a>!</p>
The main change in this version is switching the manifest format from TOML to KDL</a>.
Read this page</a> for the reasoning
behind this change.</p>
Migrating from earlier versions</a></h2>
This example demonstrates how all the features of package manifests are
represented in the old TOML format and the new KDL format.</p>
Alice.toml</code>:</p>
[package]
</span>name </span>= </span>"foo"
</span>version </span>= </span>"0.1.0"
</span>
</span>[dependencies]
</span>bar </span>= { </span>path </span>= </span>"../bar" </span>}
</span>baz </span>= { </span>path </span>= </span>"../baz" </span>}
</span></code></pre>
Alice.kdl</code>:</p>
package </span>{
</span>  </span>name </span>foo
</span>  </span>version </span>"0.1.0"
</span>  </span>dependencies </span>{
</span>    </span>bar </span>path=</span>"../bar"
</span>    </span>baz </span>path=</span>"../baz"
</span>  }
</span>}
</span></code></pre>
Install Alice v0.4.0</a></h2>
On all platforms that support opam</a>, install Alice v0.4.0 with:</p>

opam update </span>&& </span>opam install alice.0.4.0
</span></code></pre>
</div>
On Windows, Alice v0.4.0 can be installed with WinGet</a>:</p>

winget install OCaml.Alice --version 0.4.0
</span></code></pre>
</div>
On macOS and Linux, the latest version of Alice can be installed with Homebrew</a>:</p>

brew install alicecaml/homebrew-tap/alice
</span></code></pre>
</div>
Alternatively, on macOS and Linux, Alice v0.4.0 can be installed by running the install script</a>:</p>

curl -fsSL https://alicecaml.org/install.sh </span>| </span>sh -s</span> --</span> 0.4.0
</span></code></pre>
</div>
On NixOS, Alice v0.4.0 can be installed via the flake
github:alicecaml/alice#alice_0_4_0.default</code>, e.g.:</p>

nix shell github:alicecaml/alice#alice_0_4_0.default
</span></code></pre>
</div>
Read more about installing Alice here</a>.</p>
Release Notes</a></h2>
Changed</a></h3>

Use kdl</a> rather than toml for manifests. More info here</a>.</li>
</ul>
Fixed</a></h3>

Replace panics with user exceptions in some cases</li>
Detect case when the name of a dependency doesn’t match the name of the specified package</li>
</ul>


Switching Manifests to KDL
2026-01-01T00:00:00+00:00
Starting with the upcoming release of Alice v0.4.0, package manifests will change from TOML to
KDL</a>. The main reason is to avoid issues with nesting tables.</p>
Manifests are currently very simple but as Alice gains more features the
manifest format will need to be extended, and I don’t want the syntactic
difficulty of nesting tables in TOML to get in the way. There’s already an
example of this in the TOML manifest format:</p>
[package]
</span>name </span>= </span>"foo"
</span>version </span>= </span>"0.1.0"
</span>
</span>[dependencies]
</span>bar </span>= { </span>path </span>= </span>"../bar" </span>}
</span>baz </span>= { </span>path </span>= </span>"../baz" </span>}
</span></code></pre>
Note how the “dependencies” table isn’t actually inside the “package” table, but
rather they are adjacent in the document hierarchy. I implemented it this way
initially because I wanted to quickly get something working, and when in doubt
about UX I just copied whatever cargo does because I generally like its UX.</p>
However this metadata format doesn’t capture the fact that dependencies are part of</em> a package.</p>
This fact is reflected in Alice’s implementation of packages:</p>
type t </span>=
</span>  { id : Package_id</span>.t
</span>    </span>(** The name and version of the package. *)
</span>  </span>; </span>dependencies : Dependencies</span>.t option
</span>    </span>(** This is an [_ option] so that a manifest with an empty dependencies
</span>        list and a manifest with no dependencies list can both round trip via
</span>        this type. *)
</span>  }
</span></code></pre>
And ideally it would also be reflected in package metadata, which means writing
something like:</p>
[package]
</span>name </span>= </span>"foo"
</span>version </span>= </span>"0.1.0"
</span>
</span>[package.dependencies]
</span>bar </span>= { </span>path </span>= </span>"../bar" </span>}
</span>baz </span>= { </span>path </span>= </span>"../baz" </span>}
</span></code></pre>
…but I don’t like that because it repeats the word “package”.</p>
I believe that a tool’s UI should teach users how to think about the tool,
and so the representation of a package’s metadata in its manifest should
reflect a working mental model of packages. A package has</em> dependencies just
like it has</em> a name and version. The representation of dependencies in package
metadata should be inside</em> the package instead of next to it.</p>
Considering alternative popular formats, I find that XML is too verbose, JSON
requires quotes on keys and some versions don’t support trailing commas or
comments, and I always make mistakes with indentation when writing YAML. TOML was still the best
option I was aware of, especially considering I expect users to modify these
files manually.</p>
Then somebody on the OCaml forum suggested trying out KDL and I really like it.
Package metadata would look like:</p>
package </span>{
</span>  </span>name </span>foo
</span>  </span>version </span>"0.1.0"
</span>  </span>dependencies </span>{
</span>    </span>bar </span>path=</span>"../bar"
</span>    </span>baz </span>path=</span>"../baz"
</span>  }
</span>}
</span></code></pre>
I like this because the structure of the metadata matches the intuition for what a package is; dependencies are part of</em> a package.</p>
KDL also lets us avoid writing bar = { path = "../bar" }</code> when describing a dependency, which I find a little
awkward because of the two =</code> appearing on that line. KDL distinguishes between nodes</em> and properties</em>.
The entire dependency description bar path="../bar"</code> is a node named “bar”, and path="../bar"</code> is a
property of that node. You only need to write =</code> when assigning values to properties, and not when defining nodes.</p>
There are some other nice properties of KDL, such as “slashdash comments” which
allow commenting-out entire nodes, which I expect to come in handy when
manually editing package metadata during debugging and development.</p>
Fortunately Alice is still simple enough that migrating existing manifests from TOML to KDL is easy.
The example manifest on this page showcases the entire manifest syntax so should serve as a migration guide.</p>


Alice v0.3.0
2025-12-30T00:00:00+00:00
Announcing the release of Alice v0.3.0</a>!</p>
This release starts following the XDG Base Directory Specification</a>.
This means there is no longer a ~/.alice</code> directory. Tools are installed to ~/.local/share/alice/current/bin</code>, and Alice’s executable
is installed to ~/.local/bin</code> if using the install script.</p>
This is a breaking change.</p>
Migrating from earlier versions</a></h2>

Delete ~/.alice</code>.</li>
If you have a block in your shell config starting with # BEGIN configuration from Alice installer</code>, remove that block.</li>
If you installed Alice with the installation script then run the script again.</li>
If you used Alice to install OCaml tools, you’ll need to reinstall those tools (run alice tools install</code>).</li>
If you’ve configured a custom sandbox template with Visual Studio Code for any Alice projects,
change the template based on the new LSP instructions for Visual Studio Code here</a>.</li>
</ul>
Install Alice v0.3.0</a></h2>
On all platforms that support Opam</a>, install Alice v0.3.0 with:</p>

opam update </span>&& </span>opam install alice.0.3.0
</span></code></pre>
</div>
On Windows, Alice v0.3.0 can be installed with WinGet</a>:</p>

winget install OCaml.Alice --version 0.3.0
</span></code></pre>
</div>
On macOS and Linux, the latest version of Alice can be installed with Homebrew</a>:</p>

brew install alicecaml/homebrew-tap/alice
</span></code></pre>
</div>
Alternatively, on macOS and Linux, Alice v0.3.0 can be installed by running the install script</a>:</p>

curl -fsSL https://alicecaml.org/install.sh </span>| </span>sh -s</span> --</span> 0.3.0
</span></code></pre>
</div>
On NixOS, Alice v0.3.0 can be installed via the flake
github:alicecaml/alice/0.3.0</code>, e.g.:</p>

nix shell github:alicecaml/alice/0.3.0
</span></code></pre>
</div>
Read more about installing Alice here</a>.</p>
Release Notes</a></h2>
Changed</a></h3>

Follow the XDG convention when installing tools.</li>
</ul>
Fixed</a></h3>

Update dot-merlin-reader on windows to fix crash on launch.</li>
Fix issue running alice tools exec</code> on windows in CMD.exe.</li>
</ul>


Alice v0.2.0
2025-12-01T00:00:00+00:00
Announcing the release of Alice v0.2.0</a>!</p>
This release adds support for LSP by generating .cmt files in the build directory and a .merlin file at the project’s root,
as well as adding an additional development tool dot-merlin-reader</code> which is
necessary for using ocamllsp</code> in non-Dune projects. There’s a new LSP</a> page on
this site with instructions for setting up your environment and editor to use LSP in Alice projects.</p>
Install Alice v0.2.0</a></h2>
On all platforms that support Opam</a>, install Alice v0.2.0 with:</p>

opam update </span>&& </span>opam install alice.0.2.0
</span></code></pre>
</div>
On Windows, Alice v0.2.0 can be installed with WinGet</a>:</p>

winget install OCaml.Alice --version 0.2.0
</span></code></pre>
</div>
On macOS and Linux, the latest version of Alice can be installed with Homebrew</a>:</p>

brew install alicecaml/homebrew-tap/alice
</span></code></pre>
</div>
Alternatively, on macOS and Linux, Alice v0.2.0 can be installed by running the install script</a>:</p>

curl -fsSL https://alicecaml.org/install.sh </span>| </span>sh -s</span> --</span> 0.2.0
</span></code></pre>
</div>
On NixOS, Alice v0.2.0 can be installed via the flake
github:alicecaml/alice/0.2.0</code>, e.g.:</p>

nix shell github:alicecaml/alice/0.2.0
</span></code></pre>
</div>
Read more about installing Alice here</a>.</p>
Release Notes</a></h2>
Added</a></h3>

Generate files necessary to support ocamllsp.</li>
</ul>
Changed</a></h3>

Switch to github for hosting tool archives.</li>
Display progress bar while downloading tools.</li>
</ul>


Alice v0.1.3
2025-11-28T00:00:00+00:00
Announcing the release of
Alice v0.1.3</a>.
This is a patch release though it
doesn’t make any visible changes. The purpose of the release is to add a
patch</a>
which replaces the OCaml compiler version number in all lockfiles with a template
placeholder. This makes it possible to change the version of the compiler that
Dune expects to see in the environment when building the project. This is
simplifies packaging Alice for Homebrew, and possibly for other package managers
in the future.</p>
Alice builds with Dune Package Management, however Dune (by way of it using
Opam’s packaging conventions) requires that the OCaml compiler either be built
as a dependency of the project or be installed system-wide with that compiler’s
version stored in the lock directory. The first option is not desirable as it
would make Alice very slow to install, since compiling the OCaml compiler can
take a long time. The second option isn’t possible in Homebrew, since the
ocaml</code> package will be updated independently of Alice, meaning that whatever
compiler version the project is configured to expect, it will see an unexpected
version each time the ocaml</code> package is update</p>
Alice’s Homebrew
formula</a>
uses a hybrid of both approaches. Its lock directory expects a compiler to be
installed system-wide of some arbitrary version, and before compilation the
install script replaces this version with whatever version of the OCaml compiler
brew decided to install as a dependency of Alice. This way Alice’s Homebrew package can
be installed relatively quickly and will continue to work as the OCaml compiler
in Homebrew’s repository gets updated.</p>
For all Alice’s other dependencies
(besides the compiler), Dune installs them with its internal package management
mechanism. A potential alternative to this would be to rely entirely on Homebrew
to install Alice’s dependencies. This is how Alice’s Opam and Nix packages work -
rely on the foreign (i.e. non-Dune) package manager to do all</em> the package
management. Currently this isn’t an option for Homebrew because most of the
OCaml libraries it uses aren’t in Homebrew’s repository.</p>
Install Alice with Homebrew by running:</p>

brew install alicecaml/homebrew-tap/alice
</span></code></pre>
</div>
Release Notes</a></h2>
Added</a></h3>

Add a patch that replaces the locked compiler version with a template string to simplify packaging</li>
</ul>


Buzz
2025-11-27T00:00:00+00:00
People are talking about Alice online.</p>
Here</a>’s
my announcement post on the OCaml discuss forum where the project received a
fair amount of praise as well as some helpful feedback.</p>
The project has almost 100 Github stars (98 at the time of writing). I’d been
checking the number of stars each day because one of Homebrew’s
requirements</a> for acceptable
packages in homebrew-core</code> is “notability”, which can be measured in stars,
and you need 75. Another requirement is someone other than me has to use the
project which I don’t qualify for yet. As far as I know there’s a
single</a> Alice package out there, and it’s
mine.</p>
One day the number of stars shot up by about 15 which surprised me until I
tracked down this
post</a> on Lobsters.
I love when someone else posts about one of my projects. It’s happened with
Alice several times now but this is the only one to generate any discussion.</p>
Homebrew may not allow niche projects into their core repository but
WinGet</a> -
the inbuilt CLI package manager for Windows - has no such requirement.
I just published an Alice package to WinGet’s repo, and now Windows users can install Alice by running:</p>

winget install OCaml.Alice
</span></code></pre>
</div>


Alice v0.1.2
2025-11-25T00:00:00+00:00
Announcing the release of Alice v0.1.2. This is a patch release though it
doesn’t make any visible changes. The purpose of the release is to add a zip
archive containing the Windows
executable</a>.
This is intended to make it possible to release Alice on the WinGet package
manager.</p>
Release Notes</a></h2>
Added</a></h3>

Release a zip archive on windows with just alice.exe</li>
</ul>
Pre-compiled binaries of Alice v0.1.2 can be downloaded from the its release
page</a> on Github.</p>
On Windows, install Alice v0.1.2 with WinGet:</p>

winget install OCaml.Alice --version 0.1.2
</span></code></pre>
</div>
On Linux and macOS, Alice v0.1.2 can be installed by running its install script:</p>

curl -fsSL https://alicecaml.org/install.sh </span>| </span>sh -s</span> --</span> 0.1.2
</span></code></pre>
</div>
On NixOS, Alice v0.1.2 can be installed via the flake
github:alicecaml/alice/0.1.2</code>, e.g.:</p>

nix shell github:alicecaml/alice/0.1.2
</span></code></pre>
</div>


Package Hygiene in Alice
2025-11-20T00:00:00+00:00
Alice organizes code into packages. All the code for a package goes in OCaml
source files in the package’s src</code> directory. The presence of a main.ml</code> file
indicates that the package is executable</em>, and will be linked into a program
with the same name as the package. The presence of a lib.ml</code> file indicates
that the package is a library</em>, and the contents of the lib.ml</code> file (or
lib.mli</code> file if present) is the public interface</em> to the package.
A package can also be both an executable and</em> a library if it has both a
main.ml</code> and a lib.ml</code> file.</p>
If a package is a library then other packages can depend on it, and access the
definitions from its public interface via a module named after the package (but
with the first letter capitalized to comply with OCaml’s module naming rules).
Alice packages must be named such that capitalizing the first letter of their
name gives a valid OCaml module name.
I’ll refer to this module as a package module</em>. In Alice, the only way to refer to
definitions from a package other than the current package is via the other
package`s package module.</p>
Packages can depend on other packages, which themselves depend on more packages,
forming a Directed Acyclic
Graph (DAG)</a> where the nodes
are packages and edges represent the dependency relationship between two packages.</p>
A package’s immediate dependencies</em> are those packages which it directly
depends on; exactly those packages listed in the [dependencies]</code> section of the
package’s manifest.</p>
The dependency closure</em> of a package is that package’s immediate
dependencies, plus the immediate dependencies of all of its immediate
dependencies, and so on.</p>
The first graph below highlights in cyan the immediate dependencies of a</code> and
the second graph highlights a</code>’s dependency closure.</p>

</p>
</p>
</div>
Package Hygiene</a></h2>
I’ll introduce the concept of package hygiene</em> which refers to how much of the code from a package’s
dependency closure is inaccessible by that package.
Let’s call a package management system hygienic</em> if code in one
package only has access to code from the public interfaces</em> of its
immediate dependencies</em>.</p>
Let’s break this definition down into two properties:</p>

The only package modules</em> that can be accessed by code in a package are those of its
immediate dependencies</em>. It is a compile error for a package to refer to a
package module</em> from packages in its dependendcy closure</em> other than
those of its immediate dependencies</em>.</li>
The only definitions which can be accessed inside a package module</em> are those
from the package’s public interface</em>. It’s a compile error for a package to
refer to a definition from a dependency which is not exposed in its public
interface</em> (i.e. the package’s lib.ml</code> file).</li>
</ol>
Package hygiene is a useful property for software maintenance and safety.</p>
The first property means that packages are forced to specify as dependencies, exactly the packages that
they need access to, and are only given direct access to those packages.
Without this property, packages can break due to the removal of
load-bearing transitive dependencies. If a</code> depends on b</code>, and b</code>
depends on c</code>, and a</code> starts referring to c</code> directly without
explicitly adding it as a dependency, then a</code> could break if b</code> ever
removes its dependency on c</code>, or changes the version of c</code> that it
depends on. The maintenance burden on a package ecosystem can be
reduced if the package manager doesn’t let you get into this situation
in the first place.</p>
The second property allows packages to make strong guarantees about correctness, since
the only way to interact with a package is through a specific
interface. The public interface to a package can be designed to
enforce invariants over the types defined in that package, and there’s
no way for client code to circumvent the interface to bypass those
protections.</p>
Package Hygiene in Dune?</a></h2>
Dune lacks both of the above
hygiene
properties. This can be demonstrated succinctly with a small project depending
on the core</a> package:</p>
(</span>lang</span> dune </span>3</span>.</span>20</span>)
</span>; dune-project
</span>
</span>(</span>package
</span> (</span>name</span> leak)
</span> (</span>depends
</span>  ocaml
</span>  (core
</span>   (</span>=</span> v0.</span>17</span>.</span>1</span>))))
</span></code></pre>
; dune
</span>
</span>(</span>executable
</span> (</span>public_name</span> main)
</span> (</span>package</span> leak)
</span> (</span>libraries</span> core))
</span></code></pre>
(* leak.ml *)
</span>
</span>let </span>() </span>= 
</span>  </span>let </span>_ </span>: </span>unit Sexplib0__Sexp_conv_labeled_tuple.Fields.t =
</span>    Sexplib0__Sexp_conv_labeled_tuple.Fields.Empty
</span>  </span>in
</span>  </span>()
</span></code></pre>
This code has access to a module Sexplib0__Sexp_conv_labeled_tuple</code> which
corresponds to the sexp_conv_labeled_tuple.ml</code> file from the package sexplib0</code>,
which is a dependency of the package sexplib</code>, which is a dependency of core</code>.
Opam packages follow a convention of putting their public code
in a module named after the package, and under this convention the
Sexp_conv_labeled_tuple</code> module referred to above isn’t part of the public interface
to sexplib0</code>.</p>
So Dune allows code in a package to access private definitions from
non-immediate dependencies, violating both hygiene properties. Dune does have
what we might call “soft” hygiene since it renames modules so they are unlikely
to be referred to by accident, but someone determined to intentionally violate
package hygiene can do so.</p>
Fortunately Dune might be about to get true package hygiene in an upcoming release
thanks to this PR</a>. This uses a
newish option to the OCaml compiler, -H</code>:</p>
 -H <dir>  Add <dir> to the list of "hidden" include directories
</span>     (Like -I, but the program can not directly reference these dependencies)
</span></code></pre>
Had I been aware of -H</code> while doing
the work described below adding package hygiene to Alice, it would have simplified things greatly!
I didn’t notice it because it’s not in the compiler’s man page, though clearly
I didn’t look very hard because it is in the output of -help</code>.
Still, I’ve come
up with a solution that will work with older compilers lacking this feature, and
employs what I think are some interesting techniques to work around the fact
that until the relatively recent addition of -H</code>, the
OCaml compiler did not make it easy to implement hygienic package management.</p>
Why Hygienic Packages in OCaml is (was?) Hard</a></h2>
The compiler has no concept of packages. The compiler compiles OCaml source
files into object files, and links object files into executables or library
archives. Package managers for OCaml must implement packaging policies (such as
hygiene) on top of the primitives made available by the compiler.</p>
OCaml source files may depend on each other. Each file implicitly defines a
module named after the file, and code in one file may refer to modules
corresponding to other files, provided there are no dependency cycles between
files. When compiling a file which refers to a module that isn’t in scope, the
compiler will try to find an object file whose name indicates that it contains the
module in question. The compiler searches for this object file in the same
directory as the file it’s currently compiling, and also in each directory
passed to the compiler with the -I</code> option.</p>
Let’s see how we might implement the first of my two hygiene properties,
that only the immediate dependencies of a package may be referred to by that
package. A reasonable approach to build a package with the first hygiene
property might be:</p>

Build all the packages in the dependency closure</em> of the package (by
recursively applying this strategy), storing the compiled object files in
some directory corresponding to their package.</li>
Build the package, passing with -I</code> the directory containing object files
for each immediate dependency</em> of the package only.</li>
</ol>
Since packages in the dependency closure but which aren’t immediate dependencies
are excluded in step 2 above, hygiene is achieved since the package code being
compiled doesn’t have access to them.</p>
This gives us the desired hygiene property, however some correct programs
won’t compile with this policy due to module aliases</em>. In OCaml a module
defined in one file may be aliased by another file, but when compiling code
that refers to the aliased module, even indirectly, the directory containing the
original</em> module definition must be passed with  -I</code>. Suppose we have packages
a</code>, b</code>, and c</code>, where a</code> depends on b</code> and b</code> depends on c</code>, and the
public interface to b</code> has:</p>
module </span>C_alias </span>= </span>C
</span></code></pre>
If package a</code> refers to B.C_alias</code>, then in order to build a</code> we need to pass
the path to the directory containing c</code>’s object files with -I</code>.
However passing c</code>’s object files with -I</code> would make it possible for a</code> to
refer to c</code> directly</em>, which violates the first hygiene property.</p>
This is where the new -H</code> option might save us. That option acts similarly to -I</code>, in that
it lets the compiler use modules defined in a directory when compiling code that
refers to them, however unlike -I</code> it doesn’t allow code to refer to these
modules directly</em>. So a hygienic approach to building a package using -H</code>
might be to pass the paths to directories containing compiled object files for
immediate dependencies with -I</code>, and for other packages in the dependency
closure with -H</code>, allowing their modules to be used during compilation but not
referred to directly.</p>
Note that the approach above is only sufficient for the first hygiene property.
On its own it’s not sufficient to enforce the second hygiene property, to
prevent packages from accessing private code from its immediate dependencies.</p>
As I said earlier, I wasn’t aware of -H</code> when implementing hygienic packages in
Alice. Instead I’ve come up with a packaging protocol that enforces both hygiene
properties using some other compiler features and a small amount of generated
code.</p>
Package Hygiene in Alice</a></h2>
In order to resolve module aliases, the object files from each package in the
dependency closure of the package being built must be made known to the compiler
by passing their containing directories with -I</code>. Alice does this in a hygienic
way by generating modules which
shadow</a>
the modules that should be inaccessible.</p>
Compiler Features</a></h3>
Alice’s packaging protocol depends on two compiler options I hadn’t previously
encountered:
-open</code> and -pack</code>.</p>
The -open Some_module</code> option takes a module name Some_module</code>, and when
compiling a file, acts as though the file began with a new line open Some_module</code>. (Read this</a> to
learn more about what it means to open a module in OCaml.)
The -open</code> option can be passed multiple times, resulting in the effect
of multiple open <module></code> lines being at the start of the compiled file, in the same
order as their corresponding -open</code> options.</p>
The -pack</code> option creates an object file combining a given set of existing
object files, making each of their corresponding modules accessible as
sub-modules. For example:</p>
ocamlopt.opt -pack foo.cmx bar.cmx baz.cmx -o qux.cmx
</span></code></pre>
This creates a new module Qux</code> with the object file qux.cmx</code>. The modules
Foo</code>, Bar</code>, and Baz</code> can now be accessed within Qux</code> as Qux.Foo</code>,
Qux.Bar</code>, and Qux.Baz</code> respectively. Importantly these are not</em> module
aliases. Code accessing the modules via qux.cmx</code> can be compiled
without</em> access to foo.cmx</code>, bar.cmx</code>, or baz.cmx</code>.</p>
When compiling a file that will eventually be passed to
ocamlopt.opt -pack foo.cmx</code>,
it’s necessary to pass an additional option -for-pack Foo</code>, specifying the name
of the module that the file will eventually be packed into as a sub-module.</p>
The Packaging Protocol</a></h3>
To build a package, first recursively apply the process I’m about to describe
to build the immediate dependencies of the package, which will result in the
package’s dependency closure being built.</p>
The result of building a package is stored across several different directories:</p>

The package’s private</em> output directory contains the compiled artifacts
corresponding to each source file of the project. There’s a roughly one to one
mapping between .ml</code> source files and .cmx</code> object files. All the object files go
in this private output directory.</li>
The package’s public</em> output directory contains a file named
internal_modules_of_<package>.cmx</code> (replacing <package></code> with the name of
the package), which is the output of running ocamlopt.opt -pack ...</code> on all the
object files in the package’s private directory. All top-level modules of the
package, corresponding to source files, are accessible as sub-modules of the
Internal_modules_of_<package></code> module. There’s a second file in the public
directory named public_interface_to_open_of_<package>.cmx</code> which is the result of
compiling a generated file. This file defines the module that will be
-open</code>ed when compiling code in packages depending on this package.</li>
The package’s generated</em> output directory, containing the generated
public_interface_to_open_of_<package>.ml</code> file, that will be compiled to the
public_interface_to_open_of_<package>.cmx</code> file in the public directory.</li>
</ul>
Once all the dependencies of the package have been built, compile each source
file in the package. When compiling a source file, for each package in the
package’s dependency closure, pass that package’s public output directory with
-I</code>. For each of the package’s immediate dependencies, pass -open Public_interface_to_open_of_<dependency></code>. The file needs to be compiled with the
-for-pack</code> option since it will eventually be packed into a file
internal_modules_of_<package>.cmx</code>. Store the output in the package’s private
output directory.</p>
For example, to compile a source file a.ml</code> from a package named foo</code>, whose
dependency closure is the packages bar</code>, baz</code>, and qux</code>, and whose immediate
dependencies are bar</code> and qux</code>, compile it with:</p>
ocamlopt.opt a.ml -c \
</span>  -I path/to/bar/public \
</span>  -I path/to/baz/public \
</span>  -I path/to/qux/public \
</span>  -open Public_interface_to_open_of_bar \
</span>  -open Public_interface_to_open_of_qux \
</span>  -for-pack Internal_modules_of_foo \
</span>  -o path/to/foo/private/a.cmx
</span></code></pre>
Once all the source files from the package have been compiled, create the
internal_modules_of_<package>.cmx</code> file by running the compiler with -pack</code>,
passing it all the object files from the package’s private directory.
Store the result in the package’s public output directory.</p>
Continuing the example, assume the package has source files a.ml</code>, b.ml</code>,
c.ml</code>, and lib.ml</code> (remember lib.ml</code> defines the public interface to the
package). Create the internal_modules_of_foo.cmx</code> object file with the command:</p>
ocamlopt.opt -pack \
</span>  path/to/foo/private/a.cmx \
</span>  path/to/foo/private/b.cmx \
</span>  path/to/foo/private/c.cmx \
</span>  path/to/foo/private/lib.cmx \
</span>  -o path/to/foo/public/internal_modules_of_foo.cmx
</span></code></pre>
It might seem odd to store the internal modules of a package in its public
output directory. This directory is public in the sense that all packages
depending on this package will have access to the public directory with -I</code>,
however due to shadowing of the Internal_modules_of_<package></code> module name in
the -open</code>ed Public_interface_to_open_of_<package></code> module, client code won’t actually
have access to the package’s internal modules.</p>
Now generate a file in the package’s generated output directory named
public_interface_to_open_of_<package>.ml</code>. I’ll illustrate this
generated file by continuing the example above:</p>
(* public_interface_to_open_of_foo.ml *)
</span>
</span>(* Recall that the public interface to a package is defined in a file
</span>   named "lib.ml" which corresponds to a module named "Lib", which is
</span>   among the modules packed into the "Internal_modules_of_<package>"
</span>   module. Client code must be able to refer to the package by the
</span>   package's name, so define a module alias here named after the package,
</span>   aliasing the "Lib" module defined in the package. This will allow
</span>   client code to refer to the public interface of the package with a
</span>   module named after the package. *)
</span>module </span>Foo </span>= </span>Internal_modules_of_foo.Lib
</span>
</span>(* Shadow the internal modules of this package. Since the
</span>   "Public_interface_to_open_of_<package>" module will be opened by all
</span>   client code, defining a new module here named the same as the packed
</span>   module of internal modules will mean that if client code does try to
</span>   access the internals of this package, instead they get an empty
</span>   module. This enforces the second hygiene property, preventing client
</span>   code from accessing the private internals of its immediate
</span>   dependencies. If someone does try to refer to this shadowed module
</span>   anyway, the deprecated annotation will mean they see a compiler
</span>   warning. *)
</span>module </span>Internal_modules_of_foo </span>= struct end
</span>[</span>@@</span>deprecated </span>"This module is for internal use only."</span>]
</span>
</span>(* Shadow the internal modules of the packages in the dependency
</span>   closure of this package. The public output directory of each package
</span>   in the dependency closure of this package is passed with -I when
</span>   compiling files from packages that depend on this package. Shadowing
</span>   the names of the packed internal modules of those packages prevents
</span>   access to their internals by clients of this package. *)
</span>module </span>Internal_modules_of_bar </span>= struct end
</span>[</span>@@</span>deprecated </span>"This module is for internal use only."</span>]
</span>module </span>Internal_modules_of_baz </span>= struct end
</span>[</span>@@</span>deprecated </span>"This module is for internal use only."</span>]
</span>module </span>Internal_modules_of_qux </span>= struct end
</span>[</span>@@</span>deprecated </span>"This module is for internal use only."</span>]
</span>
</span>(* Shadow the public interface to each of the packages in the
</span>   dependency closure of this package, preventing client code from
</span>   referring to packages outside their immediate dependencies. This
</span>   enforces the first hygiene property. *)
</span>module </span>Public_interface_to_open_of_bar </span>= struct end
</span>[</span>@@</span>deprecated </span>"This module is for internal use only."</span>]
</span>module </span>Public_interface_to_open_of_baz </span>= struct end
</span>[</span>@@</span>deprecated </span>"This module is for internal use only."</span>]
</span>module </span>Public_interface_to_open_of_qux </span>= struct end
</span>[</span>@@</span>deprecated </span>"This module is for internal use only."</span>]
</span></code></pre>
That final batch of module shadowing requires some care.
In the example, foo</code> immediately depends on bar</code> and qux</code>.
But if bar</code> also depended on qux</code>, then inside
Public_interface_to_open_of_bar</code>, we would find the line:</p>
module </span>Public_interface_to_open_of_qux </span>= struct end
</span></code></pre>
That is, bar</code> would shadow the public interface to qux</code>.
When compiling files in foo</code>, if Public_interface_to_bar</code>
is opened before Public_interface_to_qux</code>, then due to module name shadowing,
Public_interface_to_qux</code> will be the empty shadow rather than the
true public interface to the package qux</code>.</p>
To avoid this problem, it’s necessary to sort the -open</code> arguments to
the compiler such that if one dependency depends on another dependency, the
depended upon package comes before the depending package (qux</code> must
come before bar</code> in the example).</p>
Once the public_interface_to_open_of_<package>.ml</code> file is generated,
compile it, storing the result in the package’s public output
directory. The package’s public output directory must be passed with -I</code> since
the generated code refers to Internal_modules_of_<package></code>.</p>
ocamlopt.opt path/to/foo/generated/public_interface_to_open_of_foo.ml -c \
</span>  -I path/to/foo/public \
</span>  -o path/to/foo/public/public_interface_to_open_of_foo.cmx
</span></code></pre>
And that’s it! All the necessary files are now in the package’s public
output directory where they can be consumed while building any additional
packages which depend on the current one.</p>
One final note:
In order to link an executable that depends on packages, library
archives (.cmxa</code> files) must be generated for those packages. To create a
.cmxa</code> file for a package, Alice links the .cmx</code> files in the
package’s public directory. E.g.:</p>
ocamlopt.opt \
</span>  path/to/foo/public/public_interface_to_open_of_foo.cmx \
</span>  path/to/foo/public/internal_modules_of_foo.cmx \
</span>  -a -o path/to/foo/public/lib.cmxa
</span></code></pre>
To learn more, try compiling some interdependent Alice packages. See
here</a> for
a brief tutorial on building packages with Alice. Run alice build -vv</code> to see a
list of all the commands run by Alice, and inspect the contents of the build</code>
directory to see the different output files created when building each package.</p>


Alice v0.1.1
2025-11-13T00:00:00+00:00
Announcing the release of Alice v0.1.1. This is a patch release with several
minor fixes. It also introduces a “hermetic source archive” (the
alice-0.1.1-hermetic-source.tar.gz</a>
file on the release page</a>)
which can be built with Dune package management without needing to install the OCaml toolchain with Alice.
The lock directory checked into the main branch of Alice specifies the compiler
be installed externally from Dune allowing Alice to dogfood its own toolchain
management logic, however if you just want to build Alice from source it’s more
convenient to have a codebase where running dune build</code> is all that’s
necessary. The hermetic source archive is created by deleting dune-workspace</code>
and running dune pkg lock</code>.</p>
Release Notes</a></h2>
Fixed</a></h3>

External commands are run in an environment containing the OCaml toolchain if
Alice has installed an OCaml toolchain. This fixes an issue where the OCaml
compiler couldn’t find flexlink on Windows unless the current Alice root was
in the PATH variable. (#2, fixes #1)</li>
Fixed compile error on 32-bit machines due to unrepresentable integer literal.</li>
Wrap text in help messages.</li>
</ul>
Pre-compiled binaries of Alice v0.1.1 can be downloaded from the its release
page</a> on Github.</p>
The Opam package can be installed with:</p>

opam install alice.0.1.1
</span></code></pre>
</div>
On Linux and macOS, Alice v0.1.1 can be installed by running its install script:</p>

curl -fsSL https://alicecaml.org/install.sh </span>| </span>sh -s</span> --</span> 0.1.1
</span></code></pre>
</div>
On NixOS, Alice v0.1.1 can be installed via the flake
github:alicecaml/alice/0.1.1</code>, e.g.:</p>

nix shell github:alicecaml/alice/0.1.1
</span></code></pre>
</div>


Alice v0.1.0
2025-11-08T00:00:00+00:00
Announcing the release of Alice v0.1.0. This is the first official release of
Alice, so in lieu of a changelog, here’s a summary of the capabilities of Alice
thus far:</p>

Multi-file packages with dependencies specified within the local filesystem
can be built and incrementally rebuilt.</li>
Dependency and build graphs can be visualized with graphviz.</li>
The OCaml toolchain and some development tools can be installed user-wide.</li>
</ul>
Pre-compiled binaries of Alice v0.1.0 can be downloaded from the its release
page</a> on Github.</p>
The Opam package can be installed with:</p>

opam install alice.0.1.0
</span></code></pre>
</div>
On Linux and macOS, Alice v0.1.0 can be installed by running its install script:</p>

curl -fsSL https://alicecaml.org/install.sh </span>| </span>sh -s</span> --</span> 0.1.0
</span></code></pre>
</div>
On NixOS, Alice v0.1.0 can be installed via the flake
github:alicecaml/alice/0.1.0</code>, e.g.:</p>

nix shell github:alicecaml/alice/0.1.0
</span></code></pre>
</div>


Alice as a Toolchain Manager for Dune Projects
2025-09-26T00:00:00+00:00
Alice is my experimental work-in-progress build system and package manager for OCaml.
To help users get started writing OCaml as smoothly as possible, Alice provides
a mechanism for installing the pre-built versions of the OCaml compiler and other tools.
This post is about using this feature of Alice to simplify setting up an OCaml
environment for developing a project with Dune Package Management</a>.</p>
In the Opam ecosystem (which is the package ecosystem accessible to Dune), the OCaml compiler is considered to be a mostly
regular package, which all other packages must list in their dependencies
(assuming they are written in OCaml). Opam is mostly a source-based package
ecosystem, so when building a project (including its transitive dependencies)
the first thing that usually needs to happen is the OCaml compiler needs to be
bootstrapped (it is itself written in OCaml) and compiled, which often takes
several minutes.</p>
When using ocaml-lsp-server</a> to analyze
OCaml code in a text editor, that code needs to have been compiled using the
same version of the OCaml compiler as the LSP server executable in order for the LSP
server to understand the code. This is fairly easy
to ensure when using Opam, but installing the LSP server with Opam requires building the LSP server from source which adds another
couple of minutes delay to getting started working on a new project. It’s
tempting to speed this up by distributing a pre-compiled executable of the LSP
server but this is tricky because somehow we’d need to make sure the executable
that gets installed was compiled by the same version of the compiler as was used
for the project.</p>
Another common OCaml development tool is the de-facto standard code formatter
ocamlformat</a>. It doesn’t have the
same compiler version constraint as the LSP server and is lighter in its
dependencies and therefore faster to compile. The LSP server requires that
the executables ocamlformat</code> and ocamlformat-rpc</code> are runnable as commands
(ie. they are in one of the directories in your PATH</code> variable) when using
running the LSP command to format a file.</p>
Alice simplifies getting started on a new OCaml project by providing
pre-compiled binary versions of the compiler, the LSP server, and the code
formatter. The binary version of the LSP server was compiled with the binary
version of the compiler, so the LSP server can analyze code compiled with the
compiler.</p>
You can use alice</code> to install the tools with:</p>

alice tools install
</span></code></pre>
</div>
…or you can install both Alice and a set of tools with:</p>

curl -fsSL https://alicecaml.org/install.sh </span>| </span>sh
</span></code></pre>
</div>
The remainder of this post will go through a minimal example of setting up a fresh
machine with Alice and its binary versions of development tools, and then
developing a Dune project using these tools. For the sake of ease of following
along at home and reproducing my results, I’ll build up a docker image with the
tools and then do all development inside a container.</p>
Here’s the Dockerfile</code> I’ll be using. It installs Alice, the OCaml tools, and
Dune system-wide, all without compiling any code.</p>

FROM</span> ubuntu
</span>
</span># Install packages necessary to install Alice and Dune and the
</span># low-level build tools needed by the OCaml compiler.
</span>RUN </span>apt-get update && apt-get install -y build-essential curl git
</span>
</span># Install Alice and the OCaml development tools.
</span>RUN </span>curl -fsSL https://alicecaml.org/install.sh | sh -s -- \
</span>  --global /usr --no-prompt --install-tools --no-update-shell-config
</span>
</span># Install Dune from its binary distribution.
</span>RUN </span>curl -fsSL https://github.com/ocaml-dune/dune-bin-install/releases/download/v3/install.sh | sh -s -- \
</span>  3.20.2 --install-root /usr --no-update-shell-config
</span>
</span># Install an editor to show off LSP. I'm using an unstable
</span># version of neovim here as it comes with an experimental
</span># built-in plugin manager which will make it easy to set up
</span># the lspconfig plugin which knows how to run the OCaml LSP
</span># server which Alice installed.
</span>RUN </span>apt-get install -y software-properties-common && \
</span>  add-apt-repository ppa:neovim-ppa/unstable && \
</span>  apt-get update && \
</span>  apt-get install -y neovim
</span>
</span># Add a non-root user.
</span>RUN </span>useradd -m user
</span>USER </span>user
</span>WORKDIR </span>/home/user
</span>
</span># Minimal neovim config which installs the lspconfig plugin.
</span>RUN </span>mkdir -p ~/.config/nvim && \
</span>  printf </span>'vim.pack.add({ "https://github.com/neovim/nvim-lspconfig" })</span>\n</span>vim.lsp.enable("ocamllsp")'</span> > ~/.config/nvim/init.lua
</span></code></pre>
</div>
Now from within a container running an image built from that
Dockerfile, let’s make a new Dune project!</p>
$ dune init project foo
</span>Entering directory </span>'/home/user/foo'
</span>Success: initialized project component named foo
</span>$ cd foo
</span>$ dune exec foo
</span>Hello, World!
</span></code></pre>
That indicates that Dune and the OCaml compiler both work.</p>
To test the LSP server, open an OCaml file in an editor like
bin/main.ml</code> whose contents is:</p>

let </span>() </span>=</span> print_endline </span>"Hello, World!"
</span></code></pre>
</div>
Move the editor’s cursor over the print_endline</code> function
and run the LSP command to jump to definition. In Neovim
this is:</p>

:</span>lua</span> vim</span>.</span>lsp</span>.</span>buf</span>.</span>definition</span>()
</span></code></pre>
</div>
This should take you to the file /usr/lib/ocaml/stdlib.ml</code>
where print_endline</code> is defined like:</p>
...
</span>  </span>let </span>print_endline </span>s </span>=
</span>    output_string stdout s; output_char stdout </span>'\n'</span>; flush stdout
</span>...
</span></code></pre>
Now let’s test ocamlformat</code>. Make an empty file in the project’s
root directory named .ocamlformat</code> to enable ocamlformat</code>:</p>

touch .ocamlformat
</span></code></pre>
</div>
Then open bin/main.ml</code> back up in your editor and mess with
its formatting a bit. Maybe something like:</p>

let </span>() </span>=
</span>
</span>
</span>print_endline </span>"Hello, World!"
</span></code></pre>
</div>
Then run the LSP command to format the file. In Neovim it’s:</p>

:</span>lua</span> vim</span>.</span>lsp</span>.</span>buf</span>.</span>format</span>()
</span></code></pre>
</div>
…and the code should now be formatted correctly again:</p>

let </span>() </span>=</span> print_endline </span>"Hello, World!"
</span></code></pre>
</div>
Now let’s use Dune Package Management to add a dependency.
Make a lock directory:</p>
$ dune pkg lock
</span>Solution for dune.lock:
</span>- ocaml.5.3.0
</span>- ocaml-base-compiler.5.3.0
</span>- ocaml-compiler.5.3.0
</span>- ocaml-config.3
</span></code></pre>
That doesn’t look right, because our OCaml version should be
5.3.1+relocatable</code> (confirm this by running):</p>
$ ocaml --version
</span>The OCaml toplevel, version 5.3.1+relocatable
</span></code></pre>
By default Dune uses the regular Opam repository which
doesn’t have an entry for the patched relocatable compiler
installed by Alice. Also Dune prefers to install the
compiler by building it from source rather than taking the
compiler from the system. To change both of these
behaviours, create a dune-workspace</code> file in the project
root with contents:</p>

(</span>lang</span> dune </span>3</span>.</span>20</span>)
</span>
</span>(</span>repository
</span> (</span>name</span> alice)
</span> (</span>url
</span>  git+https://github.com/alicecaml/alice-opam-repo))
</span>
</span>(</span>lock_dir
</span> (</span>constraints
</span>  (ocaml-system
</span>   (</span>= </span>5</span>.</span>3</span>.</span>1</span>+relocatable)))
</span> (</span>repositories</span> upstream overlay alice)
</span> (</span>solver_env
</span>  (sys-ocaml-version </span>5</span>.</span>3</span>.</span>1</span>+relocatable)))
</span></code></pre>
</div>
This tells Dune to use Alice’s Opam repository (which just contains an
ocaml-system</code> package for the patched relocatable compiler) and to add the
package solver constraint that the solution must include the package
ocaml-system.5.3.1+relocatable</code>. Lock the project again:</p>
$ dune pkg lock
</span>Solution for dune.lock:
</span>- ocaml.5.3.1+relocatable
</span>- ocaml-config.3
</span>- ocaml-system.5.3.1+relocatable
</span></code></pre>
Better. Check that it still builds:</p>
$ dune clean && dune exec foo
</span>Hello, World!
</span></code></pre>
We know that Dune is using the right compiler here because the only compiler installed
on the system is the one installed by Alice. For Dune to have installed a
different compiler it would have needed to build it from source, which we would
notice because doing so takes several minutes.</p>
Now add a dependency! I’m going to add a dependency on the package climate</code> by
adding it to the depends</code> field in dune-project</code>. After this change, the
entire dune-project</code> file looks like:</p>

(</span>lang</span> dune </span>3</span>.</span>20</span>)
</span>
</span>(</span>name</span> foo)
</span>
</span>(</span>generate_opam_files</span> true)
</span>
</span>(</span>source
</span> (</span>github</span> username/reponame))
</span>
</span>(</span>authors </span>"Author Name <author@example.com>"</span>)
</span>
</span>(</span>maintainers </span>"Maintainer Name <maintainer@example.com>"</span>)
</span>
</span>(</span>license</span> LICENSE)
</span>
</span>(</span>documentation</span> https://url/to/documentation)
</span>
</span>(</span>package
</span> (</span>name</span> foo)
</span> (</span>synopsis </span>"A short synopsis"</span>)
</span> (</span>description </span>"A longer description"</span>)
</span> (</span>depends</span> ocaml climate) </span>; <------------ I modified this line
</span> (</span>tags
</span>  (</span>"add topics" "to describe"</span> your project)))
</span>
</span>; See the complete stanza docs at https://dune.readthedocs.io/en/stable/reference/dune-project/index.html
</span></code></pre>
</div>
Lock the project again to make the new dependency available:</p>
$ dune pkg lock
</span>Solution for dune.lock:
</span>- climate.0.8.4
</span>- ocaml.5.3.1+relocatable
</span>- ocaml-config.3
</span>- ocaml-system.5.3.1+relocatable
</span></code></pre>
To use the new dependency, add climate</code> to the libraries</code> field in
bin/dune</code>:</p>

(</span>executable
</span> (</span>public_name</span> foo)
</span> (</span>name</span> main)
</span> (</span>libraries</span> foo climate))
</span></code></pre>
</div>
The climate</code> package is a library to help implement command-line interfaces.
Use it to make a little CLI in bin/main.ml</code>:</p>

open </span>Climate
</span>
</span>let </span>() </span>=
</span>  </span>let open</span> Command </span>in
</span>  run </span>@@</span> singleton
</span>  </span>@@
</span>  </span>let open</span> Arg_parser </span>in
</span>  </span>let+</span> name </span>=</span> pos_req </span>0 </span>string </span>~value_name:</span>"NAME" </span>in
</span>  Printf.printf </span>"Hello, %s!</span>\n</span>"</span> name
</span></code></pre>
</div>
Try it out:</p>
$ dune exec foo -- --help
</span>Usage: /home/user/foo/_build/install/default/bin/foo [OPTION]… <NAME>
</span>
</span>Arguments:
</span>  <NAME>
</span>
</span>Options:
</span>  -h, --help  Show this help message.
</span>
</span>$ dune exec foo -- Alice
</span>Hello, Alice!
</span></code></pre>
This shows how Alice can help setup an OCaml environment made up entirely
of binary distributions of tools. Along with the binary release of Dune, this
makes it possible to develop OCaml projects where the only code you need to
compile is from your project and the libraries it depends on. Using pre-compiled
binaries of the compiler and development tools speeds up getting started on a
new project, and also speeds up CI builds by removing the costly first step of
compiling the OCaml compiler. Indeed Alice is itself a Dune project which
uses Alice to manage its development and CI OCaml environments.</p>


Introducing Alice
2025-09-07T00:00:00+00:00
Alice</a> is an experimental OCaml build
system and package manager. I’m starting this blog to document progress on its
development. Here’s a quick tour of Alice’s features at the time of writing.</p>
Installing OCaml tools</a></h2>
One point of difference between OCaml’s packaging ecosystem and that of most other
languages is that the OCaml compiler itself is considered to be a package. This
avoids the need for language version management tools like
rustup</a>, nvm</a>, and
rvm</a>, and it allows projects to declare a minimum or maximum
version of the compiler which they support. However installing the OCaml
compiler as a package means building it from source and this can take a long
time. For various technical reasons, using Opam means recompiling the OCaml
compiler at least once for each new project that you work on which, given the
time it takes to compile, is not ideal.</p>
Since you obviously need a compiler before you can compile any code, it’s
probably the first thing that a new user of the OCaml ecosystem will try to do, so I
would like for it to be fast. When I eventually add package management to Alice
I’ll develop a packaging ecosystem where the OCaml compiler is not</em> a package.
This is one of the big differences between the packaging philosophies of
Opam and Alice.</p>
Since the compiler is not a package, it’s up to the user to make sure it’s installed
before compiling any code. To help with this, Alice can act like a language
version manager. I’ve pre-compiled a relocatable version of the OCaml compiler,
and Alice can install it automatically:</p>
$ alice tools install
</span>  Fetching ocaml.5.3.1+relocatable...
</span> Unpacking ocaml.5.3.1+relocatable...
</span>
</span>Successfully installed ocaml.5.3.1+relocatable!
</span>
</span>  Fetching ocamllsp.1.22.0...
</span> Unpacking ocamllsp.1.22.0...
</span>
</span>Successfully installed ocamllsp.1.22.0!
</span>
</span>  Fetching ocamlformat.0.27.0...
</span> Unpacking ocamlformat.0.27.0...
</span>
</span>Successfully installed ocamlformat.0.27.0!
</span></code></pre>
Where did it put the tools?</p>
$ ls ~/.alice/ -l
</span>lrwxrwxrwx - s  7 Jul 14:57 current -> /home/s/.alice/roots/5.3.1
</span>drwxr-xr-x - s  7 Sep 18:37 roots
</span>
</span>$ ls ~/.alice/roots/5.3.1
</span>bin  doc  lib  man  share
</span>
</span>$ ls ~/.alice/roots/5.3.1/bin
</span>ocaml          ocamldoc.opt       ocamlobjinfo.opt  ocamlrund-0096
</span>ocamlc         ocamlformat        ocamlopt          ocamlruni
</span>ocamlc.byte    ocamlformat-rpc    ocamlopt.byte     ocamlruni-00d6
</span>ocamlc.opt     ocamllex           ocamlopt.opt      ocamlruni-0096
</span>ocamlcmt       ocamllex.byte      ocamloptp         ocamlyacc
</span>ocamlcp        ocamllex.opt       ocamlprof         x86_64-pc-linux-musl-ocamlrun-0096
</span>ocamldebug     ocamllsp           ocamlrun          x86_64-pc-linux-musl-ocamlrund-0096
</span>ocamldep       ocamlmklib         ocamlrun-00d6     x86_64-pc-linux-musl-ocamlruni-0096
</span>ocamldep.byte  ocamlmktop         ocamlrun-0096
</span>ocamldep.opt   ocamlobjinfo       ocamlrund
</span>ocamldoc       ocamlobjinfo.byte  ocamlrund-00d6
</span></code></pre>
The ~/.alice/current</code> symlink can be easily changed to a different “root” (what
I’m calling a filesystem containing installations of the compiler and several
tools) with alice tools change</code> however currently the only available version is
5.3.1</code>.</p>
You’ll note that ocamllsp</code> and ocamlformat</code> are also installed. This pair of
tools is used by most OCaml developers so to improve the experience of using
Alice for the first time I’ve pre-compiled binary versions of these packages
too. The ocamllsp</code> tool needs to be compiled with the same compiler as the code
it’s analyzing. When I built the ocamllsp</code> binary package installed by Alice I
used the same compiler as the one that Alice installs, so it’s guaranteed that
the copy of ocamllsp</code> will be compatible with the compiler if you install both
through Alice.</p>
When Alice runs the compiler it just looks it up in the PATH</code> variable, so you
can still install a different version of the complier (e.g. with Opam) and have
Alice run that for you. If no OCaml compiler is found in PATH</code> then Alice will
fall back to running the one from ~/.alice/current/bin</code>. If you want to guarantee
that Alice’s OCaml compiler will be run by Alice, add ~/.alice/current/bin</code> to
the beginning of your PATH</code> variable.</p>
Hello, World!</a></h2>
Alice can set up a new project containing an executable or library package:</p>
$ alice new --help
</span>Create a new alice project.
</span>
</span>Usage: alice new [OPTION]… <NAME>
</span>
</span>Arguments:
</span>  <NAME>  Name of the project
</span>
</span>Options:
</span>  -v, --verbose      Enable verbose output (-vv for extra verbosity).
</span>  -q, --quiet        Supress printing of progress messages.
</span>  -p, --path <FILE>  Initialize the new project in this directory (must not already exist)
</span>      --exe          Create a project containing an executable package (default)
</span>      --lib          Create a project containing a library package
</span>  -h, --help         Show this help message.
</span></code></pre>
Let’s make a new executable package:</p>
$ alice new hello
</span>  Creating new executable package "hello" in /tmp/alicedemo/hello
</span>
</span>$ cd hello
</span></code></pre>
Take a look at the project:</p>
$ tree
</span>.
</span>├── Alice.toml
</span>└── src
</span>    └── main.ml
</span>
</span>2 directories, 2 files
</span>
</span>$ cat Alice.toml
</span>[package]
</span>name = "hello"
</span>version = "0.1.0"
</span>
</span>$ cat src/main.ml
</span>let () = print_endline "Hello, World!"
</span></code></pre>
Alice has a command alice run</code> that builds and runs the current package if it’s
an executable package:</p>
$ alice run
</span> Compiling hello v0.1.0
</span>   Running /tmp/alicedemo/hello/build/hello
</span>
</span>Hello, World!
</span></code></pre>
What did that build?</p>
$ ls build/
</span>hello  main.cmi  main.cmx  main.ml  main.o
</span></code></pre>
The build</code> directory was generated when building the project and contains all
built artifacts. To remove it, run:</p>
$ alice clean
</span></code></pre>
Multi-file projects</a></h2>
Add a new file src/foo.ml</code> with contents:</p>
let </span>message </span>= </span>"Hello, Alice!"
</span></code></pre>
And make an interface file src/foo.mli</code> with contents:</p>
val </span>message : </span>string
</span></code></pre>
Finally modify src/main.ml</code> so that it contains:</p>
let </span>() </span>=</span> print_endline Foo.message
</span></code></pre>
Now run alice run</code> again.</p>
 Compiling hello v0.1.0
</span>   Running /tmp/alicedemo/hello/build/hello
</span>
</span>Hello, Alice!
</span></code></pre>
Incremental Compilation</a></h2>
To build a project without running it we can run alice build</code>:</p>
$ alice build --help
</span>Build a project.
</span>
</span>Usage: alice build [OPTION]…
</span>
</span>Options:
</span>  -v, --verbose               Enable verbose output (-vv for extra verbosity).
</span>  -q, --quiet                 Supress printing of progress messages.
</span>      --manifest-path <FILE>  Read project metadata from this file instead of Alice.toml.
</span>      --release               Build with optimizations.
</span>  -h, --help                  Show this help message.
</span></code></pre>
Let’s turn up the verbosity to see what’s happening under the hood. Clean the
project and then run alice build -vv</code>:</p>
$ alice clean
</span>$ alice build -vv
</span> Compiling hello v0.1.0
</span>[DEBUG] Running command: /home/s/.alice/current/bin/ocamldep.opt -one-line -native foo.mli
</span>[DEBUG] Running command: /home/s/.alice/current/bin/ocamldep.opt -one-line -native foo.ml
</span>[DEBUG] Running command: /home/s/.alice/current/bin/ocamldep.opt -one-line -native main.ml
</span> [INFO] Copying source file: foo.mli
</span> [INFO] Building targets foo.cmi
</span>[DEBUG] Running command: /home/s/.alice/current/bin/ocamlopt.opt -g -c foo.mli
</span> [INFO] Copying source file: foo.ml
</span> [INFO] Building targets foo.cmx, foo.o
</span>[DEBUG] Running command: /home/s/.alice/current/bin/ocamlopt.opt -g -c foo.ml
</span> [INFO] Copying source file: main.ml
</span> [INFO] Building targets main.cmx, main.o
</span>[DEBUG] Running command: /home/s/.alice/current/bin/ocamlopt.opt -g -c main.ml
</span> [INFO] Building targets hello
</span>[DEBUG] Running command: /home/s/.alice/current/bin/ocamlopt.opt -g -o hello foo.cmx main.cmx
</span></code></pre>
Running alice build -vv</code> a second time shows that most of the work is now
skipped.</p>
$ alice build -vv
</span> Compiling hello v0.1.0
</span>[DEBUG] Running command: /home/s/.alice/current/bin/ocamldep.opt -one-line -native foo.mli
</span>[DEBUG] Running command: /home/s/.alice/current/bin/ocamldep.opt -one-line -native foo.ml
</span>[DEBUG] Running command: /home/s/.alice/current/bin/ocamldep.opt -one-line -native main.ml
</span></code></pre>
The project is already built so there’s nothing to do the second time around.
Those calls of ocamldep.opt</code> can probably be skipped to with some extra work!</p>
Now change src/main.ml</code> without changing any other source files.</p>
let </span>() </span>=</span> print_endline (String.cat Foo.message </span>"Yay!"</span>)
</span></code></pre>
Rebuilding yet again:</p>
$ alice build -vv
</span> Compiling hello v0.1.0
</span>[DEBUG] Running command: /home/s/.alice/current/bin/ocamldep.opt -one-line -native foo.mli
</span>[DEBUG] Running command: /home/s/.alice/current/bin/ocamldep.opt -one-line -native foo.ml
</span>[DEBUG] Running command: /home/s/.alice/current/bin/ocamldep.opt -one-line -native main.ml
</span> [INFO] Copying source file: main.ml
</span> [INFO] Building targets main.cmx, main.o
</span>[DEBUG] Running command: /home/s/.alice/current/bin/ocamlopt.opt -g -c main.ml
</span> [INFO] Building targets hello
</span>[DEBUG] Running command: /home/s/.alice/current/bin/ocamlopt.opt -g -o hello foo.cmx main.cmx
</span></code></pre>
It rebuilt some of the artifacts but not all of the artifacts (e.g. it did not
rebuild foo.cmx</code> or foo.o</code>) since those would be unchanged. Alice knows that
if src/foo.ml</code> did not change since the last time foo.cmx</code> was generated,
there is no need to generate foo.cmx</code> again.</p>
Dependency Graphs</a></h2>
Build targets depend on source files, and possibly on other build targets. Alice
needs to know which targets depend on which other files/targets. To help users
understand their projects’ build dependencies and to help me debug issues with
Alice, there is a command alice dot</code> which generates a Graphviz dot file
containing the project’s build or dependency graph.</p>
$ alice dot artifacts
</span>digraph {
</span>  "foo.cmi" -> {"foo.mli"}
</span>  "foo.cmx" -> {"foo.cmi", "foo.ml"}
</span>  "foo.o" -> {"foo.cmi", "foo.ml"}
</span>  "hello" -> {"foo.cmx", "foo.o", "main.cmx", "main.o"}
</span>  "main.cmx" -> {"foo.cmx", "main.ml"}
</span>  "main.o" -> {"foo.cmx", "main.ml"}
</span>}
</span></code></pre>
We can use Graphviz to visualize this:</p>
$ alice dot artifacts | dot -Tsvg > graph.svg
</span></code></pre>
</p>
What’s next?</a></h2>
My most recent big push on Alice was
getting it running on Windows</a>.
My next focus will be allowing packages to depend on each other, which will be
the first step on the long journey to supporting package management -
one of my long-term goals for this project. The first big milestone along that
path will be bootstrapping, where Alice has enough build-system and
package-management features to build itself</em>, and all of its dependencies have
been ported to Alice’s nascent package ecosystem.</p>


Porting Alice to Windows
2025-08-28T00:00:00+00:00
This article was originally posted to my personal website</a>.</em></p>
Alice</a> is my toy OCaml build system
project where I ask “What if Cargo</a>
but for OCaml?”. My main priority when designing Alice is accessibility but
perhaps a more suitable term would be inclusivity</em> as my goal is for the tool
to be usable by as many people as possible. Alice is still in its infancy and is
currently used by nobody</em> but if the day comes when it becomes a viable tool
for building OCaml software I would hate to systematically exclude a potential
user base because of baked-in assumptions made early in its design.</p>
I do most of my development on Linux and macOS which means I’m likely to
make design decisions favouring those systems, possibly at the expense of
potential users on other systems. In particular, because Windows differs so much
from other popular OSes due to it not being Unix-based, there’s a significant
risk of excluding Windows users if I don’t make a conscious effort to support
them.</p>
Like most people who grew up in the 2000s or later I was introduced to
computing on home and school computers running Windows (Windows 98 in my case!).
I started playing with Linux in 2009 and it gradually became my daily driver
but it took a huge amount of free time messing around with different distros and
learning the tools and conventions to get to my level of comfort. I’m also
fortunate enough to have the means to afford a Mac. But people who learnt
Windows first and lack the time, money, or inclination to switch to a
Unix-based OS will remain Windows users. So when Windows users are excluded from
a tool, who is really</em> being excluded?</p>
Today I’m going to port Alice to Windows.</p>
To prepare for this work I’ve compiled a relocatable OCaml compiler toolchain for
Windows based on David Allsopp</a>’s patches to allow
the compiler to be moved after its initial installation. See this talk from
ICFP 2022</a> for more info. Without
this work every user would need to compile the OCaml compiler on their machine before
using it. It’s important to me that a user of Alice can get started writing
OCaml as quickly as possible with no hurdles. Building the compiler from source can
take over 10 minutes and I don’t want users’ first experience of Alice to be
waiting such a long time. I don’t think I would have started working on Alice
at all if distributing a pre-compiled relocatable compiler wasn’t an option.</p>
Technically I could have used opam to bootstrap my development environment as it works
perfectly fine</a>
on Windows but one cool feature of Alice is that it can download pre-compiled
development tools for you. Alice can’t build itself (yet!) but I still want to
eat my own dogfood when I can, and so I’m testing out the prebuilt toolchain
while developing Alice. I haven’t updated Alice to be able to install the
dev tools prebuilt for Windows yet, but I have a handy
shell script</a>
that sets up a development environment for working on Alice using the same tools
as Alice would install if it was</em> already built. Classic bootstrapping problem.</p>
I’m using powershell and I have msys2</a> installed so
some commands will look very Unix-y. Alice itself will work fine on Windows once
ported but I barely know what I’m doing in powershell so I’ll stick to what I
know (ie. Unix commands from msys2) while setting up my environment!</p>
This command installed a prebuilt compiler toolchain to D:\alice\current</code>:</p>
PS D:\src\alice> sh boot\x86_64-windows.sh D:\alice
</span></code></pre>
The result:</p>
PS D:\src\alice> ls D:\alice\current\bin\
</span>
</span>
</span>    Directory: D:\alice\current\bin
</span>
</span>
</span>Mode                 LastWriteTime         Length Name
</span>----                 -------------         ------ ----
</span>-a----        2025-08-28     02:07         451937 flexlink.byte.exe
</span>-a----        2025-08-28     02:08        4706378 flexlink.exe
</span>-a----        2025-08-28     02:08        4706378 flexlink.opt.exe
</span>-a----        2025-08-28     02:08       24365426 ocaml.exe
</span>-a----        2025-08-28     02:08        3394118 ocamlc.byte.exe
</span>-a----        2025-08-28     02:08       13950043 ocamlc.exe
</span>-a----        2025-08-28     02:08       13950043 ocamlc.opt.exe
</span>...
</span></code></pre>
In addition to the compiler, this command installed ocamlformat</code> and ocamllsp</code>,
which I also pre-compiled for Windows in preparation for this work.</p>
PS D:\src\alice> Get-Command ocamlformat
</span>
</span>CommandType     Name               Version    Source
</span>-----------     ----               -------    ------
</span>Application     ocamlformat.exe    0.0.0.0    D:\alice\current\bin\ocamlformat.exe
</span>
</span>
</span>PS D:\src\alice> Get-Command ocamllsp
</span>
</span>CommandType     Name               Version    Source
</span>-----------     ----               -------    ------
</span>Application     ocamllsp.exe       0.0.0.0    D:\alice\current\bin\ocamllsp.exe
</span></code></pre>
The other development tool I’ll need is dune</code>. Alice uses Dune’s relatively new
package-management features and these have not yet been ported to Windows so
I’ve needed to hack Dune a little bit to make it work here. I already did this
work while building ocamlformat</code> and ocamllsp</code> with Dune package management on
Windows. Most hacks were to those projects’ lockfiles rather than to Dune itself.
I kept a
log</a>
of everything I needed to change. I may be referring to it in order to get Alice
to build with Dune on Windows.</p>
I built Dune from source on Windows using opam while building ocamlformat</code> and
ocamllsp</code> and that’s the Dune executable I’ll be using for today’s work on
Alice.</p>
Ok so I have all the tools I need, let’s see if Alice builds on Windows:</p>
PS D:\src\alice> dune build
</span>File "dune.lock/lock.dune", lines 18-29, characters 1-288:
</span>18 |  ((arch x86_64)
</span>19 |   (os linux)
</span>20 |   (sys-ocaml-version 5.3.1+relocatable))
</span>....
</span>27 |  ((arch arm64)
</span>28 |   (os macos)
</span>29 |   (sys-ocaml-version 5.3.1+relocatable)))
</span>Error: The lockdir does not contain a solution compatible with the current
</span>platfort.
</span>The current platform is:
</span>- arch = x86_64
</span>- os = win32
</span>- os-distribution = win32
</span>- os-family = windows
</span>- os-version = 10.0.22621
</span>- sys-ocaml-version = 5.3.1+relocatable
</span>Hint: Try adding the following to dune-workspace:
</span>Hint: (lock_dir (solve_for_platforms ((arch x86_64) (os win32))))
</span>Hint: ...and then rerun 'dune pkg lock'
</span></code></pre>
I’ve seen this error before while building ocamlformat</code>. Alice has its own
little opam repository</a> which
allows it to use the pre-compiled relocatable OCaml toolchain. The relocatable
OCaml toolchain has a version which is not released on the main opam repository
which means the ocaml-system</code> package can’t be used, so I needed to make a new
version of ocaml-system</code> matching the version of the pre-compiled toolchain
(5.3.1+relocatable</code>). I did this months ago when first getting Alice working
on Linux and macOS but the version of the ocaml-system</code> package originally had
some logic preventing its installation on Windows (copied from the upstream
ocaml-system</code> package), but that logic turned out to be unnecessary for my use
case so I just
deleted it</a>.
However I did so recently and that change hasn’t made its way into Alice yet.
Making that change to Alice was
straightforward:</p>
diff --git a/dune-workspace b/dune-workspace
</span>index bc77561..8d8b9db 100644
</span>---</span> a/dune-workspace
</span>+++</span> b/dune-workspace
</span>@@ -7,7 +7,7 @@
</span> (repository
</span>  (name alice_frozen)
</span>  (url
</span>-  git+https://github.com/alicecaml/alice-opam-repo#9957c6334ca7ea18a973ea2fa9e3e56ab9c85eeb))
</span>+</span>  git+https://github.com/alicecaml/alice-opam-repo#781db10863f3b7a3507842e88d0d3beeebd264ad))
</span>
</span> (repository
</span>  (name upstream_frozen)
</span>diff --git a/dune.lock/lock.dune b/dune.lock/lock.dune
</span>index 5ef36e2..fdc34a5 100644
</span>---</span> a/dune.lock/lock.dune
</span>+++</span> b/dune.lock/lock.dune
</span>@@ -12,7 +12,7 @@
</span>   ((source
</span>     https://github.com/ocaml-dune/opam-overlays.git#2a9543286ff0e0656058fee5c0da7abc16b8717d))
</span>   ((source
</span>-    https://github.com/alicecaml/alice-opam-repo#9957c6334ca7ea18a973ea2fa9e3e56ab9c85eeb))))
</span>+</span>    https://github.com/alicecaml/alice-opam-repo#781db10863f3b7a3507842e88d0d3beeebd264ad))))
</span>
</span> (solved_for_platforms
</span>  ((arch x86_64)
</span>@@ -26,4 +26,10 @@
</span>   (sys-ocaml-version 5.3.1+relocatable))
</span>  ((arch arm64)
</span>   (os macos)
</span>+</span>  (sys-ocaml-version 5.3.1+relocatable))
</span>+</span> ((arch x86_64)
</span>+</span>  (os win32)
</span>+</span>  (sys-ocaml-version 5.3.1+relocatable))
</span>+</span> ((arch arm64)
</span>+</span>  (os win32)
</span>   (sys-ocaml-version 5.3.1+relocatable)))
</span></code></pre>
Trying to build again:</p>
PS D:\src\alice> dune build
</span>    Building ocaml-system.5.3.1+relocatable
</span>    Building ocaml-config.3
</span>    Building ocaml.5.3.1+relocatable
</span> Downloading xdg.3.19.1
</span>    Building xdg.3.19.1
</span>    Building base-unix.base
</span>Shared cache miss [bc92329a7327ee6a16f45fa75edf32e5] (_build/_fetch/checksum/md5=a460f01d409d51b7d537429881bfa276/dir): error: Unix.Unix_error(Unix.EXDEV, "link", "_build/_fetch/checksum/md5=a460f01d409d51b7d537429881bfa276/dir/.gitignore")
</span> Downloading ISO8601.0.2.6
</span>    Building ISO8601.0.2.6
</span> Downloading menhirLib.20240715
</span> Downloading menhirSdk.20240715
</span> Downloading menhirCST.20240715
</span>    Building menhirLib.20240715
</span>    Building menhirSdk.20240715
</span>    Building menhirCST.20240715
</span> Downloading menhir.20240715
</span>    Building menhir.20240715
</span>Shared cache miss [919bb687d0058dc8265afa905483f2bd] (_build/_fetch/checksum/sha256=1d4e9c16ed9e24d46dd757ce94adc7fc8b2068eb5ff7cd2a70fce08135a752ef/dir): error: Unix.Unix_error(Unix.EXDEV, "link", "_build/_fetch/checksum/sha256=1d4e9c16ed9e24d46dd757ce94adc7fc8b2068eb5ff7cd2a70fce08135a752ef/dir/.gitignore")
</span> Downloading toml.7.1.0
</span>    Building toml.7.1.0
</span> Downloading stdlib-shims.0.3.0
</span>    Building stdlib-shims.0.3.0
</span> Downloading sha.1.15.4
</span>    Building sha.1.15.4
</span>    Building seq.base
</span> Downloading re.1.13.2
</span>    Building re.1.13.2
</span>Shared cache miss [806d141e2f359f01b7662634ccd5886d] (_build/_fetch/checksum/sha256=796d5791e2bf7b3bff200cf5057a7a1878439ebcd74ed0f1088cf86756d52be6/dir): error: Unix.Unix_error(Unix.EXDEV, "link", "_build/_fetch/checksum/sha256=796d5791e2bf7b3bff200cf5057a7a1878439ebcd74ed0f1088cf86756d52be6/dir/.gitignore")
</span> Downloading fileutils.0.6.6
</span>    Building fileutils.0.6.6
</span> Downloading ordering.3.19.1
</span> Downloading pp.2.0.0
</span>    Building pp.2.0.0
</span>    Building ordering.3.19.1
</span> Downloading dyn.3.19.1
</span>    Building dyn.3.19.1
</span> Downloading climate.0.8.0
</span>    Building climate.0.8.0
</span></code></pre>
That worked!</p>
I thought I might have to apply some of the hacks I wrote about while getting
ocamlformat</code> and ocamllsp</code> to build
(here</a>)
but fortunately not. Most of those problems come from the dependency on packages
that don’t use Dune as their build system, and I’ve avoided such packages in
Alice.</p>
The Shared cache miss</code> errors are benign, and I think related to
the fact that my user account in on a different partition to the project I’m
building, though it’s odd that it doesn’t happen for all the dependencies.</p>
PS D:\src\alice> ls .\_build\default\alice\src\alice.exe
</span>
</span>
</span>    Directory: D:\src\alice\_build\default\alice\src
</span>
</span>
</span>Mode                 LastWriteTime         Length Name
</span>----                 -------------         ------ ----
</span>-ar---        2025-08-28     02:51        7180768 alice.exe
</span>
</span>
</span>PS D:\src\alice> ls .\_build\install\default\bin\
</span>
</span>
</span>    Directory: D:\src\alice\_build\install\default\bin
</span>
</span>
</span>Mode                 LastWriteTime         Length Name
</span>----                 -------------         ------ ----
</span>-ar---        2025-08-28     02:51        7180768 alice.exe
</span>-ar---        2025-08-28     02:51        4825269 alice_demo.exe
</span></code></pre>
One difference I observe between building Alice on Windows verses Unix-based
OSes is that on Windows it’s very slow to compile. It took over 7 minutes.
One possibility is that I’m building Alice from a spinning disk drive. I use
this same computer for most of my OCaml development but usually booted into
Linux and I don’t remember if I use an SSD or spinning disk for that work but
I’ve never run into this type of performance issue there.</p>
The Shared cache miss</code> errors suggest something is going wrong accessing Dune’s
cache, and I see that rebuilding the project causes dependencies to be
downloaded again which also suggests a cache problem. As an experiment I deleted
the Dune cache from my Mac (a 2020 Macbook Air) and rebuilt Alice there, and from a
cold cache it took about a minute compared to 10 seconds building from scratch
on my Mac from a warm cache, so the caching issue on Windows probably has an
impact on the build time but it’s clearly not the full story.</p>
I tried copying the project into my Windows user account which is</em> on an SSD, and the
same partition as Dune’s cache. Rebuilding from a clean project with a cold
cache took almost 9 minutes this time but there were no cache errors. I think
this rules out the explanation that my spinning disk is the problem. Rebuilding
from a clean project a second time still caused the dependencies to be
re-downloaded so I’m not sure if the cache is even enabled (but then why the
cache errors when I was on a different drive?).</p>
Anyway incremental builds are still pretty fast and that’s
all I’ll be needing today so I’ll move on. The goal of this project isn’t to
debug Dune performance issues on Windows.</p>
Now that I have Alice building on Windows the next step is to make sure
ocamlformat</code> and ocamllsp</code> work and integrate them into my editor. I built
binary versions of these tools for Windows in preparation for today’s work but I
didn’t test them yet.</p>
I’m going to be using Neovim with the same
configuration</a> as I use
for development on Linux and macOS. It starts an ocamllsp</code> server upon opening
an OCaml source file and autoformats the code with ocamlformat</code> whenever I
save an OCaml source file.</p>
Both of these tools worked flawlessly on the first try.</p>
The next step is to add Windows support to the alice tools get</code> command which
downloads the OCaml development tools for the current platform. Alice currently
has no concept of Windows at all, and running that command on my machine prints
Unknown system: MSYS_NT-10.0-22631</code>.</p>
When Alice installs tools it creates a “root” which is a directory resembling a
typical Unix filesystem root, with subdirectories like bin</code> and share</code>. This
lets it include things like manual pages when installing tools as well as the
tools themselves. Over time I expect to support multiple different versions of the compiler
though currently 5.3.1+relocatable</code> is the only supported version. Similar
to rustup</code></a> it’s possible to change the
global root that is considered “active” by running the command alice tools change</code>. This creates a symlink at ~/.alice/current</code> pointing to (say)
~/.alice/roots/5.3.1+relocatable</code>.</p>
The problem is that creating a symlink on Windows requires admin permissions.
My solution is to copy the selected root into ~/.alice/current</code> instead.</p>
Now it works:</p>
PS D:\src\alice> alice tools get
</span>Fetching ocaml.5.3.1+relocatable...Done!
</span>Unpacking ocaml.5.3.1+relocatable...Done!
</span>Successfully installed ocaml.5.3.1+relocatable!
</span>
</span>Fetching ocamllsp.1.22.0...Done!
</span>Unpacking ocamllsp.1.22.0...Done!
</span>Successfully installed ocamllsp.1.22.0!
</span>
</span>Fetching ocamlformat.0.27.0...Done!
</span>Unpacking ocamlformat.0.27.0...Done!
</span>Successfully installed ocamlformat.0.27.0!
</span>
</span>No current root was found so making 5.3.1+relocatable the current root.
</span></code></pre>
Even though that command installed the same version of the tools I’m already
using, I updated my PATH</code> variable to include $HOME\.alice\current\bin</code>,
so now I have:</p>
PS D:\src\alice> Get-Command ocamlopt
</span>
</span>CommandType     Name          Version    Source
</span>-----------     ----          -------    ------
</span>Application     ocamlopt.exe  0.0.0.0    C:\Users\steph\.alice\current\bin\ocamlopt.exe
</span></code></pre>
Next up let’s see if it’s possible to create a new project using Alice on
Windows:</p>
PS D:\tmp> alice new foo
</span>Created new executable project in D:\tmp\foo
</span>
</span>PS D:\tmp> find foo
</span>foo
</span>foo/.gitignore
</span>foo/Alice.toml
</span>foo/src
</span>foo/src/main.ml
</span></code></pre>
Can we build it?</p>
PS D:\tmp\foo> alice build
</span>Program "ocamldep.opt" not found!
</span></code></pre>
I do have ocamldep.opt</code> installed as part of the OCaml compiler toolchain
however I suspect the .exe</code> extension is causing the problem:</p>
PS D:\tmp\foo> Get-Command ocamldep.opt
</span>
</span>CommandType Name             Version Source
</span>----------- ----             ------- ------
</span>Application ocamldep.opt.exe 0.0.0.0 C:\Users\steph\.alice\current\bin\ocamldep.opt.exe
</span></code></pre>
I updated Alice to include the .exe</code> on Windows. I also needed to update the
invocation of ocamlopt.opt</code> to ocamlopt.opt.exe</code>. After this change
alice build</code> could run successfully.</p>
PS D:\tmp\foo> alice build
</span>PS D:\tmp\foo> ls .\build\
</span>
</span>
</span>    Directory: D:\tmp\foo\build
</span>
</span>
</span>Mode                 LastWriteTime         Length Name
</span>----                 -------------         ------ ----
</span>-a----        2025-08-29     10:25        3134570 foo.exe
</span>-a----        2025-08-29     10:25            180 main.cmi
</span>-a----        2025-08-29     10:25            196 main.cmx
</span>-a----        2025-08-29     10:18             38 main.ml
</span>-a----        2025-08-29     10:25           1226 main.o
</span>
</span>PS D:\tmp\foo> .\build\foo.exe
</span>Hello, World!
</span></code></pre>
Alice has some commands for cleaning and running a project too:</p>
PS D:\tmp\foo> alice clean
</span>PS D:\tmp\foo> alice run
</span></code></pre>
Need to add some more printouts so it’s more clear when a command completes
successfully! In the case of alice run</code> something did go wrong since it didn’t
print “Hello, World!”. When I press enter again I see “Hello, World!” print at
the next prompt:</p>
PS D:\tmp\foo> alice run
</span>PS D:\tmp\foo> Hello, World!
</span></code></pre>
Alice runs programs with Unix.execv</code>. Here’s its documentation:</p>

execv prog args</code> execute the program in file prog</code>, with the arguments args</code>, and the current process environment. Note that the first argument, args.(0)</code>, is by convention the filename of the program being executed, just like Sys.argv.(0)</code>. These execv*</code> functions never return: on success, the current program is replaced by the new one.</p>
On Windows: the CRT simply spawns a new process and exits the current one. This will have unwanted consequences if e.g. another process is waiting on the current one. Using create_process</code> or one of the open_process_*</code> functions instead is recommended.</p>
@raise</strong></em> Unix_error</code> on failure</p>
</blockquote>
As the docs suggest I replaced Unix.execv</code> with Unix.create_process</code>.</p>
PS D:\tmp\foo> alice run
</span>Hello, World!
</span></code></pre>
Next I want to test alice dot</code> which prints the graphviz dot sourcecode for the
build graph:</p>
PS D:\tmp\foo> alice dot
</span>digraph {
</span>  "foo" -> {"main.cmx", "main.o"}
</span>  "main.cmx" -> {"main.ml"}
</span>  "main.o" -> {"main.ml"}
</span>}
</span></code></pre>
The .exe</code> is missing from the executable name. Windows obviously allows file
extensions like .exe</code> to be omitted under some conditions since alice run</code> was
able to execute foo.exe</code> without its extension. It would still be better to
include the file extension here and in any other debug output printed by Alice.
Another place where the extension is missing is from the build commands
themselves. Rerunning the build with verbose logging:</p>
PS D:\tmp\foo> alice build -vv
</span>[DEBUG] copying source file: main.ml
</span>[DEBUG] running build command: ocamlopt.opt.exe -g -c main.ml
</span>[DEBUG] running build command: ocamlopt.opt.exe -g -o foo main.cmx
</span></code></pre>
The OCaml compiler is clearly able to add the appropriate extension even though
it was omitted from -o foo</code> but it would still be better to update the build
rules so that on Windows they use the correct extension for executable files.</p>
PS D:\tmp\foo> alice build -vv
</span>[DEBUG] copying source file: main.ml
</span>[DEBUG] running build command: ocamlopt.opt.exe -g -c main.ml
</span>[DEBUG] running build command: ocamlopt.opt.exe -g -o foo.exe main.cmx
</span>
</span>PS D:\tmp\foo> alice dot
</span>digraph {
</span>  "foo.exe" -> {"main.cmx", "main.o"}
</span>  "main.cmx" -> {"main.ml"}
</span>  "main.o" -> {"main.ml"}
</span>}
</span></code></pre>
Just for fun here’s a render of the graph made with alice dot | dot -Tsvg > graph.svg</code>
showing dependencies between build artifacts and source files.</p>
</p>
I added a second source file and interface to exercise Alice on a slightly less
trivial case:</p>
PS D:\tmp\foo> alice build -vv
</span>[DEBUG] copying source file: foo.mli
</span>[DEBUG] running build command: ocamlopt.opt.exe -g -c foo.mli
</span>[DEBUG] copying source file: foo.ml
</span>[DEBUG] running build command: ocamlopt.opt.exe -g -c foo.ml
</span>[DEBUG] copying source file: main.ml
</span>[DEBUG] running build command: ocamlopt.opt.exe -g -c main.ml
</span>[DEBUG] running build command: ocamlopt.opt.exe -g -o foo.exe foo.cmx main.cmx
</span></code></pre>
</p>
I did a little more work not directly relating to supporting Windows but which
will make it easier for Alice to find the OCaml compiler, assuming the toolchain
was installed by Alice. If Alice would run an external program (such as the
OCaml compiler) and the program isn’t in the user’s PATH</code> variable then Alice
will run the program from the current root (like ~/.alice/current</code>). This
will make Alice easier to set up since it removes the need to add
~/.alice/current/bin</code> to PATH</code>.</p>
And now Alice works on Windows!</p>
You need to be in Powershell rather than CMD.exe, and you’ll need a C compiler
like LLVM installed an in your PATH</code> for the OCaml compiler to work
correctly. After that, as long as alice.exe</code> is in your PATH</code>, just run
run alice tools get</code> to install the OCaml compiler and dev tools, alice new <NAME></code>
to make a new project, and alice run</code> from within the new project’s directory
to run the project.</p>
</p>
Alice is highly experimental and far from ready for everyday use. The next step
will be allowing Alice packages to depend on each other.</p>

Release Notes</a></h2>
Changed</a></h3>

Use kdl</a> rather than toml for manifests. More info here</a>.</li> </ul>
Fixed</a></h3>

Replace panics with user exceptions in some cases</li>
Detect case when the name of a dependency doesn’t match the name of the specified package</li> </ul>

Changed</a></h3>

Use kdl</a> rather than toml for manifests. More info here</a>.</li> </ul>
Fixed</a></h3>

Replace panics with user exceptions in some cases</li>
Detect case when the name of a dependency doesn’t match the name of the specified package</li> </ul>

Fixed</a></h3>

Replace panics with user exceptions in some cases</li>
Detect case when the name of a dependency doesn’t match the name of the specified package</li> </ul>

Release Notes</a></h2>
Changed</a></h3>

Follow the XDG convention when installing tools.</li> </ul>
Fixed</a></h3>

Update dot-merlin-reader on windows to fix crash on launch.</li>
Fix issue running `alice tools exec</code> on windows in CMD.exe.</li> </ul>`

Changed</a></h3>

Follow the XDG convention when installing tools.</li> </ul>
Fixed</a></h3>

Update dot-merlin-reader on windows to fix crash on launch.</li>
Fix issue running `alice tools exec</code> on windows in CMD.exe.</li> </ul>`

Fixed</a></h3>

Update dot-merlin-reader on windows to fix crash on launch.</li>
Fix issue running `alice tools exec</code> on windows in CMD.exe.</li> </ul>`

Release Notes</a></h2>
Added</a></h3>

Generate files necessary to support ocamllsp.</li> </ul>
Changed</a></h3>

Switch to github for hosting tool archives.</li>
Display progress bar while downloading tools.</li> </ul>

Added</a></h3>

Generate files necessary to support ocamllsp.</li> </ul>
Changed</a></h3>

Switch to github for hosting tool archives.</li>
Display progress bar while downloading tools.</li> </ul>

Changed</a></h3>

Switch to github for hosting tool archives.</li>
Display progress bar while downloading tools.</li> </ul>

Release Notes</a></h2>
Added</a></h3>

Add a patch that replaces the locked compiler version with a template string to simplify packaging</li> </ul>

Added</a></h3>

Add a patch that replaces the locked compiler version with a template string to simplify packaging</li> </ul>

Alice the Caml

Alice v0.5.0

Release Notes</a></h2>
Changed</a></h3>

Parallel builds</li> </ul>

Changed</a></h3>

Parallel builds</li> </ul>

Parallel Alice without Eio

Parallel Alice

Alice v0.4.0

Switching Manifests to KDL

Alice v0.3.0

Alice v0.2.0

Alice v0.1.3

Buzz

Alice v0.1.2

Package Hygiene in Alice

Alice v0.1.1

Alice v0.1.0

Alice as a Toolchain Manager for Dune Projects

Introducing Alice

Porting Alice to Windows