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.1 of the utility.
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 theshedmake
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.
Here are few of the most commonly used actions shedmake
supports:
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 verbosely, installing all needed dependencies, try:
sudo shedmake install linux --verbose --install-dependencies
shedmake
will attempt to resolve all install dependencies listed inpackage.txt
prior to installing the current package. If required packages are not installed, installation will fail. You can pass--install-dependencies
(-d
) to automatically install required packages or--ignore-dependencies
to skip this step.By default,
shedmake
only acts on packages in managed repositories. To build, install, or perform other actions on a package directory located elsewhere you must pass the--locate-at-path
(-l
) option.When an alternative install root is provided to 'install' the
preinstall.sh
andpostinstall.sh
scripts will, if present, be executed in a chroot environment.
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 inpackage.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 thebuild.sh
script in the package folder with necessary environment variables. Compilation is performed in a temporary directory that is removed automatically.
The info
action prints out helpful information concerning the specified package, including its installation status:
shedmake info linux
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 theshedmake
group or have root privileges.
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
.
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
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' 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
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' 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' 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
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.
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.
The following are commands that you'll probably use less frequently, but are handy when performing packaging tasks.
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 thepush
action to perform the initial commit and submit subsequent packaging revisions.
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 thepush-repo
action to perform the initial commit and subsequent packaging revisions.
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
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
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
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' 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.
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
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.
This just prints out the installed version of the shedmake
utility.
shedmake version
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 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
This batch action builds all of the packages listed in the supplied Shedmake List (.sml
) file.
shedmake build-list thingsToMake.sml --strip no
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
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
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
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
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
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
You can use clean-list
to remove cached source and binary archives from a list of packages.
shedmake clean-list packagesToClean.sml
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