Hi Tom, here is my setup for building with QT6 (QT5 also works):
Ubuntu 25.10 all dependencies installed from the system except for GDAL (which I build by myself to have full control and because I am also co-maintainer of GDAL and I occasionally do some development work on that library). If you are in doubt about how/what to install, you can get inspired by https://github.com/qgis/QGIS/blob/master/.docker/qgis3-ubuntu-qt6-build-deps.dockerfile (or use the docker directly if you decide to go that way). The environment is configured by setting environment variables in QT-Creator and by setting the environment variables in a bash wrapper script when I run the python tests from VS-Codium (I use QT-Creator for C++ but I prefer VS-Codium for python). A docker also works just fine, I've used that in the past. IMHO a VM is probably overkill (I've also used that mainly to reduce the entry barriers for newcomers: see now abandoned https://github.com/elpaso/qgis-dev-vagrant). Hope this helps. On Fri, Nov 7, 2025 at 2:45 AM Tom Christian via QGIS-Developer < [email protected]> wrote: > Hi All, > > I am interested in learning more about how QGIS developers configure their > development environments, and I would like to get some feedback on an > alternate approach. > > I recently contributed my first changes to QGIS and I found the > development environment quite challenging. While the QGIS Developers Guide > <https://docs.qgis.org/3.40/en/docs/developers_guide/index.html> contains > lots of information I found most of it to be high-level, e.g. how to work > with Git, and there was limited information on gathering required > dependencies and setting build configurations. > > Given the number of dependencies, the risk of conflicts with existing > packages, and my strong preference to avoid VMs, I thought a containerised > build environment was ideal. My work requires frequently switching between > projects and environments. I generally cannot let any one project's > dependencies pollute the system outside of a Conda environment, a > container, or a VM. > > I found the CI Docker configuration > <https://github.com/qgis/QGIS/tree/master/.docker> and thought I could > use this to build and test QGIS. These Dockerfiles should guarantee all > required dependencies AND this is the environment that passes or fails CI > checks on my changes. Building QGIS using the CI Docker configuration was > OK, but CI is not setup for running the build product in a container - > meaning changes cannot quickly be manually / visually tested in this way. > The project would have to be compiled (with the benefit of mounted ccache) > and installed every time the container was started before the application > could run. The long Docker commands are not currently scripted outside of > GitHub Actions Workflows, and build configurations are provided via > matrices, so replicating these processes locally is non-trivial. > > I created this repo > <https://github.com/sparkgeo/QGIS-Container-Development> to better > automate container-based development and testing of QGIS. It contains build > / run / test scripts, .env configurations, and Docker Compose overrides to > work with the QGIS CI Docker configuration with as few changes as possible. > It currently requires a single small commit > <https://github.com/sparkgeo/QGIS-EOPF/commit/64b6f6568ec24f9a064a24869b3d1fb95a6ae0b1> > in > the active QGIS branch to support this approach, which I removed before > creating PRs for the main QGIS repo. > > With this approach, building and running a containerised QGIS development > build is (in theory) as simple as scripts/run.sh. Tests can be executed > with scripts/test.sh. > > > I have some questions: > > 1) are you installing QGIS build dependencies on "bare metal", or perhaps > using a VM? > 2) is there a simpler approach than this for containerised builds, runs, > and tests? > 2a) if not, is there any interest in pursuing this or a similar approach > to simplify containerised development environments? > > > Ultimately I suspect the QGIS project would benefit from lower barriers to > entry and the ability to better isolate build dependencies. > > _______________________________________________ > QGIS-Developer mailing list > [email protected] > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -- Alessandro Pasotti QCooperative: www.qcooperative.net ItOpen: www.itopen.it
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
