aboutsummaryrefslogtreecommitdiff
path: root/config/dune
AgeCommit message (Collapse)Author
2020-03-03[dune] Fix bug in auto-configure deps.Emilio Jesus Gallego Arias
`plugins` needs to be present to coq_makefile variables are properly initialized.
2019-12-07[configure] [dune] Fix configure under Dune in 32bit builds.Emilio Jesus Gallego Arias
`dev/header.c` is not registered as a dependency, so the configure step under dune fails in 32bit builds. Note we don't detect the problem due to dubious code in configure ignoring stderr messages on process calls.
2019-11-11Have only one dune rule calling configurePierre Roux
2018-12-13[dune] [doc] Support for building the reference manual with Dune.Emilio Jesus Gallego Arias
This is a reduced version of #8503 as to provide a way to build the reference manual with Dune. Dune 1.6 supports (experimentally) directories as targets, thus we introduce a rule that will call `sphinx` to build the manual. This only provides build, however generation of `.install` rules is not done, it will be hopefully addressed in #8503. Note that we set `expire: 1 month` for all the artifacts we build with Dune. IMHO this makes most sense as not to abuse Gitlab's hosting, however of course we could consider a different deployment strategy if wanted.
2018-10-11[dune] [test-suite] Support for running the test suite with Dune.Emilio Jesus Gallego Arias
2018-09-27[configure] [dune] Don't force the Dune user to set envars.Emilio Jesus Gallego Arias
In order to support sending the OPAM prefix to configure via Dune, we introduced a `COQ_CONFIGURE_PREFIX` variable. However, this had the pitfall that now the developer had to set it or else face a hanging build due to configure expecting user input. While we wait for a larger cleanup in `-prefix`, we introduce a `no-ask` option in `./configure` that will avoid this problem. If `-no-ask` is passed to `configure` no interactive question or display will be shown to the user.
2018-09-21[dune] [configure] Allow to set prefix using environment variable.Emilio Jesus Gallego Arias
This is a hack to enable correct OPAM building, the medium-term plan is to avoid having to set a prefix at configure time but instead using a set of rules to locate the Coq library. We use `(env_var ...)` in a dependency rule, which a feature of Dune 1.2
2018-09-05[build] Preliminary support for building Coq with `dune`.Emilio Jesus Gallego Arias
[Dune](https://github.com/ocaml/dune) is a compositional declarative build system for OCaml. It provides automatic generation of `version.ml`, `.merlin`, `META`, `opam`, API documentation; install management; easy integration with external libraries, test runners, and modular builds. In particular, Dune uniformly handles components regardless whether they live in, or out-of-tree. This greatly simplifies cases where a plugin [or CoqIde] is checked out in the current working copy but then distributed separately [and vice-versa]. Dune can thus be used as a more flexible `coq_makefile` replacement. For now we provide experimental support for a Dune build. In order to build Coq + the standard library with Dune type: ``` $ make -f Makefile.dune world ``` This PR includes a preliminary, developer-only preview of Dune for Coq. There is still ongoing work, see https://github.com/coq/coq/issues/8052 for tracking status towards full support. ## Technical description. Dune works out of the box with Coq, once we have fixed some modularity issues. The main remaining challenge was to support `.vo` files. As Dune doesn't support custom build rules yet, to properly build `.vo` files we provide a small helper script `tools/coq_dune.ml`. The script will scan the Coq library directories and generate the corresponding rules for `.v -> .vo` and `.ml4 -> .ml` builds. The script uses `coqdep` as to correctly output the dependencies of `.v` files. `coq_dune` is akin to `coq_makefile` and should be able to be used to build Coq projects in the future. Due to this pitfall, the build process has to proceed in three stages: 1) build `coqdep` and `coq_dune`; 2) generate `dune` files for `theories` and `plugins`; 3) perform a regular build with all targets are in scope. ## FAQ ### Why Dune? Coq has a moderately complex build system and it is not a secret that many developer-hours have been spent fighting with `make`. In particular, the current `make`-based system does offer poor support to verify that the current build rules and variables are coherent, and requires significant manual, error-prone. Many variables must be passed by hand, duplicated, etc... Additionally, our make system offers poor integration with now standard OCaml ecosystem tools such as `opam`, `ocamlfind` or `odoc`. Another critical point is build compositionality. Coq is rich in 3rd party contributions, and a big shortcoming of the current make system is that it cannot be used to build these projects; requiring us to maintain a custom tool, `coq_makefile`, with the corresponding cost. In the past, there has been some efforts to migrate Coq to more specialized build systems, however these stalled due to a variety of reasons. Dune, is a declarative, OCaml-specific build tool that is on the path to become the standard build system for the OCaml ecosystem. Dune seems to be a good fit for Coq well: it is well-supported, fast, compositional, and designed for large projects. ### Does Dune replace the make-based build system? The current, make-based build system is unmodified by this PR and kept as the default option. However, Dune has the potential ### Is this PR complete? What does it provide? This PR is ready for developer preview and feedback. The build system is functional, however, more work is necessary in order to make Dune the default for Coq. The main TODOs are tracked at https://github.com/coq/coq/issues/8052 This PR allows developers to use most of the features of Dune today: - Modular organization of the codebase; each component is built only against declared dependencies so components are checked for containment more strictly. - Hygienic builds; Dune places all artifacts under `_build`. - Automatic generation of `.install` files, simplified OPAM workflow. - `utop` support, `-opaque` in developer mode, etc... - `ml4` files are handled using `coqp5`, a native-code customized camlp5 executable which brings much faster `ml4 -> ml` processing. ### What dependencies does Dune require? Dune doesn't depend on any 3rd party package other than the OCaml compiler. ### Some Benchs: ``` $ /usr/bin/time make DUNEOPT="-j 1000" -f Makefile.dune states 59.50user 18.81system 0:29.83elapsed 262%CPU (0avgtext+0avgdata 302996maxresident)k 0inputs+646632outputs (0major+4893811minor)pagefaults 0swaps $ /usr/bin/time sh -c "./configure -local -native-compiler no && make -j states" 88.21user 23.65system 0:32.96elapsed 339%CPU (0avgtext+0avgdata 304992maxresident)k 0inputs+1051680outputs (0major+5300680minor)pagefaults 0swaps ```