Commit a00feef2 authored by David Boddie's avatar David Boddie

Merge branch 'common-sections' into 'master'

Use common sections with includes and parameters for consistency

See merge request !212
parents b15856b2 13215023
Pipeline #4312 passed with stages
in 11 minutes and 26 seconds
.. _App_Resources_tutorial_building:
Building the Application
========================
.. |executable| replace:: ``app-resources``
.. |desktop-entry-ref| replace:: :ref:`desktop entry file <App_Resources_tutorial_desktop_file>`
.. contents::
:local:
The ``app`` directory and its subdirectories contain ``meson.build`` files that
describe how the application is built. These are used by the `Meson`_ build
tool to configure the build process.
Meson is usually run so that it creates a build directory. This is where all
the resources are put so that the `Ninja`_ build tool can perform the actual
process of building and installing the application.
Top-Level Build File
--------------------
In the ``app`` directory itself, the ``meson.build`` file begins with a
declaration of the project name, version and build system requirements:
.. literalinclude:: app/meson.build
We also declare the ``data`` and ``src`` subdirectories, causing Meson to
examine them for any ``meson.build`` files they may contain.
The last line causes a special script to be run after installation. It is not
important to know what this is doing at this point.
Sources Build File
------------------
The ``meson.build`` file in the ``src`` directory describes how the source
files are processed when the build occurs:
.. literalinclude:: app/src/meson.build
In this case, we instruct Meson to take the ``main.py`` file in the ``src``
directory and copy it into the build directory as ``app-resources`` --
this is the name given as the executable in the :ref:`desktop entry file
<App_Resources_tutorial_desktop_file>`.
We also declare that the file should be installed, and that its installation
directory is the system location for executables (``bindir``).
Data Build File
---------------
The ``meson.build`` file in the ``data`` describes how the data files are
processed when the build occurs:
.. literalinclude:: app/data/meson.build
Here, we tell Meson to simply copy the ``com.example.app_resources.desktop``
file into the build directory. We also declare that it should be installed, and
that its installation directory is the ``applications`` subdirectory of the
system location for data files (``datadir``).
The ``com.example.app_resources.svg`` file is more easily described to
Meson. It will be installed in the appropriate subdirectory of the system
location for data files that is used for icons.
Building using Meson and Ninja
------------------------------
When building the application for deployment on the phone, we will use Flatpak
to coordinate the build process. However, behind the scenes, we are using Meson
and Ninja to perform the actual configuration and build. If you want to try and
build the application for testing on your workstation, you can follow the steps
below to build, install, and finally uninstall it.
To configure the build on the command line, enter the ``app`` directory and
run Meson, specifying the source and build directories::
meson . _build
Build the application using Ninja, passing the build directory as an argument
so that the build occurs within that directory. There is no need to specify a
build rule because the default rule builds the application::
ninja -C _build
Finally, use ``sudo`` to install the application in a standard location on your
system using the ``install`` build rule::
sudo ninja -C _build install
To uninstall the application, run its ``uninstall`` rule::
sudo ninja -C _build uninstall
All of the files that were installed should now have been cleanly removed from
system locations.
Summary
-------
We have examined the contents of some ``meson.build`` files to see how simple
rules are used to describe the configuration process. We have also seen how
Meson and Ninja are used to configure and build the application.
The application can also be packaged for more convenient installation using the
Flatpak framework. This is the subject of the next part of the tutorial.
.. include:: /links.txt
.. include:: ../common/Building_the_App.txt
Getting the Application
=======================
.. |app-dir| replace:: App_Resources
The application can be found in the `Librem 5 developer documentation
repository`_. You can clone this repository locally with Git::
git clone https://source.puri.sm/Librem5/developer.puri.sm.git
This should result in the creation of a directory called ``developer.puri.sm``
in your current directory. Enter this directory and find the application
directory for this tutorial::
cd developer.puri.sm/Apps/Tutorials/App_Resources/app
You can build the application from the command line or open it in :ref:`gbuilder`.
.. include:: /links.txt
.. include:: ../common/Getting_the_App.txt
.. _App_Resources_tutorial_packaging:
Packaging the Application
=========================
.. |manifest| replace:: ``com.example.app_resources.json``
.. |manifest-path| replace:: app/com.example.app_resources.json
.. |app-id| replace:: com.example.app_resources
.. contents::
:local:
The ``app`` directory contains a ``com.example.app_resources.json``
manifest file for use with Flatpak. This describes where the application
source code can be obtained from, how the application is built, the
dependencies that need to be built with it, and the permissions it needs when
it is run.
Writing the Manifest
--------------------
The manifest for this simple application is short, so we include the whole file
here to provide an overview before looking at the details:
.. literalinclude:: app/com.example.app_resources.json
We examine the three main parts of the manifest individually.
Application Information
~~~~~~~~~~~~~~~~~~~~~~~
In the manifest we record information about the application, including its ID
and the command used to run it:
.. literalinclude:: app/com.example.app_resources.json
:start-at: {
:end-at: command
The ``runtime`` and ``runtime-version`` values define precisely which
collection of libraries the application needs to run. The corresponding ``sdk``
value tells Flatpak which SDK is needed to build the application. When building
applications for a GNOME-based platform the corresponding SDK is required.
Permissions
~~~~~~~~~~~
The ``finish-args`` list is typically used to state which permissions the
application needs. In this case it will need access to the Wayland display
server to be able to show a window:
.. literalinclude:: app/com.example.app_resources.json
:start-at: finish-args
:end-at: ],
Other permissions will be required if you want to store and modify settings for
your application, access peripherals, and perform other tasks that require the
user's consent.
Modules
~~~~~~~
The ``modules`` list describes the application components (or modules),
including any dependencies that need to be bundled with it, in a list of
dictionaries:
.. literalinclude:: app/com.example.app_resources.json
:start-at: modules
:end-at: builddir
The ``name`` of the application should be unique in the list of modules but can
be otherwise freely assigned. We indicate that we are using the Meson build
system and instruct Flatpak to use a separate build directory.
After this, we describe where the sources of the application should be obtained
from. For many applications we would describe the location of a repository.
However, to make things simple, we indicate that the sources are in the same
directory as the manifest:
.. literalinclude:: app/com.example.app_resources.json
:start-at: modules
This concludes the description of the main (and only) module.
Building the Application
------------------------
Following the instructions in :ref:`cross_building_flatpaks_app`, we use
``flatpak-builder`` to build a flatpak for the application. To do this we need
to install the runtime and SDK that the application depends on. These are the
same as those mentioned in :ref:`flatpak_setup_gnome` except that we need the
ones for the aarch64 architecture::
flatpak --user install flathub org.gnome.Platform/aarch64/3.30 org.gnome.Sdk/aarch64/3.30
After installing these, build the application with `flatpak-builder`::
flatpak-builder --arch=aarch64 --repo=myrepo _flatpak com.example.app_resources.json
The result is stored in the ``myrepo`` directory, which is a local repository.
It can be exported from the repository as a binary bundle for deployment on
the target device. We do this by running ``flatpak`` with the ``build-bundle``
command, passing the repository, the name of the bundle to create and the
application ID::
flatpak build-bundle --arch=aarch64 myrepo app.flatpak com.example.app_resources
In this case the bundle is written to the ``app.flatpak`` file. This can be
copied to the phone or development board for installation.
Installing the Application
--------------------------
One way to install the application is to use the ``flatpak`` tool on the
command line to install the binary bundle. Other more user-friendly ways are
also possible.
First of all, copy the bundle to the target device and make it readable by the
``purism`` user. Then, log in to the device and ensure that the ``flathub``
remote is registered for the user::
flatpak --user remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
Assuming that the ``app.flatpak`` file is in the current directory, install it
for the user by running the ``install`` command::
flatpak --user install app.flatpak
Flatpak will resolve the dependencies of the bundle using the remote we
registered and ask you if you want to install them if they are not already
present. It will then install the application itself.
You can run the application using ``flatpak`` in the usual way::
flatpak run com.example.app_resources
When you are finished with the application and want to uninstall it, use the
following command::
flatpak uninstall com.example.app_resources
You can also uninstall the runtime needed by the application, but it may be
useful to keep it installed for future use.
.. include:: ../common/Packaging_the_App.txt
.. _First_Application_building:
Building the Application
========================
.. |executable| replace:: ``your-first-application``
.. |desktop-entry-ref| replace:: :ref:`desktop entry file <First_Application_desktop_file>`
.. contents::
:local:
The ``app`` directory and its subdirectories contain ``meson.build`` files that
describe how the application is built. These are used by the `Meson`_ build
tool to configure the build process.
Meson is usually run so that it creates a build directory. This is where all
the resources are put so that the `Ninja`_ build tool can perform the actual
process of building and installing the application.
Top-Level Build File
--------------------
In the ``app`` directory itself, the ``meson.build`` file begins with a
declaration of the project name, version and build system requirements:
.. literalinclude:: app/meson.build
We also declare the ``data`` and ``src`` subdirectories, causing Meson to
examine them for any ``meson.build`` files they may contain.
The last line causes a special script to be run after installation. It is not
important to know what this is doing at this point.
Sources Build File
------------------
The ``meson.build`` file in the ``src`` directory describes how the source
files are processed when the build occurs:
.. literalinclude:: app/src/meson.build
In this case, we instruct Meson to take the ``main.py`` file in the ``src``
directory and copy it into the build directory as ``your-first-application`` --
this is the name given as the executable in the :ref:`desktop entry file
<First_Application_desktop_file>`.
We also declare that the file should be installed, and that its installation
directory is the system location for executables (``bindir``).
Data Build File
---------------
The ``meson.build`` file in the ``data`` describes how the data files are
processed when the build occurs:
.. literalinclude:: app/data/meson.build
Here, we tell Meson to simply copy the ``com.example.first_application.desktop``
file into the build directory. We also declare that it should be installed, and
that its installation directory is the ``applications`` subdirectory of the
system location for data files (``datadir``).
The ``com.example.first_application.svg`` file is more easily described to
Meson. It will be installed in the appropriate subdirectory of the system
location for data files that is used for icons.
Building using Meson and Ninja
------------------------------
When building the application for deployment on the phone, we will use Flatpak
to coordinate the build process. However, behind the scenes, we are using Meson
and Ninja to perform the actual configuration and build. If you want to try and
build the application for testing on your workstation, you can follow the steps
below to build, install, and finally uninstall it.
To configure the build on the command line, enter the ``app`` directory and
run Meson, specifying the source and build directories::
meson . _build
Build the application using Ninja, passing the build directory as an argument
so that the build occurs within that directory. There is no need to specify a
build rule because the default rule builds the application::
ninja -C _build
Finally, use ``sudo`` to install the application in a standard location on your
system using the ``install`` build rule::
sudo ninja -C _build install
To uninstall the application, run its ``uninstall`` rule::
sudo ninja -C _build uninstall
All of the files that were installed should now have been cleanly removed from
system locations.
Summary
-------
We have examined the contents of some ``meson.build`` files to see how simple
rules are used to describe the configuration process. We have also seen how
Meson and Ninja are used to configure and build the application.
The application can also be packaged for more convenient installation using the
Flatpak framework. This is the subject of the next part of the tutorial.
.. include:: /links.txt
.. include:: ../common/Building_the_App.txt
Getting the Application
=======================
.. |app-dir| replace:: First_Application
The application can be found in the `Librem 5 developer documentation
repository`_. You can clone this repository locally with Git::
git clone https://source.puri.sm/Librem5/developer.puri.sm.git
This should result in the creation of a directory called ``developer.puri.sm``
in your current directory. Enter this directory and find the application
directory for this tutorial::
cd developer.puri.sm/Apps/Tutorials/First_Application/app
You can build the application from the command line or open it in :ref:`gbuilder`.
.. include:: /links.txt
.. include:: ../common/Getting_the_App.txt
.. _First_Application_packaging:
Packaging the Application
=========================
.. |manifest| replace:: ``com.example.first_application.json``
.. |manifest-path| replace:: app/com.example.first_application.json
.. |app-id| replace:: com.example.first_application
.. contents::
:local:
The ``app`` directory contains a ``com.example.first_application.json``
manifest file for use with Flatpak. This describes where the application
source code can be obtained from, how the application is built, the
dependencies that need to be built with it, and the permissions it needs when
it is run.
Writing the Manifest
--------------------
The manifest for this simple application is short, so we include the whole file
here to provide an overview before looking at the details:
.. literalinclude:: app/com.example.first_application.json
We examine the three main parts of the manifest individually.
Application Information
~~~~~~~~~~~~~~~~~~~~~~~
In the manifest we record information about the application, including its ID
and the command used to run it:
.. literalinclude:: app/com.example.first_application.json
:start-at: {
:end-at: command
The ``runtime`` and ``runtime-version`` values define precisely which
collection of libraries the application needs to run. The corresponding ``sdk``
value tells Flatpak which SDK is needed to build the application. When building
applications for a GNOME-based platform the corresponding SDK is required.
Permissions
~~~~~~~~~~~
The ``finish-args`` list is typically used to state which permissions the
application needs. In this case it will need access to the Wayland display
server to be able to show a window:
.. literalinclude:: app/com.example.first_application.json
:start-at: finish-args
:end-at: ],
Other permissions will be required if you want to store and modify settings for
your application, access peripherals, and perform other tasks that require the
user's consent.
Modules
~~~~~~~
The ``modules`` list describes the application components (or modules),
including any dependencies that need to be bundled with it, in a list of
dictionaries:
.. literalinclude:: app/com.example.first_application.json
:start-at: modules
:end-at: builddir
The ``name`` of the application should be unique in the list of modules but can
be otherwise freely assigned. We indicate that we are using the Meson build
system and instruct Flatpak to use a separate build directory.
After this, we describe where the sources of the application should be obtained
from. For many applications we would describe the location of a repository.
However, to make things simple, we indicate that the sources are in the same
directory as the manifest:
.. literalinclude:: app/com.example.first_application.json
:start-at: modules
This concludes the description of the main (and only) module.
Building the Application
------------------------
Following the instructions in :ref:`cross_building_flatpaks_app`, we use
``flatpak-builder`` to build a flatpak for the application. To do this we need
to install the runtime and SDK that the application depends on. These are the
same as those mentioned in :ref:`flatpak_setup_gnome` except that we need the
ones for the aarch64 architecture::
flatpak --user install flathub org.gnome.Platform/aarch64/3.30 org.gnome.Sdk/aarch64/3.30
After installing these, build the application with `flatpak-builder`::
flatpak-builder --arch=aarch64 --repo=myrepo _flatpak com.example.first_application.json
The result is stored in the ``myrepo`` directory, which is a local repository.
It can be exported from the repository as a binary bundle for deployment on
the target device. We do this by running ``flatpak`` with the ``build-bundle``
command, passing the repository, the name of the bundle to create and the
application ID::
flatpak build-bundle --arch=aarch64 myrepo app.flatpak com.example.first_application
In this case the bundle is written to the ``app.flatpak`` file. This can be
copied to the phone or development board for installation.
Installing the Application
--------------------------
One way to install the application is to use the ``flatpak`` tool on the
command line to install the binary bundle. Other more user-friendly ways are
also possible.
First of all, copy the bundle to the target device and make it readable by the
``purism`` user. Then, log in to the device and ensure that the ``flathub``
remote is registered for the user::
flatpak --user remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
Assuming that the ``app.flatpak`` file is in the current directory, install it
for the user by running the ``install`` command::
flatpak --user install app.flatpak
Flatpak will resolve the dependencies of the bundle using the remote we
registered and ask you if you want to install them if they are not already
present. It will then install the application itself.
You can run the application using ``flatpak`` in the usual way::
flatpak run com.example.first_application
When you are finished with the application and want to uninstall it, use the
following command::
flatpak uninstall com.example.first_application
You can also uninstall the runtime needed by the application, but it may be
useful to keep it installed for future use.
.. include:: ../common/Packaging_the_App.txt
Building the Application
========================
.. contents::
:local:
The ``app`` directory and its subdirectories contain ``meson.build`` files that
describe how the application is built. These are used by the `Meson`_ build
tool to configure the build process.
Meson is usually run so that it creates a build directory. This is where all
the resources are put so that the `Ninja`_ build tool can perform the actual
process of building and installing the application.
Top-Level Build File
--------------------
In the ``app`` directory itself, the ``meson.build`` file begins with a
declaration of the project name, version and build system requirements:
.. literalinclude:: app/meson.build
We also declare the ``data`` and ``src`` subdirectories, causing Meson to
examine them for any ``meson.build`` files they may contain.
The last line causes a special script to be run after installation. It is not
important to know what this is doing at this point.
Sources Build File
------------------
The ``meson.build`` file in the ``src`` directory describes how the source
files are processed when the build occurs:
.. literalinclude:: app/src/meson.build
In this case, we instruct Meson to take the ``main.py`` file in the ``src``
directory and copy it into the build directory as |executable| --
this is the name given as the executable in the |desktop-entry-ref|.
We also declare that the file should be installed, and that its installation
directory is the system location for executables (``bindir``).
Data Build File
---------------
The ``meson.build`` file in the ``data`` describes how the data files are
processed when the build occurs:
.. literalinclude:: app/data/meson.build
Here, we tell Meson to simply copy the ``com.example.first_application.desktop``
file into the build directory. We also declare that it should be installed, and
that its installation directory is the ``applications`` subdirectory of the
system location for data files (``datadir``).
The ``com.example.first_application.svg`` file is more easily described to
Meson. It will be installed in the appropriate subdirectory of the system
location for data files that is used for icons.
Building using Meson and Ninja
------------------------------
When building the application for deployment on the phone, we will use Flatpak
to coordinate the build process. However, behind the scenes, we are using Meson
and Ninja to perform the actual configuration and build. If you want to try and
build the application for testing on your workstation, you can follow the steps
below to build, install, and finally uninstall it.
To configure the build on the command line, enter the ``app`` directory and
run Meson, specifying the source and build directories::
meson . _build
Build the application using Ninja, passing the build directory as an argument
so that the build occurs within that directory. There is no need to specify a
build rule because the default rule builds the application::
ninja -C _build
Finally, use ``sudo`` to install the application in a standard location on your
system using the ``install`` build rule::
sudo ninja -C _build install
To uninstall the application, run its ``uninstall`` rule::
sudo ninja -C _build uninstall
All of the files that were installed should now have been cleanly removed from
system locations.
Summary
-------
We have examined the contents of some ``meson.build`` files to see how simple
rules are used to describe the configuration process. We have also seen how
Meson and Ninja are used to configure and build the application.
The application can also be packaged for more convenient installation using the
Flatpak framework. This is the subject of the next part of the tutorial.
.. include:: /links.txt
Getting the Application
=======================
The application can be found in the `Librem 5 developer documentation
repository`_. You can clone this repository locally with Git::
git clone https://source.puri.sm/Librem5/developer.puri.sm.git
This should result in the creation of a directory called ``developer.puri.sm``
in your current directory. Enter this directory and find the application
directory for this tutorial:
.. code-par::
cd developer.puri.sm/Apps/Tutorials/|app-dir|/app
You can build the application from the command line or open it in :ref:`gbuilder`.
.. include:: /links.txt
Packaging the Application
=========================
.. contents::
:local:
The ``app`` directory contains a |manifest|
manifest file for use with Flatpak. This describes where the application
source code can be obtained from, how the application is built, the
dependencies that need to be built with it, and the permissions it needs when
it is run.
Writing the Manifest
--------------------
The manifest for this simple application is short, so we include the whole file
here to provide an overview before looking at the details:
.. include-par:: |manifest-path|
We examine the three main parts of the manifest individually.
Application Information
~~~~~~~~~~~~~~~~~~~~~~~
In the manifest we record information about the application, including its ID
and the command used to run it:
.. include-par:: |manifest-path|
:start-at: {
:end-at: command
The ``runtime`` and ``runtime-version`` values define precisely which
collection of libraries the application needs to run. The corresponding ``sdk``
value tells Flatpak which SDK is needed to build the application. When building
applications for a GNOME-based platform the corresponding SDK is required.
Permissions
~~~~~~~~~~~
The ``finish-args`` list is typically used to state which permissions the
application needs. In this case it will need access to the Wayland display
server to be able to show a window:
.. include-par:: |manifest-path|
:start-at: finish-args
:end-at: ],
Other permissions will be required if you want to store and modify settings for
your application, access peripherals, and perform other tasks that require the
user's consent.
Modules
~~~~~~~
The ``modules`` list describes the application components (or modules),
including any dependencies that need to be bundled with it, in a list of
dictionaries:
.. include-par:: |manifest-path|
:start-at: modules
:end-at: builddir
The ``name`` of the application should be unique in the list of modules but can
be otherwise freely assigned. We indicate that we are using the Meson build
system and instruct Flatpak to use a separate build directory.
After this, we describe where the sources of the application should be obtained
from. For many applications we would describe the location of a repository.
However, to make things simple, we indicate that the sources are in the same
directory as the manifest:
.. include-par:: |manifest-path|
:start-at: sources
This concludes the description of the main (and only) module.
Building the Application
------------------------