part name
desktop-qt5:
This is an identifier that indicates a name for the “part” that can be referenced elsewhere. In the case of the desktop helpers it is used by a snap that wants to reference it by the snap’s own snapcraft.yaml including an after: entry on at least one of it’s parts that mentions the name, e.g.
parts:
depends-on-qt5: # a name for my own part
after: [desktop-qt5] # references the desktop part's name
The name of a part is arbitrary and chosen by the author of a particular snapcraft.yaml. In my example I’ve called my part “depends-on-qt5”.
source
source: .
This tells the builder where to find the files to use for building the part. Each part usually has a corresponding source, though it can be omitted if you don’t want to use the default fetch mechanism. In this case the source is set to . which means that snapcraft will look in the folder that contains the snapcraft.yaml OR the folder that contains a snap folder with the snapcraft.yaml inside.
Imagine your project directory is set up like so:
project
- snap
- snapcraft.yaml
- code
Using source: . will set the part to copy the project folder and everything below into the build environment. Likewise, setting source: code will copy everything in project/code into the build environment. Often source is set to be an http or https address, or is set to a git repository address such as the address of a repository on GitHub.
source-subdir
source-subdir: qt
Similarly to source, this optional parameter can be specified to tell snapcraft to use a folder within the files found from source. This is mostly useful for downloaded files that contain more structure than we’re interested in. e.g. if a git repository has the following structure:
git-repo
- code
- docs
- images
We’re only interested in the files inside the code subdirectory, so we will specify the following in our part definition:
parts:
git-subdirectory-example:
source: git@git.example.com:example-repository.git
source-subdir: code
plugin
plugin: make
Snapcraft ships with several so-called plugins which define how to build. Examples of available plugins are make which uses a Makefile-style build process, autotools which builds with a standard ./configure && make && make install method based on GNU AutoTools, cmake which builds using the cmake build system, go which builds a golang project with go build, and python which builds a python project using the python setuptools-style mechanism. All the plugins are documented at https://docs.snapcraft.io/build-snaps/plugins.
make-parameters
make-parameters: ["FLAVOR=qt5"]
This is an example of a configuration that is specific to the make plugin. It specifies arguments to be passed on the command line when executing make. In this example snapcraft will try to execute the following command in the build environment to build the part:
make FLAVOR=qt5
If the above command completes successfully then snapcraft will execute a make install to put the built files into the staging directory.
In this particular case, the FLAVOR argument is used within the Makefile files in the desktop helpers project to save the version of UI toolkit the resulting snap is supposed to be targeting. There are slight differences between each version of gtk and qt that require the desktop-launch script to specifically tailor it’s behaviour to each.
The Makefile files for gtk and qt are at:
You should see that it saves the value of flavor into the snap in a file called flavor-select. The desktop-launch script uses that file to determine how it runs at execution time to tailor it’s setup to each version of qt or gtk.
