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

[Konrad Rosenbaum]

Hi,

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
> applications).

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 
"archive". ;-)

> 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 
important).

> 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.

> 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.

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.



	Konrad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20120730/ffe6c263/attachment.sig>