dash/depends/description.md
fanquake 685ee8a46f
Merge bitcoin/bitcoin#28884: doc: remove x86_64 build assumption from depends doc
821a8a11256ccf26fe8b0255cea4ec04dddd8f18 doc: remove x86_64 build assumption from depends doc (fanquake)

Pull request description:

  This dates from the introduction of depends, and has not been the case for some time now.

ACKs for top commit:
  maflcko:
    lgtm ACK 821a8a11256ccf26fe8b0255cea4ec04dddd8f18
  hebasto:
    ACK 821a8a11256ccf26fe8b0255cea4ec04dddd8f18.
  theuni:
    ACK 821a8a11256ccf26fe8b0255cea4ec04dddd8f18

Tree-SHA512: 640967a3e6dfab495fd733d3379aa916ac7f67e89a92ef6a94c3bea0494dc7921a9d7485e1b90a1beab00548b575cdab8fb08eb9267dcc5e890cc796ae1b6875
2024-10-24 13:50:33 -05:00

53 lines
2.4 KiB
Markdown

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