documentation: add a short document describing how to test your systemd build tree (#3763)

1 files changed, 68 insertions, 0 deletions

diff --git a/HACKING b/HACKING
new file mode 100644
index 0000000000..3ee1c7e340
--- /dev/null
+++ b/HACKING
@@ -0,0 +1,68 @@
+HACKING ON SYSTEMD
+
+We welcome all contributions to systemd. If you notice a bug or a missing
+feature, please feel invited to fix it, and submit your work as a github Pull
+Request (PR):
+
+        https://github.com/systemd/systemd/pull/new
+
+Please make sure to follow our Coding Style when submitting patches. See
+CODING_STYLE for details. Also have a look at our Contribution Guidelines:
+
+        https://github.com/systemd/systemd/blob/master/.github/CONTRIBUTING.md
+
+Please always test your work before submitting a PR. For many of the components
+of systemd testing is straight-forward as you can simply compile systemd and
+run the relevant tool from the build directory.
+
+For some components (most importantly, systemd/PID1 itself) this is not
+possible, however. In order to simplify testing for cases like this we provide
+a set of "mkosi" build files directly in the source tree. "mkosi" is a tool for
+building clean OS images from an upstream distribution in combination with a
+fresh build of the project in the local working directory. To make use of this,
+please acquire "mkosi" from https://github.com/systemd/mkosi first, unless your
+distribution has packaged it already and you can get it from there. After the
+tool is installed it is sufficient to type "mkosi" in the systemd project
+directory to generate a disk image "image.raw" you can boot either in
+systemd-nspawn or in an UEFI-capable VM:
+
+        # systemd-nspawn -bi image.raw
+
+or:
+
+        # qemu-kvm -m 512 -smp 2 -bios /usr/share/edk2/ovmf/OVMF_CODE.fd -hda image.raw
+
+Every time you rerun the "mkosi" command a fresh image is built, incorporating
+all current changes you made to the project tree.
+
+Alternatively, you may install the systemd version from your git check-out
+directly on top of your host system's directory tree. This mostly works fine,
+but of course you should know what you are doing as you might make your system
+unbootable in case of a bug in your changes. Also, you might step into your
+package manager's territory with this. Be careful!
+
+And never forget: most distributions provide very simple and convenient ways to
+install all development packages necessary to build systemd. For example, on
+Fedora the following command line should be sufficient to install all of
+systemd's build dependencies:
+
+        # dnf builddep systemd
+
+Putting this all together, here's a series of commands for preparing a patch
+for systemd (this example is for Fedora):
+
+        $ git clone https://github.com/systemd/systemd.git
+        $ cd systemd
+        $ vim src/core/main.c                  # or wherever you'd like to make your changes
+        $ dnf builddep systemd                 # install build dependencies
+        $ ./autogen.sh c                       # configure the source tree
+        $ make -j `nproc`                      # build it locally, see if everything compiles fine
+        $ sudo mkosi                           # build a test image
+        $ sudo systemd-nspawn -bi image.raw    # boot up the test image
+        $ git add -p                           # interactively put together your patch
+        $ git commit                           # commit it
+        $ ...
+
+And after that, please submit your branch as PR to systemd via github.
+
+Happy hacking!