1
0
mirror of https://github.com/qTox/qTox.git synced 2024-03-22 14:00:36 +08:00
qTox/INSTALL.md

511 lines
13 KiB
Markdown
Raw Normal View History

# Install Instructions
2014-10-01 04:51:03 +08:00
- [Dependencies](#dependencies)
- [Linux](#linux)
- [Simple install](#simple-install)
- [Arch](#arch-easy)
- [Debian](#debian-easy)
- [Fedora](#fedora-easy)
- [Gentoo](#gentoo-easy)
- [openSUSE](#opensuse-easy)
- [Slackware](#slackware-easy)
- [Ubuntu](#ubuntu-easy)
- [Install git](#install-git)
- [Arch](#arch-git)
- [Debian](#debian-git)
- [Fedora](#fedora-git)
- [openSUSE](#opensuse-git)
- [Ubuntu](#ubuntu-git)
- [Clone qTox](#clone-qtox)
2017-04-16 04:25:21 +08:00
- [GCC, Qt, FFmpeg, OpenAL Soft and qrencode](#other-deps)
- [Arch](#arch-other-deps)
- [Debian](#debian-other-deps)
- [Fedora](#fedora-other-deps)
- [openSUSE](#opensuse-other-deps)
- [Slackware](#slackware-other-deps)
- [Ubuntu](#ubuntu-other-deps)
- [Compile dependencies](#compile-dependencies)
chore(CI): Use docker for CI scripts Motiviation: * Reproducing issues in CI is currently difficult * Predicting issues in CI is currently difficult if you are not on ubuntu 18.04 * Reproducing issues submitted from other distros is currently done by creating a VM of that distro and building qtox for it locally * Documentation for how to build on different distros is out of date * Issues on non-ubuntu distributions are not caught by CI * Cross compiling for windows locally is not trivial * Iterating when working with custom build scripts is slow, scripts don't necessarily support re-running without re-starting the docker container and re-building qtox again * Updating dependencies is a pain Changes: * docker-compose file has been added to the root of our repo. After `docker compose run --rm ubuntu` (or other supported distros), you are ready to compile and run qtox * Dependencies are owned by dependency install scripts in buildscripts/. This allows us to use the same exact dependencies in our OSX/windows/linux scripts * New docker images have been added for a variety of distributions. These are now run in CI in a variety of configurations * Docker images are cached in CI so rebuild time for the majority of jobs is quite quick * Build scripts have been trimmed to leverage state of docker containers. * Windows build script no longer installs anything, dependencies are now managed by the windows_builder docker images * Build scripts should now be easily re-runnable. Usage is now `docker compose run --rm <image>` and then run the scripts * All artifacts are now uploaded to github after build, this means we can take an appimage/flatpak/exe/dmg for any given PR and try it out without having to build it ourselves Notes: * Docker image size is quite important. We have a maximum of 5GB cache space on github actions. The majority of the linux distro docker images cache at ~300-400MB, which gives us room to test ~6 distros after accounting for the sizes of flatpak/windows docker images * Docker layer ordering is relatively intentional. Approximate order should be that large dependencies that change infrequently should be farther up. This lowers the amount of rebuilding we have to do when dependencies are updated * download_xxx.sh scripts are the cleanest way I could find to implement a shared dependency map between osx scripts and docker containers. Although it would be nice to have a single dependency mapping file, splitting it into individual scripts allows us to only rebuild some docker layers when dependencies are updated. * Github actions are split between docker image building and docker image use. This allows us to re-use the same docker images for multiple jobs, but only build it once * Unfortunately I could not find a way to de-duplicate the stitching between jobs, so we have a lot of copy pasta in that area
2021-11-08 13:27:45 +08:00
- [docker](#docker)
- [Compile toxcore](#compile-toxcore)
- [Compile extensions](#compile-extensions)
- [Compile qTox](#compile-qtox)
- [Security hardening with AppArmor](#security-hardening-with-apparmor)
- [BSD](#bsd)
- [FreeBSD](#freebsd-easy)
2014-10-01 04:51:03 +08:00
- [OS X](#osx)
2014-12-09 07:15:53 +08:00
- [Windows](#windows)
- [Cross-compile from Linux](#cross-compile-from-linux)
- [Native](#native)
2017-01-28 11:31:46 +08:00
- [Compile-time switches](#compile-time-switches)
2014-10-01 04:51:03 +08:00
## Dependencies
2014-09-03 18:54:41 +08:00
2019-11-19 12:05:10 +08:00
| Name | Version | Modules |
|--------------------------|-------------|----------------------------------------------------------|
| [Qt] | >= 5.7.1 | concurrent, core, gui, network, opengl, svg, widget, xml |
2019-11-19 12:05:10 +08:00
| [GCC]/[MinGW] | >= 4.8 | C++11 enabled |
| [toxcore] | >= 0.2.10 | core, av |
| [FFmpeg] | >= 2.6.0 | avformat, avdevice, avcodec, avutil, swscale |
| [CMake] | >= 3.7.2 | |
2019-11-19 12:05:10 +08:00
| [OpenAL Soft] | >= 1.16.0 | |
| [qrencode] | >= 3.0.3 | |
| [sqlcipher] | >= 3.2.0 | |
| [pkg-config] | >= 0.28 | |
| [snorenotify] | >= 0.7.0 | optional dependency |
| [toxext] | >= 0.0.3 | |
| [tox_extension_messages] | >= 0.0.3 | |
## Optional dependencies
2017-01-28 11:31:46 +08:00
They can be disabled/enabled by passing arguments to `cmake` command when
building qTox.
If they are missing, qTox is built without support for the functionality.
### Development dependencies
Dependencies needed to run tests / code formatting, etc. Disabled if
dependencies are missing.
| Name | Version |
|---------|---------|
| [Check] | >= 0.9 |
### Spell checking support
| Name | Version |
|----------|---------|
| [sonnet] | >= 5.45 |
Use `-DSPELL_CHECK=OFF` to disable it.
**Note:** Specified version was tested and works well. You can try to use older
version, but in this case you may have some errors (including a complete lack
of spell check).
### Linux
#### Auto-away support
| Name | Version |
|-----------------|----------|
| [libXScrnSaver] | >= 1.2 |
| [libX11] | >= 1.6.0 |
2017-01-28 11:31:46 +08:00
Disabled if dependencies are missing during compilation.
#### Snorenotify desktop notification backend
Disabled by default
| Name | Version |
|-------------------|-----------|
| [snorenotify] | >= 0.7.0 |
To enable: `-DDESKTOP_NOTIFICATIONS=True`
## Linux
### Simple install
2014-12-09 07:15:53 +08:00
Easy qTox install is provided for variety of distributions:
2015-06-28 02:16:47 +08:00
* [Arch](#arch)
* [Debian](#debian)
* [Fedora](#fedora)
2015-06-28 02:16:47 +08:00
* [Gentoo](#gentoo)
2015-06-28 19:51:45 +08:00
* [Slackware](#slackware)
* [Ubuntu](#ubuntu)
---
<a name="arch-easy" />
2015-06-28 02:16:47 +08:00
#### Arch
2014-09-05 02:00:19 +08:00
PKGBUILD is available in the `community` repo, to install:
```bash
pacman -S qtox
```
2015-06-28 02:16:47 +08:00
<a name="debian-easy" />
#### Debian
qTox is available in the [Main](https://tracker.debian.org/pkg/qtox) repo, to install:
```bash
sudo apt install qtox
```
<a name="fedora-easy" />
#### Fedora
qTox is available in the [RPM Fusion](https://rpmfusion.org/) repo, to install:
```bash
dnf install qtox
```
<a name="gentoo-easy" />
2015-06-28 02:16:47 +08:00
#### Gentoo
qTox is available in Gentoo.
2015-06-28 02:16:47 +08:00
To install:
2015-06-28 02:16:47 +08:00
```bash
emerge qtox
```
<a name="opensuse-easy" />
#### openSUSE
qTox is available in openSUSE Factory.
To install in openSUSE 15.0 or newer:
```bash
zypper in qtox
```
To install in openSUSE 42.3:
```bash
zypper ar -f https://download.opensuse.org/repositories/server:/messaging/openSUSE_Leap_42.3 server:messaging
zypper in qtox
```
2015-06-28 19:51:45 +08:00
<a name="slackware-easy" />
2015-06-28 19:51:45 +08:00
#### Slackware
qTox SlackBuild and all of its dependencies can be found here:
http://slackbuilds.org/repository/14.2/network/qTox/
2015-06-28 19:51:45 +08:00
----
2015-06-28 19:51:45 +08:00
If your distribution is not listed, or you want / need to compile qTox, there
are provided instructions.
2015-06-28 02:16:47 +08:00
2014-12-09 07:15:53 +08:00
----
2014-09-03 18:54:41 +08:00
2017-07-22 03:55:51 +08:00
Most of the dependencies should be available through your package manager. You
may either follow the directions below, or simply run `./simple_make.sh` after
cloning this repository, which will attempt to automatically download
dependencies followed by compilation.
2014-09-03 20:22:00 +08:00
<a name="ubuntu-easy" />
#### Ubuntu
qTox is available in the [Universe](https://packages.ubuntu.com/focal/qtox) repo, to install:
```bash
sudo apt install qtox
```
### Install git
2014-09-03 20:22:00 +08:00
In order to clone the qTox repository you need Git.
<a name="arch-git" />
#### Arch Linux
2014-09-03 20:22:00 +08:00
```bash
2014-12-09 07:15:53 +08:00
sudo pacman -S --needed git
2014-09-03 20:22:00 +08:00
```
<a name="debian-git" />
#### Debian
2014-09-03 20:22:00 +08:00
```bash
sudo apt-get install git
```
<a name="fedora-git" />
#### Fedora
2014-09-03 20:22:00 +08:00
```bash
sudo dnf install git
2014-09-03 20:22:00 +08:00
```
<a name="opensuse-git" />
#### openSUSE
2015-05-10 05:37:56 +08:00
```bash
sudo zypper install git
```
<a name="ubuntu-git" />
#### Ubuntu
```bash
sudo apt-get install git
```
2014-09-03 20:22:00 +08:00
### Clone qTox
Afterwards open a new terminal, change to a directory of your choice and clone
the repository:
2014-09-03 20:40:18 +08:00
```bash
cd /home/$USER
git clone https://github.com/qTox/qTox.git qTox
cd qTox
2014-09-03 20:40:18 +08:00
```
The following steps assumes that you cloned the repository at
`/home/$USER/qTox`. If you decided to choose another location, replace
corresponding parts.
2014-09-03 20:40:18 +08:00
2014-09-03 20:22:00 +08:00
chore(CI): Use docker for CI scripts Motiviation: * Reproducing issues in CI is currently difficult * Predicting issues in CI is currently difficult if you are not on ubuntu 18.04 * Reproducing issues submitted from other distros is currently done by creating a VM of that distro and building qtox for it locally * Documentation for how to build on different distros is out of date * Issues on non-ubuntu distributions are not caught by CI * Cross compiling for windows locally is not trivial * Iterating when working with custom build scripts is slow, scripts don't necessarily support re-running without re-starting the docker container and re-building qtox again * Updating dependencies is a pain Changes: * docker-compose file has been added to the root of our repo. After `docker compose run --rm ubuntu` (or other supported distros), you are ready to compile and run qtox * Dependencies are owned by dependency install scripts in buildscripts/. This allows us to use the same exact dependencies in our OSX/windows/linux scripts * New docker images have been added for a variety of distributions. These are now run in CI in a variety of configurations * Docker images are cached in CI so rebuild time for the majority of jobs is quite quick * Build scripts have been trimmed to leverage state of docker containers. * Windows build script no longer installs anything, dependencies are now managed by the windows_builder docker images * Build scripts should now be easily re-runnable. Usage is now `docker compose run --rm <image>` and then run the scripts * All artifacts are now uploaded to github after build, this means we can take an appimage/flatpak/exe/dmg for any given PR and try it out without having to build it ourselves Notes: * Docker image size is quite important. We have a maximum of 5GB cache space on github actions. The majority of the linux distro docker images cache at ~300-400MB, which gives us room to test ~6 distros after accounting for the sizes of flatpak/windows docker images * Docker layer ordering is relatively intentional. Approximate order should be that large dependencies that change infrequently should be farther up. This lowers the amount of rebuilding we have to do when dependencies are updated * download_xxx.sh scripts are the cleanest way I could find to implement a shared dependency map between osx scripts and docker containers. Although it would be nice to have a single dependency mapping file, splitting it into individual scripts allows us to only rebuild some docker layers when dependencies are updated. * Github actions are split between docker image building and docker image use. This allows us to re-use the same docker images for multiple jobs, but only build it once * Unfortunately I could not find a way to de-duplicate the stitching between jobs, so we have a lot of copy pasta in that area
2021-11-08 13:27:45 +08:00
### Docker
chore(CI): Use docker for CI scripts Motiviation: * Reproducing issues in CI is currently difficult * Predicting issues in CI is currently difficult if you are not on ubuntu 18.04 * Reproducing issues submitted from other distros is currently done by creating a VM of that distro and building qtox for it locally * Documentation for how to build on different distros is out of date * Issues on non-ubuntu distributions are not caught by CI * Cross compiling for windows locally is not trivial * Iterating when working with custom build scripts is slow, scripts don't necessarily support re-running without re-starting the docker container and re-building qtox again * Updating dependencies is a pain Changes: * docker-compose file has been added to the root of our repo. After `docker compose run --rm ubuntu` (or other supported distros), you are ready to compile and run qtox * Dependencies are owned by dependency install scripts in buildscripts/. This allows us to use the same exact dependencies in our OSX/windows/linux scripts * New docker images have been added for a variety of distributions. These are now run in CI in a variety of configurations * Docker images are cached in CI so rebuild time for the majority of jobs is quite quick * Build scripts have been trimmed to leverage state of docker containers. * Windows build script no longer installs anything, dependencies are now managed by the windows_builder docker images * Build scripts should now be easily re-runnable. Usage is now `docker compose run --rm <image>` and then run the scripts * All artifacts are now uploaded to github after build, this means we can take an appimage/flatpak/exe/dmg for any given PR and try it out without having to build it ourselves Notes: * Docker image size is quite important. We have a maximum of 5GB cache space on github actions. The majority of the linux distro docker images cache at ~300-400MB, which gives us room to test ~6 distros after accounting for the sizes of flatpak/windows docker images * Docker layer ordering is relatively intentional. Approximate order should be that large dependencies that change infrequently should be farther up. This lowers the amount of rebuilding we have to do when dependencies are updated * download_xxx.sh scripts are the cleanest way I could find to implement a shared dependency map between osx scripts and docker containers. Although it would be nice to have a single dependency mapping file, splitting it into individual scripts allows us to only rebuild some docker layers when dependencies are updated. * Github actions are split between docker image building and docker image use. This allows us to re-use the same docker images for multiple jobs, but only build it once * Unfortunately I could not find a way to de-duplicate the stitching between jobs, so we have a lot of copy pasta in that area
2021-11-08 13:27:45 +08:00
Development can be done within one of the many provided docker containers. See the available configurations in docker-compose.yml. These docker images have all the required dependencies for development already installed. Run `docker compose run --rm ubuntu_lts` and proceed to [compiling qTox](#compile-qtox). If you want to avoid compiling as root in the docker image, you can run `USER_ID=$(id -u) GROUP_ID=$(id -g) docker compose run --rm ubuntu_lts` instead.
chore(CI): Use docker for CI scripts Motiviation: * Reproducing issues in CI is currently difficult * Predicting issues in CI is currently difficult if you are not on ubuntu 18.04 * Reproducing issues submitted from other distros is currently done by creating a VM of that distro and building qtox for it locally * Documentation for how to build on different distros is out of date * Issues on non-ubuntu distributions are not caught by CI * Cross compiling for windows locally is not trivial * Iterating when working with custom build scripts is slow, scripts don't necessarily support re-running without re-starting the docker container and re-building qtox again * Updating dependencies is a pain Changes: * docker-compose file has been added to the root of our repo. After `docker compose run --rm ubuntu` (or other supported distros), you are ready to compile and run qtox * Dependencies are owned by dependency install scripts in buildscripts/. This allows us to use the same exact dependencies in our OSX/windows/linux scripts * New docker images have been added for a variety of distributions. These are now run in CI in a variety of configurations * Docker images are cached in CI so rebuild time for the majority of jobs is quite quick * Build scripts have been trimmed to leverage state of docker containers. * Windows build script no longer installs anything, dependencies are now managed by the windows_builder docker images * Build scripts should now be easily re-runnable. Usage is now `docker compose run --rm <image>` and then run the scripts * All artifacts are now uploaded to github after build, this means we can take an appimage/flatpak/exe/dmg for any given PR and try it out without having to build it ourselves Notes: * Docker image size is quite important. We have a maximum of 5GB cache space on github actions. The majority of the linux distro docker images cache at ~300-400MB, which gives us room to test ~6 distros after accounting for the sizes of flatpak/windows docker images * Docker layer ordering is relatively intentional. Approximate order should be that large dependencies that change infrequently should be farther up. This lowers the amount of rebuilding we have to do when dependencies are updated * download_xxx.sh scripts are the cleanest way I could find to implement a shared dependency map between osx scripts and docker containers. Although it would be nice to have a single dependency mapping file, splitting it into individual scripts allows us to only rebuild some docker layers when dependencies are updated. * Github actions are split between docker image building and docker image use. This allows us to re-use the same docker images for multiple jobs, but only build it once * Unfortunately I could not find a way to de-duplicate the stitching between jobs, so we have a lot of copy pasta in that area
2021-11-08 13:27:45 +08:00
NOTE: qtox will not run in the docker container unless your x11 session allows connections from other users. If X11 is giving you issues in the docker image, try `xhost +` on your host machine
2014-12-09 07:15:53 +08:00
chore(CI): Use docker for CI scripts Motiviation: * Reproducing issues in CI is currently difficult * Predicting issues in CI is currently difficult if you are not on ubuntu 18.04 * Reproducing issues submitted from other distros is currently done by creating a VM of that distro and building qtox for it locally * Documentation for how to build on different distros is out of date * Issues on non-ubuntu distributions are not caught by CI * Cross compiling for windows locally is not trivial * Iterating when working with custom build scripts is slow, scripts don't necessarily support re-running without re-starting the docker container and re-building qtox again * Updating dependencies is a pain Changes: * docker-compose file has been added to the root of our repo. After `docker compose run --rm ubuntu` (or other supported distros), you are ready to compile and run qtox * Dependencies are owned by dependency install scripts in buildscripts/. This allows us to use the same exact dependencies in our OSX/windows/linux scripts * New docker images have been added for a variety of distributions. These are now run in CI in a variety of configurations * Docker images are cached in CI so rebuild time for the majority of jobs is quite quick * Build scripts have been trimmed to leverage state of docker containers. * Windows build script no longer installs anything, dependencies are now managed by the windows_builder docker images * Build scripts should now be easily re-runnable. Usage is now `docker compose run --rm <image>` and then run the scripts * All artifacts are now uploaded to github after build, this means we can take an appimage/flatpak/exe/dmg for any given PR and try it out without having to build it ourselves Notes: * Docker image size is quite important. We have a maximum of 5GB cache space on github actions. The majority of the linux distro docker images cache at ~300-400MB, which gives us room to test ~6 distros after accounting for the sizes of flatpak/windows docker images * Docker layer ordering is relatively intentional. Approximate order should be that large dependencies that change infrequently should be farther up. This lowers the amount of rebuilding we have to do when dependencies are updated * download_xxx.sh scripts are the cleanest way I could find to implement a shared dependency map between osx scripts and docker containers. Although it would be nice to have a single dependency mapping file, splitting it into individual scripts allows us to only rebuild some docker layers when dependencies are updated. * Github actions are split between docker image building and docker image use. This allows us to re-use the same docker images for multiple jobs, but only build it once * Unfortunately I could not find a way to de-duplicate the stitching between jobs, so we have a lot of copy pasta in that area
2021-11-08 13:27:45 +08:00
<a name="other-deps" />
2014-09-03 20:22:00 +08:00
chore(CI): Use docker for CI scripts Motiviation: * Reproducing issues in CI is currently difficult * Predicting issues in CI is currently difficult if you are not on ubuntu 18.04 * Reproducing issues submitted from other distros is currently done by creating a VM of that distro and building qtox for it locally * Documentation for how to build on different distros is out of date * Issues on non-ubuntu distributions are not caught by CI * Cross compiling for windows locally is not trivial * Iterating when working with custom build scripts is slow, scripts don't necessarily support re-running without re-starting the docker container and re-building qtox again * Updating dependencies is a pain Changes: * docker-compose file has been added to the root of our repo. After `docker compose run --rm ubuntu` (or other supported distros), you are ready to compile and run qtox * Dependencies are owned by dependency install scripts in buildscripts/. This allows us to use the same exact dependencies in our OSX/windows/linux scripts * New docker images have been added for a variety of distributions. These are now run in CI in a variety of configurations * Docker images are cached in CI so rebuild time for the majority of jobs is quite quick * Build scripts have been trimmed to leverage state of docker containers. * Windows build script no longer installs anything, dependencies are now managed by the windows_builder docker images * Build scripts should now be easily re-runnable. Usage is now `docker compose run --rm <image>` and then run the scripts * All artifacts are now uploaded to github after build, this means we can take an appimage/flatpak/exe/dmg for any given PR and try it out without having to build it ourselves Notes: * Docker image size is quite important. We have a maximum of 5GB cache space on github actions. The majority of the linux distro docker images cache at ~300-400MB, which gives us room to test ~6 distros after accounting for the sizes of flatpak/windows docker images * Docker layer ordering is relatively intentional. Approximate order should be that large dependencies that change infrequently should be farther up. This lowers the amount of rebuilding we have to do when dependencies are updated * download_xxx.sh scripts are the cleanest way I could find to implement a shared dependency map between osx scripts and docker containers. Although it would be nice to have a single dependency mapping file, splitting it into individual scripts allows us to only rebuild some docker layers when dependencies are updated. * Github actions are split between docker image building and docker image use. This allows us to re-use the same docker images for multiple jobs, but only build it once * Unfortunately I could not find a way to de-duplicate the stitching between jobs, so we have a lot of copy pasta in that area
2021-11-08 13:27:45 +08:00
### GCC, Qt, FFmpeg, OpenAL Soft and qrencode
chore(CI): Use docker for CI scripts Motiviation: * Reproducing issues in CI is currently difficult * Predicting issues in CI is currently difficult if you are not on ubuntu 18.04 * Reproducing issues submitted from other distros is currently done by creating a VM of that distro and building qtox for it locally * Documentation for how to build on different distros is out of date * Issues on non-ubuntu distributions are not caught by CI * Cross compiling for windows locally is not trivial * Iterating when working with custom build scripts is slow, scripts don't necessarily support re-running without re-starting the docker container and re-building qtox again * Updating dependencies is a pain Changes: * docker-compose file has been added to the root of our repo. After `docker compose run --rm ubuntu` (or other supported distros), you are ready to compile and run qtox * Dependencies are owned by dependency install scripts in buildscripts/. This allows us to use the same exact dependencies in our OSX/windows/linux scripts * New docker images have been added for a variety of distributions. These are now run in CI in a variety of configurations * Docker images are cached in CI so rebuild time for the majority of jobs is quite quick * Build scripts have been trimmed to leverage state of docker containers. * Windows build script no longer installs anything, dependencies are now managed by the windows_builder docker images * Build scripts should now be easily re-runnable. Usage is now `docker compose run --rm <image>` and then run the scripts * All artifacts are now uploaded to github after build, this means we can take an appimage/flatpak/exe/dmg for any given PR and try it out without having to build it ourselves Notes: * Docker image size is quite important. We have a maximum of 5GB cache space on github actions. The majority of the linux distro docker images cache at ~300-400MB, which gives us room to test ~6 distros after accounting for the sizes of flatpak/windows docker images * Docker layer ordering is relatively intentional. Approximate order should be that large dependencies that change infrequently should be farther up. This lowers the amount of rebuilding we have to do when dependencies are updated * download_xxx.sh scripts are the cleanest way I could find to implement a shared dependency map between osx scripts and docker containers. Although it would be nice to have a single dependency mapping file, splitting it into individual scripts allows us to only rebuild some docker layers when dependencies are updated. * Github actions are split between docker image building and docker image use. This allows us to re-use the same docker images for multiple jobs, but only build it once * Unfortunately I could not find a way to de-duplicate the stitching between jobs, so we have a lot of copy pasta in that area
2021-11-08 13:27:45 +08:00
<a name="arch-other-deps" />
chore(CI): Use docker for CI scripts Motiviation: * Reproducing issues in CI is currently difficult * Predicting issues in CI is currently difficult if you are not on ubuntu 18.04 * Reproducing issues submitted from other distros is currently done by creating a VM of that distro and building qtox for it locally * Documentation for how to build on different distros is out of date * Issues on non-ubuntu distributions are not caught by CI * Cross compiling for windows locally is not trivial * Iterating when working with custom build scripts is slow, scripts don't necessarily support re-running without re-starting the docker container and re-building qtox again * Updating dependencies is a pain Changes: * docker-compose file has been added to the root of our repo. After `docker compose run --rm ubuntu` (or other supported distros), you are ready to compile and run qtox * Dependencies are owned by dependency install scripts in buildscripts/. This allows us to use the same exact dependencies in our OSX/windows/linux scripts * New docker images have been added for a variety of distributions. These are now run in CI in a variety of configurations * Docker images are cached in CI so rebuild time for the majority of jobs is quite quick * Build scripts have been trimmed to leverage state of docker containers. * Windows build script no longer installs anything, dependencies are now managed by the windows_builder docker images * Build scripts should now be easily re-runnable. Usage is now `docker compose run --rm <image>` and then run the scripts * All artifacts are now uploaded to github after build, this means we can take an appimage/flatpak/exe/dmg for any given PR and try it out without having to build it ourselves Notes: * Docker image size is quite important. We have a maximum of 5GB cache space on github actions. The majority of the linux distro docker images cache at ~300-400MB, which gives us room to test ~6 distros after accounting for the sizes of flatpak/windows docker images * Docker layer ordering is relatively intentional. Approximate order should be that large dependencies that change infrequently should be farther up. This lowers the amount of rebuilding we have to do when dependencies are updated * download_xxx.sh scripts are the cleanest way I could find to implement a shared dependency map between osx scripts and docker containers. Although it would be nice to have a single dependency mapping file, splitting it into individual scripts allows us to only rebuild some docker layers when dependencies are updated. * Github actions are split between docker image building and docker image use. This allows us to re-use the same docker images for multiple jobs, but only build it once * Unfortunately I could not find a way to de-duplicate the stitching between jobs, so we have a lot of copy pasta in that area
2021-11-08 13:27:45 +08:00
Please see buildscripts/docker/Dockerfile... for your distribution for an up to date list of commands to set up your build environment
### Compile dependencies
<a name="compile-toxcore" />
#### Compile toxcore
Provided that you have all required dependencies installed, you can simply run:
```bash
git clone https://github.com/toktok/c-toxcore.git toxcore
cd toxcore
chore(CI): Use docker for CI scripts Motiviation: * Reproducing issues in CI is currently difficult * Predicting issues in CI is currently difficult if you are not on ubuntu 18.04 * Reproducing issues submitted from other distros is currently done by creating a VM of that distro and building qtox for it locally * Documentation for how to build on different distros is out of date * Issues on non-ubuntu distributions are not caught by CI * Cross compiling for windows locally is not trivial * Iterating when working with custom build scripts is slow, scripts don't necessarily support re-running without re-starting the docker container and re-building qtox again * Updating dependencies is a pain Changes: * docker-compose file has been added to the root of our repo. After `docker compose run --rm ubuntu` (or other supported distros), you are ready to compile and run qtox * Dependencies are owned by dependency install scripts in buildscripts/. This allows us to use the same exact dependencies in our OSX/windows/linux scripts * New docker images have been added for a variety of distributions. These are now run in CI in a variety of configurations * Docker images are cached in CI so rebuild time for the majority of jobs is quite quick * Build scripts have been trimmed to leverage state of docker containers. * Windows build script no longer installs anything, dependencies are now managed by the windows_builder docker images * Build scripts should now be easily re-runnable. Usage is now `docker compose run --rm <image>` and then run the scripts * All artifacts are now uploaded to github after build, this means we can take an appimage/flatpak/exe/dmg for any given PR and try it out without having to build it ourselves Notes: * Docker image size is quite important. We have a maximum of 5GB cache space on github actions. The majority of the linux distro docker images cache at ~300-400MB, which gives us room to test ~6 distros after accounting for the sizes of flatpak/windows docker images * Docker layer ordering is relatively intentional. Approximate order should be that large dependencies that change infrequently should be farther up. This lowers the amount of rebuilding we have to do when dependencies are updated * download_xxx.sh scripts are the cleanest way I could find to implement a shared dependency map between osx scripts and docker containers. Although it would be nice to have a single dependency mapping file, splitting it into individual scripts allows us to only rebuild some docker layers when dependencies are updated. * Github actions are split between docker image building and docker image use. This allows us to re-use the same docker images for multiple jobs, but only build it once * Unfortunately I could not find a way to de-duplicate the stitching between jobs, so we have a lot of copy pasta in that area
2021-11-08 13:27:45 +08:00
# Note: See buildscirpts/download/download_toxcore.sh for which version should be checked out
cmake . -DBOOTSTRAP_DAEMON=OFF
make -j$(nproc)
sudo make install
# we don't know what whether user runs 64 or 32 bits, and on some distros
# (Fedora, openSUSE) lib/ doesn't link to lib64/, so add both
echo '/usr/local/lib64/' | sudo tee -a /etc/ld.so.conf.d/locallib.conf
echo '/usr/local/lib/' | sudo tee -a /etc/ld.so.conf.d/locallib.conf
sudo ldconfig
2014-12-22 18:50:08 +08:00
```
<a name="compile-extensions" />
#### Compile extensions
2019-11-19 12:05:10 +08:00
qTox uses the toxext library and some of the extensions that go with it.
chore(CI): Use docker for CI scripts Motiviation: * Reproducing issues in CI is currently difficult * Predicting issues in CI is currently difficult if you are not on ubuntu 18.04 * Reproducing issues submitted from other distros is currently done by creating a VM of that distro and building qtox for it locally * Documentation for how to build on different distros is out of date * Issues on non-ubuntu distributions are not caught by CI * Cross compiling for windows locally is not trivial * Iterating when working with custom build scripts is slow, scripts don't necessarily support re-running without re-starting the docker container and re-building qtox again * Updating dependencies is a pain Changes: * docker-compose file has been added to the root of our repo. After `docker compose run --rm ubuntu` (or other supported distros), you are ready to compile and run qtox * Dependencies are owned by dependency install scripts in buildscripts/. This allows us to use the same exact dependencies in our OSX/windows/linux scripts * New docker images have been added for a variety of distributions. These are now run in CI in a variety of configurations * Docker images are cached in CI so rebuild time for the majority of jobs is quite quick * Build scripts have been trimmed to leverage state of docker containers. * Windows build script no longer installs anything, dependencies are now managed by the windows_builder docker images * Build scripts should now be easily re-runnable. Usage is now `docker compose run --rm <image>` and then run the scripts * All artifacts are now uploaded to github after build, this means we can take an appimage/flatpak/exe/dmg for any given PR and try it out without having to build it ourselves Notes: * Docker image size is quite important. We have a maximum of 5GB cache space on github actions. The majority of the linux distro docker images cache at ~300-400MB, which gives us room to test ~6 distros after accounting for the sizes of flatpak/windows docker images * Docker layer ordering is relatively intentional. Approximate order should be that large dependencies that change infrequently should be farther up. This lowers the amount of rebuilding we have to do when dependencies are updated * download_xxx.sh scripts are the cleanest way I could find to implement a shared dependency map between osx scripts and docker containers. Although it would be nice to have a single dependency mapping file, splitting it into individual scripts allows us to only rebuild some docker layers when dependencies are updated. * Github actions are split between docker image building and docker image use. This allows us to re-use the same docker images for multiple jobs, but only build it once * Unfortunately I could not find a way to de-duplicate the stitching between jobs, so we have a lot of copy pasta in that area
2021-11-08 13:27:45 +08:00
You will likely have to compile these yourself.
2019-11-19 12:05:10 +08:00
```bash
git clone https://github.com/toxext/toxext.git toxext
cd toxext
chore(CI): Use docker for CI scripts Motiviation: * Reproducing issues in CI is currently difficult * Predicting issues in CI is currently difficult if you are not on ubuntu 18.04 * Reproducing issues submitted from other distros is currently done by creating a VM of that distro and building qtox for it locally * Documentation for how to build on different distros is out of date * Issues on non-ubuntu distributions are not caught by CI * Cross compiling for windows locally is not trivial * Iterating when working with custom build scripts is slow, scripts don't necessarily support re-running without re-starting the docker container and re-building qtox again * Updating dependencies is a pain Changes: * docker-compose file has been added to the root of our repo. After `docker compose run --rm ubuntu` (or other supported distros), you are ready to compile and run qtox * Dependencies are owned by dependency install scripts in buildscripts/. This allows us to use the same exact dependencies in our OSX/windows/linux scripts * New docker images have been added for a variety of distributions. These are now run in CI in a variety of configurations * Docker images are cached in CI so rebuild time for the majority of jobs is quite quick * Build scripts have been trimmed to leverage state of docker containers. * Windows build script no longer installs anything, dependencies are now managed by the windows_builder docker images * Build scripts should now be easily re-runnable. Usage is now `docker compose run --rm <image>` and then run the scripts * All artifacts are now uploaded to github after build, this means we can take an appimage/flatpak/exe/dmg for any given PR and try it out without having to build it ourselves Notes: * Docker image size is quite important. We have a maximum of 5GB cache space on github actions. The majority of the linux distro docker images cache at ~300-400MB, which gives us room to test ~6 distros after accounting for the sizes of flatpak/windows docker images * Docker layer ordering is relatively intentional. Approximate order should be that large dependencies that change infrequently should be farther up. This lowers the amount of rebuilding we have to do when dependencies are updated * download_xxx.sh scripts are the cleanest way I could find to implement a shared dependency map between osx scripts and docker containers. Although it would be nice to have a single dependency mapping file, splitting it into individual scripts allows us to only rebuild some docker layers when dependencies are updated. * Github actions are split between docker image building and docker image use. This allows us to re-use the same docker images for multiple jobs, but only build it once * Unfortunately I could not find a way to de-duplicate the stitching between jobs, so we have a lot of copy pasta in that area
2021-11-08 13:27:45 +08:00
# Note: See buildscirpts/download/download_toxext.sh for which version should be checked out
2019-11-19 12:05:10 +08:00
cmake .
make -j$(nproc)
sudo make install
```
```bash
git clone https://github.com/toxext/tox_extension_messages.git tox_extension_messages
cd tox_extension_messages
chore(CI): Use docker for CI scripts Motiviation: * Reproducing issues in CI is currently difficult * Predicting issues in CI is currently difficult if you are not on ubuntu 18.04 * Reproducing issues submitted from other distros is currently done by creating a VM of that distro and building qtox for it locally * Documentation for how to build on different distros is out of date * Issues on non-ubuntu distributions are not caught by CI * Cross compiling for windows locally is not trivial * Iterating when working with custom build scripts is slow, scripts don't necessarily support re-running without re-starting the docker container and re-building qtox again * Updating dependencies is a pain Changes: * docker-compose file has been added to the root of our repo. After `docker compose run --rm ubuntu` (or other supported distros), you are ready to compile and run qtox * Dependencies are owned by dependency install scripts in buildscripts/. This allows us to use the same exact dependencies in our OSX/windows/linux scripts * New docker images have been added for a variety of distributions. These are now run in CI in a variety of configurations * Docker images are cached in CI so rebuild time for the majority of jobs is quite quick * Build scripts have been trimmed to leverage state of docker containers. * Windows build script no longer installs anything, dependencies are now managed by the windows_builder docker images * Build scripts should now be easily re-runnable. Usage is now `docker compose run --rm <image>` and then run the scripts * All artifacts are now uploaded to github after build, this means we can take an appimage/flatpak/exe/dmg for any given PR and try it out without having to build it ourselves Notes: * Docker image size is quite important. We have a maximum of 5GB cache space on github actions. The majority of the linux distro docker images cache at ~300-400MB, which gives us room to test ~6 distros after accounting for the sizes of flatpak/windows docker images * Docker layer ordering is relatively intentional. Approximate order should be that large dependencies that change infrequently should be farther up. This lowers the amount of rebuilding we have to do when dependencies are updated * download_xxx.sh scripts are the cleanest way I could find to implement a shared dependency map between osx scripts and docker containers. Although it would be nice to have a single dependency mapping file, splitting it into individual scripts allows us to only rebuild some docker layers when dependencies are updated. * Github actions are split between docker image building and docker image use. This allows us to re-use the same docker images for multiple jobs, but only build it once * Unfortunately I could not find a way to de-duplicate the stitching between jobs, so we have a lot of copy pasta in that area
2021-11-08 13:27:45 +08:00
# Note: See buildscirpts/download/download_toxext_messages.sh for which version should be checked out
2019-11-19 12:05:10 +08:00
cmake .
make -j$(nproc)
sudo make install
```
### Compile qTox
**Make sure that all the dependencies are installed.** If you experience
problems with compiling, it's most likely due to missing dependencies, so please
make sure that you did install *all of them*.
If you are compiling on Fedora 25, you must add libtoxcore to the
`PKG_CONFIG_PATH` environment variable manually:
```
# we don't know what whether user runs 64 or 32 bits, and on some distros
# (Fedora, openSUSE) lib/ doesn't link to lib64/, so add both
export PKG_CONFIG_PATH="$PKG_CONFIG_PATH:/usr/local/lib64/pkgconfig"
export PKG_CONFIG_PATH="$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig"
```
Run in qTox directory to compile:
2014-09-27 06:11:13 +08:00
```bash
cmake .
make -j$(nproc)
2014-09-27 06:11:13 +08:00
```
Now you can start compiled qTox with `./qtox`
Congratulations, you've compiled qTox `:)`
#### Debian / Ubuntu / Mint
If the compiling process stops with a missing dependency like:
`... libswscale/swscale.h missing` try:
```bash
apt-file search libswscale/swscale.h
```
And install the package that provides the missing file.
Start make again. Repeat if necessary until all dependencies are installed. If
you can, please note down all additional dependencies you had to install that
aren't listed here, and let us know what is missing `;)`
---
### Security hardening with AppArmor
See [AppArmor] to enable confinement for increased security.
## BSD
<a name="freebsd-easy" />
#### FreeBSD
qTox is available as a binary package. To install the qTox package:
```bash
pkg install qTox
```
The qTox port is also available at ``net-im/qTox``. To build and install qTox
from sources using the port:
```bash
cd /usr/ports/net-im/qTox
make install clean
```
2014-12-09 07:15:53 +08:00
2014-10-01 04:51:03 +08:00
<a name="osx" />
## OS X
2016-02-01 00:27:00 +08:00
Supported OS X versions: >=10.13. (NOTE: only 10.13 is tested during CI)
Compiling qTox on OS X for development requires 2 tools:
[Xcode](https://developer.apple.com/xcode/) and [homebrew](https://brew.sh).
2014-09-27 06:04:01 +08:00
2016-02-01 00:27:00 +08:00
### Manual Compiling
#### Required Libraries
2016-02-01 00:27:00 +08:00
Install homebrew if you don't have it:
2016-02-01 00:27:00 +08:00
```bash
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
```
2014-09-27 06:04:01 +08:00
First, clone qTox.
```bash
git clone https://github.com/qTox/qTox
cd qTox
```
2014-09-27 06:04:01 +08:00
Then install required dependencies available via `brew`.
```bash
brew bundle --file osx/Brewfile
```
2014-09-27 06:04:01 +08:00
Then, install [toxcore](https://github.com/toktok/c-toxcore/blob/master/INSTALL.md), [ToxExt](https://github.com/toxext/toxext), and [tox_extension_messages](https://github.com/toxext/tox_extension_messages.
2016-02-01 00:27:00 +08:00
```bash
buildscripts/build_toxcore_linux.sh
2016-02-01 00:27:00 +08:00
```
Finally, build qTox.
#### Compiling
```bash
mkdir -p _build
cd _build
cmake .. -DCMAKE_PREFIX_PATH=$(brew --prefix qt@5)
make -j$(sysctl -n hw.ncpu)
make install
2014-09-27 06:04:01 +08:00
```
2016-02-01 00:27:00 +08:00
#### Running qTox
`qTox.dmg` should be in your build directory. You can install qTox from the dmg
to your Applications folder, or run qTox directly from the dmg.
2014-12-09 07:15:53 +08:00
<a name="windows" />
## Windows
2014-12-09 07:15:53 +08:00
Only cross-compiling from Linux is supported and tested in CI, but building
under MSYS should also work.
### Cross-compile from Linux
See [`windows/cross-compile`](windows/cross-compile).
2017-01-28 11:31:46 +08:00
## Compile-time switches
They are passed as an argument to `cmake` command. E.g. with a switch `SWITCH`
that has value `YES` it would be passed to `cmake` in a following manner:
```bash
cmake -DSWITCH=yes
```
Switches:
- `SMILEYS`, values:
- if not defined or an unsupported value is passed, all emoticon packs are
included
- `DISABLED` don't include any emoticon packs, custom ones are still loaded
- `MIN` minimal support for emoticons, only a single emoticon pack is
included
[AppArmor]: /security/apparmor/README.md
[Atk]: https://wiki.gnome.org/Accessibility
[Cairo]: https://www.cairographics.org/
[Check]: https://libcheck.github.io/check/
[CMake]: https://cmake.org/
[DBus Menu]: https://launchpad.net/libdbusmenu
[FFmpeg]: https://www.ffmpeg.org/
[GCC]: https://gcc.gnu.org/
[libX11]: https://www.x.org/wiki/
[libXScrnSaver]: https://www.x.org/wiki/Releases/ModuleVersions/
[MinGW]: http://www.mingw.org/
[OpenAL Soft]: http://kcat.strangesoft.net/openal.html
[Pango]: http://www.pango.org/
[pkg-config]: https://www.freedesktop.org/wiki/Software/pkg-config/
[qrencode]: https://fukuchi.org/works/qrencode/
[Qt]: https://www.qt.io/
[toxcore]: https://github.com/TokTok/c-toxcore/
[sonnet]: https://github.com/KDE/sonnet
[snorenotify]: https://techbase.kde.org/Projects/Snorenotify
chore(CI): Use docker for CI scripts Motiviation: * Reproducing issues in CI is currently difficult * Predicting issues in CI is currently difficult if you are not on ubuntu 18.04 * Reproducing issues submitted from other distros is currently done by creating a VM of that distro and building qtox for it locally * Documentation for how to build on different distros is out of date * Issues on non-ubuntu distributions are not caught by CI * Cross compiling for windows locally is not trivial * Iterating when working with custom build scripts is slow, scripts don't necessarily support re-running without re-starting the docker container and re-building qtox again * Updating dependencies is a pain Changes: * docker-compose file has been added to the root of our repo. After `docker compose run --rm ubuntu` (or other supported distros), you are ready to compile and run qtox * Dependencies are owned by dependency install scripts in buildscripts/. This allows us to use the same exact dependencies in our OSX/windows/linux scripts * New docker images have been added for a variety of distributions. These are now run in CI in a variety of configurations * Docker images are cached in CI so rebuild time for the majority of jobs is quite quick * Build scripts have been trimmed to leverage state of docker containers. * Windows build script no longer installs anything, dependencies are now managed by the windows_builder docker images * Build scripts should now be easily re-runnable. Usage is now `docker compose run --rm <image>` and then run the scripts * All artifacts are now uploaded to github after build, this means we can take an appimage/flatpak/exe/dmg for any given PR and try it out without having to build it ourselves Notes: * Docker image size is quite important. We have a maximum of 5GB cache space on github actions. The majority of the linux distro docker images cache at ~300-400MB, which gives us room to test ~6 distros after accounting for the sizes of flatpak/windows docker images * Docker layer ordering is relatively intentional. Approximate order should be that large dependencies that change infrequently should be farther up. This lowers the amount of rebuilding we have to do when dependencies are updated * download_xxx.sh scripts are the cleanest way I could find to implement a shared dependency map between osx scripts and docker containers. Although it would be nice to have a single dependency mapping file, splitting it into individual scripts allows us to only rebuild some docker layers when dependencies are updated. * Github actions are split between docker image building and docker image use. This allows us to re-use the same docker images for multiple jobs, but only build it once * Unfortunately I could not find a way to de-duplicate the stitching between jobs, so we have a lot of copy pasta in that area
2021-11-08 13:27:45 +08:00
[sqlcipher]: https://github.com/sqlcipher/sqlcipher
2019-11-19 12:05:10 +08:00
[toxext]: https://github.com/toxext/toxext
[tox_extension_messages]: https://github.com/toxext/tox_extension_messages