The Shedmake Manual

shedmake is a command-line utility included in all Shedbuilt system images that automates the compilation, installation and distribution of packaged software. It aims to provide a number of useful features to mitigate the tedious, error-prone aspects of source-based software distribution while remaining approachable for newcommers to the hobby. You can peruse the source, report issues and submit pull requests from the repository page on GitHub.

The following applies to version 1.0.0 of the utility.

Shedmake Usage

shedmake is typically invoked with an action, object, and if necessary, some options:

shedmake <action> <object> <option 1> <option 2> ...

An option common to nearly all actions is --verbose (or -v) which provides more information about what the shedmake script is doing behind-the-scenes. It's needed when diagnosing build failures and other issues but can otherwise be left off if you don't want your terminal to be flooded with messages.

Common Shedmake Actions

Here are few of the most commonly used actions shedmake supports:

install

What's likely to be your most frequently selected action, 'install' takes the package referenced by its object and installs it in the root filesystem or other location of your choice, compiling it if necessary. The object may refer to a package present in a remote or local managed package repository, or else be the path to any folder containing valid packaging information. Root privileges are required when installing a package from any managed repository and whenever the destination is the root filesystem or any other filesystem where normal users lack needed permissions. If the package contains them, the preinstall.sh and postinstall.sh scripts will be executed prior to and just after install files are written to the destination, respectively. Successful installations are recorded in the 'install' subfolder of the package. To perform a typical installation of the 'brogue' package mentioned above, try:

sudo shedmake install brogue

To install the 'linux' package which supplies the Linux kernel to another partition mounted at /mnt/crazyexperiment, try:

sudo shedmake install linux --install-root /mnt/crazyexperiment

shedmake will attempt to resolve all install dependencies listed in package.txt prior to installing the current package. If required packages are not installed, installation will fail. You can pass --install-dependencies (-i) to automatically install required packages or --ignore-dependencies to skip this step. When an alternative install root is provided to 'install' the preinstall.sh and postinstall.sh scripts will, if present, be executed in a chroot environment.

build

As you might expect, 'build' compiles a source package and optionally compresses the resultant binary and other installation files into an archive. This action can be performed not only on packages in managed remote and local repositories, but on any folder containing valid packaging information. Upon successful completion, a file whose name references its metadata (of the form NAME-VERSION-REVISION.tar.xz) will be created in a 'binary' subfolder in the package. To compile the 'brogue' package and store the resultant binary you may do the following:

sudo shedmake build brogue --cache-binary

shedmake will attempt to resolve all build dependencies listed in package.txt prior to compiling. If required packages are not installed, the build will fail. You can pass --install-dependencies (-i) to automatically install required packages or --ignore-dependencies to skip this step. Assuming your user can write to the package folder, it is not necessary to have root privileges when building a package outside of a managed repository. The 'build' action works by invoking the build.sh script in the package folder with necessary environment variables. Compilation is performed in a temporary directory that is removed automatically.

info

The info action prints out helpful information concerning the specified package, including its installation status:

shedmake info linux

add

The 'add' action is used to add a single package to a specified local managed package repository given the HTTP/S URL of its git repository. By default, it will add it to the first local respository listed in the configuration file at /etc/shedmake/shedmake.conf. Example:

shedmake get https://github.com/shedbuilt/brogue.git default

This will add the 'brogue' package to the 'default' local repository present in /var/shedmake/repos/local in Shedbuilt standard system images.

Because the 'add' action modifies repositories managed by shedmake, the user invoking it must either be in the shedmake group or have root privileges.

add-repo

The 'add-repo' action adds a remote package repository to shedmake's managed packaged repositories in /var/shedmake/repos/remote given the HTTP/S clone URL of its git repository. Once added, packages from the remote repository can referenced by name in shedmake commands.

sudo shedmake add-repo https://github.com/myaccount/myrepo.git

You can use the --rename option to specify the name of the folder into which the repository will be cloned in. By default it will be the final component of the URL, sans .git.

uninstall

The 'uninstall' command removes the files previously copied to disk by the install action. It will not, however, remove the package from its managed package repository.

sudo shedmake uninstall brogue

update-repo

This action looks for updates to the packages in the remote or local managed repository named as its object. If the named repository is remote, this will pull in the latest versions of the packages selected by the maintainer of the remote repository. For local repositories, this action look at the origin of each individual package and pull in the latest version targeting the installed Shedbuilt release (i.e. the tip of the branch corresponding to the RELEASE named in /etc/shedmake/shedmake.conf).

Updating a repository does not automatically install the updated packages. Use the various 'upgrade' commands below to install updated packages.

To update just the 'system' package repository, you can type:

sudo shedmake update-repo system

update-all

'update-all' performs the 'update-repo' action on all remote and local managed packaged repositories listed in the configuration file at /etc/shedmake/shedmake.conf. This command takes no additional options.

sudo shedmake update-all

upgrade

The 'upgrade' action, which takes as its object the name of a package in any remote or local managed package repository, compares the version information in the package metadata to against that in the 'install' subfolder. If the two differ, the 'install' action is performed, updating the installed version to that specified by the packaging. To upgrade the 'brogue' package, one would type:

sudo shedmake upgrade brogue

If the latest installation recorded in the 'install' folder matches the package's current version metadata, no action is performed.

upgrade-repo

'upgrade-repo' performs the 'upgrade' action on all packages in the specified remote or local managed package repository. To upgrade all the packages in the 'system' repository, simply type:

sudo shedmake upgrade-repo system

upgrade-all

