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