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

Till Oliver Knoll till.oliver.knoll at gmail.com
Mon Jul 30 10:41:01 CEST 2012


2012/7/30 Samuel Gaist <samuel.gaist at edeltech.ch>:
>
> 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?
> ...
> Personally, i am using the SUBDIR template for that case.
> For example:
>
> - mycoolproject
> ----- apps
> --------myfirstapp
> ...
> ----- libs
> --------mycoollib
> ...

That's pretty much exactly how I organise my code (except that I don't
distinguish between an "app" and "lib" folder - they live
side-by-side). In fact, starting with such a directory structure and a
"top-level" *.pro file with the SUBDIR template (you can also define
dependencies therein! It's manual work, yes, but it's worth the
effort: libraries upon which some binary/library depends are build
first - check the qmake documents!).

Here is another tip: I collect all my sources (for each library and
application) into "sources.pri".

For instance:

DEPENDPATH += $$PWD/GeneratedFiles \
                           $$PWD/src

HEADERS += $$PWD/src/UtilsLib.h \
                      $$PWD/src/PaintTools.h \
                      $$PWD/src/Settings.h

SOURCES += $$PWD/src/PaintTools.cpp \
                      $$PWD/src/Settings.cpp


I then have a top-level Translations.pro (at the same level as the
top-level *.pro file with the SUBDIRS template):

# Add all module sources here (except plugins)
include(Utils/Sources.pri)
include(Model/Sources.pri)
include(Resources/Sources.pri)
include(Kernel/Sources.pri
...

TRANSLATIONS = i18n/MyApp_fr.ts \
                            i18n/MyApp_de.ts \
                            i18n/MyApp_ru.ts ...

Once I run "lupdate Translation.pro" I get ONE *.ts translation file
per language (instead of multiple *.ts per library and executable).

That works because all my source.pri file have *relative* paths setup
with that funny $$PWD variable, which expands nicely relative to the
*.pro file which "includes" that sources.pri file (don't ask me how I
found out about that - I think it's an undocumented feature even - and
I always get confused when to use brackets (), or even {}, or double
{{}} - but in this case it seems to *only* work when using *no*
brackets: simply $$PWD ;)) It Simply Works ;)


In a similar way I also setup Common.pri and CommonLibrary.pri which
contains compiler directives common to all executables respective
libraries, a Build.pri which specifies DEBUG defines, version info
etc.. These *.pri files (all sitting in the top-level project folder)
are then included by the respective library/application *.pro project
files.


Cheers, Oliver



More information about the Interest mailing list