You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

description.md 2.5KB

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