A (nearly) full qt build environment using docker. Using multi-stage build to decouple build from actual image.
Can build a qmake
project with one single command.
Find the images on Dockerhub. Find the sources on Github
Download qt-build
from dockerhub:
docker pull darkmattercoder/qt-build:latest
Provide your qmake project that you want to build in a separate directory and build it with qt-build
:
docker run --rm -u $UID -v /path/to/your/project/directory:/var/build darkmattercoder/qt-build:latest build
You will find your built project in a new sub directory named build
in your project directory. You can safely omit the -u $UID
part in most environments, where your user has the standard UID=1000
.
The latest
-tag will give you the latest released qt
version for your build environment. For different versions available, refer to the available tags-section.
Generally you will find full version tags like 5.11.3
as well as minor version tags that refer to the last patch release for the given minor release like 5.11
or 5.12
. There will be some tags listed that are named like builder-x.y.z
, where x,y,z
represent qt version numbers. Those images are used for ci builds of the images and contain the whole qt source overhead. They are used as caches in the ci environment. You normally do not want to use them for any production stuff, because they are fairly large.
The build
command for docker run will build any qmake project that is mounted to /var/build
. However, you can get an interactive session as well for manual adjustments or examinations:
docker run --rm -it -u $UID -v /path/to/your/project/directory:/var/build darkmattercoder/qt-build:latest bash
If you pass additional arguments to build
they will be taken into account as arguments to qmake
which allows you to modify your build if needed.
git clone https://github.com/darkmattercoder/qt-build.git
cd qt-build
docker build --build-arg QT_VERSION_MAJOR=X --build-arg QT_VERSION_MINOR=Y --build-arg QT_VERSION_PATCH=Z --build-arg CORE_COUNT=N --target=qt -t qt-build:X.Y.Z
Replace X,Y,Z
according to your desired qt version. You have to provide a build configuration as a very simple configure
-script in the buildconfig
directory to make the build succeed. The script has to be named after your desired QT
version, e.g. configure-5.11.3.sh
. Example content:
#!/bin/sh
../configure -prefix $QT_PREFIX -opensource -confirm-license -nomake examples -nomake tests
The build arguments can entirely be omitted, resulting in a build with some default values from the Dockerfile
. However, I do not promise that those default values for the Qt
-Version that are hardcoded in the Dockerfile
will get updated on a regular basis, because I inject the desired versions all in my ci build matrix. Available build arguments are:
QT_VERSION_MAJOR
QT_VERSION_MINOR
QT_VERSION_PATCH
QT_DOWNLOAD_BRANCH
-- gives you the possibility to address different versions for download. Should e.g. readofficial_releases
orarchive
.QT_TARBALL_NAMING_SCHEME
-- gives you the possibility to alter the naming scheme.Qt
changed that between5.9
and5.10
ftomqt-everywhere-opensource-src
toqt-everywhere-src
. Theqt-
and-src
parts are hardcoded,QT_TARBALL_NAMING_SCHEME
is inserted betweenCI_BUILD
-- will suppress regularmake
output. If set to2
it will stay silent, if set to1
(or anything else) only warnings will show up. When the compiling fails,make
is run again regularly to give you the whole output, skipping everything that has been built before, to give you the possibility to see the actual behaviour. When left undefined, all output is visible and the second run of make is not performedCORE_COUNT
-- determines the number of parallel make jobs. Adjust it to fit your machine
In case you want to do a quick, customised build like I do it in the automated build process. Have a look at the self-explanatory script build-dockerfile-local.sh
.
All currently supported versions of Qt
should be available as tags. I added also versions that have been supported at the time adding them first, but are now archived. I'd like to add other archived versions, too, but I did not yet put any effort into thet. This is no hard work though, so might be a nice
Tags | Size |
---|---|
I highly appreciate any contributions to this project. I will add contribution guidelines later on. As a short summary here is what you could do:
- Provide new or changed documentation
- File issues against the project
- Tinker nice badges to give a visual overview of the docker image structure or the build status for individual tags
- Open pull requests, for example
- add new qt version build configurations
- add more qt features
- add tests
For opening pull requests, please keep the following in mind:
- Pull requests for the
master
branch will be rejected - Pull requests must be made for the
deploy
branch only - Pull requests that alter the build configuration or the dependencies in the base image to compile something that did not compile before have to provide a test that represents the changes. The test, when added without changes to build configs or docker file has to fail.
- Pull requests should be made with the fact in mind, that we want to provide a general multi purpose build environment that should not get bloated more than necessary.
Any directly written content in this repo is licensed under the GPL v3
. Software parts that are produced during the image build and resulting docker images are of course a composition of components that probably carry their own licenses.