It is possible to pass several packages or nothing. In the first case, all packages will be generated. If nothing is passed, then all packages are considered.
pacman.make # To make all packages. pacman.make package1,package2 # To make only two packages.
Sometimes it is interesting to make a package will all its dependencies. The
@deps will do the trick. Of course, you can add other
pacman.make package1,@deps # To make package1 and its dependencies. pacman.make package1,@deps,package2 # To make package1, its dependencies and # the package2.
In some cases (like for Continuous Integration), you can overload some properties for a specific package or all packages. The overload is done on the properties available in the definition files.
pacman.make package1 \ # Overload the version of package1. p:version=1.0.0 pacman.make package1,package2 \ # Overload only the version of package1. p:package1:version=1.0.0 # In the case of package2, it will use # its own version.
It is possible to overload all packages with only one
pacman.make package1,package2 \ # Overload the distribution globally. p:distribution=test/ pacman.make p:distribution=test/ # Like previous with all packages.
An other example very useful with a CI (when a tag is pushed for example).
pacman.make srcpackage,@deps \ p:srcpackage:version=1.0.0 \ p:srcpackage:data.get.ref=v1.0.0
It makes the srcpackage and its dependencies. The package will be created with
the version 1.0.0, and because this package is related to a git repository, the
v1.0.0 will be used.
In this case, the reference can be a commit, a branch or a tag.
A package is not re-maked if the files in its
packages/ have not changed. A
timestamp is saved in the
var/xcraft-contrib-pacman/ directory with the
current timestamp. Before a
make, this timestamp is compared against all
timestamps (mtime) of the files available in
Note that if a
data.get.uri target has changed, this
mechanism will not detect anything. File, repository, etc,… is only downloaded
or copied by the [xcraft-contrib-peon] (make or install time, it depends
if the package embeds the data or not).
Here an example where it can be a problem:
# Part a y YAML definition file. data: get: uri: home:///foobar
foobar/ directory is located in the toolchain, but for pacman, it is
just a data location like
http for example. If you change something in the
foobar/ directory, nothing will be detected by pacman.
Note that the version should probably change in this case. Then the package will be processed because the definition file will have a newer timestamp.