Installer omake avec Homebrew, apt, MacPorts, Nix, dnf

Liens du projet

• Page d'accueil
• Dépôt
• Docs amont
• Page du gestionnaire de paquets

Commandes et alias

• omake

Historique du projet

The public project page describes OMake as a build system designed for scalability and portability and notes its move from metaprl.org to camlcity.org. The opam package metadata credits Aleksey Nogin, Jason Hickey, and Gerd Stolpmann as authors, with Gerd Stolpmann listed as maintainer for the opam package.

The 2006 paper 'OMake: Designing a Scalable Build Process' framed OMake as a domain-specific programming problem. Its central goals were compositional project descriptions, concise small-project rules, and enough expressive power for larger builds.

Historique d'adoption

OMake became part of the OCaml build-tool landscape before newer tools such as Jenga and Dune changed common practice. Jane Street's retrospective on Jenga says that around 2012 OMake was one of OCaml's standard build systems, which is a useful adoption marker from a large OCaml user rather than a package index alone.

The project later consolidated maintenance under the ocaml-omake GitHub organization, while package managers such as opam, Debian, Ubuntu, Homebrew, MacPorts, Nix, and Fedora-family repositories kept shipping it for legacy and active projects.

Modes d'utilisation

A typical OMake project has an OMakeroot at the repository root and OMakefile files in project directories. When omake runs, it walks the configuration tree, evaluates the OMakefiles, and builds with global knowledge of the project rather than invoking independent recursive make processes.

OMake users reach for it when they want automatic dependency analysis, digest-based incremental rebuilds, OCaml-oriented rules, cross-directory builds, and a programmable build language without writing raw Makefile plumbing for every subdirectory.

Pourquoi les passionnés de paquets s'y intéressent

OMake is historically interesting because it captures an OCaml ecosystem moment before Dune became dominant. It is also a tidy example of a build tool whose design arguments were documented in an academic paper, then lived on as a real package carried by many operating-system distributions.

For package metadata, OMake is the kind of tool whose value is not measured only by repository activity: old build systems remain important because they are encoded into source releases, downstream package recipes, and long-lived project build instructions.

Chronologie

• 2006: the OMake design paper is published, presenting the build system as a scalable build-process DSL.
• The project moves from metaprl.org to camlcity.org, according to the official project page.
• 2012: Jane Street's Jenga history describes OMake as one of OCaml's standard build systems at the time.
• 2014: the ocaml-omake/omake GitHub repository is created, becoming the public maintenance home linked from package metadata.

Related projects

• OMake sits beside GNU Make, OCamlMakefile, ocamlbuild, Jenga, and Dune in OCaml build history. Its project-wide analysis model also makes it a useful contrast with recursive make patterns.

Sources

• https://api.github.com/repos/ocaml-omake/omake
• https://blog.janestreet.com/how-we-accidentally-built-a-better-build-system-for-ocaml-index/
• https://dl.acm.org/doi/10.1007/11693017_7
• https://github.com/ocaml-omake/omake
• https://github.com/ocaml/opam-repository/blob/master/packages/omake/omake.0.10.7/opam
• https://projects.camlcity.org/projects/dl/omake-0.10.5/doc/html/omake-quickstart.html
• https://projects.camlcity.org/projects/omake.html