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

[Samuel Gaist]

On 30 juil. 2012, at 00:02, K. Frank wrote:

> 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
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

Hi Frank,

Personally, i am using the SUBDIR template for that case.
For example:

- mycoolproject
----- apps
--------myfirstapp
------------src
------------test
------------doc
--------mynonqtapp
------------src
------------test
------------doc
----- libs
--------mycoollib
------------src
------------test
------------doc
--------mynonqtlib
------------src
------------test
------------doc

Using that kind of approach allows you to have a flexible development setup (as well as using TDD to ensure the robustness of your code) . 

All the code you want to reuse goes in a library (Qt or not) and then you application(s) link to these libraries.
In the case where you don't want to "pollute" your installation target, simply build you libraries statically.

For the non Qt application/libraries simply add CONFIG -= qt and you're done, qmake for build system but no Qt involved.

Hope it helps

Samuel