There are three basic channels to choose from
- Shared build-include (
and I discuss the practicalities of each below.
Set or add to things like
DEFINES that should affect your whole project in a
.pri file. Then use the qmake
include function in all the affected
This is my go-to method when I'm coding all the parts of a subdirs project at once. You can also get more selective and build several
.pri files that each add things to setup parts of the build environment. Then each subproject's
.pro asks for only what it needs.
A useful trick if you don't know if you are going to be a subproject or not is to check for a file and read it if it exists
# Let any super-project modify our build
I'm using this for some library code that is being built in-situ by two
projects with different needs.
- Filenames to be used with
include either need to be known in advance or you have to use one of these methods to communicate it.
Most qmake variables are not shared down the build tree, but this one is
special (this distinction also shows up in the presence of the
config() test function while all other variables have to use
CONFIG is a list you can add anything not already significant to qmake to the it. I suggest using a (more or less) unique prefix or suffix on flags meant for subdirectory builds so that you end up with values like
- Option selections can be set from the command line or the IDE
- Potential for name collisions
- Users are limited to variations that you foresee
- If you don't want to force your users to need to read your
you'll have to document the options and what they do.
I can't find any authoritative documentation, but I believe that qmake looks in the current directory and it's parent (and maybe further up the directory tree?) for a file named this way, and if found includes it in the
.pro file currently being processed.
That makes it a kind of automated version of shared build-include files.
- Without good documentation it feels fragile, hard to compose, and unreliable.