-
Notifications
You must be signed in to change notification settings - Fork 1.1k
/
opam
153 lines (114 loc) · 6.16 KB
/
opam
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
opam-version: "2.0"
maintainer: "Gabriel Radanne <drupyog@zoho.com>"
authors: [ "Thomas Gazagnaire"
"Anil Madhavapeddy"
"Dave Scott"
"Thomas Leonard"
"Gabriel Radanne" ]
homepage: "https://github.com/mirage/functoria"
bug-reports: "https://github.com/mirage/functoria/issues"
dev-repo: "git+https://github.com/mirage/functoria.git"
doc: "https://mirage.github.io/functoria/"
license: "ISC"
tags: ["org:mirage"]
build: [
["jbuilder" "subst" "-p" name] {dev}
["jbuilder" "build" "-p" name "-j" jobs]
]
depends: [
"ocaml" {>= "4.03" & < "4.12"}
"jbuilder" {>= "1.0+beta10"}
"cmdliner" {>= "0.9.8"}
"fmt"
"functoria" {with-test & >= "2.2.0" & < "3.0.0"}
"alcotest" {with-test}
]
synopsis: "A DSL to organize functor applications"
description: """
[![Build Status](https://travis-ci.org/mirage/functoria.svg?branch=master)](https://travis-ci.org/mirage/functoria)
[![docs](https://img.shields.io/badge/doc-online-blue.svg)](https://mirage.github.io/functoria/index.html)
## What is this for?
Functoria is a DSL to describe a set of modules and functors, their types and how to apply them in order to produce a complete application.
The main use case is mirage. See the [mirage][] repository for details.
## How to write a configuration file?
There are numerous examples of configuration files in [mirage-skeleton][]. Most of them should be fairly general and understandable, even outside the context of mirage. We can distinguish two parts in a `config.ml`: Defining new modules and using them.
In order to define a new module, we use the `foreign` function. Among its various arguments, it takes a module name and a type. The type is assembled with the DSL's combinators and the `@->` operator, which symbols a functor arrow.
```ocaml
let main = foreign "Unikernel.Main" (console @-> job)
```
Here, we declare the functor `Unikernel.Main` that takes a module that should be a `console` and returns a module that is a `job`. It is up to the user to ensure that the declaration matches the implementation (or be punished by a compiler error later on). If the declaration is correct, everything that follows will be.
We can now use this declaration:
```ocaml
let () = register "console" [main $ default_console]
```
Here, we register a new application with the `register` function. This function should only be called once and takes as argument the name of the application and a list of jobs. We use the `$` operator to apply the functor `main` (aka `Unikernel.Main`) to the default console.
Now that everything is ready, you can use the `configure` subcommand!
### What is a job?
A job is a module containing a function `start`. This function will receive one argument per functor argument and one per dependency, in this order. `foreign` assumes the function `start` returns `unit`.
### Defining new keys
A key is composed of:
- _name_ : The name of the value in the program.
- _description_ : How it should be displayed/serialized.
- _stage_ : Is the key available only at runtime, at configure time or both?
- _documentation_ : It is not optional so you should really write it.
Consider a multilingual application: we want to pass the default language as a parameter. We will use a simple string, so we can use the predefined description `Key.Desc.string`. We want to be able to define it both at configure and run time, so we use the stage `` `Both``. This gives us the following code:
```ocaml
let lang_key =
let doc = Key.Arg.info
~doc:"The default language for the application." [ "l" ; "lang" ]
in
Key.create "language" @@ Key.Arg.(opt ~stage:`Both string "en" doc)
```
Here, we defined both a long option `--lang` and a short one `-l` (the format is similar to the one used by [Cmdliner][cmdliner]).
In the application code, the value is retrieved with `Key_gen.language ()`.
The option is also documented in the `--help` option for both the `configure` subcommand (at configure time) and `./my_application` (at startup time).
```
-l VAL, --lang=VAL (absent=en)
The default language for the application.
```
[cmdliner]: http://erratique.ch/software/cmdliner
### Using switching keys
We can do much more with keys: we can use them to switch implementation at configure time. Imagine we want to completely change some implementation based on the language. Finns are special snowflakes, they deserve their special application!
First, we have to compute a boolean value from `lang`:
```ocaml
let is_fi = Key.(pure ((=) "fi") $ value lang_key)
```
We can use the `if_impl` combinator to choose between two implementations depending on the value of the key:
```ocaml
let dynamic_storage =
if_impl is_fi
finnish_implementation
not_finnish_implementation
```
This distinction will be visible using the `describe` subcommand and a dot diagram is available with the `--dot` option!
## Internals
### Phases
Configuration is separated into phases:
1. Specialized DSL keys
The specialized DSL's keys (along with functoria's keys) are resolved.
2. Compilation and dynlink of the config file.
3. Registering.
When the `register` function is called, the list of jobs is recorded and
immediately transformed into a graph.
4. Switching keys and tree evaluation.
The switching keys are the keys inside the [If].
Those keys are resolved and the graph is simplified. At this point,
the actual modules used are fully known.
Note: for the `describe` command, Only _partial_ evaluation is done, which
means decision nodes are resolved only if the value was given on the command
line, disregarding default values.
5. Full Key resolution.
Once the actual modules are known, we can resolve all the keys and figure out
libraries and packages.
6. Dependency handling, configuration and code emission.
Phases 1. to 4. are also applied for the `clean` command.
[mirage]: https://github.com/mirage/mirage
[mirage-skeleton]: https://github.com/mirage/mirage-skeleton"""
url {
src:
"https://github.com/mirage/functoria/releases/download/2.2.1/functoria-2.2.1.tbz"
checksum: [
"sha256=e2c883d5a0a2c3cea59cffa9989c5ee78259aee9a199048cb730d19076e668c5"
"md5=ec768d65f4070dd76c369b4a32a1ac32"
]
}