'upgrade-all' performs the 'upgrade-repo' action on all remote and local managed packaged repositories listed in the configuration file at /etc/shedmake/shedmake.conf. This command takes no additional options. To install all available upgrades, type:

sudo shedmake upgrade-all

status

The status action tells you whether or not a package is installed and, if so, whether or not it's up-to-date.

shedmake status brogue

Elevated privileges are not required for the status action which does not affect package files.

repo-status

The repo-status action provides information about installed and uninstalled packages in the specified repository as well as the availability of upgrades.

shedmake repo-status system

Elevated privileges are not required for the repo-status action which does not affect package files.

Less Common Actions

The following are commands that you'll probably use less frequently, but are handy when performing packaging tasks.

create

Using create you can easily make a new package to build software and distribute it to the Shedbuilt community. Template versions of the required build.sh, package.txt, LICENSE and .gitignore files are automatically copied into a new folder at the provided path:

shedmake create mynewpackage

Appending the --origin option allows you to specify an SSH or HTTPS git repository on GitHub or another service that has been established to host the package. You can then use the push action to perform the initial commit and submit subsequent packaging revisions.

create-repo

create-repo produces a new local managed package repository to host your own packages locally and currate packages to share with the community. The provided name is used to create a new folder for the repository in the local repos directory specified in /etc/shedmake.conf (/var/shedmake/repos/local by default):

shedmake create-repo myreponame

Appending the --origin option allows you to specify an SSH or HTTPS git repository on GitHub or another service that has been established to host the package repository. You can then use the push-repo action to perform the initial commit and subsequent packaging revisions.

push

If you supplied an --origin when creating a new package with the create action you can use push to perform the initial commit and submit subsequent packaging revisions:

shedmake push mynewpackage

push-repo

If you supplied an --origin when creating a new local package repository with the create-repo action you can use push-repo to perform the initial commit and submit subsequent updates:

shedmake push mynewpackage

fetch-source

This action downloads the source code for the specified package and caches it in the package's source folder. This is handy if you need to build a package without Internet connectivity at a later date.

sudo shedmake fetch-source brogue

clean

The basic 'clean' action takes the name of a package in a managed repository or a local package folder as its object and deletes the 'binary' and 'source' subfolders used to cache installation and source archives, respectively.

sudo shedmake clean brogue

clean-repo

'clean-repo' simply performs the 'clean' action on all the packages in the managed remote or local package repository specified as the object. The following will delete all cached source and binary archives in the 'system' package repository:

sudo shedmake clean-repo system

There is no harm in executing this command as source files will be fetched again if needed and binary archives created from them on demand.

clean-all

This action performs 'clean-repo' for every remote and local managed package repository listed in the configuration file at /etc/shedmake/shedmake.conf. It takes no object and has no supported options.

sudo shedmake clean-repo

purge

To manually delete any files orphaned when upgrading from the previous version of a package to the latest, you can use 'purge':

sudo shedmake purge brogue

This is done automatically when upgrading packages for which it is known to be safe to delete old files. When working with packages that install software libraries exercise great care when using cleanup as there may yet be software installed that depends on the earlier version.

version

This just prints out the installed version of the shedmake utility.

shedmake version

Batch Actions

Typically used for bulk installation during the bootstrapping process, shedmake offers batch versions of a number action that allow you to perform the same action on a list of packages in a file. Each line in a Shedmake List (.sml) file lists the package name, followed by options. Additional options specified after the .sml file that will be applied to all packages in the list.

Shedmake Lists

Shedmake Lists are files typically suffixed with the .sml extension that contain one or more lines of objects and options to be passed to a single shedmake action. The action itself is never specified in the Shedmake List. For example, let's consider the following toolchain.sml file:

binutils
gmp
mpfr
mpc
gcc --skip-postinstall

If passed to the install-list action, it install (compiling if needed) the four listed packages with the options passed to shedmake on the command-line, plus --skip-postinstall for gcc:

shedmake install-list compiler.sml --install-root /mnt/mycrazyexperiment

build-list

This batch action builds all of the packages listed in the supplied Shedmake List (.sml) file.

shedmake build-list thingsToMake.sml --strip no

install-list

This works the same way as the above, installing all of the packages in the supplied list and passing along any normal install options specified in the file and on the command line.

shedmake install-list stuffToInstall.sml --device orangepi-pc

add-list

You can add a number of packages to a local package repository at once using the add-list action. The package repository URLs must be listed in the supplied .sml file.

shedmake add-list stuffToAdd.sml mylocalrepo

fetch-source-list

This action downloads source files for all the packages listed in the supplied .sml file. As with fetch-source, no options are supported.

shedmake fetch-source-list stuffToFetch.sml

upgrade-list

To upgrade a batch of installed packages to their respective package versions, invoke upgrade-list with a Shedmake List (.sml) file containing their names.

shedmake upgrade-list stuffToUpgrade.sml

upgrade-repo-list

To upgrade all the packages contained within a set of managed remote or local package repositories, use the upgrade-repo-list action:

shedmake upgrade-repo-list reposToUpgrade.sml

update-repo-list

To pull in the latest packaging available for software in a set of managed remote or local package repositories, you can use update-repo-list:

shedmake update-repo-list reposToUpdate.sml

clean-list

You can use clean-list to remove cached source and binary archives from a list of packages.

shedmake clean-list packagesToClean.sml

clean-repo-list

Last and almost certainly least, if you want to clean out all the packages in a set of managed remote and/or local package repositories, give clean-repo-list a try:

shedmake clean-repo-list reposToClean.sml