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

is used to indicate an alternative temporary directory for processing. This parameter is optional, but should be a full path of the desired location. provides the location where all unique files will be copied from the --source directory. It's important to note that each unique file will retain it's location after its copy. For example, if we've executed 'dedup --source=/tmp/source --target=/tmp/target ...' and the source directory contains the unique file /tmp/source/garden/2011/sunflowers.jpg, when it's copied into the target, the directory would be /tmp/target/garden/2011/sunflowers.jpg.

-L defines the unique database of files from a prior run. Like the --temp directory, this is optional, but allows a user to compare additional (possibly) duplicate files against the database from a prior run. So, given the pictures example above, this would allow a person to compare any newly found pictures against a prior database containing the unque file hashes from a previous run.

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]