]>
Commit | Line | Data |
---|---|---|
cc3db874 | 1 | This is a system of building and caching dependencies necessary for building Bitcoin. |
1dec09b3 CF |
2 | There are several features that make it different from most similar systems: |
3 | ||
cc3db874 | 4 | ### It is designed to be builder and host agnostic |
1dec09b3 CF |
5 | |
6 | In theory, binaries for any target OS/architecture can be created, from a | |
7 | builder running any OS/architecture. In practice, build-side tools must be | |
5a809ef0 | 8 | specified when the defaults don't fit, and packages must be amended to work |
1dec09b3 CF |
9 | on new hosts. For now, a build architecture of x86_64 is assumed, either on |
10 | Linux or OSX. | |
11 | ||
cc3db874 | 12 | ### No reliance on timestamps |
1dec09b3 CF |
13 | |
14 | File presence is used to determine what needs to be built. This makes the | |
15 | results distributable and easily digestable by automated builders. | |
16 | ||
cc3db874 | 17 | ### Each build only has its specified dependencies available at build-time. |
1dec09b3 CF |
18 | |
19 | For each build, the sysroot is wiped and the (recursive) dependencies are | |
20 | installed. This makes each build deterministic, since there will never be any | |
21 | unknown files available to cause side-effects. | |
22 | ||
cc3db874 | 23 | ### Each package is cached and only rebuilt as needed. |
1dec09b3 CF |
24 | |
25 | Before building, a unique build-id is generated for each package. This id | |
26 | consists of a hash of all files used to build the package (Makefiles, packages, | |
27 | etc), and as well as a hash of the same data for each recursive dependency. If | |
28 | any portion of a package's build recipe changes, it will be rebuilt as well as | |
29 | any other package that depends on it. If any of the main makefiles (Makefile, | |
30 | funcs.mk, etc) are changed, all packages will be rebuilt. After building, the | |
31 | results are cached into a tarball that can be re-used and distributed. | |
32 | ||
cc3db874 | 33 | ### Package build results are (relatively) deterministic. |
1dec09b3 CF |
34 | |
35 | Each package is configured and patched so that it will yield the same | |
36 | build-results with each consequent build, within a reasonable set of | |
37 | constraints. Some things like timestamp insertion are unavoidable, and are | |
38 | beyond the scope of this system. Additionally, the toolchain itself must be | |
39 | capable of deterministic results. When revisions are properly bumped, a cached | |
40 | build should represent an exact single payload. | |
41 | ||
cc3db874 | 42 | ### Sources are fetched and verified automatically |
1dec09b3 CF |
43 | |
44 | Each package must define its source location and checksum. The build will fail | |
45 | if the fetched source does not match. Sources may be pre-seeded and/or cached | |
46 | as desired. | |
47 | ||
cc3db874 | 48 | ### Self-cleaning |
1dec09b3 CF |
49 | |
50 | Build and staging dirs are wiped after use, and any previous version of a | |
51 | cached result is removed following a successful build. Automated builders | |
52 | should be able to build each revision and store the results with no further | |
53 | intervention. |