Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users

Dashboard
Notifications
Mark all as read
Q&A

How do I communicate with a subproject in qmake?

+4
−0

When working with a qmake subdirs project you may want to share configuration between multiple projects. In a less common case you may including a external project within your own as code and want to configure the build of the included project.

Either way, the solution is to communicate decisions made in the master project to it's subprojects.

But how?

Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

1 comment thread

Clarify scope in title/body (3 comments)

1 answer

+3
−0

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.
Why does this post require moderator attention?
You might want to add some details to your flag.

0 comment threads

Sign up to answer this question »