but make sure to keep a consistent dune profile otherwise for `make all`,
avoiding multiple rebuilds.
This saves 30s CPU time on a `make all` that doesn't specify
`DUNE_PROFILE=release`
* Use the newer "pyproject.toml" for syntax highlighters
* Use venv for everything (previously, the pygment lexers were installed
globally, but more recent Python releases frown upon that. This will probably
be more stable in the long run...)
* Use one venv at the root of the project (`_python_venv/`) for both
pygments and the runtime
* Initialise this venv automatically from the Makefile (it should no longer be
necessary to run scattered `set_up.sh` scripts with mysterious interactions)
On the downsides, though:
* Only tested with Python 3.11 at the moment
* Need to remember to activate the venv (`. _python_venv/bin/activate`) from the
root for e.g. HTML literate output to work. A more manageable solution could
be for Catala to provide the lexers on-the-fly when calling `pygmentize`.
- fix dune compilation options: ensure both no dev failure on warnings and CI
failure on warnings (the defaults do neither of those things !)
- attempt to publish the build artifacts to github-pages, so that they could be
made more easily available and we could maybe remove the ones that are still
there from the main repo
Dune has 2 default build profiles: `dev` and `release`, which change things like warnings-as-errors, and debug in jsoo build mode.
We need to be in release mode when we generate the javascript artifacts (e.g. `make website-assets`), so the master `Makefile` had `--profile=release` for the `dune` commands building them. However, that rebuilds _the whole tree of dependencies_ in release mode, which means `make all` might rebuild everything several times, as the `release` flag is turned off and on. I had conflicting plugins that weren't rebuilt with the correct flag. And let's not imagine the `make -j` case…
This is the best solution I can think of for the time being:
- set the Makefile to use dune's `release` profile by default
- this ensure consistency and avoids surprises with e.g. bad (slower) artifacts
generated for the website
- devs can use `dune` directly when working, or set `DUNE_PROFILE` manually if
they need it
I am not sure yet about CI, though, since we want warnings-as-errors but also
useful artifacts. Might best to build twice…
The files where manually generated through Makefile rules, and
versionned (with an outdated version).
The issue was that we had:
- `dune` building Catala
- Makefiles calling `catala` to build and copy the `french_law/ocaml/law_source`
files
- then `dune` again to build `french_law`
The result was that `dune build` (without running `make` first) would
return a weird error.
The proposed solution adds ad-hoc dune rules to call the catala
binary, so that it can handle the whole pipeline correctly. If OCaml
is purely a backend, though, a simpler solution that makes us less
dependent on dune would be to handle the compilation of `french_law`
manually.
The dune rules are set to 'promote' the files so that it preserves the
fact that they are versionned (but with no confusion of the build system
about where they should come from anymore)
- one that is just the same as the python backend
- one that is a quick'n'dirty call to js_of_ocaml on top of the ocaml backend to
generate js files
Use `make plugins` to test them. They are only expected to be useful as
demonstrations of how to write plugins.
