qmake: dependency of application on common shared library

[PeterWurmsdobler]

Hello,

Using Qt Creator 0.9.1 (Qt 4.5.0), I created several projects:

1.) a shared library common to applications using the lib template and stored in projects/common/
2.) two applications using the app template in projects/app*, relying on the shared library to be built if needed and copied into the respective target dir (debug|release).

Is there a place to define dependencies similar to what MS Visual Studio allows with the concept of a solution, i.e. information that goes beyond a single project such as which project depends on what other project as well as automatic pre and post build actions?

The Qt Create's qmake help talks about PRE_TARGETDEPS and POST_TARGETDEPS, DEPENDPATH and target.depends. Unfortunately the explanations are quite brief and I could not derive a solution for this quit simple and standard problem.

Thanks for your help,
peter

[ktk]

Hello,

Using Qt Creator 0.9.1 (Qt 4.5.0), I created several projects:

1.) a shared library common to applications using the lib template and stored in projects/common/
2.) two applications using the app template in projects/app*, relying on the shared library to be built if needed and copied into the respective target dir (debug|release).

Is there a place to define dependencies similar to what MS Visual Studio allows with the concept of a solution, i.e. information that goes beyond a single project such as which project depends on what other project as well as automatic pre and post build actions?

The Qt Create's qmake help talks about PRE_TARGETDEPS and POST_TARGETDEPS, DEPENDPATH and target.depends. Unfortunately the explanations are quite brief and I could not derive a solution for this quit simple and standard problem.

Thanks for your help,
peter

What about creating a .pro with TEMPLATE=subdirs and SUBDIRS=projekt1 path/to/project2 and possibly CONFIG += ordered?

[PeterWurmsdobler]

Hello,

thanks for your answer. I thought about that and discarded the approach as this would only solve the problem of a correct build sequence. There are still two issues:

1.) You would build the top project which builds all, even if you only need one branch project and the referenced shared library.

2.) The library is still not copied from its output dir into the applications output directory.

Cheers,
peter

[seim]

The idea of using top project with subdir + ordered was right. You can have two top project files, both containing the path to your library. And then just parametrize the installation process of the library file (or its header files) with variable, that you set in the top project file.

For example, in the library .pro file you can add:

QMAKE_POST_LINK = make install
list_of_files_to_install.files = interface.h library.so
list_of_files_to_install.path = $$MY_LIBRARY_DEST_PATH
INSTALLS +=list_of_files_to_install

And the top project for your first application just appends:

MY_LIBRARY_DEST_PATH=$$PWD/app1

The same for your second application:

MY_LIBRARY_DEST_PATH=$$PWD/app2


There is no need for magic PRE_TARGETDEPS, ... options. :)

[PeterWurmsdobler]

Hello,

Thanks again for your idea. However, I do not fully agree with this approach as the library pushes the output to its "clients", so it has to know by whom it is being used. This would be like the model has to know about its views in a model/view paradigm.

Another issue is, if you are only interested in one leaf project and the parent project (library) it depends on, you need to compile the top level project, which would compile all leaf projects.

In my opinion, it should be the other way round. If an application requires a library, it should pull it in, even if it means to copy necessary files into the project.

I tried to add an additional build step for the project setting where I copy the .dll from the library path (debug|release) into the respective application build dir. However, it did not work under Windows.

Still searching for a proper solution.
peter

[TemporalBeing]

I'm working in a similar issue though I didn't use Qt Creator.

I have a library stored in one path in Subversion. It's currently being brought into to my project via SVN's externals - but that's beside the point here. Needless to say, it's a shared set of static libraries that multiple applications will be using. Each project it gets brought into needs to ensure that it (or its respective subprojects) get built before the project itself is built. The structure is basically as follows




application\
application.pro
application.sln
application.vcproj
deps\
lib\
lib.debug\
include\
src\
src.pro
<subproject>\
<subproject>.pro
<subproject files>


The src.pro uses the 'subdirs' template, and each project under it puts its output (static library and PRL file) into lib or lib.debug (for release and debug builds respectively). I find this works very well as then the application only has to know about one (or two) places for linking.

I do, however, have the same problem - I want the application to be able to build the static libraries it needs by simply adding something to the application's project file (e.g. application.pro). Thus far I have tried:



include (deps/src/src.pro)


However, that doesn't seem to work and I have to manually run the library build before the applications build. This is complicated by having to support both VS and Qmake/Make (under Linux).

Further, I have numerous static libraries being generated and it'd be nice to be able to only build what I actually need and use.

Per working directly Qt via Visual Studios, I found the following to be helpful to run from a 'build' directory in parallel to the 'src' directory for the shared libraries:



$ qmake -tp vc -r ../src/src.pro


This generates the required solutions and project files, but requires that anyone modifying the qmake project files also update the solutions/projects by re-running this command when they're done and committing the results into source control. Fortunately it can be run on Windows _or_ other systems (e.g. Linux) (Okay for now, but not good as a long term solution.)

As the OP stated - we need to be able to build the dependency. Using the SUBDIR template for the application doesn't seem like a solution - since it would require an entirely different application source layout that just doesn't make sense for the project - I don't need two directories for what could be accomplished in one.

Scripting is problematic as there would have to be a script for Windows and a script for everything else.

I think QMake could easily resolve this solution - whether it already does (if so how?) or by modification to do so. Something like the include solution would be great.

In reading through the docs, the 'features' solution sounds like a good possibility, but it doesn't seem like Qt supports having features in sub-projects in this manner.