Post History

## 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`

This file is automatically treated as part of 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.