| 3 | | = Build Types and Goals = |
| 4 | | |
| 5 | | == Novice User == |
| 6 | | |
| 7 | | In this build type, a user downloads the tahoe source and everything is as automatic as possible. Internet access is assumed, and there is nothing wrong with using it. |
| 8 | | |
| 9 | | == Developer == |
| 10 | | |
| 11 | | In this build type, someone would like to make changes to tahoe, and gets source from git. TODO |
| 12 | | |
| 13 | | == Packaging System == |
| 14 | | |
| 15 | | In this build type, the build user is a packager of rpms/debs or pkgsrc. Rather than convenience, the concern is a stable and repeatable build that produces exactly the same output bits regardless of which prereqs were already installed. Using the network is not acceptable. |
| 16 | | |
| 17 | | Within a packaging system, there are typically build phases, loosely derived from how autoconf works. |
| 18 | | |
| 19 | | * fetch: obtain the "distfiles" (tarballs published by e.g. the tahoe project) |
| 20 | | * patch: apply OS-local/pkgsrc-local changes (goal is to drive these to zero) |
| 21 | | * configure: search for dependencies and configure paths |
| 22 | | * build: compile sources to object form, run nroff to make man pages, etc. |
| 23 | | * install: place bits either in the running system or in a destdir, suitable for running |
| 24 | | * package: create a binary package from the installed bits |
