[QBS] Dynamic libraries built with qmake

[Lars Ivar Igesund]

On Fri, May 8, 2015 at 5:09 PM Christian Kandeler <
christian.kandeler at theqtcompany.com> wrote:

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

If I use dynamiclibrary_import rather than _copy, it doesn't link. With
_copy it links.


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

The reason was versioning, such that I got libFoo.so, libFoo.so.1, etc. It
seems like it is somewhat clumsy to avoid generating the version numbers
with Qmake, although it is possible. I see that this doesn't appear to be
the default behaviour of of QBS - how would I go about getting the symlink
set that Qmake generates? And in this case, would I have to make an
artifact for each to map them into QBS?

Also, is there somewhere I can attach additional or alternative clean
commands? In this case, the end result would probably be easier to get
right if Qmake did the cleaning.

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

If all destdirs are set to nothing, the folder it tries to install the
library from is the same folder that it already has been written to. Then
it deletes the old installed library, before copying the in the new one,
but then it isn't there because the old library was actually tne new one ;)
So, yes, probably caused by how I set DESTDIR when I started on this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qbs/attachments/20150512/c94f5c7a/attachment.html>