[Interest] Organizing multiple Qt and non-Qt "projects" that share code

[K. Frank]

Hello List!

What are some good ways to organize source code -- directory hierarchies,
and such -- that will be used to build multiple Qt and non-Qt applications?

So far when I've written Qt applications, I've had one Qt "project" per
application (where an application is a .exe file), and I've had all of my
source code (including things like .ui files) live together in a single
directory, and I build the application using qmake and a .pro file.

When code is shared between more than one project, I've simply
copied the files (not counting well-organized third-party libraries).

My understanding is that I can't (or that at least it's not recommended to)
use a single .pro file to build multiple targets (i.e., multiple applications).

Now I want to build a suite of applications that will share significant code.
Some will be Qt applications, some non-Qt (portable c++ command-line)
applications, and maybe a few odd and ends like scripts.

If Qt / qmake weren't involved, I would probably put all of the source code
into a single directory, and use make with a makefile that had build
rules for multiple targets.

My preference would be not to use qmake for the non-Qt applications,
so as not to introduce Qt as a dependency, but I could live with using
qmake, if such an approach were otherwise significantly cleaner.  I
would like the benefit of something like make or qmake that knows
how to rebuild only the parts for the target in question and only the
parts that have changed.  I am using mingw-w64 on windows 7.  I
would strongly prefer not introducing additional build tools (e.g., cmake
or ant) or scripting languages (e.g., tcl or perl), but, again, I would
be open to doing so if the payoff were clearly worth it.

How would people suggest I organize the build process for something
like this.

The scale should not be too large -- say five or six applications that
share code, and  dozens, but probably not hundreds of source files.

Thanks for any ideas.


K. Frank