Compiling

pipewire uses a build tool called Meson as a basis for its build process. It's a tool with some resemblance to Autotools and CMake. Meson again generates build files for a lower level build tool called Ninja working in about the same level of abstraction as more familiar GNU Make does.

Installing Build Dependencies

Step 1 - Add Launchpad PPA
Step 2 - Enable deb Source for this PPA.

sudo sed -i 's/^#//' /etc/apt/sources.list.d/pipewire-debian* && sudo apt-get update       

Step 3 -
instal the build-dependencies

sudo apt-get build-dep pipewire       

If you want to install build-dependencies from control file directly :

Try mk-build-deps from devscripts package.

mk-build-deps --install <controfile>                                                     

PS: Make sure you have package equivs installed also.

Its also possible to do this non-interactively e.g. --yes

You need to Override the default tool, to increase download speed, you can use apt-fast (from this PPA)
instead of apt-get And you can also override the default options to minimize the download size, like below. :

mk-build-deps --install --tool='apt-get -o Debug::pkgProblemResolver=yes --no-install-recommends --no-install-suggests --yes' debian/control               

Thats it Our Build Environment is ready to build PipeWire.

Getting PipeWire Sources

Download pipewire-version.tar.gz from release or clone from gitlab to use master (Remember master branch may have full of bugs, I don't recommend it) branch.

...Or to use master branch for fast cloning, issue -

git clone --depth 1 --branch master https://gitlab.com/pipwire/pipwire.git

untar the file and cd into that directory or cd into cloned repo directory.

Checking Dependencies

Meson uses a user-specified build directory and all files produced by Meson are in that build directory.
This build directory will be called build/ in this document.

Generate the build files for Ninja and check whether all build-dependencies are satisfied or not.

meson setup build

Changing Meson Options

Once this is done, the next step is to review the build options:

meson configure build

Now change meson/build options according to your requirements.
you can change installation prefix, udevrulesdir, systemd-user-unit-dir and etc. You can enable,disable some features, supports etc. prefix must be a absulte path, all relative paths resides under prefix.

To change build options, execute from the current directory.

meson configure build -D opt1=value1 -D opt2=value2 ....

for example, What option you should change, goto Line24.
Pipewire specific build options are listed in the "Project options" section. They are defined in meson_options.txt.

For more details on configuration Options and building instruction see here and here

Compiling PipeWire

After configuring all options, we need to compile it now. Recheck whether everything is ok or not.

To compile PipeWire, issue

meson compile -C build    # this version may not support in older meson (< 0.57).

meson compile pass all arguments after compile to ninja for further compile, we can manually do it, by

ninja -C build    # You can use this for older version of meson

Unit Testing PipeWire build

To test the result, issue : meson test -C build or ninja test -C build

The meson test command, (From the man page)

   meson  test  is  a helper tool for running test suites of projects using
   Meson.  The default way of running tests is to invoke the default  build
   command:

   ninja [ test ]

   meson test provides a richer set of tools for invoking tests.

   meson  test  automatically  rebuilds  the necessary targets to run tests
   when used with the Ninja backend.  Upon build failure, meson  test  will
   return  an  exit  code of 125.  This return code tells git bisect run to
   skip the current commit.  Thus bisecting using git can  be  done  conve‐
   niently like this.

   git bisect run meson test -C build_dir

Installing PipeWire

If Everything goes well upto now, its time to install the project into a fakeroot dir.

you may set DESTDIR Environment variable to tell meson where to initially install the program. If you build it for any distribution,or any research purpose, set this Env. Variable is important as you need to package for redestribute it. If you build it for your own system you may go direct install in this case DESTDIR variable no need to set.

though If you build for your own system, If you know how to package for your system, I recommend you make a package, because If we Install with our package manager, Our PM will monitor the package and maintain whole system's consistency.

to install, issue : DESTDIR="/YOUR/FULLPATH" meson install -C build

or if you are directly installing, issue : meson install -C build is enough for that purpose.

For Blueman

See dependencies - here
See Installation Notes - here

Some Tricks

If you are compiling a current release for 2-3 times, you may usually know what binaryies,files made after a building process.

But for a new relase, After building, may generates other new binaries,files, may be there is deleted binaris, files from prev. version, they may change locations.

So the question is how to figure it out, Its not simple manually because the initial install destination generally `DISTDIR` tree is huge, may have thousands of files right?

The easiest way you can go with git local repo. Git is a varsatile VCS system to handle this situation. How ? trust me I will walking you through some steps to do it.

1. first build the same way as i mentioned above a just previous release. After isntalling to DESTDIR stop here.
2. build the current release and install it to another DESTDIR
3. create a empty local git repo.
4. copy old release's DESTDIR to that git repo, cd into repo, and stage the untracked files and commit initally.
5. Now delete the Old release's DESTDIR from the repo with rm -rf $DESTDIR
6. Copy New release's DESTDIR to the git repo, and rename the DESTDIR as the same as the Old release's DESTDIR
7. VOILLA...!! We have done. No need to stage or commit. Just observe what is changed, modified, deleted, generated New files, or some path for some files may be changed, Everything you can determine from git status && git status | grep deleted and inspect all output thorowlly.
8. Now determine for New files (from New release), at where they should go (some goes to *.install, *.links and etc in deb packaging).

that's it.

What meson options (Configuration of the main PW project) has been removed/modified/new from the previous release ?

There are lots of options to configure pipewire's default behaviour for building, ie. enable/disable support of a feature, changing installation dirs, some compilation options, some project test option and etc. You may manually find it out what is changed and what are the new options, but it takes lot of time. You can do the followings to view quickly what has been changed since last release.

1. from the old release's woking dir, issue, meson setup build and then issue meson configure -C build 2>&1 >> OldRelease.config and stop here.
2. for the new release do the same, your redirect file name should be NewRelease.config
3. Now diff diff /path/to/{OldRelease.config,NewRelease.config} to figure out the changes.
4. You can clearly find out what has been changed since last release.

Troubleshooting the building process for Debian

While building you may occure some symbols mismatch error at the last moment and building process might be failed.

If there is a file, debian/${subPackageName}.symbols , Its content will be matched with DEBIAN/symbols which is under related subProject directory, generally genenated while building the project. If diff of both file is not null then there is a mismatch (deleted/modified/New). And finally building process terminate with error generating a patch of that file to STDOUT.

How to solve it?

Generally you need to diff of both file, Inspect what has been modifed, considering DEBIAN/symbols under ${subPackageDir} is correct. If you think you can figure it out from where extra symbols comes, deleted or modified, you can manually correct debian/${subPackageName}.symbols. Or Just replace debian/${subPackageName.symbols with the file from DEBIAN dir under related subProject

thats it.

For more information Read - here.

There is another error If you are building the whole project with preinstalled pipewire.

If you find the following error at the very last moment of building.

dpkg-shlibdeps: error: no dependency information found for /usr/lib/x86_64-linux-gnu/pipewire-0.3/jack/libjack.so.0 (used by debian/pipewire-tests/usr/libexec/installed-tests/pipewire-0.3/examples/jack/video-dsp-play)

then move /usr/lib/x86_64-linux-gnu/pipewire-0.3/jack/libjack.so.0 to a safe location to backup. then rebuild again but with -nc option with dpkg-buildpackage to not to compile the PipeWire again.

don't forget to replace your backuped file at the same location and do a sudo ldconfig