builder
Unless you are creating a Linux distro that is a fork of another one with a well stocked software repository, the thought of having to build one from scratch is breath taking. To tackle the thousands of source code downloads, applying necessary patches, figuring out the proper compile flags and various make systems (autogen, autoconf, bootstrap, cmake, etc), and applying file and directory ownership and permissions is quite a job! Fortunately builder will handle all of these tasks for you and already comes with a large pool of software profiles that can be tailored to your individual needs, or left to assume defaults.
What about if your repo is already a mess
- names are not uniform
Example: foo.tcz in x86 might be foo-ng.tcz in x86_64
- packages are not split the same way
Example: foo.tcz in x86 might include binaries, documentation, and libraries, whereas there might be foo.tcz, foo-lib.tcz, foo-doc.tcz in x86_64)
- the existence of a package in one repo does not mean it is available in another
Example: foo.tcz exists for x86, but not for x86_64 or rpi
- the source code used to build the packages may not be the same
Example: foo.tcz in x86 might be using 1.2.3 version of source code and the x86_64 might use 1.3.4
- the compile flags are not the same
Example: foo.tcz in x86 might use "--option1=xyz --option2 --option3", whereas "--option2 --option5" may be used to compile for x86_64
- the file and directory permissions are not set correctly
benefits:
constant updates
consistency between CPU architectures
an immediate access to a large repository of software
License
This projects' codebase is licensed under the 2-clause BSD which can be found at "Wikipedia".
Features
While there may be more features than are currently listed below, this should give potential users at least a portion of the currently implemented features.
- Simple syntax for easy compiling no matter build system
- Works with autogen, autoconf, bootstrap, cmake, and traditional
- Extreme flexibility using various pre and post step scripts
- Can pull source code from private or public locations
- Small footprint - contains only two files!
- Portable using POSIX shell
PARAMETERS
Among the standard 'help' and 'version' actions, this project also contains several others that will be covered below in greater detail.
- -a allows the user to specify which CPU architecture to use during the compile process. Currently builder supports three including ARM v6/7 (r32) and AMD/Intel 32-bit (i32) and 64-bit (i64). The former is typically used for Raspberry Pi boards.
- -d is used to build packages based on directory names instead of the supplied package name via the '-n' parameter. So, for example, if you need to create several packages from a single execution of builder such as alsa and alsa-config, you can pass this parameter to accomplish this task. It is important to note, however, that the directory names will become the package names and will need to be setup in the various pre/post scripts.
- -D in the instance that you have an online repo setup with the source code files already located there, passing this switch can automatically download those files instead of the package maintainer having to manually find and download it beforehand. It uses the URL_CODE value from the builder.conf file in order to locate the proper source tarball from you repo.
- -L similar to the '-D' option, this one will use a local (networked|attached) resource to fetch the source code files instead of having to go over the Internet. This one works with the DIR_REPO variable value in the builder.conf file.
- -n indicates the name of the package to create and requires a builder profile under /etc/builder that has the same directory name.
- -p provides the number of passes to take in order to fully compile, sort, and package a particular software. For example, php can have multiple passes to create various related packages without having to entirely recompile the source code. There are also some packages that have to start a compilation, then move files around, then re-compile in order for the end result to be correct - typically involving database interaction.
- -P states that on a follow-up attempt at building a software due to a failure, that the patches should not be re-applied since that will cause another failure in the build process. Please note, that this is not the appropriate parameter to use if you don't want patches applied for a particular pass. See the information on the various builder files below.
- -r defines phrases that can be removed from the package name and can contain regular expressions. So, for example, lets say you want to have 'lib' removed from 'libassuan', you can simply pass "-r '^lib'" and it will remove 'lib' from the beginning of the name!
- -r informs builder that no sorting or packaging attempts should be made until the final pass in a multi-pass build. Otherwise, these steps will occur every pass and will require any pre/post scripts to manually move and rename a small set of files and directories (instead of making mass adjustments).
- -s like the '-r' parameter, using this one will allow the sorting to occur, but will withhold packaging the contents (and applying ownership and permissions to the package contents).
- -S' another option that can be used to automatically obtain the source code files for package maintainers, this one will actually fetch the one from the official website. HOWEVER, this will require a properly configured associated information file containing a line beginning with 'download:' and 'filename:' representing the URL and filename respectively of the source code file to obtain. This switch uses the URL_INFO variable in the builder.conf to find the information file.
- -t defines the type of compile framework that is used for the particular package and includes: autoconf, autogen, bootstrap, cmake, custom, and default.
- -U lets builder know that it should not unload any dependencies required the build the package upon a successful run. If the SPM_UNL variable is blank, this step is ignored no matter if this is passed or not.
Installation
The installation of the software could not be easier. Simply download the package, uncompress it, and run the 'install.sh' script with an elevated account (e.g. root) or prefixing with 'sudo' such as:
$ cd /tmp $ tar zxf 2017.08.22-builder.tgz $ cd builder $ sudo ./install.sh Checking the effective UID: [done] Installing the software: [done] Congrats! Your software is installed and ready to use!
Example
In this example, we are going to assume that the libbsd source code has been downloaded and extracted under the /tmp directory
/etc/builder $ ls builder.conf libbsd /etc/builder $ cd /tmp /tmp $ builder -n libbsd -a i64 Performing filesystem checks... Installing compile-time dependencies... Entering source code directory... Applying software patches... Generating the compile script... Compiling the software... Copying in the extra files... Separating into various packages... Applying ownership and permissions... Creating the various packages... bsd [dev] bsd [doc] bsd [lib] Congrats, the software has been packaged successfully!
Developers
Dave Henderson [dhenderson (at) cliquesoft (dot) org]
