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
[]
= "yo-cli"
= "The yo command line tool."
= true
= true
= true
= true
= true
= true
= true
= true
= true
[]
= true
[]
# The global allocator, which is an application's choice and never a library's,
# so this is where it gets made. Off unless YO_ALLOC says otherwise.
= { = true }
# `yodb check` reads the file with the independent reader rather than the engine,
# on purpose. A checker that shares its idea of the format with the thing that
# wrote the file agrees with it about everything, including the mistakes.
= { = true }
# `yodb serve` is the socket in front of the engine. The engine writes into a
# sink and this crate is where that sink is a socket, which keeps the protocol
# crate free of any idea of what a network is.
= { = true }
= { = true }
# `yodb serve` asks the kernel which connections are ready rather than trying
# every one of them, which is `epoll` on Linux and `kqueue` on macOS.
[]
= { = true }
# The same question on Windows, which answers it with `WSAPoll`. One feature and
# not the whole of windows-sys, because the crate is generated from the entire
# Windows API and the default is nothing at all.
[]
= { = true, = ["Win32_Networking_WinSock"] }
# The tests are the one place both sides are allowed in the same binary. They
# build real files with the engine and then check them with the tool, which is
# the only way to find out whether the tool would notice anything.
[]
= { = true }
= { = true }
= { = true }
# The executable is `yodb`, not `yo`. `yo` on PATH is Yeoman's, and is Yeoman's
# on Homebrew core, Chocolatey and the AUR, so shipping `yo` means shipping a
# collision into every one of those channels. Only the executable moves: the
# crate is yodb, the library is libyo, the header is yo.h, the symbols are yo_*
# and the extension is .yo. dx/16 section 3.3 has the probe this came from.
[[]]
= "yodb"
= "src/main.rs"