[Interest] Organizing multiple Qt and non-Qt "projects" that share code
konrad at silmor.de
Mon Jul 30 10:23:18 CEST 2012
On Monday 30 July 2012 00:02:43 K. Frank wrote:
> 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.
This is fine as long as you don't have too many files. You may reach a point
where a single directory becomes unwieldy.
> When code is shared between more than one project, I've simply
> copied the files (not counting well-organized third-party libraries).
You should organize your code into libraries as well. You can chose between
static and dynamic libaries:
Static is easier to handle - the linker puts all the code into your executable
and you do not need to fiddle with DLLs. I do this with small libraries (only
a handful of classes, not much constant data).
Dynamic saves some memory if your shared code is large enough, but the cost is
that you need to put the DLL at the right place and you may need to add
export/import statements. (see the library Howto in the Qt docu)
> 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
It's difficult to do. Create (at least) one directory per application and
library. Put a .pro into that directory. Put another .pro file into the main
directory that is of TEMPLATE=subdir type and reference all the others from
there. Or use a makefile in the main directory.
> 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.
Put shared build scripts into a specific folder, so they are in a central
place where you can easily find them from any location. Put the shared code
into a library. If you feel uncomfortable with calling it "library" - that is
a good indicator that you should put it into a static library and call it an
> 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.
I often start with a single directory for small projects, but pretty soon re-
organize the sources into sub-directories to make them easier to administer.
Especially if you have generated code that should definitely go into its own
directory (it is easier to delete and less easy to delete something
> 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.
Depends on your definition of "clean". I often mix makefiles and qmake - but
makefiles are harder to port to other platforms.
> 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.
Check what your immediate and potential target platforms are. Check which
utilities exist there. Chose the ones you feel most comfortable with.
Use directories, if named properly they help organize your sources. I found
about 1-3 dozen files per directory is a good size. Sort files by "topic"
(e.g. widgets, data interface, user management, etc.).
Put shared code into libraries - they do not bite. Promised.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the Interest