2a38bf2961
* cleanup patches
* fix polyseed patch
* Fix iOS builds
* fix polyseed dependencies
* fix polyseed patch for macOS
* update ledger patch
* update wownero patches and version
* update checksums
* wip"
* update gitmodules
* update boost build script
* update build_single.sh
* vix verbosey_copy
* fix __clear_cache bug on wownero
* update randomwow
* migrate build system
* fix cross compilation issues
* some more build issue
* update polyseed
* cleanup cmakelists
* fix toolchain.cmake.in
* add ssp
* another attempt at building windows on CI
* fix package name
* migrate mirror to my own hosting
* change download mirror priority (fallback first)
* link ssp in monero module as well by using CMAKE_{C,CXX}_FLAGS
* fix android builds
* update polyseed source
* 13 -> trixie
* fix package name conflicts, update runner to sid
* update boost to 1_84_0, disable patch that's no longer needed
* switch to ubuntu:24.04
* add POLYSEED_STATIC to toolchain.cmake.in in order to properly link
* drop patches
* fixes to darwin
* link missing wowner-seed library
* a litte bit more of experiments
* build locale only on windows
* update iconv
* update definitions
* update ci builds
* update my progress
* ios fix, update depends, ci
* multithread build system
* fix android, mingw and linux build issues
* remove dependency check
* update Dockerfile to include pigz
* show a message when pigz is missing
* fix devcontainer mingw setup (missing ENV)
* update android build runner
* sailfishos dropped (you better go behave yourself and run actual linux programs)
* fiz pigz issues
* install llvm-ranlib for android
* fix iOS build issues
* fix dummy ledger patch
* fix macos and darwin
* fix macos ci
* fix macos build command
* install autoconf
* add automake
* add libtool
* macos fixes, wownero fixes, idk what else, please help me
* fix wownero iOS build
* Cleanup patches
* add try-catch into monero code
* fix error handling
* update checksums
2.5 KiB
This is a system of building and caching dependencies necessary for building Bitcoin. 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. For now, a build architecture of x86_64 is assumed, either on Linux or OSX.
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.