[QBS] Dynamic libraries built with qmake

Christian Kandeler christian.kandeler at theqtcompany.com
Fri May 8 17:09:11 CEST 2015


On 05/08/2015 03:43 PM, Lars Ivar Igesund wrote:
> Hi,
>
> I'm in the process of converting a largish QMake based project to QBS.
> Part of the project are two 3rd party libraries that we have to build
> ourselves, but that comes with .pro files. With QMake this was very
> simple, just subdirs them, but with QBS things are a bit more cumbersome.
>
> What I have done is to create a Module that can do the building, and
> then define a product that depends on that module with the pro-file in
> the files-list.
>
> One feature I wanted, was that when our part of the project depends on
> these qmake-products, then the resulting library files should be picked
> up and automatically linked (as if they were built with qbs).
>
> Currently it works in fresh builds, but there are some quirks and issues.
> 1) I was not able to make the automatic linking work unless I set output
> fileTags to be dynamiclibrary_copy (rather than dynamiclibrary), which
> seems wrong as long as I had to dig in the source to find that
> particular tag.

The copy is what gets linked against. When qbs builds a dynamic library, 
it only updates the copy if the list of global symbols has changed, in 
order to not relink unnecessarily. A better tag name would by 
dynamiclibrary_import, like for MSVC's .lib files.

> 2) When running clean and/or rebuild, things fails for some reason. The
> built libraries are cleaned, but they are not rebuilt. Looking at the
> output, it shows that make says "Nothing to be done".

So qbs is doing its job by calling qmake and make.

 > Maybe this is
> because I don't scan or otherwise set up proper dependencies for these
> projects as a whole? But I would think that since make generates the
> actual library, it should also figure out that its end target is missing.

If make says that its targets are up to date, then the file it believes 
to be the top-level artifact is still there. Possibly some problem 
related to DESTDIR? E.g. qbs has removed the file in DESTDIR, but there 
is a copy lying around somewhere that make considers its output 
artifact? I can only guess here.

> Here is the module, and below a sample product:
>
> import qbs
> import qbs.File
> import qbs.PathTools
>
> Module {
>    FileTagger {
>      patterns: ["*.pro"]
>      fileTags: ["qmake-pro"]
>    }
>
>    Rule {
>      inputs: ["qmake-pro"]
>
>      Artifact {
>        // NOTE: Use a subdirectory to avoid default install behaviour of
> moving then deleting potentially
>        // causing product itself to be deleted

???
Nothing gets deleted when installing.

>        filePath: product.destinationDirectory + "/.build/" +
> PathTools.dynamicLibraryFilePath(product)
>        fileTags: ["dynamiclibrary_copy"]
>      }
>
>      prepare: {
>        var cmds = [];
>        if (!File.exists(product.destinationDirectory))
>        {
>          var mkdirCmd = new Command("mkdir", ["-p",
> product.destinationDirectory + "/.build"]);
>          mkdirCmd.description = "Creating directory " +
> product.destinationDirectory;
>          cmds.push(mkdirCmd);

Should not be necessary, as qbs creates the directory part of artifacts 
itself.


Christian



More information about the Qbs mailing list