[QBS] Dynamic libraries built with qmake
Christian Kandeler
christian.kandeler at theqtcompany.com
Tue May 12 11:03:08 CEST 2015
On 05/12/2015 10:33 AM, Lars Ivar Igesund wrote:
> > 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.
Sure, that's the actual name of the tag. I was talking about what would
perhaps have been a better name.
> > 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?
Not sure. qbs creates as many symlinks as the product's version has
components (up to three). Perhaps qmake's VERSION variable behaves
similarly; you'll have to try.
> And in this case, would I
> have to make an artifact for each to map them into QBS?
Presumably. The tag is "dynamiclibrary_symlink".
> > 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.
Installing has nothing to do with DESTDIR.
Christian
More information about the Qbs
mailing list