How do I communicate with a subproject in qmake?

Options

There are three basic channels to choose from

• Shared build-include (.pri) files
• CONFIG
• .qmake.conf

and I discuss the practicalities of each below.

Shared .pri files

Set or add to things like INCLUDEPATH or DEFINES that should affect your whole project in a .pri file. Then use the qmake include function in all the affected .pro files.

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
exists(../myproject.pri){
    include(../myproject.pri)
}

I'm using this for some library code that is being built in-situ by two projects with different needs.

Pros:

• Simple
• Flexible

Cons:

• 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.

CONFIG

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 contains()).

Because 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 SOMEPROJECT_SOMEFEATURE.

Pros:

• Option selections can be set from the command line or the IDE

Cons:

• 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 .pro file you'll have to document the options and what they do.

.qmake.conf

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.

Pros:

• Simple(?)
• Flexible

Cons:

• Without good documentation it feels fragile, hard to compose, and unreliable.

posted over 3 years ago

CC BY-SA 4.0

3y ago

dmckee‭

673 reputation 5 9 80 17